Routing: ip default-network vs. Default Static Routes

http://www.scit.wlv.ac.uk/~jphb/comms/iproute.html

One point of confusion for some CCNA and CCNP candidates is the difference between configuring a static default route and using the Cisco routing command ip default-network.

At first glance, they appear to do the same thing. Both configure a destination to which packets should be routed if there is no more specific route in the routing table.

The major difference between these two options is that configuring a static default route only defines a default route for the router you're configuring it on, while ip default-network will propagate the route via its routing protocol.

Let's examine the routing tables of a hub-and-spoke network using the ip default-network command. R1 is the hub and R2 and R3 are the spokes. They are directly connected via the network 172.12.123.0 /24, and each has a loopback with a 32-bit mask that are numbered according to the router number (1.1.1.1, etc.) RIP is running on all three routers and the loopbacks are advertised.

R1 has another serial interface with the IP address 10.1.1.1 /24, and this network has been flagged as a default network with the command ip default-network 10.0.0.0 . It is not being advertised by RIP.

The routing protocol will then advertise this route. With RIP, the default network is advertised as 0.0.0.0 . (With IGRP, it appears as the network number, but is marked as an IGRP External route. ) This route has been designated a candidate default route on R1, as we see with the asterisk next to the 10.0.0.0 /24 network (code table removed for brevity):

R1#show ip route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
R 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:11, Serial0
R 3.0.0.0/8 [120/1] via 172.12.123.3, 00:00:11, Serial0
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.12.21.0/30 is directly connected, BRI0
C 172.12.123.0/24 is directly connected, Serial0
* 10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial1

On R2 and R3, a default RIP route is now seen (code tables again deleted):

R2#show ip route
Gateway of last resort is 172.12.123.1 to network 0.0.0.0

R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:00, Serial0.213
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
R 3.0.0.0/8 [120/2] via 172.12.123.1, 00:00:00, Serial0.213
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.12.21.0/30 is directly connected, BRI0
C 172.12.123.0/24 is directly connected, Serial0.213
R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:00, Serial0.213

R3#show ip route
Gateway of last resort is 172.12.123.1 to network 0.0.0.0

R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:27, Serial0.31
R 2.0.0.0/8 [120/2] via 172.12.123.1, 00:00:28, Serial0.31
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.123.0 is directly connected, Serial0.31
R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:28, Serial0.31
And the default route works, since we can ping 10.1.1.1 from both R2 and R3. Since they have no other match in their routing tables, they use the default route. R2#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

R3#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

When deciding whether to use a default static route or a default network, keep in mind that if you want the routing protocol to propagate the default route, the ip default-network command will do that for you. But if you want only the local router to have the default route, a static IP route is the way to go.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, the home of the world's clearest, most concise, most comprehensive CCNA Study Guide available today. He offers free CCNA, CCNP, and Home Lab Setup Tutorials on the website, as well as online boot camps, Video courses and training, and binary/subnetting help. Join the revolution against overpriced and incomplete CCNA and CCNP study guides - visit www.thebryantadvantage.com today

TCP Window Thing

What is this TCP Window Thing?
A TCP window the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it gets an acknowledgment back from the receiver that it has gotten some of it.

For example if a pair of hosts are talking over a TCP connection that has a TCP window size of 64 KB (kilobytes), the sender can only send 64 KB of data and then it must stop and wait for an acknowledgment from the receiver that some or all of the data has been received. If the receiver acknowledges that all the data has been received then the sender is free to send another 64 KB. If the sender gets back an acknowledgment from the receiver that it received the first 32 KB (which could happen if the second 32 KB was still in transit or it could happen if the second 32 KB got lost), then the sender could only send another 32 KB since it can't have more than 64 KB of unacknowledged data outstanding (the second 32 KB of data plus the third).



Why have a TCP window?
The primary reason for the window is congestion control. The whole network connection, which consists of the hosts at both ends, the routers in between and the actual connections themselves (be they fiber, copper, satellite or whatever) will have a bottleneck somewhere that can only handle data so fast. Unless the bottleneck is the sending speed of the transmitting host, then if the transmitting occurs too fast the bottleneck will be surpassed resulting in lost data. The TCP window throttles the transmission speed down to a level where congestion and data loss do not occur.

RFC 2821 - Simple Mail Transfer Protocol

5. Address Resolution and Mail Handling


Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.

When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.

Two types of information is used to rank the host addresses: multiple
MX records, and multihomed hosts.

Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.

The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented.

Although the capability to try multiple alternative addresses is
required, specific installations may want to limit or disable the use
of alternative addresses. The question of whether a sender should
attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery,
and indeed sometimes the probability of any delivery; the counter-
argument is that it may result in unnecessary resource use. Note
that resource use is also strongly determined by the sending strategy
discussed in section 4.5.4.1.

If an SMTP server receives a message with a destination for which it
is a designated Mail eXchanger, it MAY relay the message (potentially
after having rewritten the MAIL FROM and/or RCPT TO addresses), make
final delivery of the message, or hand it off using some mechanism
outside the SMTP-provided transport environment. Of course, neither
of the latter require that the list of MX records be examined
further.

