Frequently Asked Questions Newsletter Partners Contact Us
To Products Overview
To Accounts and Billing
To Service and Support
To Service Provisioning
To Policy and Security


| Policy/Security | SPAM | Blacklist | Products/Services | GeneralInfo | Definitions | Acronyms |


Technical Support - Subject Areas

Network
E-mail
IP Addresses, Domain Names
CIDR (Classless Inter-Domain Routing)



Network


E-Mail


IP Addresses, Domain Names


Classless Inter-Domain Routing (CIDR)


Where can I find a list of SBC DNS Servers and Resolvers for my service area?

The following is a list of SBC DNS servers and resolvers. DNS Servers, for hosting a zone file, should be selected by region. DNS Resolvers should be selected by choosing the two cities closest to the customer location.

The SBC Regional DNS servers are as follows:
Location Server Name IP Address Comments
SBC Southwest Region ns1.swbell.net 151.164.1.1 Primary
SBC Southwest Region ns2.swbell.net 151.164.1.7 Secondary
SBC West Region ns1.pbi.net 206.13.28.11 Primary
SBC West Region ns2.pbi.net 206.13.29.11 Secondary
SBC Midwest Region ns1.ameritech.net 206.141.251.2 Primary
SBC Midwest Region ns2.ameritech.net 206.141.193.168 Secondary
SBC SNET Region ns1.snet.net 204.60.0.2 Primary
SBC SNET Region ns2.snet.net 204.60.0.3 Secondary
 
