There are dark places in the router where many administrators fear to go. In the world of Cisco routers, these places are advanced configurations the likes of which mere mortals rarely see (in fact, few normal network administrators see these configurations either.) However, there may come a day when you need to set up these commands in your routers. When you do, this section will be an excellent reference. Until then, you might not want to read this chapter, because if you do, it will only give you ideas. Once these ideas start kicking around in your head, you might want to start trying them.

If you decide to proceed, you must have a good plan. First, do not implement any new changes that could lock you out of a router or bring the network down during business hours. Second, be sure to back up your original configuration, so you can revert to it if necessary. Finally, make sure you have physical access to the router, so you can break into it through the console port and eliminate a bad configuration. If at all possible, you should try out these configurations on a spare router. If you do not have one, you might try to pick up a used router, which will let you attempt many of these configurations in a non-critical environment.

You have been warned. Some of these configurations, if improperly implemented, can lock you out of a router, or worse, cause serious network problems. It is up to you to make sure you consider the consequences of your actions.

TCP/IP networking assigns an IP address (or multiple IP addresses) to a single machine (e.g., 204.176.111.4). Port numbers at that IP address reference services that operate on that machine (e.g., 204.176.111.4:23). This allows one machine to have multiple services such as mail, WWW, and telnet. Port numbering follows a standard to prevent confusion and allow for ease of communication. Some of these port numbers are 80 for HTTP, 23 for telnet, and 25 for SMTP (Simple Mail Transport Protocol).

Packet filters block packets based on information found in the packet itself. Packet filtering is the most basic kind of firewall next to the "air-gap firewall" (See Marcus Ranum’s installation instructions in Figure 8-1). You can select which packets a router will allow to enter or leave based on destination port, source address, and/or destination address. You can also choose the interface to which to apply the packet filter. Packet filters can be applied to the IP protocol in general, or any of its sub-protocols: TCP, UDP (User Datagram Protocol), and ICMP (Internet Control Message Protocol). Each selection is entered into a packet filter rule, and all these rules make up an access list.

This kind of firewall gives you extremely fine granularity to control access to and between your networks. However, it does come at a cost. Packet filters are difficult to conceptualize for some people, and generally hard to set up. Also, they are difficult to edit on the router, and cause additional processor overhead (as much as 30% on smaller routers like the 700, 1000, and 2500 series.) It may also slow down your network connection.

The more rules there are in your packet filter, the slower your connection can become. The filter must compare each packet must against each rule until it finds a match. Once a packet matches a rule, comparison ceases and the filter either passes on or discards the packet. This makes packet filter optimization extremely important. Combining as many rules as possible into one rule optimizes packet filters.

The packet filter paradigm is also important. The two choices are 'open' or 'closed'. An open paradigm passes all packets unless specifically denied by a rule. A closed paradigm rejects all packets unless specifically permitted by a rule. Balance the specific needs of your network users against the need to secure your network from outside intrusion and tampering. Allowing users to get their work done while securing the network from intrusion is a difficult task, but one that can be accomplished. It may require further reading about network security and firewalls in general before starting to construct packet filters.

Filtering networks is done using the network number and wildcard bits. The network number is the network portion of the IP address, with the host bits all set to zero. The wildcard bits determine which portion of the address the access list will act on. Only bits set to zero are acted upon (bits set to one are ignored.) This is the exact opposite of a netmask. Remember that this number is in bits, and you will always have all zeros to the left of the first one, and all ones to the right of the last zero. Table 8-1 shows some examples of netmasks and wildcard bits.

Table 8-1. Examples of subnet masks and wildcard bits.

If you do not understand network numbers and netmasks, you should read more about them in a book on TCP/IP networking, such as TCP/IP Complete by Edgar Taylor and Hands-On TCP/IP by Paul Simoneau.

Creating packet filters in IOS is a two-part task. First, the packet filter is assembled out of a series of rules, created with the "access-list" command. Next, the assembled packet filter is applied to an interface with the "ip access-group" command. Sometimes the entire packet filter is referred to as an access list.

There are different types of access lists available in IOS. The access lists are broken up into ranges of numbers, which define what protocols and options are available. Table 8-2 lists protocols that use access lists specified by numbers, and also includes the range of access list numbers that is valid for each protocol.

Table 8-2: Protocols with access lists specified by numbers

Each protocol has its own set of specific tasks and rules required for you to provide packet filtering. WE will focus on IP and extended IP access lists, as those are the most common in the Internet world. You should have a good understanding of the IP protocol to understand packet filters.

Standard IP access lists are simple, and limited in scope. Their access list range is from 1 to 99. You can use any arbitrary number in this range since their purpose is simply to match where they are applied to an Interface or a routing statement (as in Chapter 6). For simplicity's sake, you should start with 1 and increment for each additional list. The next keyword allows you to permit or deny packets with this specific access list. Finally, you can choose source address of a host or network, or the keyword any.

To filter a host, you would first enter the host name or IP address. To filter a network, you would enter the network number, followed by the wildcard bits. To filter all networks and hosts, you would use the keyword any. With standard IP addresses, you are limited to selecting only source addresses. You cannot define port numbers, protocols, or destination information; nor can you log the point when a packet matched the filter. Figure 8-2 shows examples of standard IP access list commands.

These have more options and will be more useful in many situations. They start the same as standard IP access lists, but their numbers range from 100 through 199. They give you the option permit or deny, and allow you to set up a dynamic access list. We will not discuss dynamic access lists in this book.

In this book, WE will focus on filtering the IP, ICMP, TCP, and UDP protocols. IP is the underlying protocol for the other three. Anything you filter with IP will also affect the other protocols. Control messages on the network use ICMP packets, as well as programs like "ping" and "traceroute". Most user protocols employ TCP packets. Programs like "telnet", "ftp", and web browsers all use TCP packets. UDP packets are also used by user programs, but less so than TCP. NTP, NFS (Network File System), and TFTP all use UDP packets. Since ICMP, TCP, and UDP packets are all part of the IP protocol, you may sometimes see them referred to as ICMP/IP, TCP/IP, and UDP/IP, although TCP/IP is the most prevalent of these.