If it determines that it should relay the message without rewriting
the address, it MUST sort the MX records to determine candidates for
delivery. The records are first ordered by preference, with the
lowest-numbered records being most preferred. The relay host MUST
then inspect the list for any of the names or addresses by which it
might be known in mail transactions. If a matching record is found,
all records at that preference level and higher-numbered ones MUST be
discarded from consideration. If there are no records left at that
point, it is an error condition, and the message MUST be returned as
undeliverable. If records do remain, they SHOULD be tried, best
preference first, as described above.

SMB (CIFS)

http://samba.anu.edu.au/cifs/docs/what-is-smb.html

http://www.jacco2.dds.nl/samba/smb.html

SMB, which stands for Server Message Block, is a protocol for sharing files, printers, serial ports, and communications abstractions such as named pipes and mail slots between computers.

What is SMB?
In order to communicate, you and I need a common language, like English or Swahili. Computers are no different. There are a few basic "languages" computers use to communicate on a network, and these languages are called protocols. TCP/IP, NetBEUI, IPX, SNA and Appletalk are examples of protocols.
One of the most popular protocols for PCs lets you share files, disks, directories, printers, and (in some cases) even COM ports across a network: this protocol is called the SMB (Server Message Block) standard. Microsoft is trying to rename SMB-based networking to "Windows Networking" and the protocol to "CIFS" but I'll stick to SMB in the following.

An SMB client or server can communicate with just about any other similar program that adheres to this SMB standard including Warp Connect, Warp 4, LAN Server, Lan Server/400, IBM PC Lan and Warp Server (from IBM), LANtastic in SMB mode (from Artisoft), MS-Client, Windows for Workgroups, Windows 95, LAN Manager and Windows NT Workstation & Server (from Microsoft), DEC Pathworks, LM/UX, AS/UX, Syntax and Samba.

Routing Protocols

Routing Protocols
http://www.cisco.com/public/technotes/tech_protocol.shtml
http://www.cisco.com/en/US/tech/tk365/tk80/tsd_technology_support_sub-protocol_home.html

BGP (Border Gateway Protocol)
CDP (Cisco Discovery Protocol)
CLNS (Connectionless Network Service)
HSRP (Hot Standby Router Protocol)
IGRP/EIGRP (Enhanced Interior Gateway Routing Protocol)
IP (Internet Protocol)
IS-IS (Intermediate System-to-Intermediate System)
MPLS (Multiprotocol Label Switching)
Multicast
NAT (Network Address Translation)
OSPF (Open Shortest Path First)
QoS (Quality of Service)
RIP (Routing Information Protocol)

BGP

When you make a modem connection to your ISP and want to connect to, for instance, www.bgpexpert.com, all the routers along the way have to know where to send the packets you're sending to our Web server, and the packets from the server have to find their way back to your computer.
For the first few hops, this isn't much of the problem. For instance, your computer only knows the packets don't have a local destination, so they should be sent over the modem connection. This can continue for a while, but at some point the decision where to send the packet next becomes more complex than just "local: keep it" / "not local: send it to a smarter router". The router making this decision will have to know where to send the packet based on the destination IP address contained in it. Since IP addresses are distributed fairly randomly around the globe, there aren't any shortcuts or calculations that make it possible for the router to decide this for itself.

The only way a router can know where to send a packet, is when another router tells it "send those packets to me, I know how to deliver them". The Border Gateway Protocol (BGP) is a protocol that is used between routers to convey this information. Since the routers that talk BGP to each other aren't owned by the same organization (that would kind of defeat the purpose of creating global reachability) this is often called "inter-domain" routing.

BGP and Interdomain Routing Terms
AS
Autonomous System.
AS Number
Autonomous System Number. Each AS has a unique number that is used to identify it in BGP processing.
Autonomous System
An Autonomous System is a network that has its own routing policy. In most cases, customers belong to their ISP's Autonomous System, but multihomed customers obviously have their own routing policy that is different from either ISP so they must be a separate AS.
BGP
Border Gateway Protocol.
EGP
Exterior Gateway Protocol: a routing protocol used between organizations/networks. BGP is an EGP, but there is also an older EGP called EGP.
Gateway
Older term for router. Sometimes the word "gateway" is used to describe a system that connects two dissimilar networks or protocols.
IGP
Interior Gateway Protocol: a routing protocol used within an organization/network. Examples are RIP, OSPF, IS-IS and EIGRP.
Multihoming
The practice of connecting to two or more ISPs. Most multihomed networks run BGP so the rest of the Internet knows where to send packets for the multihomed network even if one of the connections fails.
Router
1. Any system that will receive packets over one network connection and then forward them to another by looking at the network address inside the packet.
2. A special-purpose system (like a computer, but usually without a screen, keyboard and harddisks) that forwards packets.
Routing Policy
A policy that defines how a network is connected to other networks and how packets are allowed to flow.

Life Without NetBIOS

Bit by bit, I'm leaving my pre­Windows 2000 network behind. I took a big step forward recently after I realized that my Win2K network was still supporting NetBIOS over TCP/IP (NetBT). Because NetBT is a fairly chatty protocol, I figured that using only DNS would speed up my network. (And it did, quite a bit.) So, I disabled NetBT on my servers and most of my workstations. Here's what I learned.

