I keep getting this error when trying to share my internet connection. "Error 783: The LAN connection selected as the private network is either not present or disconnected from the network..." Can anyone offer me any advice to get around this? The network connection is there and working fine.

Windows 2000's Network Address Translation An inexpensive way to get an Internet connection For years, small office/home office (SOHO) networks have used dial-up modems or ISDN to access the Internet. Compared with newer options such as cable modems and asymmetric digital subscriber lines (ADSLs), dial-up solutions are complex and require you to have a certain level of OS, TCP/IP, hardware, and application expertise. Dial-up solutions also require the costly addition of items such as telephone lines, modems, ISDN connections, and ISP accounts. In Windows 2000 Server (Win2K Server), Microsoft offers you two ways to connect SOHO networks to the Internet: You can use a routed connection or a translated connection. With routed connections, Win2K Server acts as an IP router and forwards packets from SOHO clients to the hosts on the Internet. Routed connections let servers forward all IP traffic to the Internet. However, setting up routed connections requires knowledge of IP networking and routing. With translated connections, Win2K Server acts as an IP router and translates packets from the SOHO hosts to the Internet hosts. Unlike routed connections, translated connections might not permit servers to translate all IP traffic. In Win2K Server Release Candidate 2 (RC2), build 2128, you can use Microsoft Internet Connection Sharing (ICS) or Network Address Translation (NAT) to configure translated connections to the Internet. ICS is a feature of the Network and Dial-Up Connections tool. NAT is a routing protocol that you configure through the Routing and Remote Access window, which Screen 1 shows. NAT is Microsoft's variation of the Internet Engineering Task Force's (IETF's) Network Address Translator standard, which provides Internet connectivity in a simple, flexible, and inexpensive way. Microsoft uses the term ICS for what the company called Shared Access and uses the term NAT for what the company called Connection Sharing in early builds of Win2K Server. The main purpose of the ICS and NAT services is to share a network connection that acts as a gateway or router to provide transparent Internet connectivity to clients on one subnet. The clients on the internal network don't need modems, extra phone lines, or valid IP addresses to directly connect to the Internet. The clients can simply proxy through the NAT server to access the external network. NAT Background In Request for Comments (RFC) 1631, the IETF describes several variations of Network Address Translator. The variations include traditional Network Address Translator, two-way Network Address Translator, twin Network Address Translator, host Network Address Translator, and host Network Address Port Translation (NAPT). Traditional Network Address Translator lets hosts on a private network (e.g., a LAN) access hosts on an external public network (e.g., the Internet). Traditional Network Address Translator permits only outbound sessions from the private network to the public network. A two-way Network Address Translator, as its name suggests, permits sessions in both directions: inbound and outbound. Twin Network Address Translator lets you change information in both the source and destination IP address fields, so you use twin Network Address Translator when address assignments between disparate domains overlap. Host Network Address Translator and host NAPT let you use security mechanisms such as IP Security (IPSec) and DNS Security (DNSsec) in a Network Address Translator environment. Microsoft's implementation of NAT in Windows 2000 (Win2K) fits somewhere between a traditional Network Address Translator and a two-way Network Address Translator. Microsoft has added many more features to its flavor of NAT to make it easier to use. Internet Connection Sharing Let's take a closer look at Microsoft's ICS service in Win2K as a method to translate packets for Internet connectivity. Depending on your situation, you might prefer ICS to NAT. You can think of ICS as NAT light. To configure ICS, you simply select a check box to enable shared Internet access. Keep in mind that ICS and NAT are mutually exclusive—you can't run both on the same machine. Although these services have a similar purpose, NAT has some functions that ICS doesn't have. For example, you can't configure multiple public IP addresses in ICS, and ICS doesn't support WINS proxy agents. The ICS clients use mixed-node NetBIOS for name resolution on a SOHO network. The purpose of ICS is to let your clients on the internal network have transparent access to the Internet. You don't need to be a network guru to set up ICS. To set up an ICS server, your ICS computer must have at least two interfaces. One of them must be a NIC, and the other can be any other interface (e.g., dial-up adapter, Digital Subscriber Line—DSL—adapter, another NIC, ISDN adapter). You enable ICS on the external interface. When you configure the external interface for ICS, you automatically configure the internal interface on the ICS server with the IP address 192.168.0.1 and a subnet mask of 255.255.255.0. You also configure the clients to obtain an IP address from a DHCP server. The ICS server automatically assigns IP addresses to the private clients from the class C network range (i.e., 192.168.0.0 to 192.168.255.255), and the clients automatically obtain the IP address of the ICS server for DNS name resolution. None of these parameters on the ICS server are configurable. Therefore, you can't disable DNS proxy services, modify the range of client-assigned IP addresses, configure port mappings, or disable the DHCP allocator. Table 1 shows a typical ICS client configuration on a private network. To configure ICS for a dial-up connection in Win2K, select Start, Settings, Network and Dial-Up Connections. Next, double-click Make New Connection. Using the Network Connection Wizard, select an appropriate Network Connection Type, as Screen 2 shows. For example, you can choose Dial-up to private network (and you'll need to enter a number in the Phone Number to Dial dialog box). The Connection Availability dialog box gives you two options for the connection: For all users or Only for myself. In the next dialog box, select the Enable Internet Connection Sharing for this connection check box, as Screen 3 shows. To configure ICS, you need to set the LAN adapter on the private network to 192.168.0.1. A pop-up message warns you of the consequences of other clients on your SOHO network using a different address range. To configure ICS on your machine, click Yes. You want to enable ICS only on the external interface. Incorrect configuration of ICS can cause clients outside your SOHO network (e.g., other DSL users in your neighborhood) to obtain IP addresses from your DHCP allocator. If you no longer want your computer to serve as an ICS server, you can go to the network interface's Properties dialog box, select the Sharing tab, and clear the Enable Internet Connection Sharing for this connection check box. If you're running a small network and can't afford to hire a network administrator, you can easily configure ICS and access the Internet from your network clients without knowing much about TCP/IP, DNS, WINS, or browser configuration. SOHO businesses can benefit from such a solution. But if you want more control of your environment, you need to use NAT instead of ICS. Network Address Translation NAT offers all the features that ICS offers, and more. NAT keeps track of the address and port translations for outbound connections so that the proper clients on the private network receive the packets back from the external network. To provide address translation for the internal clients on a network, NAT translates the private IP addresses in the IP headers to a single public address. The clients access the Internet transparently without requiring additional software. The NAT server acts as a router and can also translate TCP or UDP ports for the clients. This approach might sound similar to the services that Microsoft Proxy Server offers. The two services have some differences, but they offer similar functionality and a NAT server isn't an alternative to Proxy Server. To install NAT in Win2K, select Start, Programs, Administrative Tools. Open the Routing and Remote Access window, add your server, right-click the server name, and select Configure and Enable Routing and Remote Access. After you install RRAS, the program prompts you to start the service. After you start, go to IP Routing and right-click General. Select New Routing Protocol, select Network Address Translation (NAT), as Screen 4, page 143 shows, and click OK. Next, under IP Routing, right-click Network Address Translation (NAT) and add the interfaces (at least two). Figure 1 shows a typical SOHO configuration with two NICs. The internal interface represents the private NIC and uses a static IP address of 192.168.0.1 to connect to the network. The external interface represents the public NIC and uses a DSL connection to an ISP using a static IP address to the Internet, such as 10.10.10.1 (this example address isn't valid on the Internet). Generally, your ISP assigns this static IP address. To configure an external interface from the interface's Properties dialog box, select the General tab, choose Public interface connected to the Internet, and click OK. To configure an internal interface, select the General tab, choose Private interface connected to private network, and click OK. These two options are mutually exclusive. Now you're ready to configure additional options for NAT. After you right-click Network Address Translation (NAT) and select Properties, four tabs are available for configuration: General, Translation, Address Assignment, and Name Resolution. The General tab has four logging options that are fairly self-explanatory. These options provide levels of logging to Win2K's Event Viewer. The Translation tab lets you set TCP and UDP session timeout values and specifies how long a dynamic mapping for a TCP or UDP session remains in the NAT server's internal routing table. The default for connection-oriented TCP sessions is 1440 minutes (24 hours), and the default for connectionless UDP sessions is 1 minute. The Address Assignment tab, which Screen 5 shows, lets you automatically assign IP addresses to your internal clients. When you select the Automatically assign IP addresses by using DHCP check box, you enable the DHCP allocator. Screen 5 shows the NAT server with a static IP address of 192.168.0.0 and a subnet mask of 255.255.255.0. To avoid duplicate IP addresses on your internal network, you can use the Exclude option to exclude a range of IP addresses that are already in use on your private network. Microsoft suggests you add the NAT server's IP address (e.g., 192.168.0.1) to the list of reserved IP addresses. The Address Assignment tab gives the impression that you need a DHCP server on your private network because the dialog box says that you're configuring this option to use DHCP for automatic address assignment. In fact, you don't need a DHCP server on the private network. When you select the Automatically assign IP addresses by using DHCP check box, you enable a DHCP allocator that functions as a limited DHCP server. The Name Resolution tab lets you resolve names to addresses for either Windows or TCP/IP networking clients. The NAT server can act as a DNS or WINS proxy agent for your private clients. The WINS proxy service that the NAT server offers isn't the same as the WINS proxy service available in Windows NT versions. NAT automatically configures the clients with the NAT server IP address as their WINS server. In a SOHO network, the WINS server address will be 192.168.0.1, which Table 1 shows. The second difference is that the clients merely think that the server is their WINS server. The NAT server will query the WINS server set in its IP configuration and return the results to the clients. (The client queries the WINS server and doesn't register its address with the WINS server.) The WINS proxy service in NAT drops clients' name registrations, so the records don't stay in the WINS database. Because your clients never register with the WINS server on your private network, you might not be able to connect to a private client by name (e.g., \\server\sharename). Therefore, you must have a method to resolve names on the private network. One solution is to use IP addresses instead of names to connect to other machines (e.g., \\192.168.0.3\data). Another option is to use the LMHOSTS file. I prefer to use DHCP to assign a WINS address to a client. The DNS proxy works similarly to a WINS proxy in which the clients send DNS queries to the NAT server. To respond to the client queries, the NAT server queries the DNS server set in its IP configuration (e.g., an ISP's DNS server) and returns the results to the clients. Unless you enable this option, the clients on the private network won't be able to resolve host names on the Internet (unless you have an alternative method in place to provide name resolution). You can make your NAT server a DNS server. In case your server can't resolve the DNS queries, you want to configure your DNS server to forward requests to another DNS server, such as an ISP's DNS server. Correction "Windows 2000's Network Address Translation" incorrectly states that to use the DHCP server on your Windows 2000 (Win2K) server instead of enabling the DHCP allocator, select the Automatically assign IP addresses by using DHCP check box. You need to clear that check box. DHCP Allocator NAT and ICS include a DHCP allocator that acts like a DHCP server. The DHCP allocator leases IP addresses to the clients from the range that you configure using the Address Assignment tab. Think of the DHCP allocator as limited DHCP (or DHCP light). Unlike DHCP server, the allocator doesn't have a configurable database. All DHCP allocator parameter configurations are automatic, including DNS and WINS proxy. You can use any range of IP addresses on the internal interface with the DHCP allocator, but I recommend that you use only nonroutable private IP address ranges, which RFC 1918 defines. The default network ID range in NAT is an area in which Microsoft made changes in the Win2K beta releases. Early builds used a class C address range. In later builds, Microsoft decided to use a class B private network ID range (169.254.0.0 to 169.254.255.255). Microsoft switched to this class B range because the Win2K and Windows 98 clients use this range for auto-IP configuration, and when NAT uses this range, communication is easier. In Win2K RC2, Microsoft returned to class C as the default IP address range, as Screen 5 shows. The DHCP allocator issues clients several IP configuration options. Table 1 shows a default configuration for a NAT client on a private network. You can right-click Network Address Translation (NAT) in the Routing and Remote Access window to view the DHCP allocator or DNS proxy information. You can also use the Netsh command to administer IP settings. For example, you can run Netsh, then type routing ip autodhcp show global to see the DHCP allocator configuration information. You can run Netsh, then type a question mark to see the available options. What if you want to use DHCP server on your internal network? Does using DHCP cause any conflicts? If you have routers, DNS servers, or DHCP servers on your network, you might run into some problems. The NAT server will try to detect these competing services, and if successful, it will shut down its services. The NAT server uses Internet Control Message Protocol (ICMP) Router Solicitation and DHCP Discover packets to detect these services. To use the DHCP server on your Win2K server instead of enabling the DHCP allocator, select the Automatically assign IP addresses by using DHCP check box. I prefer to use a DHCP server for several reasons. A Win2K DHCP server can dynamically register earlier-version clients with Win2K's dynamic DNS (DDNS) server. A DHCP server also offers control over DHCP options that the DHCP allocator doesn't offer, such as providing a domain name to the clients or changing the IP lease period. You can also assign a different DHCP or WINS server. Using DHCP to assign a WINS server to clients provides easier name resolution for internal clients. If you use the WINS proxy service (instead of using DHCP options to give a WINS server's address to clients), the clients don't register and the service can't resolve names. If you set a WINS server's address as part of the DHCP options, the clients register with the WINS server, and name resolution becomes transparent. When using a DNS server, I use DHCP options to provide the IP address of my ISP's DNS server to my private clients. To use a DHCP server instead of the DHCP allocator, select the Address Assignment tab from NAT Properties, clear the Automatically assign IP addresses by using DHCP check box, and install DHCP server on your internal network. For a SOHO environment, the NAT server can also serve as a DNS, WINS, and DHCP server. You can configure the clients to obtain IP information from a DHCP server. Table 1 shows a default client configuration using a DHCP server. Packet Translation The NAT server needs to translate all packets from a nonroutable IP address range on the private network to a valid IP address on the Internet. The server can transparently translate packets that contain IP address, TCP port, and UDP port information in the IP, TCP, and UDP headers, respectively. If the application contains the IP address, TCP port, or UDP port information in the application's header (instead of the IP header), the NAT server might not be able to properly translate these packets, such as FTP packets. A NAT editor component can properly translate packets that your NAT server can't otherwise translate. For translation, NAT servers require that packets have an IP address in the IP header, TCP port numbers in TCP header, and UDP port numbers in the UDP headers. All other packets require a NAT editor. HTTP doesn't require a NAT editor because HTTP requires translation of an IP address in an IP header and TCP port in a TCP header. PPTP doesn't use a TCP or UDP header. Instead, PPTP uses a Generic Routing Encapsulation (GRE) header. The tunnel ID in the GRE header identifies the data. If NAT is unable to translate the tunnel ID within the GRE header, you'll experience connectivity problems. Because NAT can't translate tunnel ID for PPTP packets, you need a NAT editor for proper translation. Win2K comes with built-in NAT editors for FTP, ICMP, and PPTP. Microsoft plans to make NAT editor APIs available to third-party vendors to develop additional NAT editors. Currently, no NAT editors are available for IPSec, Lightweight Directory Access Protocol (LDAP), COM, remote procedure call (RPC), or SNMP. To use encrypted applications or applications that don't contain the IP addresses in the IP headers, you can use PPTP to tunnel through the server. Layer 2 Tunneling Protocol (L2TP), which comes with Win2K, doesn't require a NAT editor, so you can transparently use L2TP. However, you can't use L2TP with IPSec because the server can't translate the packets (IPSec doesn't have a NAT editor). Although you can't use IPSec for security with NAT, you can use Secure Sockets Layer (SSL) to encrypt Web-based applications. You can't authenticate to a Win2K domain controller across a NAT server because the NAT server doesn't translate Kerberos 5 packets, which Win2K domain controllers use. Address and Port Translation NAT lets you translate specific addresses and ports. Typically, the NAT server performs address and port translations. You can also configure the server for address mapping, rather than translation. With address mapping, you can map the private internal addresses to a pool of public Internet addresses. This method is more scalable than the address and port translation method. Address mapping lets you map multiple incoming connections to the same port or service. However, address mapping is fairly complex and requires your ISP to add static routes for the pool of IP addresses that your NAT server uses. You can use the Address Pool tab of an interface's Properties dialog box to configure the server to use address translation mode. For example, you can define an address range to configure a pool of addresses. Then, clients will dynamically use a unique public address from this pool, unless you reserve certain addresses for specific machines. Reserving an address is a way to provide connections from the Internet to your private network. You can also use special port mapping by selecting the Special Ports tab of the interface's Properties dialog box, as Screen 6 shows. TCP packets arriving from the Internet on Public Port 80 of the Interface's address will be directed to Private Port 1080 of a client that has an IP address of 192.168.0.25. In addition, the TCP packets arriving on Public Port 20 will be directed to Private Port 2121 of 192.168.0.25. Comparing NAT with ICS and Proxy Server ICS is simple to configure and requires you to select only one check box. NAT's manual configuration requires more expertise. In a SOHO network, you can use ICS with one LAN adapter. The second interface can be a modem. You typically use a NAT server with multiple interfaces. With ICS, you can use only one public IP address. NAT supports multiple public IP addresses. ICS supports only a fixed range of IP addresses (e.g., 192.168.0.0 to 192.168.255.255) for clients on the private network. NAT allows a range that you can configure to suit your needs. Finally, NAT offers support for both DNS and WINS proxy services. ICS supports only DNS proxy services. NAT and Proxy Server offer similar functionality. Both services let a small private network or SOHO network use one machine as a proxy to transparently connect to the Internet. With NAT, you don't need to install or configure additional software. The only stipulation is that the clients must be DHCP-aware (i.e., configured to obtain an IP address from a DHCP server). With Proxy Server, you need to configure the clients' browsers to use the proxy server. The only exceptions are Win2K clients that can automatically look for a proxy server and self-configure the client's browser. Proxy Server can be more expensive for SOHO networks, so you'll have to consider the trade-offs. In large or secure environments, Proxy Server might be a better choice because of its superior filtering and caching capabilities. However, for home businesses or smaller networks in which security requirements aren't as stringent, NAT seems to be a better choice because of its simplicity, cost, and ease of administration. I prefer NAT for several reasons. The main reason is that NAT lets me use PPTP from a NAT client to connect to a corporate network on the Internet, which gives me secure access to my corporate network for transferring files, using a Microsoft Outlook client, printing, or running custom applications. A proxy server doesn't let a proxy client use PPTP to tunnel through a proxy server. You can use a proxy server only to make a PPTP connection to your corporate network. Similar to Proxy Server, the NAT server still gives you the ability to use SSL transparently from any client in a SOHO to do many things, such as trade stock, bank online, or run Web-based e-commerce applications. NAT also offers a certain level of security. Troubleshooting NAT If your clients can't get an IP address from the NAT server, verify that you selected the Automatically assign IP addresses by using DHCP check box. If your server can't translate the addresses, verify that you properly enabled the translation on both interfaces. Check the internal interface's Properties dialog box to ensure that you selected Private interface connected to private network, and check the external interface's Properties dialog box to ensure that you selected Public interface connected to the Internet. Also, check the status of the interfaces in the Routing and Remote Access window. The Status column should show Enabled, and the Connection State column should show Connected. If an application doesn't work through the NAT server, try to use the application on the NAT server. If the application works from the NAT server but not from the private network, it might require a NAT editor. I find that naming my public interface and private interface is useful. To name your interfaces, go to Start, Settings, Network and Dial-Up Connections. You can also select Show icon in taskbar when connected from the General tab of the interface's Properties dialog box. Naming your interfaces will help you monitor all your active connections easily. When you move your cursor to an interface icon in the taskbar, the icon will show you the name of the interface, the speed of your connection, and the number of packets sent and received. The interface icons blink during packet transfer and other activity. If you can't use a NetBIOS name to connect to another computer on the internal network, use an IP address or make sure you have a static name-resolution method. You can use the LMHOSTS file, but using a DHCP server might be a better choice. If you're using a DHCP server on the private network, don't forget to turn off the DHCP allocator. NAT Is All You Need NAT will probably become a favorite feature for many Win2K users. NAT is an efficient, simple, reliable, and inexpensive solution to Internet connectivity for branch offices and small networks. NAT is beneficial for several reasons. The ability to use PPTP is a big plus, and the filtering capabilities, port translation, and on-demand dialing are extra bonuses. The ability to add NAT editors in the future makes this service even more attractive. If you've been looking at Proxy Server and third-party solutions, you might want to check out Win2K's NAT server. You might discover that NAT is all you need. Correction "Windows 2000's Network Address Translation" incorrectly states that to use the DHCP server on your Windows 2000 (Win2K) server instead of enabling the DHCP allocator, select the Automatically assign IP addresses by using DHCP check box. You need to clear that check box. DSL Architecture Hardware White Paper Designing Hardware for the Microsoft Windows Operating System The Microsoft End-to-End Architecture for Digital Subscriber Line (DSL) DRAFT: April 28, 1999 Note We are actively seeking feedback on the architecture presented in this document. For comments or questions, please email: dslfb@microsoft.com Executive Summary Guiding Principles and Motivation Microsoft has a vision of the Web Lifestyle, where everyone is able to make fast, reliable access to information a part of everyday life. To enable this vision, a massive rollout of broadband technology is needed for residential users. Such rollouts require a strong business case, stable standards, appropriate pricing, confidence of consumers, and a workable regulatory framework. There are several technologies offering potential solutions for the “last mile” delivery of broadband services between public networks and end users. These include telephone lines, TV cable, fiber, wireless, and satellite systems. The jury is still out on which will be the dominant technology, and in all probability several solutions will continue to develop in parallel. Services to Support The primary services of interest today are seen as: · High-speed Internet (ending the “World Wide Wait”) · Additional telephony lines (second line on same pair, and so on) · Specialist broadband services (for example, Video on Demand) The priority between these varies around the world and from provider to provider. For example, cable companies find telephony compelling, while the driving force for major DSL rollouts in Asia has been Video on Demand. This is in contrast to the concentration on high-speed Internet by the North American telephone companies. A coherent architecture is required that supports all of these services and which offers each individual user a choice of providers. Definition of Terms Careful, clear terminology is required for this discussion. Many ISPs have high-capacity connections to the Internet backbone providers, and many of them offer T1, T3, or even higher service rates to corporate customers. This is not a “broadband” service as described in this document. Broadband Information and Communication Services to end-users that exploit high-bandwidth capabilities (1Mbit/s and up). These services are typically offered to consumers over ADSL or cable modem networks. Broadband ISP An Internet Service Provider equipped and prepared to provide broadband services to end users. Broadband Services Applications and information services that require a broadband connection to function. Examples include full-screen video playback, and new application purchase and installation. A Broadband ISP may offer Broadband Services within its own ‘walled garden’ available only by direct connection. Walled Garden A collection of content specially tailored or enhanced for a specific group of users. For example, AOL has a lot of content available only to subscribers to the service. In the context of broadband services, this is content intended for broadband-equipped users, so that they enjoy a richer experience than is available to users outside of the subscription group. Content within the walled garden may contain a much higher quantity of video and graphic images than a regular web site, and can take advantage of low-latency and low-jitter connections to the customer’s machine. End-to-End Architecture Following on from the successful studies in the ADSL Forum, Microsoft is advocating a network and service architecture based on using PPP over ATM over ADSL. This allows considerable freedom of design implementation within the home, while maintaining a common interface for all service providers. The key advantage of PPP over ATM is its ability to support many different service providers simultaneously from the same DSL access network, even within the same home. Figure 1 End-to-End Architecture Microsoft Contribution Microsoft is committed to the success of DSL deployments and is making efforts in many ways to ease the difficulties associated with such a large-scale enhancement to the world’s telecommunications environment. The Microsoft® Windows® 2000 product line includes many of the capabilities required to build and support DSL networks. In particular: · Microsoft Windows 2000 includes PPP-over-ATM client support, allowing users to connect using ATM PVCs or SVCs using the DSL network interface card (NIC). · Microsoft Windows 2000 Server supports incoming calls (SVC or PVC) to a public ISP or to a corporate network, including authentication of calling users by RADIUS or Windows NT Domain Security. · Microsoft Media Services allow the creation, management, and distribution of compelling broadband video and audio content. The Theatre Service is specifically designed to take advantage of ATM networks and has been successfully deployed on DSL network for delivery of Video on Demand. · Microsoft Windows 98 gains PPP-over-ATM support in OEM Service Release 1 (OSR1), enabling standards-based large-scale deployment of DSL in the near term. Standardization Microsoft has been a driving force for several years behind the developing standards for residential broadband services. Microsoft has Principal Membership in both the ADSL Forum and the ATM Forum, and is one of the founding “Promoters” of the Universal ADSL Working Group. Microsoft has shared its expertise in client and server systems, and has worked on a number of pre-competitive collaborations to accelerate the “crystallization” of industry-wide standard solutions. The End-to-End Architecture for ATM over ADSL (ADSL Forum TR12), the IETF standard for PPP over ATM [1], and the ITU’s Recommendation G.992.2 (Universal ADSL) are the result of such joint activities between Microsoft and other major industry players. Evangelism Microsoft continues to spend considerable effort in promoting the benefits of broadband and the Web Lifestyle. In their speeches, Microsoft senior executives continue to reinforce the public perception that Microsoft is committed to enabling broadband service for everyone, not just for large corporations and big spenders. Industry feedback Microsoft welcomes comments and questions regarding this document. Please email your feedback to dslfb@microsoft.com. Architectural Areas The End-to-End architecture spans a number of network areas and impacts the design of each one to some degree. These divisions are largely for ease of comprehension. However, there are regulatory reasons that require some of this separation, and it is important to understand the consequences. DSL Access Network The access network includes the DSL terminations both within the home and the public network (ATU-R and ATU-C respectively). The ATU-R is commonly called a “DSL modem,” and the ATU-C is commonly called a “DSLAM” (DSL Access multiplexer). By convention, the term “Access network” may also include an ATM access switch for grooming DSL traffic onto the appropriate core network(s). Broadband Core Network The broadband core network provides connections between multiple Access Networks and multiple Service Providers. This architecture is assumed to be an ATM-based core network, using both PVCs and SVCs. A valid core network might cover a single metropolitan area or could extend across state or international boundaries. The geographic extent of the core network does not affect the functionality it provides, and may be determined by economic and regulatory factors. Broadband Internet Service Providers Broadband ISPs are distinguished by the broadband services they provide to individual subscribers, rather than specialized services offered to specific customers such as large corporations. A broadband ISP provides high-speed access to the Internet, and supports those technologies that allow an individual user to make use of this effectively—for example, pro-rata billing, Quality of Service1, caching for broadband services, enhanced content, and so on. Broadband Access to an Enterprise For the enterprise, the discussion focuses on the connection of an enterprise directly to the broadband core network, avoiding the vagaries of Internet and ISP service. This is of particular interest when supporting high-capacity telecommuters. Pure Broadband Content Providers In addition to ISPs providing a gateway to the Internet, broadband opens the possibility of directly providing broadband services to customers. Classic examples include Video on Demand, which has driven much of the DSL deployment in Asia. Many broadband ISPs may choose to add value to their Internet service by offering these pure broadband services as well. Broadband within the Home The architecture of the network within the home has a direct relation to the overall end-to-end architecture. This is further discussed in the section “Broadband in the Home,” and there are several companion papers that deal with the issues of in-home networking and connection sharing. Protocol Architecture Reference Model Microsoft bases the entire architecture on the central concept of PPP over ATM at the ‘U’ reference point. Reference points are a holdover from the ISDN standards process, and can be summarized for DSL as shown in Figure 2. Figure 2 Architectural Reference Points The U reference point is critical, as it defines the point of physical connection between the DSL modem in the home and the DSL provider. Within the home there may be various forms of S, T, or coincident S/T interfaces, so long as the protocols exposed to the network at the U reference point are standard between providers and between home network vendors. The V reference is internal to the public network and is not usually standardized outside of Europe. ETSI has defined the family of V5 interface(s) and protocols at this point as a regulatory requirement in ETSI territories. Protocol Stacks Figure 3 shows the protocol stacks required for compliance with this architecture. This diagram simplifies the situation somewhat, as it shows a single directly-connected PC as the client. In practice, the in-home network is usually more complex, as discussed in the section “Broadband in the Home” later in this document. Also hidden are the layers underlying the ATM and IP networks, as these have no real impact on the architecture in this discussion. For example, the ATM service may run over (for example) plesiochronous DS3 links or SONET OC3, with individual providers making their own decision on how to connect to the ATM backbone. The same applies to the IP network, which may be wholly transported over private network connections, go via the Internet, or be physically connected directly in some other way. Figure 3 Basic End-to-End Protocol Architecture In Figure 3, the U reference point falls between the DSL Client box and the Telco Network box. The S and T reference points fall within the DSL Client box, and the V reference point falls within the Telco Network box. As such, the S, T, and V reference points do not generally require standardization. The functions performed by each protocol are as follows: Function Protocol Switches user packets through the public network to the point of presence (POP) of the service provider chosen by the user. Many different service types can be carried on the ATM layer. ATM Segments and reassembles user packets sent over the ATM network. Error checking is performed at this layer to ensure accurate delivery and arrange for retransmission if necessary. AAL52 Runs between the client and the Service Provider (shown as an ISP POP in Figure 3). This provides an authenticated “login session” for the user, and provides the client computer with the IP configuration to use. PPP Handles the delivery of data packets between the client and the applications it is accessing. This may include services running locally at the ISP or accessed from a content provider across the Internet. IP Figure 4 Service Providers A combination of service providers is needed to put together an end-to-end broadband service: Requirement Component Must be provisioned and installed. DSL access network Must provide interconnection between DSL customers and their chosen ISPs or Enterprise(s). Switching provider Must generate compelling content to read, see, watch, and listen to, either as Web services or using Native access to the switched network (AOL could be regarded as a native service – much of the content offered does not require IP or HTTP). Content providers Note on Protocol Layering Several sections of this document make mention of protocol “Layers” in terms of the OSI 7-layer model. However, this is not a very exact match for the functions provided on the DSL architecture. Therefore, the following definitions as used in this discussion are included for clarity. · Layer 1 is used to mean the physical layer protocol, which determines how the data bits are electrically conveyed across the copper wire (DMT for DSL). · Layer 2 means the protocol used to switch user data to a specific service provider (ATM in this case). The OSI model doesn’t really allow for switching at this layer, although it is common practice in real-world networks such as Ethernet (MAC Layer), POTS, ISDN, and ATM (call control). · Layer 3 means the routing protocol used to direct traffic between service providers. For the Internet, this will always be Internet Protocol, although for some telecommuting cases IPX or NetBEUI will also be considered as Layer 3 protocols. In between Layer 2 and Layer 3 is a form of “session” layer that allows a user to connect as an authenticated user of a specific service provider. In this architecture, PPP is used for this function. This should not be confused with the OSI Session layer (Layer 5), which is more concerned with application sessions than with a session giving access to the network. An OSI style session layer would be beyond the scope of this document. As defined for this document, when reference is made to specific layer, direct comparisons with the traditional OSI model are unreliable at best. DSL Access Network The Access Network comprises the “last mile” of DSL service delivery, and the interconnections to the home network and core network at either end. Through the Access Network, home users gain their ATM connection to the core network. The “modem” in the home may be provided by a service provider (loaned, leased, or rented), or purchased and owned by the consumer. This will vary from market to market. The former is more common at present, but developments such as “splitterless modems” and DSL-ready PCs should make the latter case dominant within a few years. The network end of a DSL connection requires a DSLAM (ATU-C) to be located at the CO or DLC (see below). The DSL service provider will own the DSLAM. Figure 5 DSL Access Network Figure 6 Combined Architecture of Home and Access Networks Note The “PCI bus” connection shown above indicates an internal (PCI) NIC card to terminate the DSL service inside the PC. Copper Pair The copper pair itself will be owned and installed by the ILEC3 or a regional equivalent such as a European PTT. In early 1999, there are no other companies interested in digging the street to install additional copper wire to residential customers. In many cases, this phone wire will also carry voice telephony. A CLEC or other carrier wishing to install their own DSLAM equipment will typically have to buy an “unbundled” copper pair from the ILEC—that is, a phone line with no phone service provided. This may be practical for some business services or where there are plenty of spare copper lines in the ground, but it is an unlikely model for wider scale deployment to typical residential customers. DSL Signal on the Wire Phone companies (ILECs) are not required to provide spectral unbundling, and it’s technically very difficult to implement. In other words, they have control over all of the signals sent down a wire at any frequency. The upshot of this is that they will often provide the DSL service on the copper pair as a supplement to POTS telephony service. This DSL service may then be sold wholesale to another provider (such as a CLEC or ISP), but the key point is that the DSLAM (ATU-C) will still be owned by the ILEC. Use of the DSL service may then be sold wholesale to another provider (such as an ISP) who will offer the complete bundle of service as a package. If the CLEC or ISP wants to operate its own DSLAM, it will be forced to buy unbundled copper loops as discussed in the provision section. There are a number of proprietary DSL protocols and formats on the market today. Although some of these have interesting technical merits, Microsoft strong supports the use of standard Discreet Multi-tone (DMT) as the ADSL line coding. In particular, Microsoft supports ANSI T1.413 (or ITU G.992.1) as the line coding for full-rate ADSL, and ITU G.992.2 for splitterless (Universal) ADSL. Microsoft recognizes that there are some situations where alternative technologies are required, and work is proceeding in the ADSL Forum on the use of Symmetric DSL (SDSL), Very-High-Speed DSL (VDSL), and other related technologies. Once ITU standards are determined for these, they will probably become an important part of the broadband environment. DSLAM Location We use the term DSLAM loosely. Other forms of “DSL Access Node” are equally acceptable to Microsoft, provided they adhere to the functional requirements. Examples of other Access Node types include DLC and Telephone line card solutions. However, DSLAM is the most commonly used term across the industry and in the press, so we will stay with it for now. The type of copper pair wiring in a geographic area determines the physical location of a DSLAM. Copper pairs in the telephone network are either connected continuously between a consumer and the CO, or they pass through an intermediate loop. In North America, the copper pair has traditionally been brought directly from the consumer back to the nearest Central Office (CO) of the Phone Company. The DSLAM needed to terminate these copper lines is located at the CO. This could be an external unit, or the DSLAM functionality could be integrated with the existing telephone switch. In areas with new or significantly extended wiring, Digital Loop Carriers (DLCs) have replaced traditional direct wiring. A DLC terminates the copper pair in the street, usually quite close to the home, and carries the signal back to the CO over fiber. The DSLAM needed to terminate these copper lines is located at the DLC, or works as an integral component of the DLC itself. This imposes strict requirements on space, power, remote management, and rack fittings for the DSLAM. However, it has the advantage of offering shorter copper pairs to the home than in many traditional phone networks. DSLAM Aggregation A single DSLAM can handle a few tens or hundreds of DSL lines. Because of the cost of providing access to the core network, it can be expensive to directly connect each DSLAM to the core network, so there is usually a “concentration” stage added. Some DSLAMs can be “daisy chained” together, with a small group connecting together onto a single OC-ATM port of a core switch. Others are aggregated using a small “access” ATM switch. Often this switch also provides the signaling and call-control for SVCs. This document does not claim to be exhaustive on DSLAM configuration and architecture, and readers are directed to the various DSL equipment vendors who will be able to give details of their own architectural approaches. SVC Capability in the Access Network For efficient use of SVCs, Microsoft recommends the use of SVC-aware DSLAM technology (for example, the Fujitsu SPEEDPORT). This provides ATM ILMI and UNI Signaling directly on the DSLAM itself, with the DSLAM being aware of the dynamic connections and allocating bandwidth and QoS resources within its own capacity. This maximizes the use of resources within the DSLAM and the connection to the Access switch (if any), and requires only a single instance of the UNI protocol on each port of the Access Switch. For those DSLAM installations that do not support local UNI Signaling for SVCs, there are two options: · In North America, the solution must rely on provisioning of Permanent Virtual Paths through the DSLAM, terminating as a Virtual UNI on the Access switch. This arrangement is an inefficient use of Access Network resources and is far from flexible for QoS support, but is adequate for supporting up to about 250 DSL lines per ATM switch port with sufficient over-provisioning. The ATM switch hosting the DSLAM is required to support UNI 4.0 signaling capabilities, and requires huge signaling capacity, which eliminates this approach for anything larger than small trials. · In the European context, Vb5.2 [6] connection control can be used between the DSLAM and the Access switch. This allows the signaling to reside on the switch, while enabling dynamic control of DSLAM resources using the Vb5 connection control protocols. The DSLAM effectively becomes an extension of the switch for resource control purposes. However, the Access Switch still needs to support a very large number of UNI signaling associations. Both the Virtual UNI and Vb5.2 architectures produce an increased signaling load on the Access Switch, hence the Microsoft preference for signaling support on the DSLAM. DSL Power Management In high-density DSL environments, especially those supporting large numbers of G.992.2 (Universal) ADSL modems, the power consumption at the DSLAM is an important factor in determining rack density and therefore cost of providing the service. G.992.2 provides for reduced power levels of the ADSL line during idle times. Also, current EPA requirements for Energy Star require PCs to reduce power when inactive. Both of these requirements impact on the traditional and oft-stated ability of DSL to provide an “always on” service. In practice, power management and “always on” are mutually exclusive conditions. The choice between “Always On” and “Always Available” is an opportunity for differentiation between service providers, and that both approaches have valid applications in the real world. The Universal ADSL Working Group (http://www.uawg.org) developed the following two definitions to assist in understanding these issues. Always On In this state: · DSL link remains in L0 or L1 power state (see G.992.2), meaning that some data capacity remains available at all times, though usually at a significantly reduced bandwidth. · ATM SVC remains connected (always true for PVCs). · PPP session remains active. · IP address remains allocated. · User remains “logged on.” Several of these conditions require the CPU of the PC to be running (ATM Call Manager, PPP engine, and so on). Also, several of the protocol layers need to exchange messages between the client and the network (for example, SSCOP for ATM signaling, PPP challenge/keep-alive, and so on). As such, neither the DSL modem nor the PC can enter a low power state. However, the G.992.2 link can enter a reduced power “L1” state as a partial conservation. As soon as any packets are destined to the client, or the user causes something to happen, the link can be restored to full L0 power and the original bandwidth becomes available. “Always On” limits the power conservation and rack density possible at the DSLAM, which increases the cost of the service. However, this capability is very attractive to users. Always Available By contrast, in the “Always Available” state: · DSL power can be reduced to L3, meaning that DSL connectivity can be closed down until it is reestablished by either end. · ATM SVCs are cleared down (PVCs remain in place). · PPP sessions are closed. · IP addresses are released to the provider. · User’s session with the network is disconnected. The user may remain logged on to the computer, but not the network. From this condition, an incoming call from the network requires the DSLAM to power up the DSL link. This will trigger the client modem to “wake up” the PC and make it ready to receive the incoming connection (RAS). The process can take up to 10 seconds, but the call can still be accepted in most cases. If the human user wakes the PC, this will trigger the modem to change the link power state, effectively waking the DSLAM and restoring the L0 power state on the DSL line. This also will take up to 10 seconds if the PC must be woken. If the PC is already running on full power, restoring the DSL link will only take the time of a fast-retrain (see G.992.2), which is only a few seconds and still much faster than conventional V.34 or V.90 modem dialing. Device Power Management There is a need to avoid network-initiated actions that can cause unsolicited power-up events on the client computer. In particular, use of the computer’s main CPU must be avoided while in a power-saving mode. When a computer has been placed on standby, the normal procedure is to save the contents of the main memory to disk and stop the CPU. To bring the CPU back on line, it is necessary to spin up the disk drive(s) and reload this memory image, together with any additional software required for the specific function. Microsoft and the PC industry in general are strongly opposed to such “gratuitous” disk access events. From a noise perspective, such disk activity is a serious issue when the computer is located in a child’s bedroom. Additionally, Microsoft is aware of strong consumer resistance to anything that suggests an outside entity “touching” their precious computer without warning. Broadband Core Network The core network provides Layer 2 (data link)4 service between DSL consumers and a variety of service providers. Figure 7 Core Network ISPs and corporations providing direct service to the core ATM network must support the PPP-over-ATM protocol stack (included in Windows 2000 Server). This does not mean they must always run TCP/IP over the PPP session. For example, an enterprise with an existing NetBEUI or IPX/SPX internal network can use the PPP session to extend its corporate network out to telecommuting workers. Legacy providers without ATM connectivity will not necessarily become obsolete. Such providers may continue to use Frame Relay or other networking technologies. Customers of legacy providers will not realize the bandwidth and QoS gains that customers of broadband providers will enjoy, but they will continue to receive previous levels of service. For access from the ATM network, legacy network operators will need to provide an appropriate gateway. For example, a frame-relay gateway can connect the (ATM) broadband network with an existing frame-relay infrastructure hosting these legacy providers. An example scenario based on integration of ATM and legacy networks is the case of an enterprise (without direct ATM connectivity) providing telecommuting access to employees having ATM-based broadband residential service. The enterprise would retain the old frame relay link to an ISP, and provide a PPTP server (included in Windows NT® Server 4.0 and Windows 2000 Server) to terminate VPN connections. The ISP provides access to the Internet or a private IP network over the ATM network, and also an ATM/frame relay gateway. Employees of the enterprise would connect via broadband ATM to the Internet or private network provided by the ISP, and establish a VPN connection which tunnels first on ATM, and then on the legacy frame relay link, to the enterprise network. The aggregate throughput and QoS available to the telecommuting employees will be limited by the frame relay bottleneck, but otherwise they will enjoy a seemingly transparent network connection to the enterprise. Figure 8 Combined Architecture of Core Network and Service Providers Layer 2 Service ATM is specified as the Layer 2 switching (data link) layer, with a strong preference for Switched Virtual Circuits (SVCs) in addition to Permanent Virtual Circuits (PVCs). The use of ATM keeps the core network technologically separate from the various Layer 3 (routed network layer) services, and it can be treated in much the same way as the POTS network is treated, providing simple point-to-point connections capable of supporting many different types of service. ATM also provides good separation of traffic based on service categories defining Quality of Service (QoS) levels, and the creation of on-demand connections with specific bandwidth and QoS capabilities [7]. See the section “End-to-End Quality of Service” for more details. Using ATM allows us to support many different service providers. These can include ISPs, OSPs (for example, America Online), and enterprises (extranets and telecommuting access). To participate directly in the Broadband service, ISPs and enterprises are required to implement the PPP-over-ATM specification, which can be simply accomplished by deploying Windows 2000 Servers on their ATM connections. Switched Virtual Circuits (SVCs) Microsoft strongly believes that SVCs are architecturally far superior to PVCs. SVCs provide the following key advantages: · Connections only have to exist while they are in use, allowing a larger number of users to be supported on a given switch or server. · Configuration of the client is much simpler. Microsoft Dial-Up-Networking icons can connect to a specific service provider, without concern for local DSLAM PVC configurations. · Setting up access to a new service provider requires only knowing the address of the provider. The Telco does not have to reconfigure the network in each case. The provider is still responsible for signup and account creation, as with analog ISP services today. · Network faults can cause the loss of a call, but a new call establishment will automatically reroute around the problem. PVCs (generally) need to be manually reconfigured onto working links. · Broadband Service Providers have the option to use alternative protocols (not just PPP) for specialist purposes, for example, for Video on Demand or Voice Telephony over ATM. · Applications can make use of the Generic QoS features of Winsock2. See the section “End-to-End Quality of Service” for more details. For example, the Classical IP over ATM protocol support in Windows 98 and Windows 2000 (sometimes referred to as IPOA) makes use of ATM SVCs to deliver end-to-end QoS for demanding applications such as Video on Demand. · Enterprises can implement dial-back security, just as for POTS or ISDN, as a way to strongly authenticate telecommuters. · ATM “Anycast” addresses (if supported by the public ATM network) allow calls to be directed to the nearest available server, providing for dynamic load balancing over the network. However, it is wrong to assume the need for coast-to-coast SVC support as a prerequisite for useful SVC deployment. In the ADSL context, the SVC is usually used to select the Layer 3 service provider, not to directly place calls. In most cases, the SVC capability need only extend to the local POPs of the supported ISPs, or to the nearest enterprise site for telecommuting. This will often be within the metropolitan area, often transiting only one or two core network switches. It is quite feasible for a network operator to begin offering SVC service within a single CO or a small local group, without connecting directly to their existing ATM backbone. In fact, PVCs or PVPs across the main ATM backbone could be used to link small “islands” of SVC capability as the DSL service grows. SVCs are less useful as a technology linking backbone switches and routers together, and this argument is sometimes used against the use of SVCs in the local access market. However, Microsoft believes the advantages to users, network operators, and equipment vendors will eventually make SVCs the norm for local connection at Layer 2. After all, there are very few manual-board telephone exchanges in existence today. Internet Access via an ISP It’s worth noting that access to the Internet is not included directly in a DSL service. Internet access is just one of the Layer 3 (network) services that can be supplied to a DSL customer. Obviously, this is one of the most appealing, and many ISPs will provide a bundled service including Layer 1 (DSL), Layer 2 (ATM) and Layer 3 (IP/Internet), hiding the details from the end-user. However, nothing about DSL requires an Internet connection. In particular, clients connecting to an enterprise for telecommuting may never see an Internet connection or even an IP packet. If the corporation uses NetBEUI or IPX/SPX, that is what will be passed over the PPP connection. Core Network Interworking The core network provides access and interworking with other wide-area systems at Layer 2. This is necessary to support a number of legacy services and to connect with providers who do not yet have compliant broadband services established. Telephony remains an important service and a key source of revenue for network operators. “Second line” service over the same copper pair is attractive, and the possibility exists of support large numbers of “on demand” virtual lines that can be called into being whenever needed. Figure 9 Voice Services on DSL (examples) There are two forms of POTS interworking to be supported, depending on the way the service is offered to broadband customers: H.323 voice over IP, and voice over ATM. · H.323 Voice over IP. Where the POTS service is being used from a Windows PC, the preferred technology is to use the H.323 capabilities of Microsoft NetMeeting® conferencing software running over an IP layer connection. This connection will terminate at a gateway to the PSTN. · H.323 Gateway to the PSTN. In the simpler case, the client makes a PPP connection over ATM to a preferred ISP, then establishes an H.323 connection with a suitable gateway at this or another ISP. · Combined PPPOA / H.323 Gateway to the PSTN. In this case, the client establishes a PPP session directly to the PSTN gateway and forms an H.323 call over that connection. The (private) allocated IP address for this PPP connection is local to the gateway and is not routed by the ILEC in any way. The gateway is built on a Windows 2000 Server platform and combines the PPP-over-ATM RAS termination with the H.323 gateway functionality in a single server. · Voice over ATM. The future can expect to include the presence of telephones directly connecting to a home gateway, with the use of “Voice Telephony over ATM” technology (VTOA). This will switch voice traffic within ATM connections and avoids the use of IP. Such a service offers lower latency than can be achieved through H.323, and thus reduces the need for echo suppression and cancellation. Also, this approach is attractive to ILECs and PTTs who may be prohibited from offering a service that requires an IP layer. Of course, they could contract with an ISP for this function, but there is little incentive for them to do so when they already have the ATM network and PSTN under their own control. Involving an ISP purely to make the protocol work is a waste of money. Having said that, the standards and technology available for VTOA are still very limited. Most development up to now has concentrated on using ATM for trunking between PBXs, with very little effort looking at VTOA to the desktop. Consequently, Microsoft is concentrating efforts on the development of VoIP solutions, while the VTOA approach remains under study. Broadband Internet Service Providers ISPs have traditionally offered residential customers modem-based services (sometimes using ISDN), and offered business customers expensive leased-line or T1 services. Now, DSL allows an ISP to offer broadband service to residential users at far lower tariffs. Connection to DSL Networks A Broadband ISP must provide a point of presence (POP) on the broadband core network. Because the End-to-End Architecture is defined as PPP over ATM, the ISP must terminate this standard protocol stack at their point of presence. The Telco must provide an ATM connection to the ISP’s POP location, on which ATM calls can be delivered to the POP. The ISP is responsible for terminating PPP sessions established by users and connecting them to the Internet service itself. This process is very similar to analog dial-up, and much of the same technology can continue in service (for example, RADIUS). ISP Architecture A Broadband ISP is little different in internal architecture from a traditional ISP. Figure 10 ISP Architecture There is the same motivation to separate functions between the local POP to minimize access charges, and the centralized data center to simplify system management and maintenance. Points of Presence The conventional separation of local POPs from the centralized Data Center is still available. There are a couple of newer functions, sometimes seen in POPs today, that will be increasingly important in a broadband environment. First, some form of caching to reduce the load on the backbone link (see the section “Cache Technology” later in this document). Second, some form of bandwidth management, to ensure users get appropriate access to the backbone, perhaps having a guaranteed minimum throughput for each customer. There are a number of products on the market for this. Microsoft Active Directory and Authentication Greater system integration will help handle the increased complexity as ISPs provide more services that are billed on a per-use or metered basis. Subscriber Accounts Clients connecting to the ISP will make a dialed connection across the ATM network, or will use pre-defined PVC(s). This will reach one of the Windows 2000 Server computers at the POP, which will terminate the PPP session using RAS. The client login credentials will be passed back for authentication using the RADIUS protocol, and the client session will then be enabled onto the ISP’s backbone network. In addition, ISPs that participate in Microsoft’s “Passport” system will be able to offer their users a “single login” experience, such that their ISP credentials will allow them access to Microsoft and third-party sites without needing

Well, we finally have someone who's REALLY enthusiastic about this!

use the set up internet connection wizard and select use my lan on all. it works great and is simple.... what the hell is that person talking about?

ummmm, that's one hell of a response...lol john, thanks, but i tried that also i did find out what that error is and what was causing it on my network. error 783 is caused when another machine on the network is already using the ip number 192.168.0.1 problem was i disconnected all other machines from the network and it still gave me the error. the damn hub had ip number 192.168.0.1...lol