The next step in assembling an Extended IP access list is defining the source and destination addresses. The source comes first, followed by the destination. You can use the keyword any to indicate all hosts. You should use the keyword host before listing a host IP address and use the standard network number and wildcard bits notation to define network ranges. Next, come protocol specific options, and finally, the ability to turn logging on for that rule. If you use the command line help, you will see that there are many options available for each sub-protocol. We will focus on those that allow you to select ports, log information, and deal with established connections. Figure 8-4 shows some examples of Extended IP access lists.

There are some major things to keep in mind when designing packet filters. All packet filters rules process from the top down. There is an implicit "deny all" at the end of all access lists. New lines in the configuration always add at the end. In addition, undefined lists referenced by an interface have an implicit "permit any".

Since all packets undergo top-down evaluation, the order of the access list commands is vital. If your first rule is an explicit "permit all", you would never reach any subsequent rules. Conversely, if you bury a rule that matches a majority of packets below many rules that match only a few packets, the earlier, less general rules must be evaluated before the broader rule. This adds a lot of processing overhead to your routers, and would slow down network traffic. Remember, the order of access-list commands counts.

Since there is an implicit "deny all" at the end of all access lists, they may not function they way you think they should. To compensate for this, you should end all your access lists with explicit "permit" or "deny all" statements so they can will be easier to read. Easy to read access lists are easy to maintain.

The final step in setting up an access list is to assign it to one or more interfaces. This is done using the "ip access-group NUM" command, where NUM is the same number used in the access list that you want to apply to the interface. By default, the access list is applied to packets leaving (or going out of) the interface. You should always use the keywords in or out to make the command easier to read.

Be careful when choosing in versus out. This option reverses the meanings of the source and destination definitions in your access lists. For example, a packet destined for the local Ethernet would be the destination when coming out that Ethernet port, or going in some other port. It could not be the destination coming in that Ethernet port, since it is on the local network, and therefore wouldn't be routed anywhere (never entering the router at all.)

Another concern when choosing in or out is router processor overhead. If you use out, the packet must enter the router first, be evaluated for routing, and then be evaluated for the access list. If you use in, the packet does not enter the router unless it first passes the access list. This requires less processing power for the same job, making it more efficient.

As a tutorial, we will create two packet filters for a simple configuration: one mostly closed, the other mostly open. In this example, we have a Cisco 2501 router with a local Ethernet network, and a leased line to an ISP. This is shown in Figure 8-5. We will setup a packet filter inbound on the serial port to protect the router and the company from the Internet. We will allow only inbound WWW and mail traffic to access the web server and the mail server. We will allow the local users will to go anywhere on the Internet they choose, using any protocol. We will also protect against someone on the Internet claiming to be on the local Ethernet. This is called 'IP address spoofing'.

In addition, we will block all telnet connections to the router, in order to prevent someone on the Internet from subverting the router. We will also block all incoming file sharing protocols, such as those used by Microsoft for peer-to-peer networking, and SUN Microsystems NFS (Network File System). Our router's two IP addresses are 137.39.1.3 on the serial interface and 208.213.189.1 on the Ethernet interface.

In a mostly closed scenario, we need only specify what we want to permit, and then use an explicit "deny all" to block the rest. In a mostly open scenario, we would deny what we do not want, and permit the rest with an explicit "permit all" command. In both cases, the first rules deny connections from local networks. Since a packet from our local network will never originate on the Internet (unless someone is trying to spoof our IP network), this should always be blocked. IP spoofing is one way a hacker can trick machines on your network into trusting him.

Since no packets coming from the Internet should ever appear to be coming from the local Ethernet, this is the first thing we deny. This stops IP spoofing attacks. Next, we allow established connections back to users. Without this, no outbound connections from the local users to the Internet could happen. Any user on the Internet may connect to the mail server using port 25 (SMTP), and to the web server using port 80 (www). This fulfills most of our requirements except for letting the users go anywhere and do anything. Unfortunately, the file transfer protocol (FTP) requires inbound connections on TCP port 20 and on many ports above 1023. In order to allow users to continue to use FTP, we must open these ports as well. We could open all ports above 1023 by ending a command with "gt 1023", but this may not be necessary. A majority of FTP connections will be destined for the first few thousand ports, so we might use the range of ports between 1024 and 6000. This would be done by ending the command "range 1024 6000".

The final line is an explicit "deny all". Although there is already an implicit "deny all" statement in place, this makes the packet filter easier to read. Figure 8-6 shows the command lines used to create the mostly closed filter.

Even in a mostly open environment, we start by blocking IP spoofing and allowing established connections. Since we only want to let web and mail traffic into their respective servers, we add permit statements for this, and then use a deny statement for the whole network. Since the filter undergoes top-down interpretation, web and mail connection can still take place to the proper servers. Next, we deny access to the router's two IP addresses. Finally, we block TCP/IP ports 137 through 139 and UDP/IP ports 137, 138, and 2049 to block Microsoft and SUN file sharing protocols.

The final line is an explicit "permit all". This will override the implicit "deny all" statement which comes after it by default. Figure 8-7 shows the command lines used to create the mostly open filter.

Once the packet filter has been created and is ready to be put in place, we need to add it to the proper interface. Remember if we choose the default "out" for the direction, our access list will be applied explicitly. This will make the configuration easier to read. The access list is applied to an interface using the "ip access-group NUM" command, where NUM is the number of the access list you want to apply. Always explicitly append the keywords "in" or "out" to the end of the command.

In Figure 8-8, we add access list 100 to the interface serial0. The access list filters packets that come in to the serial port.

You must also test your packet filters to make sure they are working properly. From inside your network, you should use all possible programs to make sure your users can still get out to the Internet. This is relatively easy but time consuming. The true challenge comes when trying to test your inbound filters.