Disabling NetBT
To disable NetBT manually, right-click My Network Places and choose Properties to display the computer's TCP/IP properties. (You can use DHCP to disable NetBT on a system, but that process requires a fairly lengthy explanation, so I'll leave it for another day.) In the Network and Dial-up Connections window, you'll see an object for each network card on your system. Right-click the network card for which you want to disable NetBT, then choose Properties. On the Properties page, double-click the Internet Protocol (TCP/IP) object, then click Advanced on the Internet Protocol (TCP/IP) Properties page. Click the WINS tab, then click the Disable NetBIOS over TCP/IP radio button. Clear the Enable LMHOSTS lookup check box, then click OK until you've closed the pages. To verify that you've killed NetBT, you can type

ipconfig /all
on a command line. You'll see a line confirming that NetBT is disabled.

You can disable NetBT on a few systems without affecting your other computers, except of course that those other computers won't be able to use NetBIOS to communicate with the systems on which you've disabled NetBT. After you disable NetBT, you can shut down the Computer Browser service to recover some memory and simplify your system's software. If you don't do so, the Computer Browser service will eventually get tired of not being able to retrieve browse lists and will shut itself down.

Working Without Browsing
Shutting off NetBT greatly reduces the network's browsing functionality because the Computer Browser—the service manifested in Network Neighborhood, My Network Places, and the Net View command—sits atop NetBIOS. A machine on which you've disabled NetBT can't retrieve the workgroup browse list for a Windows NT 4.0 domain, nor can the machine retrieve the list of shares from a pre-Win2K server. And under no circumstances can that system use the Net Use command to access a share on a pre-Win2K server.

But browsing doesn't disappear altogether. You can still browse shares on another Win2K or later system. For example, suppose your workstation is part of an Active Directory (AD) domain named acme.com. If you type any of the following commands:

