Introduction

Protocol purpose and main principles of its work

Configuration of equipment

The process of assigning IP address

Secondary subnet

Additional options: relay

Additional options: option 82, snooping

Additional options: import of parameters

Additional options: VRF support

DHCP and routing

Conclusion

Introduction

Behind the seeming simplicity of DHCP, a large set of opportunities, about which network administrators often don’t even know, is hidden. In this article we will not study all opportunities of the protocol in detail, however, immerse into some interesting ones. We don’t claim the fullest review of theoretical aspects, which the reader can find in any specialized literature. Here we’d like to emphasize that despite the fact of review DHCP working (RFC2131) mainly on Cisco devices, most of the parameters are also available on switches and routers of other vendors. Also we’d like to mention that the article in question is aimed at a wide audience of readers, so we will start from the simplest or even elementary things, however, hope that we won’t scare away more advanced reader.

Okay, let’s get started!

Protocol purpose and main principles of its work

DHCP (Dynamic Host Configuration Protocol) is intended for centralized IP parameters managing of end user equipment. Certainly, one is not forbidden from using DHCP for configuring servers or network equipment, but more often static configuration, which is considered to be more predictable, is used in such cases. We intentionally mentioned that the protocol is used for managing exactly IP parameters because many network administrators have a wrong stereotype that client-server protocol DHCP is limited by setting IP address only. IP address is only one of the parameters which can be configured with the help of the protocol in question. Which other parameters can be provided to a host? Among them (but this is not the whole list) are the following (RFC1533 and RFC2132): subnet mask, default gateway, addresses of DNS and WINS servers, domain name and name of the host itself, routes to particular subnets, time zone and address of time server, boot image address, TTL and MTU, addresses of POP3 and SMTP servers, address lease time. Not all options can be used or supported by the client or server, but often DHCP clients and servers support rather wide set of options.

Receiving of IP parameters is performed with the help of four messages which the client and server exchange.

 

DHCP discover message is sent by the client for discovering DHCP server in the local network segment. Looking ahead, we mention that modern topologies don’t mean direct connecting a server to each virtual network (VLAN) in which client hosts are placed. Instead of this, a special relay is used, which we’ll discuss a bit later.

After receiving DHCP discover message, DHCP servers reply to the client with DHCP offer message containing the offering parameters. The client received several such offers can choose one the most satisfying among them. To tell the truth, usually the first received DHCP offer is chosen. It’s worth noting that at this moment the server reserves the offered IP address for the client for only a short period of time, and if the client doesn’t request its using, the server will release the address for the further use (return it to the pool).

Having chosen one of the offers, the client sends broadcast DHCP request to the server for assigning the offered parameters. Before receiving an acknowledgment from the server, the client is not in the right to use the chosen IP address. The broadcast message is used here also to notify other servers that their offers are not considered, that will allow them to return address to the pool more quickly.

The server received DHCP request message sends to the client DHCP ack message that acknowledges the client’s right on using the provided IP address. It’s worth noting that in some cases the server can reject a client’s request on using the address. This situation may occur, for example, in case when the server provided another client with the IP address in question or reconfiguration of the DHCP-server was performed. If the server cannot acknowledge using of earlier offered parameters, it sends DHCP nack message to the client.

One of the necessary options sent to the client by the server is IP address lease time. This parameter specifies time interval during which the client is in right to use the provided IP parameters. After this time is over, the client has to release the used IP address or perform its extension. If the client is going to release the using IP address, DHCP release message is sent. After receiving this message, the server returns IP address belonged to the client to the pool of free addresses.

For our readers we prepared traffic dump containing the procedure of IP address getting and release by the host. All dump files from this article can be opened with the help of network analyzer Wireshark. We strongly recommend exploring in detail all fields in all packets containing in the file. One can filter DHCP messages in a bulk dump using Wireshark with the help of “bootp” display filter.

Packets from the first to the forth inclusive contain a standard procedure of getting IP parameters. In the packets 5, 6 and 7, DHCP release message noting the server about an early termination of the lease was sent by the client.