Testing inbound filters must happen from the Internet and for this you will need a way of getting out of your network and coming back in. There are several ways to do this. You can make a dial-up connection to the Internet through any ISP (including yours) and content providing services like America Online and CompuServe, which offer Internet connectivity. You could also make a trip to your local college, mall, library, or Internet café that has an Internet connection. This will let you test, but making corrections will be difficult if you discover a problem. For this, you may be tempted to take a printout of your router configuration file with you. If you do, make sure to obscure any passwords first, just in case someone is leaning over your shoulder. Never leave it anywhere and do not throw it in the trash. Take it back to the office, or home and either burn it or shred it. This is your network security you are carrying around with you. There is no such thing as too much caution.

Another way to test it is to get a UNIX shell account somewhere out on the Internet, usually through an ISP or college. Certain text-based tools will let you test remotely. Chief among these is "telnet". The "telnet" command allows you to pick which port you connect to on a remote system (by default, port 23.) To test the basic packet filter, you could first try to telnet back to the router. The router should deny your connection. Next, you could telnet to port 80 on your web server and port 25 on your mail server, and pretend to be a proper client. All you need to do is send the string "GET /" to the web server, and "QUIT" to the mail server to see if they are alive. As you can see in Figure 8-9, the servers respond to the telnet command and send back data. This lets you know they are functioning.

In order to do a true test of services like WWW and SMTP, you should also set up dummy hosts with these services and test connecting to them. This will let you know that you have not made a mistake and are allowing all protocols to all servers. You can also test file sharing by contacting someone on the Internet and getting read-only access to NFS and Microsoft based servers. You can try to see the NFS server with the UNIX command "showmount -e IP_ADDRESS". To see a Microsoft Windows machine, you will need to add the host name and IP address to a file named "lmhosts" (without a file extension) in the C:\WINDOWS directory. After rebooting, right click on the Network Neighborhood icon, and choose Find Computer. Enter the name of the machine you put in the "lmhosts" file. If your packet filters are correct, you should not be able to see either type of system.

From there, follow a strict methodology. First, make sure never to experiment on an operational router. Edit your packet filters in a text editor and use the "configure network" command or the cut and paste buffer of your GUI to transfer them to the router. Always use the "no access-list NUM" command to clear the old packet filter before entering the new one. Remember that if you lock yourself out of the router before you save the configuration to NVRAM, you should still be able to access the router from the console serial port. If not, you can always reboot it to restore it to the start-up configuration.

Using dial-up routing adds an important new requirement to packet filters; namely, the ability to save money. In many areas, ISDN lines are billed per minute. In the Northeast United States, Bell Atlantic charges as much as two cents per minute per channel for data connections. This makes it possible for your ISDN bill to be several hundred dollars a month if left up for long periods. At those prices, you could probably afford a T1 line. So, how can packet filters keep these costs down?

Unlike IOS routers, the 700 series routers are able to declare packets insignificant to the counters that bring up, and keep up, the ISDN WAN connection. Along with the filter types "block" and "accept" that allow you to create basic firewalls, you also get two new ones, "demand" and "ignore". "Block" and "accept" work like "permit" and "deny" in IOS. They allow you to specify which packets are and are not allowed into or out of an interface. "Demand" allows you to declare which packets will affect the WAN threshold and idle time-out counters. "Ignore" does the opposite of "demand". If the WAN connection is up, the router passes packets through without affecting when the WAN connection will come down. If the WAN connection is down, the router drops the packets and will not bring the WAN connection back up.

In IOS, you create packet filters and then assign them to one or more interfaces. The "set ip filter" command creates packet filters directly into individual profiles in the 700 series routers, unlike packet filters in IOS. So if you have several sites you dial into with ISDN, you may want to add packet filters to all of them. In addition, you may want to consider blocking packets from passing between two sites, because it may represent a security risk if you connect one channel to each site simultaneously (see Figure 8-10.) A connection like this may allow a clever hacker to enter a corporate network through the home user's ISDN router.

The syntax for the "set ip filter" command is complex. You must specify which type of protocol you want to filter, whether it is an inbound or an outbound filter, and (optionally) the source and/or destination address and the port to you want to filter. Finally, you must choose the action the filter will take. There are seven types of protocols that you can set filters on:

• icmp - Internet Control Message Protocol (ICMP) packets.
• icmpxrd - ICMP packets, except redirect packets.
• icmprd - ICMP redirect packets.
• tcp - Transmission Control Protocol (TCP) packets.
• tcpsyn -TCP SYN (connection establishment) packets.
• tcpxsyn -TCP packets, except SYN.
• udp - User Datagram Packets.

These give you a lot of flexibility when setting up filters, but users will most likely stay with the icmp, tcp, and udp types of protocols.

Choose inbound or outbound by using the keywords "in" and "out". Remember that this will affect the meaning of the source and destination addresses. Inbound filters process before the packet enters an interface, and outbound filters process before a packet leaves an interface.

The selection of source and destination can be tricky. You can choose either a source or destination address, or both. Specify a source address with the keyword "source", and a destination address with the keyword "destination". Use an equal sign to assign the address to the keyword. In addition to the address itself, you can use the command "/bits" to specify the number bits in the netmask. This is typically 8 for a class A network, 16 for a class B, 24 for a class C, and 32 for a host. Finally, you can choose the port number on which to filter. The port number(s) follow(s) and is (are) separated from the IP address by a colon (:).

Port ranges can be set using the plus (+) and minus (-) signs. The plus sign allows tells the router to filter all ports greater than those listed in your filter. So, "1023+" specifies ports 1024 and up. The minus sign allows you to set a discrete range of ports to filter. For example, "137-139" will make the filter act on packets destined for ports 137, 138, and 139.

The final part of the filter syntax specifies the action: "block", "accept", "demand", or "ignore". "Block" tells the router not to pass the packet on. "Accept" tells the router to allow the packet to pass unmolested. "Demand" tells the router that the packet is of interest to the threshold queues which determine when to bring the ISDN line up, and the idle timer, which determines when to bring the ISDN line down. Conversely, the "ignore" command tells the router that the packets are not interesting to the threshold queues or the idle timer, and to drop them if the line is down.

Some examples of packet filters are listed in Figure 8-11.

The router processes any packets that fail to match a filter in order of precedence, as follows:

• If any one of the filters is set to "accept", a packet that does not match at least one filter is blocked.
• If all the filters are set to "block", a packet that does not match any filter is accepted.
• If any one of the filters is set to "demand", a packet that does not match a "demand" filter is ignored.
• If "ignore" filters are used, a packet that does not match an "ignore" filter is treated as "demand".

To block packets between specific machines on a specific port, you must specify an IP sub-protocol. If you do not, the router will filter on the IP. Just like in IOS, you can not filter port numbers in the IP protocol, but rather only on a sub-protocol such as UDP, TCP, or ICMP. Unlike IOS, the 700 series routers will allow you to specify a port number without choosing a sub-protocol. This allows you to create a configuration where the port number is ignored, but you can still see it in the configuration. This is confusing to no end if you do it by mistake, so make sure to add your sub-protocol type information.

A good example of this problem is listed in Figure 8-12. In the first line, you can see an invalid command that does not use a sub-protocol, but has a port number. This command attempted to block WWW traffic between the two IP addresses only, while letting those machines continue to communicate with each other on all other protocols. The second line shows what the command really does, i.e., block all traffic between those machines. The third line shows the correct command with the TCP sub-protocol chosen.

Series 700 users may face different problems than normal WAN users. Obviously, if they connect to the Internet directly, they need to use packet filters to provide some measure of security for their data. However, if they are part of a corporate network, they may have security provided for them by the corporate firewall. This may remove the need for security packet filters, but there is still the need for money saving packet filters.

One problem that many 700 series users see is the line staying up too long. This can be caused by any number of network protocols chattering on the LAN, but two big ones are Microsoft Windows NT browsers and Microsoft Windows 95 shared directories. Microsoft NT announcing it has shares available will chatter incessantly to the local broadcast address. If it is running the License Manager, it will also chat on the network. Windows 95 sends packets to the undirected broadcast address (255.255.255.255) and ports 137, 138 and 139 if it is sharing its resources. If you block these types of packets from passing through your router, you will have problems sharing files or licenses.

Rather than blocking these protocols, a better way to handle this would be "ignore" all packets to these addresses and ports. When using "ignore" or "demand" to filter any packets, you must set the filters on the outbound side of the WAN profile. Figure 8-13 shows the packet filter commands used to help reduce ISDN usage. This will not block these packets, but rather keep them from bringing up or keeping up the ISDN line. You can see that all packets destined for the undirected (255.255.255.255) and local (204.176.117.255) broadcast addresses are being ignored. The router ignores all packets from the local network using the Microsoft file sharing ports as well.

The packet filter designs for mostly open and mostly closed scenarios detailed earlier in this section are also valid for the 700 series routers. Only the implementation will change, due to the different configuration syntax. First, we will set up a packet filter inbound on the WAN profile for protection from the Internet. Only inbound Internet traffic will have permission to access only the web server. The SOHO/RO users will have access to anywhere on the Internet. We will also protect against IP address spoofing.

In addition, we will make sure to block all telnet connections in to the network, since we offer no public telnet services. We will also block all incoming file sharing protocols, such as those used by Microsoft for peer-to-peer networking, and SUN Microsystems NFS (Network File System). The local network address is 208.213.189.0 and the local web server's IP address is 208.213.189.55. The mostly open packet filter is shown in Figure 8-14, while the mostly closed packet filter is shown in Figure 8-15.

DHCP is a client-server protocol that allows devices on an IP network to request configuration information from a DHCP server. Ordinarily, DHCP allocates IP addresses from a central pool on an as-needed basis. DHCP is useful for assigning IP addresses to hosts connected to the network temporarily, or for sharing a limited pool of IP addresses among a group of hosts that do not need permanent IP addresses. It can also remove the burden of IP address management for machines that do not need fixed IP addresses.

DHCP increases automation and lessens network administration problems by eliminating the need for the manual configuration of individual computers, printers, and shared file systems. It also prevents the simultaneous use of the same IP address by two clients and allows for configuration from a central site.

A Cisco 700 series router acting as a DHCP server can provide the following information to the DHCP client machines (usually MS Windows 95):

• IP address (example: 199.5.37.248)
• Internet domain name (example: gryphon.com)
• The IP addresses of the primary and secondary Internet Domain Name Service (DNS) servers
• The IP addresses of the primary and secondary IP gateways (i.e., the default route for the clients, usually the IP address of the routers LAN interface)
• NetBIOS Scope (also known as TCP/IP Scope)
• IP Netmask (example: 255.255.255.0)
• The IP addresses of the primary and secondary WINS (Windows Internet Name Service) servers

The information configurable in the 700 series DHCP server is the minimum necessary to get a Windows 95 client automatically configured on the network. If you need to send more information to the client machines, you will need to get a more fully functional DHCP server. A DHCP server will run on almost any server OS. SCO UnixWare and Open Server, Microsoft NT, Linux, and SUN Solaris all support DHCP servers.

The DHCP server in the 700 series routers is limited to managing a maximum of 254 IP addresses. If your subnet has less than 254 addresses, you will have no problem. If your subnet has more than 254 addresses, this implementation of DHCP will only serve 254 of them and you do have a problem. If you need to serve more than 254 addresses, you will need to look to a more fully featured DHCP server.

DHCP is only available on the 760 and 700 series routers. The DHCP code does not exist in the operating system for the older 750 series routers. DHCP is not available for IOS routers. A similar protocol to automatically configure clients dialing into a modem or ISDN line does exist for IOS, but it only supports PPP dial-in clients, not LAN clients. If you need DHCP services for a LAN and have only an IOS based router, you will not be able to get it from your router.

Configuring the DHCP server on the 700 series routers is actually quite easy. Most of the information used to configure it will already exist in your client PCs. You simply need to extract it from one PC and then set the machine for automatic configuration. The first step is to turn on the DHCP server with the "set dhcp server" command. The next step is to decide on the range of addresses that DHCP will manage. The DHCP server will automatically assign these addresses to clients on the network, and the network administrator will no longer need to manage them. You must pick a starting address, then assign the total number of addresses from that starting point that DHCP will control. If you used an IP address of 204.176.189.100 and a total number of 110, then DHCP will control all IP addresses in the range between 204.176.189.100 and 204.176.189.209. Remember that you count address 204.176.189.100 as the first address, so you are really adding 109 to 100 to get the last IP address controlled by the server.