net view
net view /domain:acme.com
net view /domain:acme
you'll get the message There are no entries in the list. In other words, the Net View command can't list the servers in the domain. Similarly, if you open My Network Places and navigate to Entire Network, then go to the icon that represents your domain's workgroup, you'll find the list of servers empty. But if you happen to know the name of the Win2K server (the server must be a Win2K server; you can't attach to any shares on a pre-Win2K OS after you turn NetBT off), you can use the Net View command to list its shares without NetBT's help. For example, if you know that acme.com has a server named Bigserver, you can type

net view bigserver.acme.com
to list its shares. Notice that you don't need to type two backslashes (\\) before the server name—the server's DNS name is sufficient.





You can use the Net Use command similarly. For example, a command such as

net use x: \\bigserver.acme
.com\share1
accesses the specified share. (Note that Net Use still requires those pesky backslashes.) You can also get to a share by opening Microsoft Internet Explorer (IE) and typing the share's Uniform Naming Convention (UNC) name in the Address bar—for example, typing \\bigserver.acme.com\share1 in the Address bar opens that share. Alternatively, you can click Start, Run and type the UNC name, or you can simply add \\bigserver.acme.com\share1 to your My Network Places folder. In short, connecting to a share doesn't change when you eliminate NetBT, but finding the share does change.

Browsing the AD Way
Life without a browser doesn't sound very appetizing. Can you bid NetBT adieu and still find network resources? Sure—simply publish them in AD.

You can use AD as a place to list and describe (i.e., publish) all the shares on a domain (and in other domains, for that matter). Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the icon for the domain or any organizational unit (OU) in the domain, choose New, then select Shared Folder. Type the folder's UNC name and a descriptive name for the shared folder, then click OK. You'll see that the domain now contains a shared-folder icon for the new share. You can open the share's Properties, click Keywords, and type keywords that users can use to search for folders that include those keywords.

When you use the Computer Browser, you poke around in the network's servers to look for a share. But with the AD approach, you don't care which server contains the share you want—rather, you're interested in the share's contents, or at least its name. Suppose you're looking for the share that contains the human resources (HR) forms. You can simply go to My Network Places, but instead of looking into each server to browse its shares, double-click Entire Network, then double-click the Directory icon. You'll see a list of shares, one of which is called HR Forms. You double-click the icon to open the share without knowing—or caring—which server it's on.

Furthermore, you can put a shortcut to that share on your desktop. When you publish shares in AD, shortcuts to those shares have a neat feature: If the shortcut's definition changes in AD—for example, if you move the HR Forms share to a different server—you don't need to change the shortcut. Whenever you click the shortcut, the shortcut goes to AD to determine the actual UNC, then uses it to open the share.

I want to mention one annoying thing about AD-published shares: Before you publish a share in AD, you must create the share in a separate step. Why Win2K servers don't automatically let you publish the share when you create it eludes me, particularly because every shared printer is published by default.

File Sharing Without NetBIOS Ports
What are the implications for firewalls and ports when you do file sharing without using NetBIOS? You can share files over any TCP/IP-based network—including the Internet—without using NetBIOS's infamous ports (i.e., UDP ports 137 and 138, TCP ports 137 and 139). Because Win2K on a NetBT-less network uses DNS to find computers and your network presumably is already using DNS without incident, no port changes are required. But according to the network traces that I saw while connecting to file shares, file sharing without NetBT uses both UDP port 445 and TCP port 445 as its source port.

Logons and Trust Relationships to NT 4.0 Domains
Keep in mind that NetBIOS does more than support browsing. When pre-Win2K systems try to log on a user, they use NetBIOS to find domain controllers (DCs). Thus, if you turn off NetBT on a Win2K system that's a member of an NT 4.0 domain, the Win2K system can't log on to that domain.

However, a Win2K system that tries to log you on to an NT 4.0 domain and fails because of a lack of NetBT support won't tell you that you didn't successfully log on. You can perform a simple exercise to verify that fact. Log on from a Win2K workstation or server that's a member of either an NT or an AD domain. Then, open a command line and type the Set command. You'll see the values of the environment variables on your system. One of the variables is logonserver=some-machine-name, where some-machine-name is the name of the DC that logged you on.

I've found that when I log on to an NT 4.0 domain from a Win2K system and examine the logonserver value, the value names some DC in the NT 4.0 domain, as you'd expect. But if I then disable NetBT, reboot the Win2K system, and log on with my NT 4.0 domain account, the logonserver value names the Win2K system, not a DC. Clearly, the Win2K system used cached credentials to log me on in that situation. In contrast, if I try to log on to the Win2K system with an NT 4.0 domain account that has never before logged on to the NT 4.0 system, I can't log on, and I get a message explaining that the Netlogon service isn't running.

Failed logons affect more than the user who wants to log on to a particular server. Connections between DCs support trust relationships: To facilitate users from the trusted domain logging on to the trusting domain's machines, every NT 4.0 DC from the trusting domain finds and logs on to a DC from the trusted domain. Therefore, if your Win2K AD DCs no longer respond to NetBT requests, those machines can't find and connect to DCs for trusted NT 4.0 domains. The trusts will fail, and both the NT 4.0 and AD DCs' event logs will contain messages stating that the machines couldn't find any DCs to correspond with.

Going NetBT-less is worth considering. At first, the lack of the Computer Browser service was disorienting, but after I published my shares in AD, I didn't miss the browser. And the NetBT-less logons seem considerably faster, although I haven't benchmarked them. If you don't need to communicate with pre-Win2K systems and you don't rely on NetBIOS-based server applications (a big if), disabling NetBT is an interesting way to streamline your network.

Netbeui, NWlink, TCP/IP, NetBios

Windows NT supports several network protocols, and the protocol you use can affect your network performance significantly. To choose the best protocol for your network, you must understand the protocols NT supports, how each works, and where each protocol is most effective. Then, consider the resources that are necessary to implement your protocol choice.

NetBEUI
When Microsoft developed Windows for Workgroups (WFW), the NetBEUI protocol was a good choice, and many networks run it even after they convert to NT and Windows 95. The name NetBEUI comes from NetBIOS Extended User Interface, and this name has created confusion since NetBEUI's introduction. NetBIOS is a programming interface, and NetBEUI is a transport protocol. Most Microsoft software and many other packages that run on Windows platforms use the NetBIOS programming interface. Thus, many network administrators continue to use NetBEUI after they install other protocols, because they think the application software can't function without NetBEUI.

IBM developed NetBEUI in the mid-1980s for small workgroups with closely linked computers. NetBEUI was by far the fastest NT protocol available until Microsoft released NT 3.51. Microsoft concentrated its programming effort on speeding up TCP/IP in NT 3.51. TCP/IP has overtaken NetBEUI in popularity because of the computer industry's push to make TCP/IP the standard protocol for business applications.

NetBEUI's ideal users are small businesses or individual departments in larger corporations. NetBEUI is a reasonable choice for small networks. It requires relatively little memory; it's self-tuning, with no user-configurable parameters; and it's compatible with Microsoft networks. NetBEUI is a good choice for DOS clients, because it requires minimal system memory. (Remember, you must run it on the server and the clients.)

One of NetBEUI's disadvantages is that it lacks routing capability (which might be an advantage if you want to isolate traffic on a network segment). It does not scale well, because it uses broadcasts for many functions, including identifying other computers (through NetBIOS broadcasts). The broadcast approach works on small networks, but the network traffic it generates can overwhelm a large network. Although NetBEUI is compatible with Microsoft networks, you must have another protocol if your network includes Novell or UNIX servers.

Is NetBEUI for you? The answer may be yes, if you have a small network. However, be prepared to remove or disable NetBEUI when your network outgrows it.

NWLink
NWLink is Microsoft's version of Novell's IPX/SPX protocol. Networks with Windows clients that access Novell servers use NWLink: for example, a client/server application in which the client runs on NT Workstation or Win95 and the server component, such as a database, runs on a Novell server. Small networks can use NWLink, even without connectivity to a Novell server. NWLink requires less configuration than TCP/IP does. Like TCP/IP, NWLink is routable.

A common problem with NWLink is having the wrong frame type, especially in a mixed-frame environment. A frame is a package of information transmitted as a unit from one network device to another. An Institute of Electrical and Electronics Engineers (IEEE) frame-type specification outlines each option for formatting network data. NT attempts to detect the frame type through its Auto Frame Type Detection (which Screen 1, page 214, shows). However, NT will detect only one frame type, even though the network may be running several. Before version 3.3, NetWare's default was to use frame type 802.3; with version 3.3 and later, NetWare switched to 802.2 as the default. Recent versions of NT (3.5 and later) look first for 802.2 frames and accept this as the default frame type. NT does not continue to search for other frame types. Thus a computer on a mixed-frame network can talk to some but not all of the other computers on the network. You can solve this problem by telling NT to use multiple frame types, as Screen 2, page 214, shows.

TCP/IP
Microsoft is channeling its programming effort into TCP/IP. The corporate world prefers TCP/IP, and you must use it to connect to the Internet, so it's becoming the industry standard. TCP/IP uses more memory and system resources than NWLink or NetBEUI uses; thus it might not be the best choice for small networks. It certainly is not the best choice for DOS clients.

TCP/IP requires more configuration than NWLink or NetBEUI requires. With TCP/IP, network administrators must decide how to assign IP addresses­ and must worry about how to obtain them, because IP addresses are limited until IP6 comes out. The Internet Network Information Center (InterNIC) assigns IP addresses, which currently use 32 bits. This addressing scheme limits the number of available IP addresses (available at http://ds.internic.net). The IP6 specification will introduce 128-bit addresses to ease the availability problem. For now, InterNIC has assigned or reserved almost all of the available IP addresses, and obtaining a range of valid IP addresses is difficult for a small company. You can make up your own IP addresses, but when you connect to the outside world through the Internet, you need a valid InterNIC-assigned IP address. (For information about IP addressing, see Mark Minasi, "You Can't Spell 'Internet' Without 'NT,'" February 1996.)

You must decide whether to assign IP addresses automatically or manually. If you choose automatic assignment, NT can help with the Dynamic Host Configuration Protocol. DHCP is available on NT Server and uses additional system resources. Your Backup Domain Controller (BDC) can run DHCP and perform user validation. When you configure the DHCP server, it automatically handles IP addressing. Screen 3 shows an example DHCP server configuration, including addresses reserved for printers, routers, and other system devices.

If you don't use DHCP, you must manually assign and track IP addresses, making sure the addresses are typed in correctly and troubleshooting problems that occur when people move computers around the network. These tasks are overwhelming in a large organization and can be equally daunting in a small company. Screen 4 shows manually assigning an IP address in the TCP/IP Properties window.

Other Considerations
If you use TCP/IP as your network protocol, you might discover that your computers cannot communicate with one another. If they are on different subnets­that is, they have different IP addresses and are separated by a router­they will not be able to find one another. This problem occurs because applications and the operating system refer to a computer by name (e.g., SERVER1, Accounting2), but TCP/IP requires a network card address rather than a name.

A computer running NetBEUI can find the address for another computer by broadcasting the name of the target computer and then waiting for a response, which will include the target computer's address. Connecting to a computer on another part of the network is not an issue for NetBEUI, because NetBEUI is not routable. A router divides a network into segments, each with its own set of addresses.

Because TCP/IP is routable, you need a way to find addresses for computers on different parts of your network. Broadcast messages don't pass through the routers, so you must know the target computer's address to send a message directly to it. One solution is to keep a list of your network computer names and IP addresses. TCP/IP can use this list, in the form of an LMHOSTS file, to convert a computer name to an IP address and then send a message to the IP address to ask for the network card address. (For more information about LMHOSTS files, see Mark Minasi, "Inside a NetBIOS Name Resolution," March 1997.) However, keeping LMHOSTS files up-to-date is tedious and difficult in a rapidly changing environment, especially if you use DHCP.

Another solution is to install Windows Internet Naming Service. WINS is an automated database of computer names and IP addresses. After you configure the WINS server, your client computers register with the server by giving their names and addresses to the WINS database when they start up. When a client computer needs another computer's address, it asks the WINS server. (For more information about WINS, see David Lafferty, "Setting Your WINS Strategy," October 1997.) An NT server such as a BDC might be a good candidate to function as a WINS server. A WINS server must have a fixed IP address that the DHCP server can automatically pass to clients when they receive their IP addresses from the DHCP server. Think of this process as dialing 411 on the telephone to find other phone numbers through directory assistance.

The More the Merrier?
More is not necessarily better with protocols. A company often starts with a small peer-to-peer network and perhaps uses WFW or Win95. Then, as more users come online, the company adds a server. Thus a company might add NWLink to its network to communicate with a NetWare server. When the Internet becomes important to business, the company adds TCP/IP. But how often does the company's network administrator go back and make sure that only the necessary protocols are running? To many administrators, leaving older protocols in place seems safer, in case users have not converted to TCP/IP.

Running multiple protocols on an NT-based network is a bad idea. Many NT system functions, such as browsing, depend on broadcasts. Each computer announces its presence on the network when it first comes online and every 15 minutes thereafter. Because a computer does not know which protocol the server is listening to, every computer sends out a broadcast on each of its protocols. If your network is running NetBEUI, NWLink, and TCP/IP, your browser service initiates three times as much network traffic. Although the broadcasts stop at the routers, they generate excessive local traffic.

If you want to reduce network traffic, consider disabling older protocols that you no longer use. On NT computers, go to Control Panel, Services, Network; select the Bindings tab. In the Bindings tab window, you can disable any protocols (rather than remove them), as Screen 5 shows. Thus, if one of your users needs a protocol, you can reenable it.

If disabling protocols worries you, run the Network Monitor utility that comes with NT, or run the full version of the utility, which is part of Systems Management Server (SMS). The Network Monitor utility will show you which protocols on your network are generating the most traffic. You can then make an informed decision to eliminate some of them. Your choice will affect your network's productivity, and the decision depends not only on the protocols you need but also on the protocols you can live without.

If you are having trouble getting File and Printer sharing to work and have multiple IP addresses from your ISP

The easiest way to fix this is to add the NetBeui or IPX/SPX protocol (make sure you enable NetBIOS over IPX/SPX) to all your computers and make sure it is bound to Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. This will set up File and Printer sharing independently from TCP/IP, so it won't matter what the TCP/IP settings are! Make sure you unbind these from TCP/IP.

The Need For Name Resolution

To ensure successful communication on a network, your systems need to be able to associate a name with an IP (or other relevant network number) so that users do not need to memorize the numeric identifier, such as a TCP/IP address. Proper name resolution is essential for fast network communication, and if it is not configured correctly, your network will be slow, and your network users will be unhappy.

On Windows networks running TCP/IP, the following options exist for name resolution:
Host Name Resolution

*

HOSTS ............... Static
*

DNS ................... Dynamic

NetBIOS Name Resolution

*

LMHOSTS ........... Static
*

WINS ................. Dynamic
*

DNS ................... Dynamic (not the default for NT4 or earlier)
*

HOSTS ............... Static (with NT/2000/XP/2003)

Although commonly advocated, there is no need to run NETBEUI on your Windows network. It is a chatty, non-routable broadcast protocol, and only useful on very small networks, or if you don't want to connect to the Internet at all. Instead, you can rely on NetBIOS support, tunneled over another protocol such as TCP/IP. All versions of 32-bit Windows support NetBIOS over TCP/IP.

If you want to use DNS for resolving NetBIOS names on versions of Windows prior to Windows 2000, you must go into the TCP/IP properties in the Control Panel and enable "Use DNS for Windows Resolution". With 2000, XP and 2003, Windows has an increased reliance on DNS, whether on a peer network or through Active Directory.
If you are unable to get Windows 95/98/ME machines to talk to systems in the Windows NT-family without installing NetBEUI, then it is very likely that you have not setup NetBIOS Name Resolution for your client systems. Also, remember that NetBIOS traffic should always be confined to your internal network ONLY. There is no need to allow NetBIOS traffic to traverse the Internet or another public network without the benefit of a VPN.
NETBIOS vs. NETBEUI

Many folks confuse NETBIOS and NETBEUI. The former, is a program (API) developed by IBM which allows applications on a LAN to communicate. The latter is a chatty, non-routable protocol originally used by LAN Manager, and subsequently by Windows, to provide the frame and data format for NetBIOS traffic.

NetBEUI = NetBIOS Extended User Interface

Under Windows, NetBIOS can be transported over other protocols such as IPX and TCP/IP. Starting with Windows 2000, Microsoft networks are no longer dependent on NetBIOS for communication, although you still need it for browsing Network Neighborhood and for using certain utilities such as the Windows Messenger Service (NET SEND).
Where Are My HOSTS/LMHOSTS Files?

Both the HOSTS and LMHOSTS files can be found in the same location. Neither of these files has a file extension. The .SAM files found in the same location are sample files, and must be renamed to be used by Windows.

*

Win9x/ME ................. %windir% (usually C:\WINDOWS)
*

NT/2000/XP .............. %SystemRoot%\System32\Drivers\ETC

If creating or editing these files in NOTEPAD, be sure to place the name in quotes so that NOTEPAD does not add a .TXT extension to the saved file. Or just use Textpad to edit all your files.

To speed up name resolution on a peer-to-peer network, add the name and IP of each machine on your network to the HOSTS file on each machine. This will make it easier for the systems to find each other without waiting for broadcast messages.

Example:

127.0.0.1 localhost
172.30.50.11 workstation1
172.30.50.12 workstation2
172.30.50.13 workstation3

http://www.rxn.com/services/faq/smb/using_samba/html/ch01_03.htm


Name Resolutions Summary

MS provides many options for NetBIOS name resolution such as local cache lookup, WINS server query, broadcast, DNS server query, and LMHOSTS and HOSTS lookup. Microsoft TCP/IP uses NetBIOS over TCP/IP (NetBT) to support the NetBIOS client and server programs in the LAN and WAN environments. In the most cases, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses in workgroup network and WINS resolves NetBIOS names to IP addresses in domain network.

Common NetBIOS name problem

NetBIOS names must be between 1 and 15 characters long (the names are up to 16 characters, but the last character is reserved as a special characters). For that reason, you should not give a computer name longer than 15 characters.

Duplicate name issue
Symptoms: Event viewer may show Event ID 4320, Event ID: 4319. You may get system error 52 and a duplicate name has been detected on the TCP network.
Resolutions:
1. If two computers on the Network with the same name, use the nbtstat -n command to find out these two computers, for example, using nbtstat -n to check the name and ip of the local computer, and then using nbtstat -a command with the IP address to get the another computer name.
2. If identical username is logging on to multiple computers, the usernames will register with a <03h>, and that may cause the name conflict in the network. Ask the user to log off of all computers and log back on to just one computer.
3. This may be occurred because of inactive or duplicate names in the WINS Database. Go to the WINS server, check the database and delete the inactive or duplicated names.
4. This my be occurred because of a possibly corrupted DHCP database. To clear DHCP related entries or clean out old settings in the registry, delete any .mib files, and then reinstall DHCP.
5. This may be occurred because of conflicting NICs in a Multihomed Computer. To fix this problem, you may want to stop Computer Browser service or uncheck one of Client for MS Network.
6. This may be ocurred because IPCONFIG /ALL returns incorrect host name. To change computer name in the TCP/IP parameters section, run regedit.exe, and locate the HOSTNAME value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters, and then edit the string data.

Still need help, contact consultant Your feedback and contributions to this web site
Failed to access NetBT driver -- NetBT may not be loaded

causes: 1. No rights to run NBTSTAT.
2. Missing NetBT parameters in registry.
3. NetBIOS is not enabled.

How can I install NetBEUI on WinXP?
A: NetBEUI is not included on XP by default. To install NetBEUI, 1) Copy Nbf.sys to the %SYSTEMROOT%\System32\Drivers
directory from Windows XP CD - Valueadd\MSFT\Net\NetBEUI folder. 2) Copy Netnbf.inf to the %SYSTEMROOT%\Inf hidden
directory. 3) Go to Control Panel>Network Connections, right-click the adapter you want to add NetBEUI to, and then click Properties>General>Install>Protocol>Add>NetBEUI Protocol.

