Introduction

This month's article is for lab aficionados, also those needing to support remote small and home offices (SOHO). The two features we're going to cover are normally provided via servers. They are DHCP and DNS. Yet the router can certainly act as DHCP server for smaller offices and labs. It was a bit of a pleasant surprise to find the DNS functionality there as well (well-hidden).

The Summary section at the end contains links to relevant Cisco web pages documenting these features further. 

Review of DHCP

DHCP is a way for a PC to request to be assigned a temporary address. The temporary address is assigned with a lease, a period of time for which it may be used. The PC may request a lease extension, and normally does so well before the lease expires. DHCP may also provide a growing number of optional and vendor-specific items of information. So, for example, with Nortel IP phones, DHCP can specify they shift to a certain VLAN, and what TFTP server to obtain boot images from. With PC's, the default gateway router and DNS server(s) are normally included with DHCP info, and the WINS server may also be specified, for those still using WINS.

I'm a big fan of O'Reilly Press books, for their overall very high quality. They have one on DHCP: DHCP for WIndows 2000, by Neall Alcott. See also http://www.amazon.com/exec/obidos/tg/detail/-/1565928385/.

Configuring DHCP

Cisco routers have been picking up bits and pieces of DHCP functionality over time, to better support home and small office users, and to provide ease of use. Many of the smaller routers act as DHCP servers, just as Linksys, Netgear, and other small routers do. These routers provide addresses and default gateway to your SOHO PC's.  They also are DHCP clients, obtaining an outside address (etc.) from your ISP. They typically then do NAT (network address translation) or PAT (port address translation) between the private inside addresses and the one public Internet address on the router's outside interface.

Here's a sample of what you can configure on your router:

Each DHCP pool is a pool of addresses. The excluded address commands bar those addresses from being assigned to DHCP clients. Here, the router interface and switch management address were excluded. You then supply DHCP attributes for the router to supply to the client. So for the main VLAN/subnet 10.20.1.0, the router will give clients and address and subnet mask, the default router, and the DNS server address. For pool pjw03, the router will also supply the address of the NetBIOS name server, along with a short lease of 3 minutes (the arguments are days / hours / minutes).

When a DHCP request is received by the router, it notes the inbound interface's address. The DHCP pool is chosen to match. See the following screen capture of Ethereal showing the entire DHCP exchange. (It's useful to have a sample healthy exchange to assist in troubleshooting when DHCP isn't happening, or isn't happening correctly).

Since this article is in danger of exceeding the appropriate length,  I'll refer you to the Cisco documentation links below for further info about the rest of the capabilities of the Cisco IOS DHCP server!

If you're doing DHCP for a remote office rather than a lab, you probably will want to look into having your router save DHCP bindings (assigned addresses) to a server. Otherwise, should the router reboot, it will have amnesia about what addresses it assigned and when the leases expire. This could lead to duplicate IP addresses on your network, never a good thing.

Review of DNS

By the way, the idea with DNS Spoofing is for the router to temporarily respond to DNS queries, until the ISP link comes back up. That's why I said "SOHO" above. You have your DHCP specify the real DNS server address, and the router will fill in as needed. You can then pre-stuff important local corporate addresses into your local host table, so the most critical user name lookups will be supported even with the local link down.

You probably require 12.3(2) T code to find this feature, although I seem to have it in 12.3(3) non-T.  That suggests the feature may have been there earlier. I did a lot of searching on this one, with very little in the way of matches. Is it me, or has Cisco been a bit frugal with its documentation lately? I've been noticing missing (undocumented) commands, explanations that don't really explain more than you'd guess, etc. If I'm right, this has the perhaps unintended consequence of causing more TAC calls of the "what does this command really do, and which variation do I need?" variety. Or lab time for customers trying to figure out what the command actually does?

Configuring DNS

The DNS Spoofing page says that for the feature to work, you have to have one of the following conditions in the router:

• Configure "no ip domain-lookup", OR
  
• Configure no IP DNS server addresses, OR
  
• Have no valid interfaces or routes for reaching configured DNS server addresses
  

Actually configuring the feature involves:

The first command is a familiar one, telling the router to locally not attempt DNS lookups. It seems to have recently lost its hyphen somewhere.  The spoofing command causes the router to pretend to be the specified server address except when queried for exactly its configured hostname followed by the configured domain name. If the optional server address is omitted, the router responds to DNS queries using the address of the inbound interface.

When the DNS server functionality is enabled, the ip host commands double to provide DNS records for lookups.  This seems to work even when you  omit the spoofing command completely.  Here's a sample captured from my laptop:

C:\>nslookup
...
> server 10.20.1.1
DNS request timed out.
    timeout was 2 seconds.
Default Server:  [10.20.1.1]
Address:  10.20.1.1

> a
Server:  [10.20.1.1]
Address:  10.20.1.1

Non-authoritative answer:
Name:    a
Address:  1.2.3.4

> a.mylab.com
Server:  [10.20.1.1]
Address:  10.20.1.1

Non-authoritative answer:
Name:    a.mylab.com
Address:  1.2.3.4

> 1.2.3.4
Server:  [10.20.1.1]
Address:  10.20.1.1

Name:    a.mylab.com
Address:  1.2.3.4

Note that this tells us that you don't have to put in PTR (address to name) records, the ip host entry is also used for that. I've often wished some of the GUI enterprise DNS server tools were as intelligent! (Tell them name & address and they figure out the reverse mapping). (Sort of like net management software that knows the right SNMP string or telnet password for box A but never tries them on box B as a last resort).

When I added the following command

ip dns primary mylab.com soa 10.20.1.1 pjw@mylab.com 21600 900 7776000 86400

I got authoritative replies for the specified domain (mylab.com):

> a
Server:  [10.20.1.1]
Address:  10.20.1.1

Non-authoritative answer:
Name:    a
Address:  1.2.3.4

> a.mylab.com
Server:  [10.20.1.1]
Address:  10.20.1.1

Name:    a.mylab.com
Address:  1.2.3.4

In working with 802.1x and tying it to Microsoft login, I found it useful to configure:

(since I was running lab Active Directory on a server we also use for Cisco Unity lab work).  You'll note the Cisco IOS DNS server supports several types of DNS records:

TheRouter(config)#ip host foo ?

  <0-65535>   Default telnet port number
  A.B.C.D     Host IP address
  additional  Append addresses
  mx          Configure a MX record
  ns          Configure an NS record
  srv         Configure a SRV record

Summary

One other tip that can help keep your home lab affordable. The 2600 at some recent point acquired support for trunking on 10 Mbps Ethernet links. So a 2900 XL plus a 2600 with Ethernet can be quite useful in a home lab. Going forward, I would certainly prefer FastEthernet in my 2600. As used equipment prices drop, you'll want at least a 3550 to keep up with QoS, 802.1x, and NAC developments, and the switch will double as a 2nd router for routing lab work.

There's another example of "broader usefulness" I find amusing. See the "proxy-auth" feature, which is in the routers but apparently not in the 3550, 3750, etc. IOS-based L3 switches. Unreliable rumor says it's being added into their programming code trees. Proxy-auth is basically a web login, which is part of what BlueSocket and others have been selling in the WLAN arena.  For some simpler sites, e.g. colleges, web authentication may be all you really want for your WLAN network. Neat feature!

I do hope this article was interesting and useful. Ideas, comments, questions are always welcome. Send to the email address below.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net (formatted this way to fool email harvesting software).

9/4/2004
Copyright (C)  2004  Peter J. Welcher