You should make sure that any machines on the network are not using IP addresses in your chosen range. If they are, you will eventually have multiple machines with the same IP addresses on your network. This will cause problems for the end users, and cause problems in the end for you, too. So, make sure no IP addresses in your range are in use, or pay the price later.

The chosen IP addresses must be part of the same IP network as the router's LAN interface. If they are not, the PCs will never be able to talk to the router after getting an IP address. This is because the PC will be on a different logical network then the router, and therefore unable to see it.

Once you have decided on the range of addresses the DHCP server will control, use the "set dhcp address" command to configure it into the router. From this point on, you have turned over control for these IP addresses to the router's DHCP server. Figure 8-16 shows an example of the command used to configure the DHCP range of addresses on the router.

Next, you need to complete the IP address set up by telling the clients their netmask and default gateway. Configure the netmask with the "set dhcp netmask" command. The default gateway is set with the "set dhcp gateway primary" command. Typically, the netmask will be the same as that on the LAN interface of the router. The primary gateway is almost always the IP address of the LAN interface itself. If you have more than one router on the network, you may want to set a secondary default gateway, but this is usually not the case. Examples of these commands can be seen in Figure 8-17.

The final commands deal with host name resolution. Both standard Internet DNS and Microsoft WINS host resolution are supported. You must know the IP addresses of both kinds of servers, if you want to configure them. If used, DNS servers will reside at a corporate site or ISP. WINS servers will always be part of your local or corporate network. In addition to this, you will need to know the Internet domain of your hosts. (If you are the network administrator, you really should know this.) However, if you do not, you can usually find it in the DNS Configuration tab of the TCP/IP properties for a LAN adapter, under Network Neighborhood in Microsoft Windows (see Figure 8-18).

If you are not connected to the Internet and are not using DNS, you may not have an Internet domain; therefore, you will not need to fill in the DNS server or the domain name information. If this is the case, you are probably using WINS, so you will need to add that information instead. Locate it in the WINS Configuration tab of the TCP/IP properties for a LAN adapter, under Network Neighborhood in Microsoft Windows (see Figure 8-19).

Once you determine this information, you can configure it into the router. Add the DHCP domain with the "set dhcp domain" command. Add the DNS server IP addresses with the "set dhcp dns" command. Finally, add the WINS server IP addresses with the "set dhcp wins" command. You may have noticed that the WINS configuration screen in Figure 8-19 used the same IP address for both the primary and secondary WIN servers. If you only have one WINS server, you may want to use it for both primary and secondary server IDs. Due to the problems involved with remote networks, a WINS server sometimes cannot respond to a client before it times out. By using the WINS server as both primary and secondary server ID, you double your chances of getting correct information from the server. These configuration commands are shown in Figure 8-20.

Configuring a Microsoft Windows client to use DHCP is very simple. To do so, remove all information in the WINS and DNS configuration tabs, as well as the default gateway for the LAN adapter. Next, choose to "Obtain and IP address automatically" in the IP Address tab (see Figure 8-21). The next time the system reboots, it will ask the DHCP server for an IP address, and all the configuration information you have given the router will be sent to the PC. You can check the accuracy of this information using the "winipcfg" command under Windows 95 (see Figure 8-22), or the "ipconfig /all" command under NT.

programmed into the router's DHCP server.

Address pooling is the PPP equivalent of DHCP in IOS and is also simple to configure. Whether you are on an access server or lower end routers like a Cisco 2503, address pooling only works on ISDN and low-speed serial line connections. ISDN connections can be both BRI and PRI. Low-speed serial connections can be the modems in access servers or terminal and modem lines on all routers. You can configure the auxiliary port on every IOS router to use a dial-in modem, but certain routers act as small access servers, and have many low-speed serial connections available.

For the purposes of this section, we will assume that you have already set up the serial or ISDN lines for dial-in, and are currently using static IP addresses. If your router only has a single dial-in port this is OK, but in the case of multiple ports, routing to dial-in sites becomes extremely difficult. By using address pooling, you can conserve IP address space and make your dial-in configurations easier to maintain.

Having the router assign IP addresses to dial-in clients may be easy, but it is limited. Unlike DHCP, which had seven pieces of information to configure remote clients, address pooling only has three. These are: the IP address, DNS server IP addresses, and WINS server IP addresses. The client must itself provide information like the Internet domain name.

Just like with DHCP, you must start by picking a range of addresses for the router to distribute. Set aside one IP address for each low-speed serial port and ISDN B channel on which users will be dialing in. Access servers using T1's for modems have no B channels, only 24 modem lines per T1. Access servers using ISDN PRI service will have one less dial-in connection per PRI than the total number of channels in their underlying leased line (23 for T1 and 29 for E1). Purely serial access server routers like the Cisco 2509 will need one IP address per modem connected to the router.

The IP addresses that you choose should have the same network number as the router's Ethernet interface. If the router has more than one Ethernet address, pick the network to which you want the dial-in users to belong. As with DHCP, these addresses must not be in use anywhere else, or you will get an IP address conflict. An IP address conflict occurs when more than one machine has the same IP address. This confuses the other hosts on the network, as they become unable to distinguish which machine they should talk to. It will also cause much grief for the network administrator, as they will have to troubleshoot the problem.

Once you have determined the IP address range, you configure it into the router using the "ip local pool" command. The first option to this command is the name of the address pool. This is an arbitrary name used to link asynchronous and ISDN interfaces to the address pool so they can use its addresses. You can use almost any name, but you should keep it short and concise. If only one pool you will have only one pool on the router, you could use the name "mypool" for simplicity. The next two options for the command specify the low and high addresses in the pool.