How does the server notify the client for which time IP address is provided? As all in DHCP, this information is provided in the packet as an option (option #51). Besides this, DHCP has two timers usually named T1 (renewal) and T2 (rebinding) providing by the options 58 and 59 correspondingly. T1 timer is usually equal to the half of lease time and T2 corresponds to 7/8 of lease time. For which purposes are these timers used? If T1 time interval is over after receiving DHCP ack message, the client starts the procedure of renewing IP parameters and repeats request to the server for the right to use them. If no changes occurred, the server enables extension of lease time by sending DHCP ack message. If the server doesn’t answer the request for lease extension for any reason, after T2 time interval is over, broadcast sending of DHCP request message is performed, with the help of which the client tries to find a server that is able to extend the lease of IP parameters received earlier. If this attempt is unsuccessful, at the end of lease time the client has to release received IP address.

In the previous example the server sets lease time equal to seven days. We decreased lease time to one minute and captured the process of DHCP messages exchange. From the list of packets below, one can see that almost each 30 seconds the client sends DHCP request message requesting for the acknowledgement to use received addresses from the server. Answering to this message, the server sends DHCP ack packet. For example, pairs of packets 5-6, 7-8 and 9-10 are successful attempts of lease extension. Packet #11 contains DHCP request message for which acknowledgement from the server was not received. So the client sends broadcast DHCP request (packet #12) for which (in our example) acknowledgment was not received too. Packets #13-17 contain standard DHCP discover messages sent after the host refused from the used IP address.

The picture below shows content of DHCP offer packet containing all three timers.

If the client is Cisco router, the following messages are shown in log at the moment of ending the lease.

R1#*Aug 11 21:16:12.743: %DHCP-5-RESTART: Interface GigabitEthernet0/0 is being restarted by DHCP
R1#*Aug 11 21:16:14.815: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
R1#*Aug 11 21:16:15.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
R1#*Aug 11 21:16:17.847: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
R1#*Aug 11 21:16:18.847: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up

We also cannot ignore the first message sending by the client – DHCP discover. Option #55 (Parameter Request List) contains the list of options interesting for an end device. The picture below displays such a list generated by Cisco 7206VXR (NPE400) router with the operating system IOS of 15.2(4)M8 ADVENTERPRISEK9 version, performing functions of DHCP client.

The list of requested options is not static, its content depends on the type and configuration of the end device. So, for example, for the client based on Windows 7 x64 operating system the list is a bit different and shown below.

Strictly speaking, one cannot fully identify a client based on the list of requested parameters, but, nevertheless, operating system and using software leave some fingerprint in DHCP messages according to which it’s possible to approximately identify which client is used. We will not describe all possible fingerprints here, but specify some of the most interesting ones. So, for example, Cisco router includes brief information about itself to the option #61. Option #12 contains name of the requesting host. Perhaps, it’s worth noting that among the opportunities provided by Cisco ISE system, there is a function for identifying an operating system used by the client, but discussing the questions of this system working is far out of the article’s scope.

DHCP client built in Microsoft Windows 7 x64 operating system also sends some information about itself according to which it can be identified with the help of the option #60 (Vendor class identifier).

In addition to already described messages of DHCP, there is one more that we didn’t mention yet – DHCP information. With the help of it the client can request additional information which was not sent by the server in DHCP offer message.

That’s where we proceed to completion of the review of the main aspects of DHCP operating and pass directly on to its configuration.

Configuration of equipment

To configure using of DHCP on the client side is usually not very difficult. For instance, in case of using Microsoft Windows 7 operating system, the only thing that should be performed is selecting “Get IP address automatically” option in IPv4 protocol settings.

To make sure of successful receiving the address with the help of GUI is also not difficult.

One can get the information about current configuration of the computer network cards in modern Microsoft Windows operating systems with the help of ipconfig /all command.

C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : torrent
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : Beeline.Gate
Ethernet adapter LAN 2:
Connection-specific DNS Suffix  . : Beeline.Gate
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT NIC
Physical Address. . . . . . . . . : 00-0C-29-CD-86-26
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.0.1.112(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 13 Aug 2015 21:20:01
Lease Expires . . . . . . . . . . : 14 Aug 2015 21:20:01
Default Gateway . . . . . . . . . : 10.0.1.5
DHCP Server . . . . . . . . . . . : 10.0.1.5
DNS Servers . . . . . . . . . . . : 8.8.8.8
Primary WINS Server . . . . . . . : 10.0.1.5
NetBIOS over Tcpip. . . . . . . . : Enabled

Administrator can refuse from the assigned address and request a new one via ipconfig /release and ipconfig /renew commands. It’s also worth noting that in the specified set of operating systems there is a rather powerful network utility netsh, with the help of which one can view and change parameters of network cards working. So, for example, one can get information about using IPv4 addresses with the help of netsh interface ipv4 show addresses command.

Modern SOHO routers allow connecting to a provider obtaining IP parameters dynamically. The pictures below show typical settings for connection to the ISP on the example of two modern wireless routers.

Apart from this, such devices have built-in DHCP server that allows dynamic assigning of IP addresses in the user LAN. Yes, there are not too many parameters here…

All further configurations we will perform using Cisco Systems equipment in the network emulator GNS3 of 1.3.9 version. We decided to use this emulator intentionally to provide our readers with the opportunity to repeat all the settings in question by themselves. It’s worth noting that in GNS3 of 1.4.0 version built-in support of virtual machines VMware will appear, that makes the process of new network schemas testing simpler. Certainly, even now there is an opportunity to connect emulating in GNS3 equipment with a real network and VMware virtual networks with the help of a cloud object, but we cannot consider this connection very convenient. But we’ve digressed, it’s time to get back to DHCP. As routers we will use 7206VXR (NPE400) model with IOS ADVENTERPRISEK9 of 15.2(4)M8 version. Also we need L2 switch IOU (switch built-in to GNS is not applicable because of the absence of the needed functionality).

Basically, as DHCP client in GNS3 one can use VPCS object that allows static and dynamic assigning of IP parameters. For demonstrating VPCS operating we prepared a simple schema shown below. Configuration of the server side – router R1 – we’ll discuss later.

The listing displayed below shows the process of dynamic obtaining of IP parameters by the virtual host VPCS of 0.6.1 version in GNS3 emulator.

PC1> ip ?
ip ARG ... [OPTION]
 Configure the current VPC's IP settings
 ARG ...:
 address [mask] [gateway]
 address [gateway] [mask]
 Set the VPC's ip, default gateway ip and network mask
 Default IPv4 mask is /24, IPv6 is /64. Example:
 ip 10.1.1.70/26 10.1.1.65 set the VPC's ip to 10.1.1.70,
 the gateway to 10.1.1.65, the netmask to 255.255.255.192.
 In tap mode, the ip of the tapx is the maximum host ID
 of the subnet. In the example above the tapx ip would be
 10.1.1.126
 mask may be written as /26, 26 or 255.255.255.192
 auto           Attempt to obtain IPv6 address, mask and gateway using SLAAC
 dhcp [OPTION]  Attempt to obtain IPv4 address, mask, gateway, DNS via DHCP
 -d         Show DHCP packet decode
 -r         Renew DHCP lease
 -x         Release DHCP lease
 dns ip         Set DNS server ip, delete if ip is '0'
 domain NAME    Set local domain name to NAME
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.101/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 86388, 86400/43200/75600
MAC         : 00:50:79:66:68:00
LPORT       : 10001
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500

Despite the fact that VPCS requires less RAM for its work than virtual Cisco router of 7200 series, we will further use this particular router even for performing DHCP client role, because, firstly, the command line of the router is more familiar to us and, secondly, we are not limited in resources.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no sh
R2(config-if)#ip add dc
*Aug 14 08:50:40.347: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Aug 14 08:50:41.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
R2(config-if)#ip address dhcp
*Aug 14 08:50:59.183: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.102, mask 255.255.255.0, hostname R2
R2(config-if)#^Z
R2#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.102   YES DHCP   up                    up  
FastEthernet1/0            unassigned      YES unset  administratively down down
FastEthernet1/1            unassigned      YES unset  administratively down down
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.0.1
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.102/32 is directly connected, GigabitEthernet0/0
R2#sho ip dns view
DNS View default parameters:
Logging is off
DNS Resolver settings:
 Domain lookup is disabled
 Default domain name:
 Domain search list:
 Lookup timeout: 3 seconds
 Lookup retries: 2
 Domain name-servers:
 8.8.8.8
DNS Server settings:
 Forwarding of queries is disabled
 Forwarder timeout: 3 seconds
 Forwarder retries: 2
 Forwarder addresses:

From the listing above one can see that router R2 gets IP address 192.168.0.102/24 on its Gi0/0 interface. Apart from the address itself, default route and the address of DNS server were provided with the help of DHCP. More detailed information on the operating of DHCP on the client router one can get with the help of sho dhcp lease command.

R2#sho dhcp lease
Temp IP addr: 192.168.0.102  for peer on Interface: GigabitEthernet0/0
Temp  sub net mask: 255.255.255.0
 DHCP Lease server: 192.168.0.1, state: 5 Bound
 DHCP transaction id: 2155
 Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs
Temp default-gateway addr: 192.168.0.1
 Next timer fires after: 11:53:40
 Retry count: 0   Client-ID: cisco-ca02.0468.0008-Gi0/0
 Client-ID hex dump: 636973636F2D636130322E303436382E
 303030382D4769302F30
 Hostname: R2

Naturally, displaying of debug information about DHCP messages exchange is available. The listing shown below displays the moment of refuse from the address leased before by router R2. Displaying of debug messages can be also performed on DHCP server side, but it’s worth noting that one should be especially careful during using debug command in heavy loaded networks.

R2#debug dhcp ?
 detail      DHCP packet content
 redundancy  DHCP client redundancy support
 <cr>
R2#debug dhcp
DHCP client activity debugging is on
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no ip add
*Aug 14 08:59:30.487: DHCP: Sending notification of TERMINATION:
*Aug 14 08:59:30.487:   Address 192.168.0.102 mask 255.255.255.0
*Aug 14 08:59:30.491: DHCP: Client socket is opened
*Aug 14 08:59:30.491: DHCP: SRelease attempt # 1 for entry:
*Aug 14 08:59:30.491: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:30.495: DHCP: SRelease: 279 bytes
*Aug 14 08:59:32.175: DHCP: SRelease attempt # 2 for entry:
*Aug 14 08:59:32.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:32.175: DHCP: SRelease: 279 bytes
*Aug 14 08:59:34.175: DHCP: SRelease attempt # 3 for entry:
*Aug 14 08:59:34.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:34.175: DHCP: SRelease: 279 bytes
R2(config-if)#
*Aug 14 08:59:35.999: RAC: DHCP stopped on interface GigabitEthernet0/0
R2(config-if)#
*Aug 14 09:00:07.207: DHCP: deleting entry 6AF1FA40 192.168.0.102 from list
*Aug 14 09:00:07.207: DHCP: Client socket is closed
R2(config-if)#do sho deb
DHCPC:
 DHCP client activity debugging is on

Now let’s review settings on the server side that is the configuration of router R1. The first that should be done is starting a corresponding service. In modern IOS versions DHCP service is launched by default. One can disable the specified service with the help of no service dhcp command.

R1(config)#service dhcp
R1(config)#no service dhcp

The second step is creating DHCP pool with the help of ip dhcp pool name command, where name is a name of creating pool. In the listing below on router R1 foxnetwork pool is being created, for which DNS servers, default gateway and lease time are specified. If some changes are planned in the network in the near future, we recommend significant reducing of the lease time before these changes to allow user devices to react to the happened changes as quickly as possible. After the network topology is stabilized, lease time can be significantly increased. Lease time is often set equal to several days or even weeks. Basically, value of this parameter is chosen not only according to static character of the network infrastructure, but also considering the mobility of the clients. For example, during organizing a network in a café, it should be considered that changing of visitors happens very often, so it doesn’t make sense to set lease time equal to more than one hour. With the help of network command one can choose an interface to which the pool is connected and specify range of addresses used for assigning to the clients. One can exclude some IP addresses from the range with the help of ip dhcp excluded-address global command.

ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 lease 1
 default-router 192.168.0.1
 dns-server 8.8.8.8

One can view the list of created pools and their usage with the help of sho ip dhcp pool command.

R1#sho ip dhcp pool
Pool foxnetwork :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.102        192.168.0.1      - 192.168.0.254     1

The command sho ip dhcp binding displays the list of addresses assigned to the clients.

R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.101       0063.6973.636f.2d63.    Aug 21 2015 09:46 AM    Automatic
 6130.322e.3034.3638.
 2e30.3030.382d.4769.
 302f.30

One can get static information about DHCP service operating on a router with the help of sho ip dhcp server statistics command.

R1#sho ip dhcp server statistics
Memory usage         73238
Address pools        1
Database agents      0
Automatic bindings   1
Manual bindings      0
Expired bindings     0
Malformed messages   0
Secure arp entries   0
Message              Received
BOOTREQUEST          0
DHCPDISCOVER         5
DHCPREQUEST          4
DHCPDECLINE          0
DHCPRELEASE          6
DHCPINFORM           0
Message              Sent
BOOTREPLY            0
DHCPOFFER            4
DHCPACK              4
DHCPNAK              0

Sometimes in corporate networks the necessity of static binding of providing IP address to a particular client occurs. Such a binding can be performed based on the client identifier sending in option #61. Compare values of option #61 in DHCP discovery messages sending by different DHCP clients. The example of DHCP discovery sending by Cisco router is contained in foxnetwork_1.pcapng file, the same message from Microsoft Windows 7 is in foxnetwork_3.pcapng file. So, before creating a static binding of IP address to the client, one should clarify the value of identifier sent by the client operating system. After the identifier is clarified, it’s necessary to start configuration of DHCP server working on the router. Static binding is performed by creating a new DHCP pool in which one only has to specify address providing to the client and client identifier. In addition, one can specify client name with the help of client-name command (is not provided to the client in DHCP messages). The example of such a pool is shown below.

ip dhcp pool r2
 host 192.168.0.111 255.255.255.0
 client-identifier 0063.6973.636f.2d63.6130.322e.3135.3063.2e30.3030.382d.4769.302f.30
 client-name test

All other settings (apart from IP address) the client inherits from the parent pool. It's also worth noting that inheritance of the settings is also performed during using ordinary pools. Let’s review a small fragment of the network shown below.

In the listing below we created two pools for nested ranges 192.168.0.0/16 and 192.168.0.0/24. For the larger subnet the only setting is performed: address of the DNS server. The pool with the smaller more subnet contains address of the default gateway.

ip dhcp pool parent
 network 192.168.0.0 255.255.0.0
 dns-server 8.8.8.8
ip dhcp pool child
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
R1#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.1     YES manual up                    up 

One can make sure that the client (which role VPCS host performs) gets all necessary settings with the help of show ip command.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.2/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 86397, 86400/43200/75600
MAC         : 00:50:79:66:68:00
LPORT       : 10000
RHOST:PORT  : 192.168.228.2:10001
MTU:        : 1500

For consolidating the knowledge we recommend that the beginner readers perform the corresponding lab.

The process of assigning IP address

Earlier we reviewed ip dhcp excluded-address command that allows excluding a range of addresses from delivery. Such exclusion is helpful when in one IP subnet there are both dynamically configuring clients and hosts with the static configuration, for example, interfaces of the network equipment or server. But what if a statically configured device with the address out of excluding range exists in the network? For discovering such situations DHCP service working on Cisco router uses ICMP protocol. Probably, some of our readers will be surprised when find out that ICMP echo but not ARP is used. Yes, exactly ICMP is used and then it will be clear why. Let’s review what exactly happens at the moment of address delivery to the client, on the examples.

To start with let’s, use a simple schema with two routers R1 and R2 which we used before. R1 performs server functions and R2 – client ones. All packets of which two devices exchange we saved to the file foxnetwork_4.pcapng. The first packet is sent by the client, this is a simple gratuitous ARP, after which a broadcast message DHCP discover follows. The third packet is ARP request of DHCP server for 192.168.0.102 address. Next three packets are an ordinary ending of DHCP exchange. But what is 192.168.0.102 address? From the fourth packet (DHCP offer) it’s clear that this is the address offered to the client by the server. So, before providing an IP address the server broadcasts ARP request. But no ICMP, right? Well, let’s try to place in the network a host with the IP address that R1 plans to deliver. Our network changed a bit.

We added router R3 and assigned to its Gi0/0 interface IP address 192.168.0.103 which should be provided on the next DHCP request to router R1. The next providing IP address is shown in the listing of sho ip dhcp pool command in Current index field. We captured the process of messages exchange on receiving the address by router R2 and saved it to foxnetwork_5.pcapng file. According to the traffic dump, one can see that router R1 after receiving DHCP request sends ARP request for 192.168.0.103 address and after receiving an answer sends ICMP echo-request message, in reply to which R3 sends ICMP echo-reply. After receiving echo-reply, router R1 checks if the address 192.168.0.104 is occupied. Made sure that the address in question is free, R1 offers it to the client. So, we watched that during choosing an address for the client DHCP server checks the occupation of this address using ICMP. Cisco Systems routers performing functions of DHCP server even allow setting a number of sending ICMP echo-requests and their timeouts.

R1(config)#ip dhcp ping ?
 packets  Specify number of ping packets
 timeout  Specify ping timeout
R1(config)#ip dhcp ping pa
R1(config)#ip dhcp ping packets ?
 <0-10>  Number of ping packets (0 disables ping)
 <cr>
R1(config)#ip dhcp ping ti
R1(config)#ip dhcp ping timeout ?
 <100-10000>  Ping timeout in milliseconds

The only question is open: what is DHCP server going to do in case of receiving ARP reply but not receiving ICMP echo-reply? Let’s try to reproduce this situation. To forbid router R3 from replying to ICMP requests, one should create an access list denying ICMP echo and enter command no ip unreachables on the interface Gi0/0. The access list and configuration of Gi0/0 interface of router R3 are shown in the listing below. We’d like to pay readers’ attention to the fact that we also changed IP address of the interface because the next offered by DHCP address should be 192.168.0.105.

ip access-list extended NOICMP
 deny   icmp any any
 permit ip any any
interface GigabitEthernet0/0
 ip address 192.168.0.105 255.255.255.0
 ip access-group NOICMP in
 no ip unreachables
 duplex full
 speed 1000
 media-type gbic
 negotiation auto

And what happens now if suppose that DHCP service of Cisco routers relies exactly on ICMP? During using the shown configuration, R2 should receive the address already assigned to router R3. Fortunately, this doesn’t happen because before start using of address offered by DHCP server, the client checks the presence of this address in the network with the help of ARP. All messages of which the routers exchange are shown in foxnetwork_6.pcapng file. The sequence of actions of hosts in the network is as follows.

  1. R2 sends DHCP discover message
  2. R1 checks the availability of 192.168.0.105 address with the help of ICMP
  3. During such checking R3 replies to ARP request (that makes it possible to send ICMP message), but doesn’t reply to ICMP echo-request message
  4. Router R1, not having received ICMP message from the host with 192.168.0.105 address, offers its using to R2 client with the help of DHCP offer message
  5. R2 client receives DHCP offer message containing offered IP address from R1 server, after which performs its own checking of availability of 192.168.0.105 address with the help of ARP protocol
  6. R3 host replies to ARP request of router R2
  7. R2 considers that IP address 192.168.0.105 offered by the server is already occupied, and sends notification about this to the server with the help of DHCP decline message
  8. R1 adds 192.168.0.105 address to its base of conflicting addresses
  9. R2 again initiates search of DHCP server by sending DHCP discover message
  10. R1 server chooses the next address from the pool - 192.168.0.106 and checks if it is available
  11. R1 server offers 192.168.0.106 address to R2 client with the help of DHCP offer message
  12. R2 client requests permission on using 192.168.0.106 address from the server with the help of DHCP request message
  13. R1 server acknowledges using of 192.168.0.106 address by R2 client with the help of DHCP ack message
  14. Router R2 performs its own checking of the new address availability and makes sure that it’s free

Stop-stop-stop! There is something wrong in this list. According to the dump, after sending the second DHCP discover message, the client doesn’t perform validation of availability for the offered address and accepts it right away, after which broadcasts gratuitous ARP message. We repeated the process one more time and assigned 192.168.0.107 address to router R3. This cannot be a mistake, everything comes this exact way. But what happens if the repeatedly received address occurred to be occupied? We added one more host to our schema with the next following in order address, so there are R3 host with 192.168.0.109 address and R4 with 192.168.0.110 address that don’t reply to ICMP messages in our network.

We again initiated the procedure of obtaining an IP address by router R2. The traffic dump we saved in foxnetwork_7.pcapng file. So, having received IP address the second time, the client assigns it to its interface, sends gratuitous ARP, discovers the occupation of the address in question, after which performs a standard procedure of rejection from the received address with the help of DHCP decline message. On R3 and R4 hosts the following messages appears at this moment.

*Aug 14 15:22:04.751: %IP-4-DUPADDR: Duplicate address 192.168.0.110 on GigabitEthernet0/0, sourced by ca02.150c.0008

One can view the list of conflicting addresses on R1 with the help of sho ip dhcp conflict command.

R1#sho ip dhcp conflict
IP address        Detection method   Detection time          VRF
192.168.0.103     Ping               Aug 14 2015 01:12 PM                       
192.168.0.105     Gratuitous ARP     Aug 14 2015 02:15 PM                       
192.168.0.107     Gratuitous ARP     Aug 14 2015 03:16 PM                       
192.168.0.109     Gratuitous ARP     Aug 14 2015 03:22 PM                       
192.168.0.110     Gratuitous ARP     Aug 14 2015 03:22 PM     

Clearing of conflicting addresses base is performed with the help of clear ip dhcp conflict command.

R1#clear ip dhcp conflict ?
 *        Clear all address conflicts
 A.B.C.D  Clear a specific conflict
 vrf      DHCP vrf conflicts
R1#clear ip dhcp conflict *
R1#sho ip dhcp conflict
IP address        Detection method   Detection time          VRF
R1#

That’s where we complete the review of getting IP parameters procedure and go to review of using secondary IP subnets together with DHCP.

Secondary subnet

On increasing a number of IP devices in the network, run out of IP addresses in the pool can occur. Certainly, in some cases one can solve this problem by decreasing IP address lease time, however, situations when all devices are in up state are not rare. There are two ways out of the situation in question: increase of the earlier leased subnet or using the secondary subnet. Unfortunately, increase of the subnet is not always possible, for example, because of absence of large continuous subnets. Let’s review configuration of equipment for using the secondary subnet on the example of the network shown below. Let’s consider that subnet 192.168.0.0/30 was used initially for connecting PC1 host with router R1. After PC2 node was added, the existing range became not enough.

The listing below demonstrates main settings of router R1 before adding PC2 host. Loopback 0 interface is used for the emulation of the global network.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.252
 default-router 192.168.0.1
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 lease 0 1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.252
 load-interval 30

The first from which we should begin is configuration of the router’s interface and L3 switch, on which interface it’s needed to set secondary IP address.

R1#sho run int gi0/0
Building configuration...
Current configuration : 204 bytes
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.252 secondary
 ip address 192.168.0.1 255.255.255.252
 load-interval 30
end

One of the ways of using the secondary subnet by DHCP server is creation of the second DHCP pool.

ip dhcp pool foxnetwork2
 network 192.168.1.0 255.255.255.252
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 default-router 192.168.1.1
 lease 0 1

Apart from creation of the second pool, more elegant solution exists, that is in specifying a secondary subnet presence in the settings of existing address pool.

R1#sho run | sec pool
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.252
 network 192.168.1.0 255.255.255.252 secondary
 override default-router 192.168.1.1
 default-router 192.168.0.1
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 lease 0 1

It’s worth noting that for the secondary subnet one can change only the value of default gateway in the settings of DHCP pool. If it’s necessary to differ some other parameters, the only solution is creation of the second DHCP pool.

It remains only to check the functionality of the construction described above.

PC2> ip dh
DDORA IP 192.168.1.2/30 GW 192.168.1.1
PC2> sho ip
NAME        : PC2[1]
IP/MASK     : 192.168.1.2/30
GATEWAY     : 192.168.1.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 3599, 3600/1800/3150
DOMAIN NAME : foxnetwork.ru
MAC         : 00:50:79:66:68:01
LPORT       : 10004
RHOST:PORT  : 192.168.56.1:10005
MTU:        : 1500
PC2> sho ip all
NAME   IP/MASK              GATEWAY           MAC                DNS
PC2    192.168.1.2/30       192.168.1.1       00:50:79:66:68:01  8.8.8.8
PC2> sho arp
ca:01:5f:7c:00:08  192.168.1.1 expires in 37 seconds
PC2> ping 192.168.1.1 -c 3
84 bytes from 192.168.1.1 icmp_seq=1 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.1 -c 3
84 bytes from 192.168.0.1 icmp_seq=1 ttl=255 time=5.001 ms
84 bytes from 192.168.0.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 192.168.0.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.2 -c 3
84 bytes from 192.168.0.2 icmp_seq=1 ttl=63 time=11.001 ms
84 bytes from 192.168.0.2 icmp_seq=2 ttl=63 time=19.001 ms
84 bytes from 192.168.0.2 icmp_seq=3 ttl=63 time=19.002 ms
PC2> ping 1.1.1.1 -c 3
84 bytes from 1.1.1.1 icmp_seq=1 ttl=255 time=4.000 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=255 time=9.000 ms

An obvious drawback of using secondary subnets (instead of increase of an existing network) is the necessity of using a router for transmitting traffic between hosts of primary and secondary IP networks. Using of two or more IP networks in this case doesn’t lead to the decrease of broadcast traffic that, probably, should be considered during building large corporate networks. In this case, probably, it’s better to use several virtual networks (VLAN) and different DHCP pools. One more remark that we’d like to add, is connected with using of multilayer switches. If the only MLS device performing functions of routing, switching and DHCP server is used, one can ignore the increase of delays and decrease of the network performance (because of the necessity to route traffic between hosts of primary and secondary IP networks).

During discussing the specifics of using secondary IP networks on the interfaces we cannot help but mention about ip dhcp smart-relay command that influences the router’s functioning that performs functions of DHCP relay and uses secondary IP addresses on the interfaces. Let’s review a small network shown in the picture below as an example.

Router R1 is DHCP relay and R2 performs functions of DHCP server. Suppose that on Fa1/0 interface of router R1 two IP networks are configured. The example of Fa1/0 interface of router R1 configuration is shown below. Address 2.2.2.2 is assigned to Loopback interface of router R2. Consider that routing is configured in appropriate way on both routers.

interface FastEthernet1/0
 ip address 192.168.1.1 255.255.255.0 secondary
 ip address 192.168.0.1 255.255.255.0
 ip helper-address 2.2.2.2

On router R2 DHCP pool is configured.

ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool foxnetwork
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.1
 dns-server 8.8.8.8
 lease 0 1

By default, router R1 sends DHCP discover message from primary IP address assigned to Fa1/0 interface. As there is no DHCP pool for the network 192.168.0.0/24 on router R2, DHCP offer message will not be sent that will lead to the fact that client host PC1 will not receive IP address. Enable of smart-relay option makes router R1 after sending of three messages from the primary IP address send DHCP discover messages from the address of the secondary network in situation when for the first three messages DHCP offer was not received. Capturing of DHCP messages between routers R1 and R2 we saved to the file foxnetwork_13.pcapng. It would be good for the readers to pay attention to the field «Relay agent IP address» in DHCP discover messages.

From the routing point of view, primary and secondary networks are not different in principle. Here we don’t review using of dynamic routing protocols, some of which cannot establish neighbourship with other routers placed in secondary IP networks.

R1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, GigabitEthernet0/0
L        192.168.0.1/32 is directly connected, GigabitEthernet0/0
 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/30 is directly connected, GigabitEthernet0/0
L        192.168.1.1/32 is directly connected, GigabitEthernet0/0

Now let’s review which other options are provided by Cisco equipment during working with the protocol.

Additional options: relay

All schemas discussed above supposed setting of DHCP server directly to the user segment. Certainly, using of multilayer switch as DHCP server is also appropriate, however, during using of MLS equipment, using of IPAM systems, to which the solution of managing Cisco Network Registrar (CNR) networks belongs, can be difficult or even impossible. If a technology that allows not connecting DHCP server to each user segment and not making switches and routers perform IP addresses distribution exists? Such a function, certainly, exists and is called DHCP relay. Equipment performing function of DHCP relay intercepts broadcast messages DHCP discover and sends them to DHCP server. Enable of relay function is performed with the help of interface command ip helper-address. Let’s review a small schema shown below.

PC1 host is DHCP client. Router R1 terminates client network on itself and performs relay functions. Router R2 is DHCP server. Let’s view the main configuration parameters for both routers. On R1 device the following commands are used.

interface Loopback0
 ip address 192.168.255.1 255.255.255.255
interface FastEthernet1/0
 ip address 192.168.0.1 255.255.255.0
 ip helper-address 192.168.255.2
interface FastEthernet1/1
 ip address 192.168.1.1 255.255.255.0
router eigrp 1
 network 192.168.1.0
 redistribute connected

Configuration of router R2 is displayed below.

ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
 lease 0 1
interface Loopback0
 ip address 192.168.255.2 255.255.255.255
interface FastEthernet1/1
 ip address 192.168.1.2 255.255.255.0
router eigrp 1
 network 192.168.1.0
 redistribute connected

The process of getting IP address by the client with the use of relay doesn’t differ from one with placing of DHCP server directly in the client network.

PC1> ip dhcp
DDORA IP 192.168.0.11/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.11/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 3595, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10000
RHOST:PORT  : 192.168.56.1:10001
MTU:        : 1500
PC1> ping 192.168.255.2
84 bytes from 192.168.255.2 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=3 ttl=254 time=16.001 ms
84 bytes from 192.168.255.2 icmp_seq=4 ttl=254 time=21.001 ms
84 bytes from 192.168.255.2 icmp_seq=5 ttl=254 time=32.002 ms

Naturally, we captured the process of receiving IP address by the client. In the file foxnetwork_11.pcapng there are packets sending between the client and router R1, and foxnetwork_12.pcapng file contains traffic of which routers R1 and R2 exchanged. As one can see from the dump foxnetwork_12.pcapng, exchange of DHCP messages between routers is performed with the help of unicast addresses. We recommend that our readers compare the value of «Relay agent IP address» field in both files. Also it’s interesting to view ICMP traffic sending by DHCP server in the process of getting IP address by the client. In the previous package we described algorithms using by DHCP server for checking the assignment of IP address before offering it to the client. Well, ARP protocol in this case, obviously, cannot be used at all, because sending of ARP messages via router can’t be performed.

It’s worth noting that by default ip helper-address command sends not only DHCP messages but also the whole set of other ones. One can disable relaying of the protocol with the help of no ip forward-protocol command.

switch(config)#no ip forward-protocol ?
 nd             Sun's Network Disk protocol
 sdns           Network Security Protocol
 spanning-tree  Use transparent bridging to flood UDP broadcasts
 turbo-flood    Fast flooding of UDP broadcasts
 udp            Packets to a specific UDP port
switch(config)#no ip forward-protocol udp ?
 <0-65535>      Port number
 biff           Biff (mail notification, comsat, 512)
 bootpc         Bootstrap Protocol (BOOTP) client (68)
 bootps         Bootstrap Protocol (BOOTP) server (67)
 discard        Discard (9)
 dnsix          DNSIX security protocol auditing (195)
 domain         Domain Name Service (DNS, 53)
 echo           Echo (7)
 isakmp         Internet Security Association and Key Management Protocol (500)
 mobile-ip      Mobile IP registration (434)
 nameserver     IEN116 name service (obsolete, 42)
 netbios-dgm    NetBios datagram service (138)
 netbios-ns     NetBios name service (137)
 netbios-ss     NetBios session service (139)
 non500-isakmp  Internet Security Association and Key Management Protocol (4500)
 ntp            Network Time Protocol (123)
 pim-auto-rp    PIM Auto-RP (496)
 rip            Routing Information Protocol (router, in.routed, 520)
 snmp           Simple Network Management Protocol (161)
 snmptrap       SNMP Traps (162)
 sunrpc         Sun Remote Procedure Call (111)
 syslog         System Logger (514)
 tacacs         TAC Access Control System (49)
 talk           Talk (517)
 tftp           Trivial File Transfer Protocol (69)
 time           Time (37)
 who            Who service (rwho, 513)
 xdmcp          X Display Manager Control Protocol (177)
 <cr>

Also we cannot help but mention one, probably, not the most obvious detail: on the router performing functions of DHCP relay, DHCP service should be enabled. Enable of the service is performed with the help of service dhcp command, for disable one can use no service dhcp command. In Cisco routers this service is enabled by default and in running state is not even displayed in running config.

R2#sho run | i dhcp
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#no serv dhcp
R2(config)#^Z
R2#sho run | i dhcp
no service dhcp
R2#

Administrator can also configure the behavior of DHCP relay for receiving DHCP message containing information about another relay. The specified messages can be dropped, encapsulated (DHCP server can use both options #82), sent without changes or the information about relay can be changed.

switch(config)#ip dhcp relay information policy ?
 drop         Do not forward BOOTREQUEST message
 encapsulate  Encapsulate existing information
 keep         Leave existing information alone
 replace      Replace existing information

Very close to DHCP relay topic, there are support of option #82 and DHCP snooping, which we will discuss in the next section.

Additional options: option 82, snooping

Before this moment we didn’t configure switch connecting the client with router R1, the only thing that was required that ports e0/0 and e0/1 were placed in the same virtual network. However, from time to time the necessity to provide a particular client with a particular address with the help of DHCP occurs. The problem became more difficult if the client can use different devices for connecting to the network, so his/her MAC-address and client identifier can differ, that won’t allow DHCP server to use these fields for creating a static binding. In this case switch with the support of option 82 can help. This option differs from all others by the fact that it is added to DHCP message not by the client or server but by the switch, and DHCP server analyzes its value. Fortunately, L2 IOU of adventerprisek9-15.1a version supports this function. Enable of option 82 support is performed with the help of ip dhcp relay information option command in global configuration mode. Also one should enable DHCP snooping. Commands configured on the router are displayed below.

ip dhcp relay information option
ip dhcp snooping vlan 1
ip dhcp snooping
interface Ethernet0/1
 ip dhcp snooping trust

We captured DHCP discover message on the part of network between IOU1 switch and router R1. As one can see from the picture below, the switch added option #82 to the message. Its content we are not reviewing yet.

However, despite the fact that we watched DHCP discover message in the network, the client stopped receiving IP address. Viewing of the traffic dump leads us to the fact that router R1 stopped performing relay functions. It’s unexpected, right? With the help of deb ip dhcp server packet command we enabled displaying of debug information on DHCP router. At the moment of receiving the packet with DHCP discover message, the following messages are shown in the console –so named sanity check worked.

*Aug 21 18:28:28.247: DHCPD: inconsistent relay information.
*Aug 21 18:28:28.247: DHCPD: relay information option exists, but giaddr is zero

Disable of the check specified above is performed on Fa1/0 interface of router R1 with the help of ip dhcp relay information trusted command, after which the client successfully gets IP address. The list of interfaces for which this command is enabled can be shown with the help of sho ip dhcp relay information trusted-sources call.

R1#sho ip dhcp relay information trusted-sources
List of trusted sources of relay agent information option:
FastEthernet1/0

Providing IP address to the client doesn’t consider the value of option #82 at the moment. To allow DHCP server to consider value of option #82, one should configure a special class for this client. The example of such configuration is shown below.

ip dhcp class foxnetwork
 remark test client
 relay agent information
 relay-information hex 010600040001000002080006aabbcc000100

Command remark is not necessary; however, we strongly recommend using it for not confusing in a big number of created classes. With the help of this command one should give the most clear description connected with the client for which this class is being created.

Now it’s required to use created class in DHCP server settings. Configuration of DHCP pool is displayed below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
 lease 0 1
 class foxnetwork
 address range 192.168.0.101 192.168.0.101

Let’s repeat getting IP address by the client and make sure that PC1 received address 192.168.0.101.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.11/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 2753, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.101/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 3593, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500

But what is a magic number 010600040001000002080006aabbcc000100 which we specified in command relay-information and which was sent in option #82? Let’s check from which parts it’s consist from.

010600040001000002080006aabbcc000100
0106 Beginning of the first section, 6 bytes
0004 Field curcuit-id, 4 bytes
0001 VLAN number (in hex)
0000 Number of switch port to which the client is connected (starts from zero)
0208 Beginning of the second section, 8 bytes
0006 Field remote-id, 6 bytes
aabbcc000100 MAC address of the switch, to which the client is connected

Now we can calculate the value of option #82 beforehand, without waiting for it in the captured packets. To be fair, it’s worth mentioning that Cisco switches allow changing the format of option #82.

cisco_3750(config)#ip dhcp snooping information option format remote-id ?
 hostname  Use configured hostname for remote id
 string    User defined string for remote id
cisco_3750(config)#ip dhcp snooping information option format remote-id hostname ?
 <cr>
cisco_3750(config)#ip dhcp snooping information option format remote-id string ?
 WORD  Use string for remote id (max length 63)

During configuration of the switch in this section we used functions DHCP snooping. But what is it purposed for? DHCP snooping function of the switch is purposed for the defense against attacks using DHCP. The example of such an attack is installation of rogue DHCP server or DHCP starvation attack in the result of which the attacker can completely exhaust the address space allocated by the DHCP servers. The database created at the result of DHCP snooping working can be used by other defense mechanisms among which are DAI (Dynamic ARP Inspection) and IP Source Guide. However, discussion of these functions working is out of scope of this article.

DHCP snooping function sets two roles for all ports: trusted and untrusted. To trusted ports one can connect other switches or DHCP servers, DHCP-messages received via these ports are not dropped. DHCP traffic received from untrusted ports is inspected and messages DHCP offer, ack/nack and leasequery are dropped. Inspecting of DHCP traffic from untrusted ports means, for example, the following: messages DHCP release and decline are checked on correspondence to the database, checking of the correspondence between MAC addresses in the frame and in DHCP message itself, the absence of option #82 is checked. Also one can make routers perform checking of DHCP messages on the absence of relay’s address in the message.

IOU1(config)#ip dhcp snooping verify ?
 mac-address             DHCP snooping verify mac-address
 no-relay-agent-address  DHCP snooping verify giaddr

Viewing of configurations of DHCP snooping function is performed with the help of show ip dhcp snooping command.

IOU1#sho ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is operational on following VLANs:
1
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
 circuit-id default format: vlan-mod-port
 remote-id: aabb.cc00.0100 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface                  Trusted    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------
Ethernet0/1                yes        yes             unlimited
 Custom circuit-ids:

Command show ip dhcp snooping statistics displays statistical information about working of DHCP snooping.

IOU1#sho ip dhcp snooping statistics
 Packets Forwarded                                     = 229
 Packets Dropped                                       = 0
 Packets Dropped From untrusted ports                  = 0

One can view current bindings with the help of show ip dhcp snooping binding command.

IOU1#sho ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:50:79:66:68:00   192.168.0.101    1992        dhcp-snooping   1     Ethernet0/0
Total number of bindings: 1

Sometimes it’s necessary to add a static record to the database of DHCP snooping bindings. To perform the operation in question one should use ip dhcp snooping binding <mac-address> vlan <vid> <IP address> interface <interface-id> expiry <seconds> command. The key word expiry allows specifying time interval during which a creating record will be existing. The maximum value allowed by expiry option is 4294967295 seconds that is almost equal to 136 years.

The database of DHCP snooping function can be stored locally in nonvolatile memory or on the remote servers.

IOU1(config)#ip dhcp snooping database ?
 disk0:       Database agent URL
 disk1:       Database agent URL
 ftp:         Database agent URL
 http:        Database agent URL
 rcp:         Database agent URL
 scp:         Database agent URL
 tftp:        Database agent URL
 timeout      Configure abort timeout interval
 unix:        Database agent URL
 write-delay  Configure delay timer for writes to URL

Probably, we can also mention here that one can save on remote servers or in nonvolatile memory not only the database of DHCP snooping function but also the base of DHCP bindings that is the base of IP addresses used by the clients at the moment. Such saving of the database can be required for not losing the database at the moment of device reboot. The example of command saving the base of DHCP bindings locally is displayed below.

ip dhcp database disk1:fox.txt

However, the file will be created not right after entering the command but with some delay. By default, such delay is equal to 300 seconds. One can make sure of this delay with the help of sho run all command displaying all values of the default parameters. In the listing below the same command is shown but together with the default parameters.

ip dhcp database disk1:fox.txt write-delay 300 timeout 300

Content of the file saved this way is shown below.

R1#more disk1:fox.txt
*time* Aug 24 2015 02:07 AM
*version* 4
!IP address     Type  Hardware address   Lease expiration       VRF
192.168.1.3     id    0063.6973.636f.2d63.6130.322e.3165.3663.2e30.3030.382d.4769.302f.30  Aug 25 2015 02:03 AM

!IP address      Type     Hardware address  Interface-name

!IP address     Interface-name  Lease expiration      Server IP address  Hardware address  Vrf
*end*

One more interesting option about which we cannot help but mention here is DHCP lease query message that allows requesting from DHCP server information about leased IP addresses. DHCP lease query message can be used by the devices performing, for example, functions of DHCP relays in the case of losing the own database of active bindings because of the emergency reboot or for other reasons. This information can be used by the network equipment, for example, for the defense from IP spoofing attacks or in case when it’s necessary to perform client authentication based on his/her MAC address by SSG service. Detailed exploration of DHCP lease query message is far out of scope of this article. More detailed information about this message can be found in RFC4388 and RFC6148.

Additional options: import of parameters

Sometimes it’s necessary to provide DHCP clients with parameters that were received dynamically. Let’s review the schema below.

Router R3 is provider equipment that performs functions of DHCP server for connected clients. Router R2 is client equipment that is simultaneously DHCP client in the provider network and DHCP server in the own network to which PC1 host is connected. R3 provides addresses from 192.168.1.0/24 network, R2 provides addresses from 192.168.0.0/24 network. The task is in sending particular parameters, for example, address of DNS server, from router R3 to PC1 host. As addresses of DNS servers are sending dynamically, one cannot add them to the configuration beforehand. Instead of this, one should use import all option in the settings of DHCP pool. In the listing below there is a partial configuration of router R3. As we can see, R3 provides its clients with the address of DNS server.

ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool test
 network 192.168.1.0 255.255.255.0
 dns-server 8.8.8.8
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0

The partial configuration of router R2 is shown below.

ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool test2
 import all
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
interface FastEthernet1/0
 ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
 ip address dhcp

As we can see, router R2 doesn’t contain information about DNS server, but PC1 host receives the corresponding setting.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.12/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 71323, 86400/43200/75600
MAC         : 00:50:79:66:68:00

Here we’d like to pay readers’ attention to one rather obvious thing – the order of actions. To import parameters successfully, it’s needed that corresponding DHCP pool was fully configured to the moment of receiving IP parameters from the provider’s equipment.

Additional options: VRF support

In modern enterprise networks administrators more often come to using VRF. Service of DHCP server in Cisco equipment is VRF-aware. Let’s review the situation when clients from a particular VRF or global clients (not belonging to any VRF) connect to the router. It’s worth noting that VRF has local importance, so neighboring devices don’t know if any VRFs are configured on the router.

So, in our example, router R1 has two interfaces: FE 1/0 (belongs to VRF a) and FE 1/1 (belongs to the global routing table). Connection of the clients is performed the way as shown above. In our example we will use overlapping addresses of the networks, for example, 192.168.0.0/24. Assign address 192.168.0.1/24 to both interfaces of the router. Exclude from the pool addresses from the first to ten inclusive. To check functionality of the schema we create two DHCP pools a bit differ from each other. Clients connecting to the global pool will receive address of the default gateway and address of DNS server 8.8.8.8. Clients connecting to the interface belonging to vrf a, will not receive address of the default gateway, and the address of their DNS server will be 8.8.4.4. The listing below contains main configuration parameters for router R1.

vrf definition a
 rd 1:1
address-family ipv4
 exit-address-family
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp excluded-address vrf a 192.168.0.1 192.168.0.10
ip dhcp pool global
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
ip dhcp pool vrfa
 vrf a
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.4.4
interface FastEthernet1/0
 vrf forwarding a
 ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
 ip address 192.168.0.1 255.255.255.0

One can view the statistics of using pools with the help of sho ip dhcp pool command showing also information about a pool belonging to a particular VRF.

R1#sho ip dhcp pool
Pool global :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.12         192.168.0.1      - 192.168.0.254     1
Pool vrfa :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 VRF name                       : a
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.12         192.168.0.1      - 192.168.0.254     1

The command sho ip dhcp binding also displays information to which VRF the client received IP address belongs.

R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.11        0100.5079.6668.01       Jan 09 2016 12:30 AM    Automatic
Bindings from VRF pool a:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.11        0100.5079.6668.00       Jan 09 2016 12:30 AM    Automatic

In conclusion, it’s worth noting that support of VRF and MPLS VPN is provided also for devices performing functions of DHCP relay. The readers who are interested in it can study the following commands on their own.

ip helper-address vrf
ip dhcp relay information option vpn
ip dhcp relay information option vpn-id

That’s where we complete this chapter and go to the review of connection between DHCP and routing processes.

DHCP and routing

In this part we decided to raise questions about interaction between DHCP and processes of building a routing table. We decided to begin with the dynamic routing protocols (IGP).

Suppose, we faced with the problem in its general way: it's required to set EIGRP neighboring with devices connected to the interface Gi0/0 of router R2, which IP address is configured dynamically and the range of addresses is not known.

In this case in the configuration of EIGRP routing process one should perform three commands: disable EIGRP on all interfaces (passive-interface default), enable routing for all networks (network 0.0.0.0), and enable support of Gi0/0 interface in EIGRP (no passive-interface GigabitEthernet0/0). Configuration of router R1 is typical, so we don't provide it here. Main configuration commands entered on router R2 are shown below.

interface GigabitEthernet0/0
 ip address dhcp
!
router eigrp 1
 network 0.0.0.0
 passive-interface default
 no passive-interface GigabitEthernet0/0

After this EIGRP neighboring with router R1 is performed successfully.

R2# sho ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(1)
 Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/0                    1        0/0       0/0          24       0/0           64           0
R2#sho ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
 (sec)         (ms)       Cnt Num
0   192.168.0.1             Gi0/0                    13 00:05:10   24   144  0  3

Configuration of RIP protocol is the same and is displayed below.

router rip
 version 2
 passive-interface default
 no passive-interface GigabitEthernet0/0
 network 0.0.0.0
 no auto-summary

Dynamic routing protocol OSPF can be configured the same way as EIGRP and RIP.

router ospf 1
passive-interface default
 no passive-interface GigabitEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0

However, from the example of OSPF protocol configuration shown above, an obvious restriction occurs: if there are two or more interfaces which address is assigned dynamically, all these interfaces should belong to the same area. Fortunately for OSFP there is an interface command which allows enabling this protocol on a particular interface without specifying IP address, but with specifying area number. The example of such configuration is displayed below, all available interfaces are added to area 1, but Gi0/0 belongs to the backbone area.

interface GigabitEthernet0/0
 ip address dhcp
 ip ospf 1 area 0
!
router ospf 1
 router-id 2.2.2.2
 network 0.0.0.0 255.255.255.255 area 1

Dynamic routing protocol OSPF allows finding out which interfaces and why participate in routing and also to which areas they belong. For displaying the specified information command sho ip proto is purposed, the example of its work is displayed below.

R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Router ID 2.2.2.2
 It is an area border and autonomous system boundary router
 Redistributing External Routes from,
 connected, includes subnets in redistribution
 Number of areas in this router is 2. 2 normal 0 stub 0 nssa
 Maximum path: 4
 Routing for Networks:
 0.0.0.0 255.255.255.255 area 1
 Routing on Interfaces Configured Explicitly (Area 0):
 GigabitEthernet0/0
 Routing Information Sources:
 Gateway         Distance      Last Update
 1.1.1.1              110      00:00:05
 Distance: (default is 110)

One more local dynamic routing protocol popular in the networks of large service providers is ISIS. And though ISIS is rare in corporate networks, we decided to mention it, because configuration of IGP for working with DHCP is rather simple and similar to OSPF one. ISIS doesn't support network command for specifying interfaces on which this protocol works. Instead of this, only the interface command should be used. The example of ISIS settings is shown below.

interface GigabitEthernet0/0
 ip address dhcp
 ip router isis
!
router isis
 net 49.0001.0000.0000.0002.00

Also we decided to provide our readers with the output of several diagnostic commands.

R2#sho isis neighbors
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R1             L1   Gi0/0       192.168.0.1     UP    29       R2.01            
R1             L2   Gi0/0       192.168.0.1     UP    23       R2.01            
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
i L2     1.1.1.1 [115/10] via 192.168.0.1, 00:07:05, GigabitEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback0
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.2/32 is directly connected, GigabitEthernet0/0
R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "isis"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Redistributing: connected, isis
 Address Summarization:
 None
 Maximum path: 4
 Routing for Networks:
 GigabitEthernet0/0
 Routing Information Sources:
 Gateway         Distance      Last Update
 192.168.0.1          115      00:06:56
 Distance: (default is 115)

Let’s consider that we dealt with the dynamic routing but the questions about static routing are not less interesting.

Firstly, it may be needed to provide the client via DHCP with not only the default route but other static routes. The default route (option #3) can be provided with the help of default-router command in configuration mode of DHCP pool. Static routes are provided with the help of option #33, requested by the client. We built a small schema to illustrate working of these options.

Routers R1 and R2 have static configuration of the interfaces. To Gi0/0 interfaces 192.168.0.1/24 and 192.168.0.2/24 addresses are assigned. Also on these routers loopback 0 interfaces with addresses 1.1.1.1/32 and 2.2.2.2/32 are configured. Router R3 receives IP parameters dynamically with the help of interface command ip addr dhcp. DHCP settings on router R1 are displayed below. With the help of option 33 static routes are provided.

ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.8.8
 default-router 192.168.0.1
 option 33 ip 2.2.2.2 192.168.0.2

Naturally, we cannot help but make sure that router R3 has successfully received all necessary parameters.

R3#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.101   YES DHCP   up                    up  
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.0.1
 2.0.0.0/32 is subnetted, 1 subnets
S        2.2.2.2 [254/0] via 192.168.0.2
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.101/32 is directly connected, GigabitEthernet0/0
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms

The whole traffic exchange we saved in dump foxnetwork_8.pcapng.

Using of option #33 is rather simple: however, it's impossible to send route with the mask different from /32 with the help of this option. One can perform sending of the route with any mask to DHCP client placed on Cisco router using option #121, but, to be honest, the rule of its configuring is a bit more difficult. All numbers are written in hexadecimal. The first octet contains the length of the mask. After it significant octets meaning addresses of the destination network followed, after them the address of the next router is specified. If it’s needed to send several routes simultaneously, all of them are written one after another without spaces. Let's review all said above on the example. Suppose, we use the previous network schema and want to send the following routes: 1.1.1.1/32 via 192.168.0.1 and 2.2.20/23 via 192.168.0.2. The first route contains four significant octets of the network, the second - three. So the records of the specified routes in hexadecimal are as follows: 2001010101C0A80001 and 17020202C0A80002, where 20 and 17 – length of the masks in hexadecimal, 01010101 and 020202 – hexadecimal record of significant octets of the network address, and C0A80001 and C0A80002 – routers’ addresses. The example of the updated configuration of DHCP pool of router R1 is shown below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.8.8
 option 121 hex 2001.0101.01c0.a800.0117.0202.02c0.a800.02

However, the specified commands are not enough. By default, DHCP client based on Cisco IOS doesn't request option #121 from the server. One can make the client request this option with the help of interface command ip dhcp client request classless-static-route performed on the client. Make sure of the functioning of the specified configuration.

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int gi0/0
R3(config-if)# ip dhcp client request classless-static-route
R3(config-if)#ip add dhcp
R3(config-if)#^Z
R3#
*Aug 16 04:23:03.179: %SYS-5-CONFIG_I: Configured from console by console
*Aug 16 04:23:04.467: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.106, mask 255.255.255.0, hostname R3
R3#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.106   YES DHCP   up                    up  
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [254/0] via 192.168.0.1
 2.0.0.0/23 is subnetted, 1 subnets
S        2.2.2.0 [254/0] via 192.168.0.2
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.106/32 is directly connected, GigabitEthernet0/0
R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/20 ms
R3#

Capture of the process of traffic exchange between three routers is provided in the file foxnetwork_9.pcapng.

Sending of static routes to DHCP clients based on other operating systems can be performed with the help of other options, but in any case, any option is just a hex-string, so DHCP server based on Cisco routers can be configured for transmitting of the routing information to the clients based on other operating systems as well.

Also it's worth noting that routes received via DHCP can be transmitted to any dynamic routing protocol with the help of redistribute static command (or redistribute static subnets in case of using OSPF).

By default, DHCP client based on Cisco IOS requests the whole set of options among which is default route (option #3). To restrict the router requesting for some options one can using corresponding interface commands.

R3(config-if)#no ip dhcp client request ?
 classless-static-route       Classless static route (121)
 dns-nameserver               DNS nameserver (6)
 domain-name                  Domain name (15)
 netbios-nameserver           NETBIOS nameserver (44)
 router                       Default router option (3)
 sip-server-address           SIP server address (120)
 static-route                 Static route option (33)
 tftp-server-address          TFTP server address (150)
 vendor-identifying-specific  Vendor identifying specific info (125)
 vendor-specific              Vendor specific option (43)
 <cr>

In the pictures below DHCP discover and DHCP offer messages from routers R3 and R1 are displayed, on router R1 in the mode of DHCP pool configuration default-router command was entered. On Gi0/0 interface of router R3 we preliminary issued no ip dhcp client request router command.

As one can see from DHCP messages shown above, router R3 doesn't request option #3, and R1 doesn't send it to the client. DHCP messages of which routers R1 and R3 exchanged are shown in the file foxnetwork_10.pcapng.

Our attentive reader, probably, has paid attention to the value of administrative distance in the routing table with which default router was appeared, receiving via DHCP – 254. Such AD value tells that almost any statically configured route or route received with the help of any IGP or even BGP seems to have more priority than one received using DHCP. One can change the distance of the default route received via DHCP using ip dhcp-client default-router distance command in global configuration mode. The command in question influences only newly received route and makes unchangeable one which was already included to the routing table. In case the router dynamically receives default route via two or more interfaces, one can change preferences with the help of interface command ip dhcp client default-router distance which influences only the default route received via a particular interface. Illustrate all said above on the example of a small network. Routers R1 and R3 are configured as DHCP servers, and R2 performs functions of DHCP client.

On router R1 the following configuration is set.

interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
ip dhcp pool test
 network 192.168.12.0 255.255.255.0
 default-router 192.168.12.1

Configuration of R3 is almost identical.

interface GigabitEthernet0/0
 ip address 192.168.23.3 255.255.255.0
ip dhcp pool test
 network 192.168.23.0 255.255.255.0
 default-router 192.168.23.3

Review the process of receiving IP parameters by router R2 during which we at first receive IP address from router R1, after which change administrative distance globally, repeat request for IP parameters, change administrative distance for Gi1/0 interface and request IP address and default route from router R3.

R2#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         unassigned      YES unset  up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#ip add dh
*Aug 16 08:05:21.255: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.6, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.6    YES DHCP   up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config-if)#exi
R2(config)#ip dhcp-client default-router distance 10
R2(config)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config)#int gi0/0
R2(config-if)#no ip add dh
R2(config-if)#ip add dh
*Aug 16 08:06:23.807: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.7, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.7    YES DHCP   up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [10/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.7/32 is directly connected, GigabitEthernet0/0
R2(config-if)#int gi1/0
R2(config-if)#ip dhcp client default-router distance 5
R2(config-if)#ip add dh
*Aug 16 08:07:00.471: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet1/0 assigned DHCP address 192.168.23.1, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.7    YES DHCP   up                    up  
GigabitEthernet1/0         192.168.23.1    YES DHCP   up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.23.3 to network 0.0.0.0
S*    0.0.0.0/0 [5/0] via 192.168.23.3
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.7/32 is directly connected, GigabitEthernet0/0
 192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.23.0/24 is directly connected, GigabitEthernet1/0
L        192.168.23.1/32 is directly connected, GigabitEthernet1/0

Also, probably, it's worth noting that administrator can manually remove or restore these or that routes received with the help of DHCP, from the routing table. Naturally, one can restore only the routes which were announced by DHCP server in DHCP offer message. To be honest, storing is performed with the administrative distance of an ordinary static route in case of not specifying AD value additionally. Also entered command ip route includes to running and/or startup router configuration.

Connecting to the provider with the use of dynamically configured IP address helps provide hosts placed in the user network with access to the global network with the help of NAT/PAT. Review the network displayed on the schema below.

Router R1 belongs to the provider and performs functions of DHCP server for the network 192.168.0.0/24. User router R2 is connected to the provider via its Gi0/0 interface, and to the user local network 192.168.1.0/24 via Gi1/0 interface. Naturally, router R1 doesn't have routes to internal client network. Settings of router R1 are rather simple and displayed below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
interface GigabitEthernet0/0
 ip address 192.168.0.1 255.255.255.0

Configuration of PC1 host is also rather simple.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.1.2/24
GATEWAY     : 192.168.1.1
DNS         :
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10002
MTU:        : 1500

The only thing left is to configure router R2. The first from which we start is creating the access list selecting IP addresses for which translation would be performed. Then it's needed to assign IP addresses to interfaces Gi0/0 and Gi1/0, specify internal and external interfaces for NAT and to create the translation itself. On translation creation, it's required to specify key word overload which makes router perform PAT. The example of R2 configuration is displayed below.

interface GigabitEthernet0/0
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
interface GigabitEthernet1/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
ip nat inside source list PAT interface GigabitEthernet0/0 overload
ip access-list extended PAT
 permit ip 192.168.1.0 0.0.0.255 any

Make sure of the correct configuration with the help of PC1 host.

PC1> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=254 time=29.002 ms

Check the same after enabling of displaying debug information on router R1. Naturally, we don't recommend enabling of debug in high load networks.

R1#deb ip icmp
ICMP packet debugging is on
R1#
*Aug 16 19:58:21.931: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:22.959: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:23.975: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:25.003: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:26.035: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0

During checking the following translations are created on router R2.

R2#sho ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.0.2:16835 192.168.1.2:16835  1.1.1.1:16835      1.1.1.1:16835
icmp 192.168.0.2:17091 192.168.1.2:17091  1.1.1.1:17091      1.1.1.1:17091
icmp 192.168.0.2:17347 192.168.1.2:17347  1.1.1.1:17347      1.1.1.1:17347
icmp 192.168.0.2:17859 192.168.1.2:17859  1.1.1.1:17859      1.1.1.1:17859
icmp 192.168.0.2:18115 192.168.1.2:18115  1.1.1.1:18115      1.1.1.1:18115

Certainly, one can make sure of the correctness of the performed settings with the help of network analyzer Wireshark, analyzing passing packets.

That's where we complete the part describing mutual influence of DHCP and routing and go to the conclusion.

Conclusion

In this article we tried to describe opportunities and examples of using DHCP in rather detailed way. We didn't have an aim to review absolutely all options of all realizations and platforms, instead of this, we decided to make our readers acquainted with the most frequently used options and functions. So, for example, we intentionally missed questions about using DHCP on ATM interfaces, because are naive to believe that time of countrywide implementation of ATM is over.
Despite the fact that almost all configurations are provided for the Cisco equipment, we hope that administrators who own the equipment of other vendors will manage to find in this article a lot of interesting things.

Add comment


Security code
Refresh

Comments   

0 #1 DHCP in detaileli_koch 2017-05-11 20:30
Hurrah! At last I got a web site from where I be able to truly obtain useful facts
concerning my study and knowledge.
Quote | Report to administrator
Found a typo? Please select it and press Ctrl + Enter.