Cisco CNS Network Registrar User's Guide, 5.5
Configuring the DHCP Server for Virtual Private Networks and Subnet Allocation
Downloads: This chapterpdf (PDF - 194.0 KB) The complete bookPDF (PDF - 5.45 MB) | Feedback

Configuring the DHCP Server for Virtual Private Networks and Subnet Allocation

Table Of Contents

Configuring the DHCP Server for Virtual Private Networks and Subnet Allocation

Configuring a Virtual Private Network Through DHCP

Typical Virtual Private Network

Setting the Virtual Private Network Namespace

Namespace Usage With Other Objects or Processes

Configuring DHCP Subnet Allocation

Tuning Parameters

Configuring the DHCP Server for Virtual Private Networks and Subnet Allocation

This chapter describes how to configure the Network Registrar DHCP server to support virtual private networks (VPNs) and subnet allocation for on-demand address pools. For an introduction to these features, see the "Virtual Private Networks and Namespaces" section, and the "Subnet Allocation and Address Blocks" section.

Configuring VPNs involves an adjustment to the usual DHCP host IP address designation. VPNs use private address spaces that are not unique across the Internet. Because of this, Network Registrar supports IP addresses that are distinguished by a VPN identifier. Relay agents on routers must support this capability as well. This VPN identifier selects the namespace in which the client belongs. VPN support for DHCP is currently only supported by the Cisco Internet Operating System (IOS), the newest versions of which incorporate VPN IDs in the relay agent code.

Subnet allocation is a way of offering subnets (ranges of addresses) wholesale to relay agents so that remote access devices can provision IP addresses to DHCP client hosts. This can occur along with or instead of managing individual client addresses. Subnet allocation can vastly improve IP address provisioning, aggregation, characterization, and distribution by relying on the DHCP infrastructure to dynamically manage subnets. These subnets or ranges of addresses are called address blocks. Subnet allocation through DHCP is currently only supported by Cisco IOS, the newest versions of which incorporate the on-demand address pools feature in the relay agent.

Table 14-1 describes the topics of this chapter.

Table 14-1 LDAP Configuration Topics

If you want to...
Go to...

Configure a VPN

"Configuring a Virtual Private Network Through DHCP" section

Configure an on-demand address pool

"Configuring DHCP Subnet Allocation" section

Fine-tune namespace and address block characteristics

"Tuning Parameters" section

Configuring a Virtual Private Network Through DHCP

To configure a VPN whereby a client can request IP addresses from a DHCP server using a relay agent, you must define a namespace for the VPN and associate a scope with that namespace. Specifically:

1. Ensure that the relay agents that handle DHCP VPN traffic are configured with a version of Cisco IOS that supports the vpn-id suboption of the relay-agent-info option (82) in DHCP.

2. Coordinate with the IOS relay agent administrator whether the VPN is identified by a VPN ID or a VPN Routing and Forwarding instance (VRF) name. It is rarely both.

3. Configure a namespace in Network Registrar to correspond to the VPN. Associate this namespace with the VPN ID or VRF name.

4. Create a scope for the namespace.

Typical Virtual Private Network

Figure 14-1 shows a VPN scenario with DHCP Client1 as part of VPN "blue" and DHCP Client2 in VPN "red." Both have the same private network addresses The DHCP relay agent has gateway addresses inside the two VPNs as well as outside of them. There are two failover DHCP servers, both of which know the relay agent through its external gateway address.

Figure 14-1 Virtual Private Network DHCP Configuration

Here is the processing that takes place for the server to issue a VPN-supported address to a client:

1. DHCP client1 broadcasts a DHCPDISCOVER packet, including its MAC address, host name, and any requested DHCP options.