How to configure WINS for a non-WINS client

If your have non-WINS machines on a subnet and want to them to be visible browsing participants, you may have two options to setup WINS for non-WINS machines. 1) Enable WINS Agent. To setup a machine as proxy agent in NT 4, run regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters. Double-click on the EnableProxy and set vale to 1. 2) add static entries on WINS Manager. To do this, run WINS Manager>Mappings>Static Mappings and add information.

How to check NetBIOS status

To check if the computer has registered a 00, a 03, and a 20 entry, and these correspond to the Workstation service, the Messenger service, and the Server service, respectively, use nbtstat -n. That will list local NetBIOS names. To list remote computer name table, use nbtstat -a computer name or nbtstat -A IP.

How to disable WINS Proxy

To disable wins proxy, go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters, change the value to 0.

Value Name: EnableProxy
Value Type: REG_DWORD
Values: Boolean (0 or 1)
Default: 0

How to modify Node Type

1. For W2K/XP, go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters to make change:
Name: DhcpNodeType
Value Type: REG_DWORD - Number
Valid Range: 1,2,4,8 (b-node, p-node, m-node, h-node)
Default: 1 or 8 based on the WINS server configuration

If this key is present, it will override the DhcpNodeType key. If neither key is present, the system defaults to b-node if there are no WINS servers configured for the client. The system defaults to h-node if there is at least one WINS server configured.
2. Windows 95, go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP
Name: NodeType
Value type: DWORD
Valid range: 1, 2, 4, or 8
Default: 1 (b-node) if no value is specified or no WINS servers are configured on the network; 8 (h-node) if WINS servers are specified and NodeType is not otherwise defined in the Registry.

