IP address allocation with DHCP in IOS
Tue, May 10 2011 07:19
| cisco, dhcp, ios, services
We all know the pain of static IP address assignment on large networks. The majority of us would probably configure DHCP services onto a server or host like Windows or a *nix platform. This guide is going to show you how to configure DHCP in IOS. You have to be clear on this however, Cisco devices whether a switch or router are NOT really meant to be a DHCP server. The function of your network device is pushing traffic around ;-) If you really really really must do this then take it in the context it is meant. DHCP on a Cisco device is only ever going to be a best effort service. It'll work and it'll work well but don't expect too much in terms of lease visibility.
So lets begin with a little overview of the DHCP protocol. Way way back in the early to mid 90's we had BOOTP (RFC 951). This protocol was often used for disk-less hosts using a BOOTPROM. The BPROM would broadcast out it's MAC address onto the LAN and the BOOTP server would send back an IP address plus the BOOT server and BOOT image required by the disk-less server to boot its operating system. BOOTP worked well for single networks but didn't include a things like IP gateways so the host didn't know how to get out.
Along comes DHCP. With this reworking of BOOTP we now have included options like default gateway, DNS servers, WINS servers and all manner of extra IP host configuration parameters to aid the modern client.
The DHCP 'lease' process whereby the client is provided with a unique IP address follows a 4 way process:
i) Client comes online and will broadcast a DISCOVER message onto the network
ii) DHCP server hears the DISCOVER and sends OFFER message in response
iii) The client sends a REQUEST message back to the server saying 'sounds good to me man, I'll take it'
iv) The SERVER sends an ACKNOWLEDGE message to the client saying 'You're welcome'
So thats the process, how do we setup the cisco router or layer 3 switch to do DHCP leasing. WE'll configure our router to lease IP addresses from the 172.16.1.0 255.255.255.0 subnet. Set the netmask, default gateway, dns-servers and domain name. The only REQUIRED part is the 'network' statement, all of the others are optional.
R1# configure term
R1(config)# ip dhcp pool TEST
R1(dhcp-config)# network 172.16.0.0 /16
R1(dhcp-config)# default-router 172.16.1.1
R1(dhcp-config)# dns-server 172.16.1.5 172.16.1.6
R1(dhcp-config)# domain-name mynetwork.com
So what if we've got some static addresses in the network which have been set statically? For example, above we have two DNS servers 172.16.1.5 and 172.16.1.6. What about the default gateway which was 172.16.1.1? We don't want the DHCP server leasing those addresses. You should note that most modern DHCP servers including the Windows DHCP server perform an initial ping on the LEASE address before the OFFER is sent. This way any already live addresses will be noticed and made invalid for lease to avoid duplicate addresses.
Anyway - lets ask the router to NOT lease addresses between 172.16.1.1 and 172.16.1.10 so we can use those addresses statically and be assured it won't OFFER them.
R1#(config) ip dhcp excluded-adresses 172.16.1.1 172.16.1.10
So thats it! Pop a client onto the LAN to check it out.
Don't forget to enable the dhcp service or to check leasing using:
R1(config)# service dhcp
R1# show ip dhcp server statistics
When you need log data you need good timekeeping
Sun, Apr 10 2011 01:11
| cisco, ios, ntp, services
When there is a technical error with the device or you need to troubleshoot a failure the most important thing is time. Recently we were onsite troubleshooting a denial of service attack (DoS) on a web server for a client. They informed us that it had taken place sometime between 22:00 and 22:10 on a certain date. We asked for the web logs and then for the router/firewall logs for the period concerned. We spent time looking though the logs and noticed no commonality with the customers experience and the logs we were looking at. Indeed there appeared to be some difference even with the log files we had been given. For example a very clear HTTP GET request on the web server had no matching event on the firewall...
You guessed it, not only was the time wrong on the web server but it was also wrong on the firewall. Worse still the timezone was wrong so even if the time setting was correct we were at best an hour out as we were operating in BST.
Setting the time on the web server to point to the cisco switch (Catalyst 4500) to obtain it’s time was the first stage. The timezone was setup correctly and we were to use the windows time service using NTP. Here are the steps we took to setup the Cisco switch to set it’s timezone, to setup the correct British Summer Time skew plus the NTP daemon function so that the Cisco device to collect the correct time information from the internet and also allow the windows server to collect the time information.
First we setup the timezone so that the switch knew where in the world it was:
Now we need to setup the NTP daemon itself. We need to find an NTP source out there to deal with us. There are different tiers of NTP service called ‘strata’. We don’t really need to be hugely accurate so we chose a stratum 2 NTP source. Here are a list of the UK NTP servers
The prefer keyword is just to say to IOS “if this one is available then we’d like you to trust this one most”. We also want to make sure our log data on the switch is given a timestamp.
So lets just make sure it’s all working. Type “show ntp associations”