An example of this is shown in Figure 8-23. Here, an access server with 48 modems receives calls through ISDN PRI T1s. Since one channel is lost per PRI for signaling, a maximum of 46 calls are supported, so only 46 IP addresses are needed. Since the low and high numbers are included in the pool, we take the low number and add 45 to it to get the high number.

Next, link this pool into all the Async, Group-Async, and Dialer interfaces on the router that will use it. This is done with the "peer default ip address pool" command, which takes the pool name as its only option. In Figure 8-24, we see this command using the pool name "mypool".

Finally, you can send the IP addresses of the Internet DNS servers and the WINS servers to the dial-in clients using the "async-bootp" command in global configuration mode. This command takes the option dns-server to send the primary and secondary DNS server IP addresses and the nbns-server option for the primary and secondary WINS servers. As with DHCP above, we will set the primary and secondary WINS server to the same IP address. An example of this is shown in Figure 8-25.

Channelized line cards give you the ability to isolate and control each channel of a high-speed serial line (T1 or E1) individually. They do this by providing multiple data paths from the serial line to the interface processor. All of these cards have a built-in DSU, and some also have a built-in CSU. Those with only a built-in DSU must have an external CSU to interface between the card and the telco jack (e.g., NP-CT1 and NP-CE1 for Cisco 4000 series). Those with both a DSU and a CSU built-in allow you to plug the telco jack right into the router (e.g., T1 or E1 line card for Cisco AS5200). It is important to note that the existence of a built-in CSU/DSU in a router does not allow you to control multiple channels independently.

Routers like the Cisco 2524 can be equipped with a built-in T1 CSU/DSU, but this only provides a single data path to the interface. This means you have the flexibility to select the number of channels to use (1-24), and the speed to use them at (56 Kbps or 64 Kbps), but only to make one full or fractional data connection. For example, if you purchased a 512 Kbps fractional T1 leased line, you would configure the router to use eight 64 Kbps channels. The other 16 channels would not be useable by this router.

The channelized line cards come in two specific flavors: T1 or E1. For the rest of this section, we will refer to them as T1 cards, but E1 cards perform the same way. Both varieties will handle a plain T1 or E1, or the same lines with ISDN PRI signaling encoded on them. The ISDN implementation always sacrifices one channel for signaling.

All channelized cards use the "controller" heading for configuration and management. This is similar to the "interface" heading used for high-speed serial, Ethernet, and Fast Ethernet ports. Configure and maintain the internal DSU under this heading. All "controller" sections of the router configuration will tell you what kind of channelized line card is detected (for example "controller T1 0"). Multiple cards will be shown as separate "controller" lines (i.e., "controller T1 1", "controller T1 2", etc.) The number of channelized cards supported depends on the type of router you have.

The first thing to do when setting up a channelized card is to configure the framing and the line code. These must match those configured by the telco. If you do not know them, ask your telco installation engineer what they are. Next, you must select a clock source. You only need one primary source per router; all others will be secondary. You must also use the "no shutdown" command to activate the T1 controller. Once you have done this, you should be able to establish basic connectivity with the telco, and they should be able to test the line. A configuration section like this is shown in Figure 8-26.

There are three basic ways to configure a channelized card in IOS. The first is a WAN-only T1, which handles multiple fractional T1 connections over a single line. The second is an ISDN PRI, which useful for ISDN B channel dial-up connections or modem connections if there are modems in the router. Finally, there is the T1 line which routes voice calls to modems.

Use the keyword channel-group to create multiple virtual interfaces for WAN-only channelized connections. Each virtual interface uses a unique and contiguous set of T1 channels or time slots for its connection. Despite the appearance of multiplicity, a T1 line is a single line supplied by a single provider (even if only a few channels are in use); all connections on that T1 must come from that provider.

Take the scenario where we have two 384 Kbps fractional T1 lines, a 64 Kbps line, and a 56 Kbps line coming over a single piece of cable. The two 384 Kbps lines use six channels each. The 56 Kbps and 64 Kbps lines each use only one channel. Since we are designing a single line to hold four connections, we can assign each set of channels as we desire, and the telco will configure the line to our specifications. We want to leave room for the 384 Kbps connections to grow, especially if the sites they connect to need more bandwidth. Because of this, we will not put the end of one line up against the beginning of the other. Instead, we will leave six unused channels in between. Not wanting to do the same with the connection in the middle, we will put the single channel connections up against the last channels in the T1. These connections are fixed and cannot expand, so we have no fears about penning them in.

If we wanted to grow a 384 Kbps connection in the future, we would call the telco and arrange for more channels. Next, when they were ready to give us a new larger (or smaller) pipe, we would connect to the remote router and change the number of time slots in its "channel-group" (if it had an internal CSU/DSU.) If it used an external CSU/DSU, we would talk the local site administrator through changing the number of time slots assigned to it. Next, we would make the changes in the local router's time slots, and have the telco make their changes. If everyone does the same thing, the line should only be down for a short time while the number of channels changes.

Getting back to our example, the first connection uses time slots one through six. The next six are left empty, and time slots 13 through 18 belong to the second connection. The last two connections use time slots 23 and 24. To set these up, we would assign each a "channel-group" number, typically zero through three. See Figure 8-27 to see how the commands would look in the router configuration. Note that the option "speed 64" denotes the use of 64 Kbps channels, while its absence denotes the use of 56 Kbps channels.

Once you create the channel groups, you will need to create the interfaces for each. These commands will take the form "interface Serial CTLR:CG" where CTRL is the controller number and CG is the channel-group number. In our example, we need to create the interfaces Serial0:0, Serial0:1, Serial0:2, and Serial 0:3. Each will get its own description and IP address.

We will also add a bandwidth statement. This has no bearing on how much data passes through the line, but is for reporting statistics on line usage. These interfaces do not exist before we enter them into the global configuration. The act of entering them into the configuration file creates them for our use. These interfaces are initially in a "shutdown" state by default. Before you use them you must enter the "no shutdown" command for each interface. See Figure 8-28 for the layout of the configuration file.

