Cisco CNS Network Registrar User's Guide, 6.0
Configuring the DHCP Server for Virtual Private Networks and Subnet Allocation
Downloads: This chapterpdf (PDF - 282.0KB) The complete bookPDF (PDF - 7.06MB) | 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 Cisco CNS 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 DHCP Address-Blocks" section.

Configuring VPNs involves an adjustment to the usual DHCP host IP address designation. VPNs use private address spaces that might not be 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 can include VPN IDs in the relayed DHCP messages.

Subnet allocation is a way of offering entire subnets (ranges of addresses) 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. Subnet allocation through DHCP is currently only supported by Cisco IOS, the newest versions of which incorporate the on-demand address pools feature.

Table 14-1 describes the topics of this chapter.

Table 14-1 LDAP Configuration Topics

If you want to...
See...

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 192.168.1.0/24. 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 192.168.1.1 picks up the broadcast packet. It adds a relay-agent-info option (82) to the packet and includes the subnet-selection suboption. This identifies 192.168.1.0 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 (192.168.1.1). The relay agent also includes in the packet its external gateway address (giaddr), 172.27.180.232.

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 192.168.1.37 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 192.168.1.1, 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 
100 Ok
blue:
addr-blocks-default-selection-tags =
addr-blocks-use-client-affinity =
addr-blocks-use-lan-segments =
addr-blocks-use-selection-tags =
description =
id = 99
name = blue
vpn-id =
vrf-name =

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 
100 Ok
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 
100 Ok
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 192.168.1.0 255.255.255.0 namespace=blue 
100 Ok
namespace=blue
blue-1921681:
...
namespace-id = 99  namespace: blue
...

Or:

nrcmd> scope blue-1921681 create 192.168.1.0 255.255.255.0 namespace-id=99 
100 Ok
namespace-id=99
blue-1921681:
...
namespace-id = 99  namespace: blue
...

Or:

nrcmd> session set current-namespace=blue 
100 Ok
current-namespace=blue
nrcmd> scope blue-1921681 create 192.168.1.0 255.255.255.0 
100 Ok
blue-1921681:
...
namespace-id = 99  namespace: blue
...

Then:

nrcmd> scope blue-1921681 addRange 192.168.1.1 192.168.1.100 
100 Ok
192.168.1.1 192.168.1.100
nrcmd> scope-policy blue-1921681 setOption routers 192.168.1.1 
100 Ok
routers=192.168.1.1

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 
100 Ok
current-namespace=global
nrcmd> scope 1921682 create 192.168.2.0 255.255.255.0 
100 Ok
1921682:
addr = 192.168.2.0
bootp = disabled
deactivated =
...
nrcmd> scope 1921682 addRange 192.168.2.1 192.168.2.100 
100 Ok
192.168.2.1 192.168.2.100
nrcmd> scope-policy 1921682 setOption routers 192.168.2.1 
100 Ok
routers=192.168.2.1

Step 7 Reload the server.

nrcmd> dhcp reload 
100 Ok


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 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 this syntax:

namespace/ipaddress

For example, red/192.168.40.0

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:

Address blocks—Define the namespace for an address block.

nrcmd> address-block red create 192.168.50.0/24 
100 Ok
red:
address = 192.168.50.0/24
default-subnet-size = [default=28]
deprecated = [default=false]

nrcmd> address-block red set namespace=blue 
100 Ok
namespace=blue

Or:

nrcmd> address-block red set namespace-id=99 
100 Ok
namespace-id=99

Clients and client-classes—In some cases it is desirable to provision a VPN inside of Network Registrar instead of externally, where it might have to be configured for every Cisco Internet Operating System (IOS) device. To support this capability, you can specify a namespace for a client or client-class. Two attributes are provided:

default-namespace—Namespace that the packet gets if it does not already have a vpn-id or vrf-name value in the incoming packet. You can use the attribute with clients and client-classes.

nrcmd> client 1,6,00:d0:ba:d3:bd:3b set default-namespace=blue 

override-namespace—Namespace the packet gets no matter what is provided for a vpn-id or vrf-name value in the incoming packet. You can use the attribute with clients and client-classes. Note that if you specify an override namespace on the client-class, and a default namespace for the client, the override namespace on the client-class takes precedence over the default namespace on the client.

nrcmd> client-class CableModem set override-namespace=blue 

In a cable modem deployment, for example, you can use the override-namespace attribute to provision the cable modems. The client-class would determine the scope for the cable modem, and the scope would determine the VPN for the uBR. User traffic through the cable modem would then have the vpn-id suboption set and use the specific VPN namespace. The override-namespace value also overrides any default-namespace set for the client.

Leases—List leases, show a lease, or get its attributes. If you had previously specified a namespace for the scope, the output shows leases in that 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 
100 Ok

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 
100 Ok
nrcmd> export leases -server -namespace red leaseexport.txt 
100 Ok

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

nrcmd> scope examplescope1 set namespace=blue 
100 Ok
namespace=blue

Or:

nrcmd> scope examplescope1 set namespace-id=99 
100 Ok
namespace-id=99

Subnets—Listing subnets, showing a subnet, or getting the namespace or 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 DHCP 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 or 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 192.168.0.0/16 namespace=vpn-red policy=Policy1 
100 Ok
namespace=vpn-red
policy=Policy1
red:
...

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 192.168.0.0/16 selection-tags=subRed,subGreen 
100 Ok
selection-tags=subRed,subGreen
red:
...

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> namespace blue create 92 
100 Ok
blue:
addr-blocks-default-selection-tags =
...
nrcmd> dhcp set addr-blocks-default-selection-tags=subRed,subGreen 
100 Ok
addr-blocks-default-selection-tags=subRed,subGreen
nrcmd> namespace blue set addr-blocks-default-selection-tags=subBlue 
100 Ok
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 
100 Ok
addr-blocks-use-selection-tags=false
nrcmd> namespace blue disable addr-blocks-use-selection-tags 
100 Ok
addr-blocks-use-selection-tags=false
nrcmd> dhcp disable addr-blocks-use-client-affinity 
100 Ok
addr-blocks-use-client-affinity=false
nrcmd> namespace blue disable addr-blocks-use-client-affinity 
100 Ok
addr-blocks-use-client-affinity=false

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 192.168.0.0/16 segment-name=lan192168 
100 Ok
segment-name=lan192168
red:
...
nrcmd> namespace blue enable addr-blocks-use-lan-segments 
100 Ok
addr-blocks-use-lan-segments=true

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 
100 Ok
allow-lease-time-override=enabled
nrcmd> address-block-policy red set server-lease-time=3600 
100 Ok
server-lease-time=60m
nrcmd> address-block-policy red setOption dhcp-lease-time 3600 
100 Ok
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
red:
address = 192.168.0.0/16
default-subnet-size = [default=28]
deprecated = [default=false]
embedded-policy = "((ClassName Policy)(name address-block-policy:red)
(allow-lease-time-override true)(version 1)(server-lease-time 60m)
(option-list {[((ClassName} NewOption)(number 51)(value 00:00:0e:10))\]))"
name = red
namespace-id =
policy = default
segment-name = lan192168
selection-tags =

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 
100 Ok
default-subnet-size=25

Step 3 Reload the DHCP server.

nrcmd> dhcp reload 
100 Ok

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/192.168.1.0/24 show 
nrcmd> subnet vpn-red/192.168.1.0/24 activate 
nrcmd> subnet vpn-red/192.168.1.0/24 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 these 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.