Posts Tagged ‘dhcp’
The DHCP Information option (Option 82) is commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.
A question on GroupStudy gave me an idea for the short post dedicated to explaining the use of DHCP “import all” command. The command first appeared in IOS 12.2T. It allows importing certain DHCP information learned from some external source, such as another DHCP server. This is helpful in reducing the amount of configuration needed in large hub-and-spoke networks, where spokes use centralized servers (e.g. WINS, DNS, TFTP). Instead of configuring the repetitive settings in every spoke router, you may import them by requesting an IP address for the router via DHCP. More than that, any change in central configuration could be easily imported in the remote routers, using DHCP address refresh. Here is how it works:
1) The router requests an IP address on its WAN interface via DHCP. In addition to the IP/subnet information, the router also learns other DHCP information, such as various DHCP options (DNS, WIN, TFTP IP addresses). This is store with the local DHCP client configuration.
2) The is a local pool configured in the router, with the subnet corresponding to the local Ethernet interface (say office network). This pool is configured with the statement “import all”.
3) By the virtue of “import all” statement and the default “origin dhcp” setting, the local pool imports the information learned by the router’s DHCP client. The imported information does not preempt the local subnet and mask, but instead add missing information.
4) Every time the DHCP lease expires, the router will re-request it, thus re-learning all other information as well.
As an alternative to using the DHCP it is possible to use IPCP for information import, if the WAN link uses PPP protocol (e.g. PPPoE). You simply need the statement “ip address negotiated” on the PPP link plus configured “origin ipcp” under the DHCP pool. Notice that the amount of IPCP options is much smaller than that of DHCP. However, you may still send WINS and DNS servers IP addresses, and even the netmask, using the command “ppp ipcp mask”. See the post The myster of “PPP IPCP mask request command” for more information on this command.
Here is a sample configuration.
If you ever used IPCP for address allocation with PPP (“ip address negotiated” on client side and “peer default ip address” on server side) you may have noticed that the mask assigned to a client is always /32. It does not matter what mask a server uses on it’s side of the connection, just PPP is designed to operate this way.
However, many have noticed two strange commands “ppp ipcp mask request” and “ppp ipcp mask X.X.X.X” under PPP interface configuration mode. If IPCP assigned address never uses a custom mask, what would the purpose of those commands be? The answer is simple – to configure on-demand address pools in a client. That is, a client may request a DHCP pool parameters from server using IPCP – for example request a subnet and a mask. The client may then further use this information and allocate IP addresses to it’s subordinates. Here is a configuration to verify this feature. Consider that R1 connects to R3 over a point-to-point link:
R1: ip dhcp pool LOCAL import all origin ipcp ! ! Link to R3 ! interface Serial0/1 ip address pool LOCAL encapsulation ppp ppp ipcp mask request R3: ! ! Link to R1 ! interface Serial1/2 ip address 172.16.13.3 255.255.255.0 encapsulation ppp peer default ip address pool POOL clock rate 128000 ppp ipcp mask 255.255.255.0 ! ip local pool POOL 172.16.100.1 172.16.100.254
Using the “debug ppp negotiation” command on R1 (the client) and R3 (the server) you may see the mask being requested and passed down to the client. Debug output from R1:
Se0/1 IPCP: I CONFREQ [REQsent] id 1 len 10 Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se0/1 IPCP: O CONFACK [REQsent] id 1 len 10 Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se0/1 CDPCP: Redirect packet to Se0/1 Se0/1 CDPCP: I CONFREQ [REQsent] id 1 len 4 Se0/1 CDPCP: O CONFACK [REQsent] id 1 len 4 Se0/1 IPCP: I CONFNAK [ACKsent] id 1 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 IPCP: O CONFREQ [ACKsent] id 2 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 CDPCP: I CONFACK [ACKsent] id 1 len 4 Se0/1 CDPCP: State is Open Se0/1 IPCP: I CONFACK [ACKsent] id 2 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 IPCP: State is Open Se0/1 IPCP: Subnet: address 172.16.100.3 mask 255.255.255.0
Debug output from R3:
Se1/2 IPCP: O CONFREQ [Closed] id 1 len 10 Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se1/2 CDPCP: O CONFREQ [Closed] id 1 len 4 Se1/2 PPP: Process pending ncp packets Se1/2 IPCP: I CONFREQ [REQsent] id 1 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C0100000000) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403) Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0 Se1/2 IPCP: O CONFNAK [REQsent] id 1 len 14 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 CDPCP: I CONFREQ [REQsent] id 1 len 4 Se1/2 CDPCP: O CONFACK [REQsent] id 1 len 4 Se1/2 CDPCP: I CONFACK [ACKsent] id 1 len 4 Se1/2 CDPCP: State is Open Se1/2 IPCP: I CONFACK [REQsent] id 1 len 10 Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se1/2 IPCP: I CONFREQ [ACKrcvd] id 2 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403) Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0 Se1/2 IPCP: O CONFACK [ACKrcvd] id 2 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403)
Now this is what you get when you configure “ip address negotiated” on R1:
R1#sh ip interface serial 0/1 Serial0/1 is up, line protocol is up Internet address is 172.16.100.5/32 Broadcast address is 255.255.255.255 Address determined by IPCP Peer address is 172.16.13.3
And this is what shows up when you use local DHCP address pool for autoconfiguration (note the subnet mask):
R1#sh ip interface serial 0/1 Serial0/1 is up, line protocol is up Internet address is 172.16.100.4/24 Broadcast address is 255.255.255.255 Address determined by setup command Peer address is 172.16.13.3
However, the funniest part is that R1 serial interface IP address is actually not allocated from the local (on-demand) DHCP pool! Observing the debug output you can see that R1 uses the IP address sent from R3, not allocated from the local DHCP pool. Then again, the local pool DHCP still has the requested subnet:
R1#sh ip dhcp pool Pool LOCAL : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 0 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 172.16.100.1 172.16.100.1 - 172.16.100.254 0 R1#sh ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name R1#
You can see the following on R3:
R3#sh ip local pool POOL Pool Begin End Free In use POOL 172.16.100.1 172.16.100.254 253 1 ... 172.16.100.1 Se1/2 172.16.100.2 Se1/2 172.16.100.3 Se1/2 172.16.100.4 Se1/2 Inuse addresses: 172.16.100.4 Se1/2
This is what so funny about Cisco IOS – you can never be sure the feature works in a most logical way you may suppose it to work. You can play with this example further, for example changing IP address allocation on R3 to local DHCP Pools or a static IP – there is always something you can experiment with!