The following DNS servers can be used in any SBC Region, however, ONLY Domain Names that have been registered or transferred through the SBC E-Services, Inc. websites (http://webhosting.com) or http://sbcdomreg.com) should reside on these servers.
 
Location Server Name IP Address Comments
SBC E-Services, Inc. ns1.sbcglobal.net 151.164.1.6 Primary
SBC E-Services, Inc. ns2.sbcglobal.net 204.60.203.190 Secondary
 
The SBC Resolvers are as follows:
Location Resolver Name Primary Resolver IP Secondary Resolver IP
Arkansas dns1.fyvlar.sbcglobal.net (Fayetteville) 151.164.169.201 151.164.1.8
  dns1.ltrkar.sbcglobal.net (Little Rock) 151.164.64.201 151.164.1.8
Kansas dns1.tpkaks.sbcglobal.net (Topeka) 151.164.172.201 151.164.1.8
  dns1.wchtks.sbcglobal.net (Wichita) 151.164.70.201 151.164.1.8
Missouri dns1.ksc2mo.sbcglobal.net (Kansas City) 151.164.8.201 151.164.1.8
  dns1.spfdmo.sbcglobal.net (Springfield) 151.164.88.200 151.164.1.8
  dns1.stlsmo.sbcglobal.net (St. Louis) 151.164.14.201 151.164.1.8
Oklahoma dns1.okcyok.sbcglobal.net (Oklahoma City) 151.164.23.201 151.164.1.8
  dns1.tulsok.sbcglobal.net (Tulsa) 151.164.67.201 151.164.1.8
Texas dns1.ablntx.sbcglobal.net (Abilene) 151.164.166.201 151.164.1.8
  Amarillo 151.164.1.8 151.164.11.201
  dns1.austtx.sbcglobal.net (Austin) 151.164.20.201 151.164.11.201
  dns1.bumttx.sbcglobal.net (Beaumont) 151.164.160.201 151.164.11.201
  dns1.crchtx.sbcglobal.net (Corpus Christi) 151.164.79.201 151.164.11.201
  dns1.elpstx.sbcglobal.net (El Paso) 151.164.73.201 151.164.1.8
  Euless/Fort Worth 151.164.1.8 151.164.11.201
  Harlingen 151.164.11.201 151.164.1.8
  dns1.hstntx.sbcglobal.net (Houston) 151.164.11.201 151.164.1.8
 dns1.lgvwtx.sbcglobal.net (Longview) 151.164.175.200 151.164.1.8
  dns1.lbcktx.sbcglobal.net (Lubbock) 151.164.163.201 151.164.1.8
  McAllen 151.164.11.201 151.164.1.8
 dns1.mdldtx.sbcglobal.net (Midland) 151.164.34.201 151.164.1.8
  Odessa 151.164.34.201 151.164.1.8
 dns1.rcsntx.sbcglobal.net (Richardson) 151.164.1.8 151.164.11.201
 San Angelo 151.164.11.201 151.164.1.8
 dns1.snantx.sbcglobal.net (San Antonio) 151.164.17.201 151.164.1.8
 dns1.wacotx.sbcglobal.net (Waco) 151.164.85.201 151.164.1.8
 dns1.wcfltx.sbcglobal.net (Wichita Falls) 151.164.193.201 151.164.11.201
Illinois dns1.chcgil.sbcglobal.net 206.141.192.60  
  (Chicago)  
Indiana dns1.ipltin.sbcglobal.net (Indianapolis) 67.36.128.26 
Michigan dns1.klmzmi.sbcglobal.net (Kalamazoo) 67.36.55.26 
  dns1.sfldmi.sbcglobal.net (Southfield) 206.141.193.55 
Ohio dns1.bcvloh.sbcglobal.net (Brecksville) 66.73.20.40 
 dns1.wotnoh.sbcglobal.net (Worthington) 67.36.13.26 
Wisconsin dns1.milwwi.sbcglobal.net (Milwaukee) 65.43.19.26 
California dns1.bkfdca.sbcglobal.net 64.160.192.70 
 (Bakersfield)  
 dns1.chicca.sbcglobal.net 63.200.183.70 
 (Chico)  
 dns1.frsnca.sbcglobal.net 63.202.63.72 
 (Fresno)  
 dns1.lsanca.sbcglobal.net 206.13.29.12 
 (Los Angeles)  
 dns1.mtryca.sbcglobal.net 63.200.115.40 
  (Monterey)  
 dns1.scrmca.sbcglobal.net 206.13.31.12 
 (Sacramento)  
 dns1.sndgca.sbcglobal.net 206.13.30.12 
 (San Diego)  
 dns1.snfcca.sbcglobal.net 206.13.28.12 
 (San Francisco)  
 dns1.snloca.sbcglobal.net 64.166.172.8 
 (San Luis Obispo)  
 dns1.sntcca.sbcglobal.net 63.203.35.55 
 (Santa Clara)  
 dns1.sktnca.sbcglobal.net 64.169.140.6 
 (Stockton)  
Nevadadns1.renonv.sbcglobal.net 64.169.10.7 
 (Reno)  
SBC SNET ns1.snet.net 204.60.0.2 
  ns2.snet.net 204.60.0.3 
  dns1.mrdnct.snet.net 204.60.203.179 
National Stand Alone dns1.nycmny.sbcglobal.net 66.10.48.198 

 

What is the recommended Routing Protocol?

We recommend that Dedicated Access customers set up a static default route in their router that points to the appropriate SBCIS hub router. A static route helps avoid the problems associated with dynamic routing protocol interactions. If static routes are not appropriate for your situation (i.e., you have multiple, diverse links to the Internet), SBCIS will be happy to discuss a more suitable choice with your local network administrator. Please contact your Internet Application Manager with such concerns.

Is my network down?

First, check to see if DSU/CSU is showing a red alarm or yellow alarm. If there is an alarm, there could be a problem with the cable between the CSU and the NIU. Reseat the cable at the CSU and the NIU and, if you have a spare, replace the cable. If the problem persists, it may be a circuit problem.

Some routers have the CSU built in. From your router, try to ping SBCIS gateway address. If the ping fails, then there is a problem between your router and our router. Also, try to trace out to a Web site from your router. The trace will help determine where your traffic is stopping. The last thing to try is rebooting your router. This may bring the connection back up. If none of these tips repairs the problem, please contact our Dedicated Enhanced Service Center at 1-866-937-3664 (1 866 WE'RE ON IT) or e-mail trouble@pbi.net.

TOP OF PAGE

Why is my network running so slow?

First, check to see if the problem is in your local area network or somewhere past your router toward the Internet. From your router, trace to a workstation on your local area network. Also do a trace to a known Web site. Look at the times at each hop. Time over 300 ms should be researched further. Any routing problems from your router to the Internet should be reported to our Dedicated Enhanced Service Center at 1-866-937-3664 (1 866 WE'RE ON IT), and/or paste your traceroutes into e-mail and send it to trouble@pbi.net. One of our engineers will review the traceroutes and work to fix the problem(s).

What time does the zone transfer occur at SBCIS?

The zone transfer occurs daily at 5:00 a.m., Noon and 5:00 p.m. (PST).

I can trace to some places, but not everywhere I used to. Can you tell me why?

Other providers may be having problems, or we may be experiencing routing difficulties. Run a traceroute to the sites you are having problems with, then send an e-mail to trouble@pbi.net and attach the traceroute results.

TOP OF PAGE

What address should I ping to test if my network is alive?

You can test your site from:

  • http://nitrous.digex.net/mae/mae-lg.html.

Select the option "ping", enter your address and then click on the "submit" button.

When do you conduct system maintenance?

SBCIS has two maintenance windows a week during which your service might be interrupted while we upgrade or test our network. Of course we try to keep service interruptions at a minimum, but there are occasions when we cannot perform our work without impacting service.

Effective August 1st, 2003, the service windows are:

  • Tuesdays, Thursdays, 3:00 A.M. to 6:00 A.M. (Eastern time)
  • Tuesdays, Thursdays, 2:00 A.M. to 5:00 A.M. (Central time)
  • Tuesdays, Thursdays, 1:00 A.M. to 4:00 A.M. (Mountain time)
  • Tuesdays, Thursdays, 12:00 A.M. to 3:00 A.M. (Pacific time)
I can't receive e-mail. All the e-mail's are bounced back.

Either your DNS or mail server is having problems. To check your mail server, try to telnet to the IP address of your mail server and port 25. (100.100.100.100 25) If you do not get a reply from telnet, then your mail server is not answering. Port 25 is where your mail is being sent from other mail servers. SBCIS will spool your e-mail for up to five (5) days if your mail server is down. If SBCIS is hosting both your primary and secondary DNS, call the Network Operations Center to receive help on this issue.

TOP OF PAGE

Do you have backup e-mail available through SBCIS?

Backup E-mail is available through SBCIS, however, it must be set up before it will work. If you are authoritative for your domain, that is to say the InterNIC "whois" points the world to your name servers, you will have to add a second (or additional) mail server record (MX record) with a lower priority than your main mail server(s). If our DNS servers are authoritative for your domain, you will need to request SBCIS to act as backup to your mail server. You can send a request to trouble@pbi.net if this was not covered when your account was created.

Should your mail server become unavailable, our server will accept e-mail for your domain and hold it for approximately five days (space permitting) until your mail server comes back on line. Senders will get a "message has not been delivered" message from our server before the five days are up, but our server will keep trying to reach your server for a few days before it bounces the mail back to the sender. Our mail server currently supports the "ETRN" command so you can trigger our server to attempt delivery of your mail, on demand, rather than wait for it to get around to checking your server again.

Here is a sample MX record showing how smtp-relay.swbell.net is configured as a backup mail server to mail.your-domain.com:

  • IN MX 10 mail.your-domain.com
  • IN MX 100 smtp-relay.swbell.net

TOP OF PAGE

I just changed my DNS files. Why are my users still looking at the old IP address?

We update our DNS record at 5:00 a.m., Noon and 5:00 p.m. (PST) daily. Make sure your serial number is updated after you've made the changes.

Why Must I Register My Address and Domain Name?

All Internet IP addresses and Domain Names must be registered to ensure that there are no duplications. If duplications were to occur, there would be a great deal of confusion and inaccessibility due to incorrect host name/IP address, mapping, and routing errors. Such problems could be extreme and affect many Internet users.

To avoid this, the Internet Addressing and Numbering Authority (IANA) was established. The IANA has chosen the InterNIC as its service provider, who in turn has contracted with Network Solutions Inc. (NSI) to perform the tasks associated with address and name registration. While this may seem somewhat confusing, the processes are fairly straightforward.

How Do I Register My Address?

To receive an InterNIC allocated or registered IP address, the policies of the InterNIC must be followed. SBCIS will be happy to assist dedicated access customers with this process.

TOP OF PAGE

How Long Will Internet Address Registration Take?

The length of time required to obtain an InterNIC allocated address depends your specific circumstances. Below are the most common scenarios and their corresponding time lines. It should be noted that the re-addressing of the local network cannot begin until the Internet address assignment process is completed by the InterNIC.

What If I Don't Have a Previously Assigned Internet IP Address?

SBCIS should be able to allocate an IP address out of its existing address block within two weeks. If your addressing requirements are very large or unique, addresses may have to be obtained directly from the InterNIC. This process could take eight weeks depending on how busy the InterNIC is at the time.

How Do I Get a Previously Assigned Internet Address Block "transferred" to SBCIS?

If a dedicated access customer has been allocated an Internet IP address block by another Internet Service Provider (ISP), agreement with the ISP must be reached as to whether the addresses can be transferred. The advantage of transferring IP addresses is that the customer will not have to re-number all hosts on their local network.

In the best interest of the customer, SBCIS will only accept address transfers with a legitimate 18-bit network address prefix (subnet masks of 255.255.192.0) or less. SBCIS may, on an individual case basis, agree to transfer address assignments with up to a 24-bit network address prefix (subnet masks of 255.255.255.0). However, customers requesting such transfers must understand the associated risks.

Specifically, other ISPs may drop these small network entries from their routing tables as their routing tables reach capacity. Neither SBCIS nor the InterNIC can mandate that these routes be re-entered in other ISP routing tables. For this reason, the customer should thoroughly and carefully evaluate transfers. In order to begin the transfer process, the customer must obtain written permission from their previous ISP. These transfers may take up to 8 weeks.

TOP OF PAGE

Can I Get a Previously Assigned Address Replaced by a SBCIS Allocated Address?

Dedicated access customers who have IP addresses from another ISP will be allocated a SBCIS IP address block upon request. SBCIS should be able to allocate an IP address out of its existing address block within two weeks. If your addressing requirements are very large or unique, they may have to be obtained directly from the InterNIC. This process could take eight weeks depending on how busy the InterNIC is at the time.

It is recommended that customers re-numbering their hosts to a SBCIS allocated address work with their SBCIS Dedicated Service Engineer to ensure the transition is as smooth as possible.

How Do I Register My Domain Name?

Once you provide us with the completed Domain-Name-Information Form, a DNS Management Administrator will assist you with this process. You can go to www.sbcdomreg.com to initiate the registration on your own, or at your request, we will submit without additional charge to Dedicated Internet Access customers a completed template(s) to SBC E-Services. There is a separate and additional charge to park your chosen domain name. These fees are outlined in table below.

DNR Pricing for All Regions effective 10/01/02
Note: Minimum 2 years lease
Type of ActivityOne-Time Price to End-UserEnd-User Billing
New/Change Domain Non-recurring charge will no longer be charged for new DNR. Only registration fees apply. This applies if the customers process their own order or if SBC does it.Not applicable
New Domain Registration $50 for each domain name on a 2-year lease on the domain name
$75 for each domain name on a 3-year lease on the domain name
$125 for each domain name on a 5-year lease on the domain name
$250 for each domain name on a 10-year lease on the domain name

NOTE: Special Pricing on .to domain name:
$120 for each .to domain name on a 2-year lease on the domain name
$180 for each .to domain name on a 3-year lease on the domain name
$300 for each .to domain name on a 5-year lease on the domain name
$600 for each .to domain name on a 10-year lease on the domain name

SBC E-Services Bills via Credit Card (CC) or BTN
Note - SNET and Neveda only CC billing is available

 

TOP OF PAGE

What If I Already Have A Registered Domain Name?

Modifications to an existing Domain Names are the responsibility of the administrative and/or technical contact on the existing Domain Name. You can go to www.sbcdomreg.com to initiate a modification to a Domain name with SBC E-Services.

TOP OF PAGE

Classless Inter-Domain Routing (CIDR) Overview

What Is CIDR?

CIDR is a new addressing scheme for the Internet which IP addresses to be allocated more efficiently when compared to the old Class A, B, and C address scheme.

Why Do We Need CIDR?

With a new network being connected to the Internet every 30 minutes the Internet was faced with two critical problems:

  • Running out of IP addresses
  • Running out of capacity in the global routing tables
Running Out of IP Addresses

There is a maximum number of networks and hosts that can be assigned unique addresses using the Internet's 32-bit long addresses. Traditionally, the Internet assigned "classes" of addresses: Class A, Class B, and Class C were the most common. Each address had two parts: one part to identify a unique network and the second part to identify a unique host in that network. Another way the old Class A, B, and C addresses were identified was by looking at the first 8 bits of the address and converting it to its decimal equivalent.

Address Class# Network Bits# Hosts BitsDecimal Address Range
Class A8 bits24 bits1-126
Class B16 bits16 bits128-191
Class C24 bits8 bits192-223

TOP OF PAGE

Using the old Class A, B, and C addressing scheme the Internet could support the following:

  • 126 Class A networks that could include up to 16,777,214 hosts each
  • Plus 65,000 Class B networks that could include up to 65,534 hosts each
  • Plus over 2 million Class C networks that could include up to 254 hosts each

(Some addresses are reserved for broadcast messages, etc.). Because Internet addresses were generally only assigned in these three sizes, there was a lot of wasted addresses. For example, if I needed 100 addresses I would be assigned the smallest address (Class C), but that still meant 154 unused addresses. The overall result was that while the Internet was running out of unassigned addresses, only 3% of the assigned addresses were actually being used. CIDR was developed to be a much more efficient method of assigning addresses.

TOP OF PAGE

Global Routing Tables At Capacity

A related problem was the sheer size of the Internet global routing tables. As the number of networks on the Internet increased, so did the number of routes. A few years back it was forecasted that the global backbone Internet routers were fast approaching their limit on the number of routes they could support.

Even using the latest router technology, the maximum theoretical routing table size is approximately 60,000 routing table entries. If nothing was done the global routing tables would have reached capacity by mid-1994 and all Internet growth would be halted.

How Were These Problems Solved?

Two solutions were developed and adopted by the global Internet community:

  • Restructuring IP address assignments to increase efficiency
  • Hierarchical routing aggregation to minimize route table entries
Restructuring IP Address Assignments

Classless Inter-Domain Routing (CIDR) is a replacement for the old process of assigning Class A, B, and C addresses with a generalized network "prefix". Instead of being limited to network identifiers (or "prefixes") of 8, 16, or 24 bits, CIDR currently uses prefixes anywhere from 13 to 27 bits. Thus, blocks of addresses can be assigned for networks as small as 32 hosts up to networks with over 500,000 hosts allowing for address assignments that much more closely fit an organization's specific needs.

TOP OF PAGE

A CIDR address includes the standard 32-bit IP address and also information on how many bits are used for the network prefix. For example, in the CIDR address 206.13.01.48/25, the "/25" indicates the first 25 bits are used to identify the unique network leaving the remaining bits identify the specific host.

CIDR Block
Prefix # Equivalent Class C # of Host Addresses
/27 1/8th of a Class C 32 hosts
/26 1/4th of a Class C 64 hosts
/25 1/2 of a Class C 128 hosts
/24 1 Class C 256 hosts
/23 2 Class C 512 hosts
/22 4 Class C 1,024 hosts
/21 8 Class C 2,048 hosts
/20 16 Class C 4,096 hosts
/19 32 Class C 8,192 hosts
/18 64 Class C 16,384 hosts
/17 128 Class C 32,768 hosts
/16 256 Class C 65,536 hosts
  (= 1 Class B)  
/15 512 Class C 131,072 hosts
/14 1,024 Class C 262,144 hosts
/13 2,048 Class C 524,288 hosts

TOP OF PAGE

Hierarchical Routing Aggregation To Minimize Routing Table Entries

The CIDR addressing scheme also enables "route aggregation" in which a single high-level route entry can represent many lower-level routes in the global routing tables.

The scheme is similar to the telephone network where the network is set up in a hierarchical structure. A high-level, backbone network node only looks at the area code information and then routes the call to the specific backbone node responsible for that area code. The receiving node then looks at the phone number prefix and routes the call to its subtending network node responsible for that prefix and so on. The backbone network nodes only need routing table entries for area codes, each representing huge blocks of individual telephone numbers, not for every unique telephone number.

Currently, big blocks of addresses are assigned to the large Internet Service Providers (ISPs) who then re-allocate portions of their address blocks to their customers. For example, SBCIS has been assigned a CIDR address block with a prefix of /15 (equivalent to 512 Class C addresses or 131,072 host addresses) and typically assigns its customers CIDR addresses with prefixes ranging from /27 to /19. These customers, who may be smaller ISPs themselves, in turn re-allocate portions of their address block to their users and/or customers.

TOP OF PAGE

However, in the global routing tables all these different networks and hosts can be represented by the single SBCIS route entry. In this way, the growth in the number of routing table entries at each level in the network hierarchy has been significantly reduced. Currently, the global routing tables have approximately 35,000 entries.

User Impacts

The Internet is currently a mixture of both "CIDR-ized" addresses and old Class A, B, and C addresses. Almost all new routers support CIDR and the Internet authorities strongly encourage all users to implement the CIDR addressing scheme. (We recommend that any new router you purchase should support CIDR).

The conversion to the CIDR addressing scheme and route aggregation has two major user impacts:

  • Justifying IP Address Assignments
  • Where To Get Address Assignments

Even with the introduction of CIDR, the Internet is growing so fast that address assignments must continue to be treated as a scarce resource. As such, customers will be required to document, in detail, their projected needs. Users may be required from time to time to document their internal address assignments, particularly when requesting additional addresses. The current Internet guideline is to assign addresses based on an organization's projected three-month requirement with additional addresses assigned as needed.

TOP OF PAGE

Where To Get Address Assignments

In the past, you would get a Class A, B or C address assignment directly from the appropriate Internet Registry (i.e., the InterNIC). Under this scenario, you "owned" the address and could take it with you even if you changed Internet Service Providers (ISPs). With the introduction of CIDR address assignments and route aggregation, with a few exceptions, the recommended source for address assignments is your ISP. Under this scenario, you are only "renting" the address and if you change ISPs it is strongly recommended that you get a new address from your new ISP and re-number all of your network devices.

While this can be a time consuming task, it is critical for your address to be aggregated into your ISP's larger address block and routed under their network address. There are still significant global routing table issues and the smaller your network the greater your risk of being dropped from the global routing tables. In fact, networks smaller than 8,192 devices will very likely be dropped. Neither the InterNIC nor other ISPs have control over an individual ISP's decisions on how to manage their routing tables.

As an option to physically re-numbering each network device, some organizations are using proxy servers to translate old network addresses to their new addresses. Users should be cautioned to carefully consider all the potential impacts before using this type of solution.

TOP OF PAGE

Need More Information?

For more detailed technical information on CIDR, go to http://www.rfc-editor.org/rfcsearch.html and type in the number of the CIDR RFC you are interested in:

  • RFC 1517: Applicability Statement for the Implementation of CIDR
  • RFC 1518: An Architecture for IP Address Allocation with CIDR
  • RFC 1519: CIDR: An Address Assignment and Aggregation Strategy
  • RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment

As mentioned before, there are a few exceptions where an organization would not use an ISP assigned address block.

Conclusion

The implementation of CIDR has been critical to the continued growth of the Internet, allowing more organizations and users to take advantage of this increasingly vital global networking and information resource.

TOP OF PAGE



| Home | Product Overview | Accounts & Billing | Service & Support |
| Service Provisioning | Policy & Security | Contact Us | FAQ | Newsletter | Partners |

Copyright 2002 SBC Internet Services. All rights reserved.