Once this is complete, all lines should come up and be operational (assuming the telco has done their part and the remote router and CSU/DSU have been configured.) It is important to note that all the remote sites must have their own leased lines, which will be provided by the same telco that is joining them together into one for you. The main reason for doing something like this is to save money.

Although the channelized T1 card costs more than a quad serial board, this is a one-time expense, and as such, is trivial compared to the continuing cost of having four local loops (2 T1, a 64 Kbps, and a 56 Kbps) brought into your site by a telco provider. These would incur monthly charges totaling a minimum of $1,000. By combining them into one local loop, the long distance charges stay the same but the local loop costs drop to around $330 a month. At a savings of $670 a month, the difference in cost between a channelized T1 card costs and a quad serial board quickly pays for itself. Also factored into the savings are the one-time charges for four external CSU/DSUs versus a single external CSU. Depending on the level of features and options you prefer to buy, this may make up the cost between the two Cisco cards by itself.

Use the pri-group keyword to create multiple virtual interfaces for handling dial-in B channel connections for PRI connections. Each PRI usually uses all channels in a T1, although you can order them with fewer channels. The revision of IOS reviewed in this book (11.2) supports only a single ISDN provider. Although you can have multiple PRIs terminating in the same router, under IOS 11.2 they must all come from a single telco provider's ISDN switch.

The first step in setting up the PRI is to assign time slots to the PRI group. Next, create the D channel interface to establish proper ISDN signaling with the telco. To do this, create the interface "Serial CTLR:23" where CTLR is the number of the T1 controller. It is possible to order multiple PRIs as a group from the telco. In this case, you do not need all the D channels that come with them by default. In this case, you should make sure to have at least two D channels for your PRI groups. This allows you to maintain connectivity with the telco if you lose the PRI with the D channel. If you were purchasing four PRIs for connection to a Cisco AS5300, you could order two with D channels and two without. This would give you two extra B channels on which to receive ISDN or modem dial-in connections.

The D channel interface (Serial0:23) is shown in Figure 8-29. The IP address is usually set to the unnumbered address of the Ethernet port. PPP encapsulation is used here because it is the most universally accepted dial-up IP protocol. If you have modems in the router, such as in an AS5200 access server, the command "isdn incoming-voice modem" will send all voice calls to them. If there are no modems, this command is unnecessary and you should order the PRI line without voice capabilities. The exception to this rule depends on how the local telco charges for 56 Kbps voice calls.

If the local telco treats 56 Kbps ISDN voice calls as flat rate, you may want to use voice spoofing to lower your phone charges. Voice spoofing is an ISDN call placed as 56 Kbps voice by a router. When the call is initiated, the telco counts it as a voice call, and in some areas, the telco may bill you at voice rates for the entire connection (as little as 10¢ per minute (flat rate)). Once the voice connection completes, the two routers can still communicate with each other and essentially convert the call to 56 Kbps data. This lowers your bandwidth a little, but could potentially lower your phone bill a lot.

Dial-in users receive IP addresses through address pooling. In this case, they get IP addresses out of the pool named "mypool". The "dialer rotary-group 1" command tells the router that all 23 B channels handled by this D channel interface are part of the group interface Dialer 1. The "dialer-group 1" command tells the router that "dialer-list 1" (defined further in the global configuration) lists all packets considered interesting enough to make the router dial out to a site. In this case, all IP packets are considered interesting. Finally, STAC compression is enable for all B channel connections.

While the D channel interface (Serial0:23) handles the physical layer of the PRI, interface "Dialer 1" handles the B channels as synchronous interfaces. It uses the same unnumbered IP address, encapsulation, and address pool as the D channel interface. The command "dialer in-band" tells the router that DDR (Dial-on-Demand Routing) is configured for dial-in calls only. Dial-out DDR requires many different configurations. The "dialer idle-timeout 600" sets the idle time-out to 600 seconds. If this interface is idle for ten minutes, the router will hang up on it. The "dialer-group 1" command tells the router that the dialer-list command in Figure 8-28 determines what packets will reset the idle timer. This command can save you money if dial-in users walk away from their machines while connected. Especially if the company pays for the dial-in line or has a toll-free (800 or 888) number.

Figure 8-29 also defines STAC compression as turned which helps increase throughput. The PPP protocol uses PAP and then CHAP for authentication. Microsoft Windows clients use PAP while routers and UNIX systems can use either PAP or CHAP. Finally, multilink PPP negotiation is allowed.

There is not much difference between setting up T1 controllers for WAN connections and for modems, except that the T1 you are connecting to will be a voice T1 and all calls will be routed to the modems. Slightly different signaling is used to support a voice T1, and the keyword cas-group is used to tell the router to send all calls to the modems. You also need to select the T1 voice call signaling method. This will be e&m-fgb for modem pooling. You must also specify the type of dialing to use. Typically, this is DTMF (Dual Tone Multi-Frequency), although you can also choose to use DNIS (Dialed Number Identification Service).

With DNIS configured as part of the cas-group command, the system collects DNIS digits for incoming calls, which it then redirects to specific modem pools. You must be running MICA modems in the system and have at least 10% of your total modems in the default modem pool. There must be free modems in the default pool to detect the incoming called number (or DNIS) before handing the call off to the appropriate modem in the pool. Therefore, two modems are necessary to handle each incoming call.

Once you have configured DNIS, you will have the physical interfaces for 24 modems available. You should consolidate these into one or more "Group-Async" interfaces for ease of configuration. See the next section for setting up modems.

To set up modems, you need to configure both their physical and data layer interfaces. It makes no difference if they are built into an access server or connected to a serial port. Some access servers have many serial ports, while almost every router has an auxiliary port to which you can attach a modem. The physical interfaces are set up using the "line X Y" command, where X is the first serial line or built-in modem, and Y is the last. You will need to set "login local" which will read individual user names and passwords set with the "username" command. The "modem dial-in" sets the modem to dial-in only mode. The "modem inout" command sets the modem for dial-in and dial-out. (There is no command to set the modem to dial-out only.) The command "autocommand ppp" tells the modem to go into PPP mode as soon as a modem connection is established. Finally, "transport input all" tells the router to use all protocols when a connection is made. These commands can be seen in Figure 8-31.