If DNS is enabled (which also enabled LMHOSTS in Windows 95), name resolution will also follow the mode defined by this parameter. This value can also be configured using DHCP.

How to re-cache the NetBIOS name

If you can ping a remote computer IP but not the name, and you have WINS or enable NetBIOS over TCP/IP, this may be an outdated NetBIOS name resolution in the local NetBIOS name cache. You may want to run NBTSTAT -r to reset the cache and force the computer to retrieve remote computer name.

How to fix name resolution issue on a standard DNS network

Some w2k/xp computer have a difficulty to connect to a laptop and your company has standardized on DNS for name resolution (no WINS and NetBIOS enabled). you also find that you can ping the laptop ip but not name. You may want to run ipconfig /registerdns to renew the ip configuration and register the laptop's DNS name with the DNS.



NetBios vs NetBeui

I see a lot of confusion between NetBeui and NetBios. The differences are simple, but possibly misleading. In NT (and Win9x) terms, NetBeui is a transport protocol, at the same level in the network stack as TCP/IP and IPX/SPX. It is a simpler transport protocol than TCP/IP in that it does not support routing and is self configuring. NetBios, on the other hand, is a network interface and sits above the transport protocols.

A major weakness of NetBios is it's naming. With NetBios, the name space is flat, thus all systems and domains have to have a unique name, unlike DNS names which, being hierarchal, allows substaintially more flexibility.All NT, 95 and Windows for Workgroups systems have unique NetBios names. NT also used NetBios names to find different services by utilising the 16th character (often shown as NetBios name - the xx is the 16th character and is in hex). To find the domain controler for the Hawaii domain, for example, you would find HAWAII<1B>.

