Transcript DHCP at Stanford

DHCP at Stanford
Kent Reuber
725-8092, [email protected]
Outline
• What DHCP is, and how it works
• What’s special about DHCP at Stanford
• What happens when DHCP doesn’t
work
• Q&A
Skills You’ll Learn
• How to check Netdb records to see if DHCP
is working the way you want
• How to look at DHCP server logs to
troubleshoot problems
• How to uncover rogue DHCP servers on your
network
DHCP Basics
What is DHCP
• “Dynamic Host Configuration Protocol” (RFC
2131)
• Automatically assigns IP addresses to
devices (I.e. hosts) on your network
– Prevents having to manually enter data
– Prevents typos that can cause connectivity
problems or disrupt the network (e.g., exchanging
IP address and gateway address)
DHCP Conversation
• Four step process between client (UDP port
68) and servers (UDP port 67)
– Client sends Discover “Someone send me an
address”. This is a broadcast.
– Servers Offer “Use this address”.
– Client Requests “I’ll use this one”. (broadcast)
– Servers Acknowledge “OK or No Way!”
(ACK/NAK)
DHCP Results
• Servers should provide address, net mask,
DNS servers, domain, and gateway (and
perhaps other stuff, e.g., WINS)
• Client will be allowed to use the address for a
period of time called a Lease
– Normal campus addresses: 2 day lease
– Roaming addresses: 42 minutes
Lease Renewal
• Halfway through lease period, client asks its
current server to continue using the address.
– Client sends Request (unicast).
– Server sends Acknowledge.
• If current server isn’t available, client will
broadcast request. This may cause it to
change servers.
• If lease expires, client must stop using the
address and start the process from scratch.
Looking at DHCP
Information
• MacOS X:
– Use “ipconfig getpacket interface_name” (e.g.,
en0). Lease times are in hexadecimal.
• Windows NT/2000/XP:
– Command line: “ipconfig /all”
• Windows 95/98
– Winipcfg GUI utility
DHCP at Stanford
DHCP at Stanford: Netdb
Connection
• Have to have MAC (hardware) address in
Netdb and DHCP box checked to get DHCP
provided address
• If you specify one or more IP addresses for a
MAC address, you will always get one of
those addresses if appropriate
• Use more than one IP address if you have
multiple “home bases”, for example, an office
in one building and a lab in another building.
Example Whois Record
• Multiple interfaces with multiple addresses:
name: lapwarmer
type: Node (Advanced)
cpu: Apple PowerBook
op-sys: MacOS X
interfaces:
1) name: slab-en0
hw-addr: 000a.95a0.03ce dhcp roam
ip-addr: 171.64.20.45
slab
171.65.92.2
slab-clark-92
2) name: slab-en1
hw-addr: 0003.93eb.26dd dhcp roam
ip-addr: 171.66.32.245
slab-ap
DHCP and Netdb:
Roaming
• Checking “roaming” allows you to get an address
from the local roaming address pool if none of the IP
addresses associated with your MAC address are
appropriate
• For example, my laptop wired interface has two
“home” addresses, 171.64.20.45 and 171.65.92.2.
When on those nets, I’ll get the appropriate address.
On other campus nets, I’ll get an address from the
local roaming pool if one is available.
• If local roaming pool is full or doesn’t exist, I’m stuck!
How Big is the Local
Roaming Pool?
• The number of addresses available for
roaming is specified by the LNA
• Look at the network record for the network of
interest:
[mac-kent-x:~] reuber% whois 171.64.20.0
name: Pine-B-net.Stanford.EDU
ip-subnets:
1) addr space: 171.64.20.0/24
lo: 5 hi: 5
dhcp-addr: 171.64.20.242
DNab4014f2.Stanford.EDU
171.64.20.243
DNab4014f3.Stanford.EDU
171.64.20.244
DNab4014f4.Stanford.EDU
171.64.20.245
DNab4014f5.Stanford.EDU
171.64.20.246
DNab4014f6.Stanford.EDU
More Roaming Trivia
• Each DHCP server (dusk, dawn) is
responsible for 1/2 of the roaming pool.
• For example, if one of the servers were
unavailable, only 1/2 of our roaming
pool would be available.
Policy Issues
• Never add residential (128.12.*.*) or Stanford West
(171.66.152-159.*) to campus Netdb records.
• Add campus address to residential or Stanford West
records.
• Never assign clients new addresses in these ranges.
Clients must contact RCC or Comm Services.
• More Stanford West info:
http://www.stanford.edu/group/itsscns/stanfordwest/faq.html
Troubleshooting
SUNet Reports
Troubleshooting Page
• https://www.stanford.edu/group/networking/dist/sunet.reports/
(Off the main SUNet reports page. Must be a registered LNA to
access this page.)
• Has links for looking at DHCP conversation for a particular
client and for DHCP Dynamic (I.e., roaming) Address Utilization
Roaming Address
Utilization
• Shows how many of your roaming
addresses were used in the last 24 hrs.
Pine-B-net
171.64.20.0/24
5
• Very rough indicator of usage.
3 60%
DHCP Client Conversation
Report
• Takes practice to read. Look for
common date and time for messages
• Most helpful if you type in the MAC
address rather than the IP address
– Can see where the laptop has been
– Can see the discover message (I.e.,
before the device gets an address)
Odd Addresses You Might
Encounter
• 10.*.*.*: Hospital uses this range, but Airport base stations also
give out this range (esp. 10.0.1.*)
• 192.168.*.*. Used for a few special purposes on campus, but
often used by rogue wireless access points
• 169.254.*.* “Zero-conf” address -- device can’t contact DHCP
server. May be indicative of Netdb, cabling, inactive jack, etc.
• 172.20.*.* Wireless guest network range (experimental). Will
get this address on certain wireless nets when MAC address
isn’t in Netdb.
Troubleshooting Questions
For DHCP Problems
• What address if any did clients receive?
• Is their Netdb record set up correctly (correct MAC,
DHCP/roaming checked)?
• What network is the user connected to when they’re trying to
use DHCP? What is the network range?
• Does the user have an address on this network or is the user
roaming?
• Are there available roaming addresses (roaming is defined and
there are free addresses)?
• Check DHCP server report? What happened?
• There may be a physical problem (cabling issues, jack not
activated, NIC problems, etc.).
Finding Rogue DHCP
Servers
• If users are getting inappropriate 10.* or
192.168.* addresses, may need to hunt for a
rogue server on your net.
• Often, these rogue servers are poorly
configured access points or PCs/Macs set for
“Internet Sharing”. Note: Internet Sharing
means sharing your *address* not your files!
This shouldn’t be used at Stanford!
Finding Rogue Servers
• Must do this from a machine getting a “bad” address!
• Ping the machine acting as your DHCP server. Can
get this info from the command line. Often the rogue
will advertise itself as the gateway.
• Get the MAC address:
– OS X: arp IP_ADDR
– Windows: arp -a IP_ADDR
• Give MAC address to your LNA or submit a HelpSU
ticket.
Questions?