1 / 25

DHCP at Stanford

DHCP at Stanford. Kent Reuber 725-8092, reuber@stanford.edu. 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

wade-diaz
Download Presentation

DHCP at Stanford

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DHCP at Stanford Kent Reuber 725-8092, reuber@stanford.edu

  2. Outline • What DHCP is, and how it works • What’s special about DHCP at Stanford • What happens when DHCP doesn’t work • Q&A

  3. 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

  4. DHCP Basics

  5. 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)

  6. 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)

  7. 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

  8. 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.

  9. 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

  10. DHCP at Stanford

  11. 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.

  12. 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

  13. 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!

  14. 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

  15. 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.

  16. 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/itss-cns/stanfordwest/faq.html

  17. Troubleshooting

  18. 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

  19. 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 3 60% • Very rough indicator of usage.

  20. 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)

  21. 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.

  22. 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.).

  23. 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!

  24. 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.

  25. Questions?

More Related