A programmer would use NetBios to access the transport protocols. In this sense, NetBios is transport independent. NetBios over TCP/IP (NBT) is defined in RFC 1001/2. With NT, if you have TCP/IP you have NetBios too, there's no way to separate this.

A final note: to a large degree, NetBios as both a network interface and a naming convention will be going in Windows 2000. Although Windows 2000 will support NetBios names (for downlevel clients and domains), DNS as the locator service and DNS names as standard.

Setting up new router/switch

Get ready
Choose your hostname, IP addresses and make the DNS reflect these.

Log on
Connect your terminal to the console port. If brand new, you can just hit return when asked for a password. Otherwise, enter our password. Now prepare to configure the box by entering privileged mode:

enable

and give the password, again possibly just hitting return.
--------------------------------------------------------------------------------

Get a clean state
If the box is being recycled, make the config "out of the box" with:
clear config all

If you are changing the type of module in a slot, nuke the config for that slot with:
clear config 2

or
clear config 3

as appropriate. If you don't do this, the spanning tree parameters may be wrong.
--------------------------------------------------------------------------------

Give the box its identity
set password
set enablepass
set prompt
set banner motd @
The it-network@blogger.com

Authorized access only
#
set system name
set system location
set system contact

--------------------------------------------------------------------------------

SNMP
set snmp community read-only
set snmp community read-write
set snmp community read-write-all
set snmp trap 10.10.10.1