2. DHCP relay agent at address picks up the broadcast packet. It adds a relay-agent-info option (82) to the packet and includes the subnet-selection suboption. This identifies as the subnet. The packet also includes the vpn-id suboption that identifies the VPN as "blue." Because the DHCP server cannot communicate directly with the requesting client, the server-id-override suboption contains the address of the relay agent as known by the client ( The relay agent also includes in the packet its external gateway address (giaddr),

3. The relay agent unicasts the DHCPDISCOVER packet to the configured DHCP server on its subnet.

4. DHCP server1 receives the packet and uses the vpn-id and subnet-selection suboptions to allocate an IP address from the proper VPN address space. It finds the available address in the subnet and VPN, and places it in the yiaddr field of the packet (the address offered to the client).

5. The server unicasts a DHCPOFFER packet to the relay agent that is identified by the giaddr value.

6. The relay agent removes the relay-agent-info option and sends the packet to DHCP Client 1.

7. DHCP client1 broadcasts a DHCPREQUEST message requesting the same IP address that it was offered. The relay agent receives this broadcast message.

8. The relay agent forwards the DHCPREQUEST packet to DHCP Server1, which replies with a unicast DHCPACK packet to the client.

9. For a lease renewal, the client unicasts a DHCPRENEW packet to the IP address found in the dhcp-server-identifier option of the DHCPACK message. This is, the address of the relay agent. The relay agent unicasts the packet to the DHCP server. The server does its normal renewal processing, without necessarily knowing whether it was the server that gave out the original address in the first place. The server replies in a unicast DHCPACK packet. The relay agent then forwards the DHCPACK packet to the client's IP address identified by the ciaddr field value.

If the server-id-override suboption of the relay-agent-info option (82) exists, the DHCP server uses its value to compare to that of the dhcp-server-identifier option in the reply packet. Any packet that the DHCP client unicasts then goes directly to the relay agent and not to the server (which may, in fact, be inaccessible from the client). Both partners in a failover environment can renew a lease if the packet includes the server-id-override suboption.

Setting the Virtual Private Network Namespace

Using the CLI

Here is what you can do as the administrator to set up the VPN and its namespace:

Step 1 Coordinate with the IOS relay agent administrator whether VPNs are configured by VPN ID or VRF name on the relay agent. This will determine how to identify the VPN in Network Registrar.

Step 2 Create a namespace to include the DHCP client, with an ID number. A namespace name can be any unique text string except the reserved words all or global, and its associated ID must be unique.

nrcmd> namespace blue create 99 

Step 3 Supply the appropriate VPN identifier, either by VPN ID or VRF name. It is rarely both.

If you use a VPN ID, set the vpn-id attribute value for the namespace. The value is usually in hexadecimal, in the form oui:index, per RFC 2685. It consists of a three-octet VPN Organizationally Unique Identifier (OUI) that corresponds to the VPN owner or ISP, followed by a colon. It is then followed by a four-octet index number of the VPN itself.

nrcmd> namespace blue set vpn-id=a1:3f6c 

If you use a VPN Routing and Forwarding instance (VRF) name, set the vrf-name attribute value for the namespace. Cisco routers frequently use VRF names.

nrcmd> namespace blue set vrf-name=framus 

If you need to unset a namespace attribute other than its ID (which you cannot unset), use the namespace name unset attribute command.

Step 4 Show or list the namespace you created using the namespace name show command. To list multiple namespaces, use the namespace list command. If you need to delete the namespace and start over again, use the namespace name delete command.

Step 5 Create a scope for the namespace, keeping the two names as similar as possible for identification purposes. You can identify to which namespace the scope belongs in one of three ways:

Its namespace name, through the namespace attribute (which applies the namespace ID to the scope).

The namespace ID itself, through the namespace-id attribute.

The current session namespace name, by omitting the namespace or its ID on the command line.

You set the current namespace using the session set current-namespace command. You can then set the usual address range and necessary option properties for the scope.

nrcmd> scope blue-1921681 create namespace=blue 
nrcmd> scope blue-1921681 create namespace-id=99 
nrcmd> session set current-namespace=blue 
nrcmd> scope blue-1921681 create 

nrcmd> scope blue-1921681 addRange 
nrcmd> scope-policy blue-1921681 addOption routers 

Step 6 Create a non-VPN scope for non-VPN clients. Note that if the session's current namespace is set, unset it (using the session unset current-namespace command) to use the global namespace.

nrcmd> session unset current-namespace 
nrcmd> scope 1921682 create 
nrcmd> scope 1921682 addRange 
nrcmd> scope-policy 1921682 addOption routers 

Step 7 Reload the server.

nrcmd> dhcp reload 

Namespace Usage With Other Objects or Processes

When you create a namespace, you must give it a name and a numerical ID, either a VPN ID or VRF name. Network Registrar stores the namespace internally by its ID. Once you set the ID, you cannot unset it, although you can change the namespace name associated with it.

In both the CLI and GUI, you can include the namespace in many IP address specifications, as the namespace name prefix followed by a slash and the IP address. For example, lease names can have the following syntax:


For example: red/

A namespace can be any unique text string except the reserved words global and all. You can use global and all when you export address or lease data.

You can define or request the namespace or its ID for a few Network Registrar objects. If you omit the namespace or its ID in defining an object, the namespace defaults to the value set by the session set current-namespace command. If the current namespace is not defined, it defaults to the global namespace, which includes all addresses outside of any defined namespaces and especially VPNs.

The objects that have associated namespace properties are the following:

Address blocks—Define the namespace for an address block.

nrcmd> address-block red set namespace=blue 
nrcmd> address-block red set namespace-id=99 

Leases—Listing leases, showing a lease, or getting the namespace-id attribute for a lease shows the namespace. However, you cannot list leases in a particular namespace only.

To import leases, use the import leases filename command. Each lease entry in the file can include the namespace at the end of the line. If it is missing, Network Registrar assigns the global namespace. See the "Importing and Exporting Lease Data" section.

nrcmd> import leases leaseimport.txt 

To export the address or lease data to include the namespace, use the export addresses command with the namespace attribute, or the export leases command with the -namespace option. The namespace value can be the reserved word global or all.

Global—Any addresses outside the defined namespaces

All—All namespaces, including the global one

If you omit the namespace, the export uses the current one as set by the session set current-namespace command. If the current namespace is not set, the server uses the global one.

nrcmd> export addresses file=addrexport.txt namespace=red 
nrcmd> export leases -server -namespace red leaseexport.txt 

Scopes—Scopes can include the namespace name or its ID, as described in the "Setting the Virtual Private Network Namespace" section.

nrcmd> scope testScope set namespace=blue 
nrcmd> scope testScope set namespace-id=99 

Subnets—Listing subnets, showing a subnet, or getting the namespace-id attribute for a subnet shows the namespace. See the "Configuring DHCP Subnet Allocation" section.

Configuring DHCP Subnet Allocation

For an introduction to using on-demand address pools for provisioning in Network Registrar, see the "Subnet Allocation and Address Blocks" section. The following section provides an example of setting up subnet allocation using the DHCP server.

Figure 14-2 shows a sample subnet allocation configuration with subnets assigned to provisioning devices, along with the conventional DHCP client/server configuration.

Figure 14-2 Subnet Allocation Using DHCP

Using the CLI

Step 1 Create an address block for a subnet, set the initial subnet mask and its increment, and set other subnet allocation request attributes. Also, associate a policy or define an embedded policy.

If you use VPNs, you can specify a namespace-id attribute (see the "Configuring a Virtual Private Network Through DHCP" section). Note that unsetting the namespace ID reverts the value to the current session namespace.

nrcmd> address-block red create address= namespace=vpn-red 
       initial-subnet=24 subnet-increment=24 policy=Policy1 

If you do not use VPNs, you can specify a selection-tags attribute identifying one or more subnets from which to allocate the addresses. If the relay agent sends this string, which it associates with a subnet, any address block with that string as one of it selection-tags attribute values uses that subnet.

nrcmd> address-block red create address= selection-tags=subRed,subGreen 

For incoming subnet allocation requests that do not have a selection tag, you can set the default selection tag value or values on the server or namespace level.

nrcmd> dhcp set addr-blocks-default-selection-tags=subRed,subGreen 
nrcmd> namespace blue set addr-blocks-default-selection-tags=subBlue 

The selection tags capability is enabled by default for the server and namespaces, but you can disable it for each one. Note also that the default behavior on the server and for namespaces is that the DHCP server tries to allocate subnets to clients using address blocks that the clients already used. Disabling the blocks-use-client-affinity attribute causes the server to supply subnets from any suitable address block, based on other selection data in the clients' messages.

nrcmd> dhcp disable addr-blocks-use-selection-tags 
nrcmd> namespace blue disable addr-blocks-use-selection-tags 
nrcmd> dhcp disable addr-blocks-use-client-affinity 
nrcmd> namespace blue disable addr-blocks-use-client-affinity 

If you want to support configurations of multiple address blocks on a single LAN segment (analogous to using primary and secondary scopes), add a segment-name attribute string value to the address block. When the relay agent sends a single subnet selection address, it selects address blocks tagged with that segment-name string value. However, you must also explicitly enable the LAN segment capability on the server or namespace level; this is disabled by default.

nrcmd> address-block red create address= segment-name=lan192168 
nrcmd> dhcp enable addr-blocks-use-lan-segments 
nrcmd> namespace blue enable addr-blocks-use-lan-segments 

Instead of associating a policy, you can set properties for the address block's embedded policy. As in embedded policies for clients, client-classes, and scopes, you can enable, disable, set, unset, get, and show attributes for an address block policy. You can also set, unset, get, and list any DHCP options for it, as well as set, unset, and list vendor options. Note that deleting an address block embedded policy unsets all the embedded policy properties.

nrcmd> address-block-policy red enable allow-lease-time-override 
nrcmd> address-block-policy red set server-lease-time=3600 
nrcmd> address-block-policy red setOption dhcp-lease-time 3600 

Step 2 Show the results using the address-block name [show] (or list) command. You can also get any attributes and delete the address block entirely, if need be.

nrcmd> address-block red show 
100 Ok
    address =
    default-subnet-size =
    embedded-policy =
    name = red
    namespace-id =
    policy = default
    segment-name = lan192168
    selection-tags = subRed

Note that the server allocates subnets based on the relay agent request. If not requested, the default subnet size is a 28-bit address mask. You can change this default if necessary.

nrcmd> address-block red set default-subnet-size=25 

Step 3 Reload the DHCP server.

nrcmd> dhcp reload 

Step 4 You can control any of the subnets the DHCP server creates from the address blocks. Identify the subnet in the form vpn-name/netipaddress/mask, with the vpn-name optional. Subnet control includes activating and de-activating the subnet as you would a lease. Likewise, you can force a subnet to be available, with the condition that before you do so, check that the clients assigned the subnet are no longer using it. First, show or list any subnets created.

nrcmd> subnet list 
nrcmd> subnet vpn-red/ show 
nrcmd> subnet vpn-red/ activate 
nrcmd> subnet vpn-red/ force-available 

Step 5 You can list the subnets that Network Registrar created for an address block.

nrcmd> address-block red listsubnets 

Tuning Parameters

Consider the following tuning parameters for VPNs and on-demand address pools.

Keep orphaned leases that have nonexistent namespaces—Network Registrar usually maintains leases that do not have an associated namespace in its state database. You can change this through the dhcp enable delete-orphaned-leases command. Either way you set the attribute, the DHCP server cannot use the orphaned leases. Leaving it disabled at least lets you associate a namespace at some point without losing the lease entries in the lease state database.

Keep orphaned subnets that have nonexistent namespaces or address blocks—This is the default behavior, although you can change it using the dhcp enable delete-orphaned-subnets command. As the DHCP server starts up, it reads its database of subnets and tries to locate the parent namespace and address block of each subnet. With the attribute enabled, if a subnet refers to a namespace that is no longer configured in the server, or if the server cannot locate a parent address block that contains the subnet, the server permanently deletes the subnet from the state database.

Keep the VPN communication open—This is the default behavior, although you can change it using the dhcp disable vpn-communication command. The DHCP server can communicate with clients that reside on a different VPN from that of the server by using an enhanced DHCP relay agent capability. This is signalled by the appearance of vpn-id suboption of the relay-agent-info option (82). Disable the vpn-communication attribute only if you notice a security hole in the network.