Grouping ports together into Group-Async interfaces helps make the data interface layer setup easier. Otherwise, you would have to enter the same information repeatedly for all modems configured alike. It is in the Group-Async interface that you will assign IP addresses to modem users, enable compression, and list which asynchronous ports belong to the group interface.

In Figure 8-32, we begin "interface Group-Async1" by choosing to use the unnumbered IP address of the Ethernet port. Next, we select passive TCP header compression. This allows incoming systems to request Van Jacobson header compression, but the router will not block systems that do not support it. To select it header compression under Windows 95 open the "My Computer" icon, and then pick "Dial-up Networking". Right click on the dial-up connection you want to edit and select "Properties", then go to the "Server Types" tab and select "TCP/IP Settings." You should see a window just like Figure 8-33. Make sure that "Use IP header compression" is selected.

The selected encapsulation mode is PPP. The command "async mode dedicated" tells the router to put the modem connection directly into PPP mode when the connection is made. This mode stops normal text based logins and forces all users to use PPP. To return to a configuration that will support text logins, use the command "async mode interactive". Next, define the ip address pool to use "mypool". Then, set the compression algorithm to STAC. Next, set the PPP authentication to PAP first and then CHAP. Finally, add modems number one through 48 to this Group-Async interface with the "group-range" command.

IPX is the protocol used by Novell NetWare servers and clients. If you are running NetWare and you want to route IPX over LAN, WAN, and dial-up lines, you need to assign an IPX network number to each individual segment of the network. IPX network numbers are arbitrary hexadecimal numbers up to eight characters long. All NetWare servers on a segment must have the same network number, as must all routers. Clients, whether PCs or printers, learn their IPX network number from a server or a router on their network segment. If you change an IPX network number on a LAN segment, you must ensure all servers also change network numbers, and all clients reboot.

You must make sure that all segments of the network have duplicate IPX network numbers. The best way to do this is to draw a diagram of your network and assign IPX network numbers to each router interface. All router interfaces on the same network share the same IPX network number. A sample diagram is shown in Figure 8-34. As you can see, all ISDN and modem dial-in users share the same IPX network number ABC123. The LAN side of the access server, the router connection to LAN 2, and all the clients off that hub will be on IPX number DEF456. LAN segment 1 off the router's second Ethernet port uses IPX number 10101010. The leased line connection between routers uses IPX number B1, and the Ethernet on the remote site is all on IPX network DEF623.

The first step in configuring IPX routing in IOS is to turn it on. This is done by entering the "ipx routing" command into the global configuration. After entering the command, you will notice that it acquires another keyword. This is the router's MAC (Media Access Layer) address, sometimes called the Ethernet address. This is shown in Figure 8-35.

Once you have turned on IPX routing, you can start adding IPX network numbers to the interfaces. LAN and WAN interfaces are easy. Enter the configuration for that interface and add the IPX network number with the "ipx network" command. Figure 8-36 shows the Cisco 4500 router from Figure 8-34 being set up with the proper IPX network numbers. That is all it takes to route IPX on LAN and WAN interfaces.

IPX routing for dial-in users is only slightly more complicated. Since each remote machine is, in effect, its own WAN segment, you might think you have to assign each one its own IPX network number. This would be a bear to configure and maintain, as well as a waste of a large amount of IPX network numbers. Be glad that Cisco has tamed the bear for you.

To set up IPX networking on an access server, you must first activate IPX routing and then configure the Ethernet port to match the IPX network number of all other routers and servers on that LAN segment. Next, create a new interface called "Loopback0". This interface will not have an IP address, but it will contain the IPX network number for all dial-in connections. Finally, go to the "Group-Async" and "Dialer" interfaces and add the command "ipx ppp-client Loopback0". This will bind the IPX network number in interface "Loopback0" to all dial-in connections. This is shown in Figure 8-37.

Configuring IPX routing for 700 series routers is a bit more complex. You must know how IPX networking is set up and you must configure IPX routing for both the LAN and WAN profiles. The first step is to turn IPX routing on. This is done with the "set ipx routing on" command. Next, you need to set the IPX network number with the "set ipx network NNN" command, where NNN is the IPX network number. Next, you must decide whether to use IPX spoofing.

IPX spoofing leads NetWare servers to believe that a session is still active, even though the ISDN connection is down. It does this by having the router respond to a server's Watchdog requests on behalf of a remote client. If there is a NetWare server on your end, you may want to turn it on. Benefits of IPX spoofing include:

• Local acknowledgment of queries
• No link responses
• Efficient use of the link
• Minimal operator intervention

When the number of IPX or SPX sessions are limited, this can cause connectivity problems by denying logins to legitimate users, so be careful about using it. The default command for IPX spoofing is "set ipx spoofing off". If you want to activate it, replace the keyword "off" with the number of minutes (between 1 and 32,000) you want to spoof an idle connection.

To specify the forwarding of NetBIOS (Type 20) packets to a profile, use the "set ipx netbios accept" command. If you are using a NetBIOS protocol (such as Windows for Workgroups over IPX), you must use this to pass the packets through the router. If you are not using this, you can replace the keyword accept with block.

The dynamic routing protocol for IPX is IPX RIP. If there is only one router on the network, there is no need to enable IPX RIP in your LAN profile. This is done with the "set ipx rip update off" and "set ipx rip receive off" commands. If you want to pass IPX routing information, replace the keyword off with the keyword periodic in the "update" command and on in the "receive" command.

Finally, you need to set the IPX frame type information. This will be located on your IPX servers and clients. If you do not know it, try stepping through all four choices until it works, but you will never know if other problems are causing IPX routing failures if you do. Your choices for frames are SNAP, 802.2, 802.3, and Ethernet_II. The command to set the frame type is "set ipx framing TYPE ". All these commands are listed in Figure 8-38.

The WAN profile configuration for IPX over the ISDN line is essentially the same as for the LAN profile. The basic difference is the IPX framing type. For router to router connections over ISDN, set the IPX frame type to "none". This is shown in Figure 8-39.