--------------------------------------------------------------------------------

IP host config
set int eth0 10.10.1.1 255.255.255.0
set ip route default 10.10.1.3

--------------------------------------------------------------------------------

DNS
set ip dns server 10.10.1.200
set ip dns domain
set ip dns enable


This step is not essential. The DNS feature can only be used by an administrator who is logged in to the switch. If there are network problems, DNS lookups will probably fail anyway. Bare IP addresses will always do, and are what is usually used in this context.
--------------------------------------------------------------------------------

Set the time
This is not vital, but you may be confused in an emergency if the box logs problems with wrong times on them. Set the time:
set ntp client enable
set ntp server 10.10.1.100
set ntp server 10.10.1.101

If the box is going somewhere really weird where it won't be able to reach those NTP servers, set the time instead with:
set time Monday 07/20/1999 10:00:00

set timezone

--------------------------------------------------------------------------------

Turn on CGMP
CGMP is used for multicasting. It should be turned on. It is off by default on CatOS.
set cgmp enable



--------------------------------------------------------------------------------

Turn off VTP

set vtp mode transparent

--------------------------------------------------------------------------------

Set up necessary VLANs
set vlan 13 name staff
set vlan 14 name student


--------------------------------------------------------------------------------

Turn off bad things
Cisco have some funny options turned on by default. This can muck up devices which boot fast.
Use the example below as a guide, adjusting the port numbers for the cards you have installed. Note that on older CatOS versions the "port channel" commands only seem to work if you do the ports one module at a time.

Be extremely careful if you are trying to do this "cleanup" on a box which is already configured. It is very easy to turn off important trunks by doing this. Do not copy these commands or port numbers!

For CatOS 6.1 and newer (most new boxes bought from now on):

set trunk all off
set port channel all mode off


or (an example for a full 4006) -- still CatOS 6.1 and newer:
set trunk 1/1-2,2/1-48,3/1-48,4/1-48,5/1-48,6/1-48 off
set port channel 1/1-2 mode off
set port channel 2/1-48 mode off
set port channel 3/1-48 mode off
set port channel 4/1-48 mode off
set port channel 5/1-48 mode off
set port channel 6/1-48 mode off


For CatOS prior to 6.1 (most of our 4003s in production that haven't been upgraded yet):
set trunk 2/1-34,3/1-48 off
set port channel 2/1-34 off
set port channel 3/1-48 off


If you are adding a card to a previously vacant slot, you will need to fix up these settings for that module.


--------------------------------------------------------------------------------

GBIC trunks
Make sure that VLANs to be carried on the trunk have all been set up. Prune off all other VLANs except VLAN 1 (from release 7.2, dot1q trunks support 4096 VLANs). Give the port a sensible name.
set vlan 1 2/1
set trunk 2/1 on
clear trunk 2/1 2-1005
clear trunk 2/1 1025-4094
set trunk 2/1 13-14
set port name 2/1 c4-h04-2
set spantree portfast 2/1 disable

Don't worry about autonegotiation or duplicity - these don't apply to gigabit.
--------------------------------------------------------------------------------

Slower trunks (over copper usually)
Set the speed and the duplicity explicitly.
set vlan 1 2/3
set trunk 2/3 on
clear trunk 2/3 2-1005
clear trunk 2/3 1025-4094
set trunk 2/3 13-14
set port name 2/3 c4-h04-3
set port speed 2/3 100
set port duplex 2/3 full
set spantree portfast 2/3 disable

Make sure the other end of the trunk matches exactly. Don't let trunks autonegotiate anything.
--------------------------------------------------------------------------------

Vanilla ports
Ports to be connected to a single host:
set vlan 14 2/3-34
set vlan 13 3/1-48
set spantree portfast 2/3-34,3/1-48 enable

portfast mode must never be set on links to other networking devices (hubs, switches, routers, bridges, concentrators). It will sabotage the spanning tree calculations.
To accommodate particular computers, you may need to set some of these on some ports, e.g.:

set port speed 3/1 100
set port duplex 3/1 full

The speed will usually autonegotiate, but this will sometimes fail, particularly with Sun computers. Any big important computer should have all of these parameters configured explicitly, both at the switch and on the computer.
--------------------------------------------------------------------------------

Dumb hubs
Set parameters explicitly to the appropriate values, e.g.:
set vlan 14 2/3
set spantree portfast 2/3 disable
set port speed 2/3 10
set port duplex 2/3 half

It is very important to turn off portfast mode. Trunks are kind enough to ignore it, but vanilla links to dumb devices won't. Although dumb hubs will not participate in spanning tree, a switch could be daisy-chained off the dumb hub later, causing problems.
--------------------------------------------------------------------------------

Undoing things
Examples:
set trunk 2/1 off
set port duplex 2/3
set port speed 2/3
set port name 2/3
set spantree portfast 2/3 disable
set vlan 1 2/3
clear config 3


--------------------------------------------------------------------------------

Making changes later
When making changes to a port, check that you have the right:
port name
port duplex
port speed
portfast mode
trunking or not
VLANs down a trunk - exactly those needed, at both ends of the trunk

--------------------------------------------------------------------------------