Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco IOS Software Releases 12.2 T

DHCP Server - On-Demand Address Pool Manager

Downloads

Table Of Contents

DHCP Server—On-Demand Address Pool Manager

Feature Overview

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Configuration Tasks

Defining DHCP ODAPs as the Global Default Mechanism

Defining DHCP ODAPs on an Interface

Configuring the DHCP Pool as an ODAP

Configuring ODAPs to Obtain Subnets Through IPCP Negotiation

Configuring AAA

Configuring RADIUS

Disabling ODAPs

Verifying ODAP Operation

Troubleshooting Tips

Monitoring and Maintaining the ODAP

Configuration Examples

Defining DHCP ODAPs as the Global Default Mechanism Example

Defining DHCP ODAPs on an Interface Example

Configuring the DHCP Pool as an ODAP Example

Configuring the DHCP Pool as an ODAP for Non-MPLS VPNs Example

IPCP Subnet Mask Delivery Example

Configuring AAA and RADIUS Example

Command Reference

aaa session-id

clear ip dhcp binding

clear ip dhcp conflict

clear ip dhcp subnet

ip address-pool

ip address pool

ip dhcp aaa default username

origin

peer default ip address

show ip dhcp pool

utilization mark high

utilization mark low

vrf

Glossary


DHCP Server—On-Demand Address Pool Manager

Feature History

Release
Modification

12.2(8)T

This feature was introduced.

12.2(15)T

This feature was enhanced to support non-MPLS VPN address pools.


This document describes the DHCP Server—On-Demand Address Pool Manager feature and includes the following sections:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Prerequisites

•Configuration Tasks

•Monitoring and Maintaining the ODAP

•Configuration Examples

•Command Reference

•Glossary

Feature Overview

The DHCP Server—On-Demand Address Pool Manager is a feature in which pools of IP addresses can be dynamically increased or reduced in size depending on the address utilization level. On-demand address pools (ODAPs) support address assignment using the Dynamic Host Configuration Protocol (DHCP) for customers using private addresses. Each ODAP is configured and associated with a particular Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN). Cisco IOS Release 12.2(15)T introduces support for non-MPLS VPN address pools by adding pool name support to the peer default ip address dhcp-pool pool name command.

For MPLS VPNs, each VPN is associated with one or more VPN routing and forwarding instances (VRFs). The VRF is a key element in the VPN technology because it maintains the routing information that defines a customer VPN site. This customer site is attached to a provider edge (PE) router. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table.

Once configured, the ODAP is populated with one or more subnets leased from a source server and is ready to serve address requests from DHCP clients or from PPP sessions. The source server can be a remote DHCP server or a RADIUS server (via AAA). Currently, only the Cisco Access Registrar RADIUS server supports ODAPs. Subnets can be added to the pool when a certain utilization level (high utilization mark) is achieved. When the utilization level falls below a certain level (low utilization mark), a subnet can be returned to the server from which it was originally leased. Summarized routes for each leased subnet must be inserted or removed from the related VRF with each addition or removal of subnets into the ODAP.

A PPP session belonging to a specific VPN is only allocated an address from the ODAP associated with that VPN. These PPP sessions are terminated on a Virtual Home Gateway (VHG)/PE router where the ODAP is configured. The VHG/PE router maps the remote user to the corresponding MPLS VPNs.

For PPP sessions, individual address allocation from an ODAP follows a First Leased subnet First (FLF) policy. FLF searches for a free address beginning on the very first leased subnet, followed by a search on the second leased subnet if no free address is available in the first subnet, and so on. This policy provides the benefit of grouping the leased addresses over time to a set of subnets, which allows an efficient subnet release and route summarization.

However, the FLF policy differs from the normal DHCP address selection policy. Normal DHCP address selection takes into account the IP address of the receiving interface or the gateway address if it is nonzero. To support both policies, the DHCP server needs to be able to distinguish between a normal DHCP address request and an address request for a PPP client. The DHCP Server—On-Demand Address Pool Manager feature introduces a new IP address pooling mechanism for PPP that allows the DHCP server to distinguish between a normal DHCP address request and a request from a PPP client.

Subnet release from an ODAP follows a Last Leased subnet First (LLF) policy, which prefers the last leased subnet to be released first. This LLF policy searches for a releasable subnet (a subnet with no addresses currently being leased) starting with the last leased subnet. If a releasable subnet is found (candidate subnet), it is released, and the summarized route for that subnet is removed. If more than one releasable subnet exists at that time, only the most recently allocated is released. If there are no releasable subnets, no action is taken. If by releasing the candidate subnet, the high utilization mark is reached, the subnet is not released. The first leased subnet is never released (regardless of the instantaneous utilization level) until the ODAP is disabled.

When a DHCP pool receives multiple subnets from an upstream DHCP server, an address from each subnet is automatically configured on the client connected interface so that the addresses within the subnets can be requested by DHCP clients.

The first address in the first subnet is automatically assigned to the primary address on the interface. The first address of each subsequent subnet is assigned to secondary addresses on the interface. In addition, as client addresses are reclaimed, the count of lease addresses for that subnet is decremented. Once a lease counter for a subnet reaches zero (that is, lease expiry), the subnet is returned to the pool. The previous address on the interface is removed and the first secondary address on the interface is promoted as the primary address of the interface.

Benefits

Efficient Address Management

The ODAP Manager allows customers to optimize their use of IP addresses, thus conserving address space.

Efficient Route Summarization and Update

The ODAP Manager inserts a summarized route when a subnet is added to the ODAP.

Restrictions

Currently, the ip dhcp excluded-address global configuration command cannot be used to exclude addresses from VRF associated pools.

The vrf DHCP pool configuration command is currently not supported for host pools.

Attribute inheritance is not supported on VRF pools.

Related Features and Technologies

•IPCP subnet mask negotiation

•DHCP proxy client and local IP address pooling mechanisms

Related Documents

•Cisco IOS IP Configuration Guide, Release 12.2

•Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services, Release 12.2

•Cisco IOS Security Command Reference, Release 12.2

•Cisco IOS Security Configuration Guide, Release 12.2. Refer to the chapters "Configuring Authentication," "Configuring Authorization," "Configuring Accounting," and "Configuring RADIUS."

•Cisco IOS Switching Services Command Reference, Release 12.2

•Cisco IOS Switching Services Configuration Guide, Release 12.2. Refer to the chapters "Multiprotocol Label Switching Overview" and "Configuring Multiprotocol Label Switching" in the part "Multiprotocol Label Switching."

•Introduction to Cisco MPLS VPN Technology 

•Release Notes for the Cisco 820 Series Routers for Cisco IOS Release 12.2(1)XD1. Refer to "IPCP Subnet Mask Delivery" in the "New and Changed Information" section

•MPLS VPN ID, Release 12.2(8)T

Supported Platforms

Refer to feature navigator for the latest platform information as referenced below.

Finding Support Information for Platforms and Cisco IOS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

•RFC 3046, DHCP Relay Information Option

•RFC 2685, Virtual Private Networks Identifier

Prerequisites

Before configuring the DHCP Server—On-Demand Address Pool Manager feature, you must configure standard MPLS VPNs unless you intend to use non-MPLS VPNs.

In order for the IP address pooling mechanism to work correctly, the VRF of the PPP session must match that configured on the pool. Typically this matching is done either by configuring the ip vrf forwarding vrf-name command on the virtual template interface, or if AAA is used to authorize the PPP user, it can be part of the user's profile configuration.

For more information on configuring MPLS VPNs, refer to the Cisco IOS Switching Services Configuration Guide, Release 12.2. For more information on configuring AAA, refer to the Cisco IOS Security Configuration Guide, Release 12.2.

Configuration Tasks

See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional.

•Defining DHCP ODAPs as the Global Default Mechanism (required)

•Defining DHCP ODAPs on an Interface (optional)

•Configuring the DHCP Pool as an ODAP (required)

•Configuring ODAPs to Obtain Subnets Through IPCP Negotiation (optional)

•Configuring AAA (required)

•Configuring RADIUS (required)

•Disabling ODAPs (optional)

•Verifying ODAP Operation (optional)

Defining DHCP ODAPs as the Global Default Mechanism

IP addressing allows configuration of a global default address pooling mechanism. The DHCP server needs to be able to distinguish between a normal DHCP address request and an address request for a PPP client.

To specify that the global default mechanism to use is on-demand address pooling, use the following command in global configuration mode:

Command
Purpose

Router(config)# ip address-pool dhcp-pool

Enables on-demand address pooling as the global default IP address mechanism. For remote access (PPP) sessions into MPLS VPNs, IP addresses are obtained from locally configured VRF-associated DHCP pools.


Defining DHCP ODAPs on an Interface

You can also configure the on-demand address pooling mechanism on an interface-by-interface basis, which overrides the global default mechanism on that interface. To enable DHCP on-demand address pooling assignment on an interface, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface name

Specifies the interface and enters interface configuration mode.

Step 2 

Router(config-if)# peer default ip address dhcp-pool [pool name]

Specifies an IP address from an on-demand address pool to be returned to a remote peer connecting to this interface. The pool name argument is mandatory if the session is not associated with any VRF. Multiple pool names can be accepted.

Configuring the DHCP Pool as an ODAP

To configure a DHCP pool as an on-demand address pool, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip dhcp pool name

Configures a DHCP address pool on a Cisco IOS DHCP server and enters DHCP pool configuration mode.

Step 2 

Router(config-dhcp)# vrf name

(Optional) Associates the address pool with a VRF name. Only use this command for MPLS VPNs.

Step 3 

Router(config-dhcp)# origin {dhcp | aaa | ipcp} [subnet size initial size [autogrow size]]

Configures an address pool as an on-demand address pool.

Step 4 

Router(config-dhcp)# utilization mark low percentage-number

Sets the low utilization mark of the pool size. The default value is 0 percent.

Step 5 

Router(config-dhcp)# utilization mark high percentage-number

Sets the high utilization mark of the pool size. The default value is 100 percent.

Configuring ODAPs to Obtain Subnets Through IPCP Negotiation

You can assign IP address pools to customer premises equipment (CPE) devices, which, in turn, assign IP addresses to the CPE and to a DHCP pool. This functionality has three requirements:

•The Cisco IOS CPE device must be able to request and use the subnet.

•The RADIUS server (via AAA) must be able to provide that subnet and insert the framed route into the proper VRF table.

•The PE router must be able to facilitate providing the subnet through IP Control Protocol (IPCP) negotiation.

To configure your router to use subnets obtained through IPCP negotiation, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip dhcp pool name

Configures a DHCP address pool on a Cisco IOS DHCP server and enters DHCP pool configuration mode.

Step 2 

Router(config-dhcp)# import all

Imports option parameters into the Cisco IOS DHCP server database.

Step 3 

Router(config-dhcp)# origin ipcp

Configures an address pool as an on-demand address pool using IPCP as the subnet allocation protocol.

Step 4 

Router(config-dhcp)# exit

Exits DHCP pool configuration mode.

Step 5 

Router(config)# interface type

Configures an interface and enters interface configuration mode.

Step 6 

Router(config-if)# ip address pool name

Specifies that the interface IP address will be automatically configured from the named pool, when the pool is populated with a subnet from IPCP.

Configuring AAA

To allow ODAP to obtain subnets from the RADIUS server, the AAA client must be configured on the VHG/PE router. To configure AAA on the VHG/PE router, use the following commands in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# aaa new-model

Enables AAA access control.

Step 2 

Router(config)# aaa authorization configuration default group radius

Downloads static route configuration information from the AAA server using RADIUS.

Step 3 

Router(config)# aaa accounting network default start-stop radius



or


Router(config)# aaa accounting network default stop-only radius


Enables AAA accounting of requested services for billing or security purposes when you use RADIUS. Sends a "start" accounting notice at the beginning of a process.

or


Enables AAA accounting of requested services for billing or security purposes when you use RADIUS. Sends a "stop" accounting notice at the end of the requested user process.

Step 4 

Router(config)# aaa session-id common

Ensures that the same session ID will be used for each AAA accounting service type within a call.

Configuring RADIUS

To configure RADIUS, use the following commands in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip radius source-interface subinterface-name

Forces RADIUS to use the IP address of a specified interface for all outgoing RADIUS packets.

Step 2 

Router(config)# radius-server host ip-address auth-port port-number acct-port port-number

Specifies a RADIUS server host.

Step 3 

Router(config)# radius server attribute 32 include-in-access-req

Sends RADIUS attribute 32 (NAS-Identifier) in an access request or accounting request.

Step 4 

Router(config)# radius server attribute 44 include-in-access-req

Sends RADIUS attribute 44 (Accounting Session ID) in an access request or accounting request.

Step 5 

Router(config)# radius-server vsa send accounting

Configures the network access server (NAS) to recognize and use vendor-specific accounting attributes.

Step 6 

Router(config)# radius-server vsa send authentication

Configures the NAS to recognize and use vendor-specific authentication attributes.

Disabling ODAPs

When an ODAP is disabled, all leased subnets are released. If active PPP sessions are using addresses from the released subnets, those sessions will be reset. DHCP clients leasing addresses from the released subnets will not be able to renew their leases. To disable an ODAP from a DHCP pool, use the following command in DHCP pool configuration mode:

Command
Purpose

Router(config-dhcp)# no origin {dhcp | aaa | ipcp}

Disables the ODAP.


Verifying ODAP Operation

Step 1 Enter the show ip dhcp pool [name] command:

The following output is for two DHCP pools: Green and Global. Pool Green is configured with a high utilization mark of 50 and a low utilization mark of 30. The pool is also configured to obtain more subnets when the high utilization mark is reached (autogrow). The Subnet size field indicates the values configured in the origin command as the initial and incremental subnet sizes that would be requested by the pool named Green. The Total addresses field is a count of all the usable addresses in the pool. The Leased addresses field is a total count of how many bindings were created from the pool. The Pending event field shows subnet request, which means that a subnet request is pending for the pool. The subnet request was scheduled because the Leased addresses count has exceeded the high utilization level of the pool. Subnets currently added to pool Green are shown in sequence. The Current index columns shows the address that would be allocated next from this subnet. The IP address range column shows the range of usable addresses from the subnet. The Leased addresses column shows individual count of bindings created from each subnet. Three subnets are currently added to pool Green. The first two subnets have used all their addresses and thus the Current index is showing 0.0.0.0.

Notice that pool Green and pool Global can have the same subnet (172.16.0.1-172.16.0.6) because pool Green is configured to be in VRF Green, while pool Global is configured to be in the global address space.

Router# show ip dhcp pool 

 
Pool Green :

 Utilization mark (high/low)    : 50 / 30

 Subnet size (first/next)       : 24 / 24 (autogrow)

 VRF name                       : Green

 Total addresses                : 18

 Leased addresses               : 13

 Pending event                  : subnet request

 3 subnets are currently in the pool :

 Current index        IP address range                    Leased addresses

 0.0.0.0              172.16.0.1       - 172.16.0.6        6

 0.0.0.0              172.16.0.9       - 172.16.0.14       6

 172.16.0.18          172.16.0.17      - 172.16.0.22       1


Pool Global :

 Utilization mark (high/low)    : 100 / 0 

 Subnet size (first/next)       : 24 / 24 (autogrow)

 Total addresses                : 6

 Leased addresses               : 0

 Pending event                  : none

 1 subnet is currently in the pool :

 Current index        IP address range                    Leased addresses

 172.16.0.1           172.16.0.1       - 172.16.0.6        0

Step 2 Enter the show ip dhcp binding command:

The output following shows the bindings from pool Green. The Type field shows On-demand, which indicates that the address binding was created for a PPP session. The Lease expiration field shows Infinite, which means that the binding is valid as long as the session is up. If a subnet must be released back to the leasing server while the session is still up, the session is reset so that it will be forced to obtain a new IP address. The Hardware address column for an On-demand entry shows the identifier for the session as detected by PPP. There are no bindings shown under the Bindings from all pools not associated with VRF field because the Global pool has not allocated any addresses. 

Router# show ip dhcp binding 

Bindings from all pools not associated with VRF:

IP address       Hardware address        Lease expiration        Type


Bindings from VRF pool Green:

IP address       Hardware address        Lease expiration        Type

172.16.0.1       5674.312d.7465.7374.    Infinite                On-demand

                 2d38.3930.39

172.16.0.2       5674.312d.7465.7374.    Infinite                On-demand

                 2d38.3839.31

172.16.0.3       5674.312d.7465.7374.    Infinite                On-demand

                 2d36.3432.34

172.16.0.4       5674.312d.7465.7374.    Infinite                On-demand

                 2d38.3236.34

172.16.0.5       5674.312d.7465.7374.    Infinite                On-demand

                 2d34.3331.37

172.16.0.6       5674.312d.7465.7374.    Infinite                On-demand

                 2d37.3237.39

172.16.0.9       5674.312d.7465.7374.    Infinite                On-demand

                 2d39.3732.36

172.16.0.10      5674.312d.7465.7374.    Infinite                On-demand

                 2d31.3637

172.16.0.11      5674.312d.7465.7374.    Infinite                On-demand

                 2d39.3137.36

172.16.0.12      5674.312d.7465.7374.    Infinite                On-demand

                 2d37.3838.30

172.16.0.13      5674.312d.7465.7374.    Infinite                On-demand

                 2d32.3339.37

172.16.0.14      5674.312d.7465.7374.    Infinite                On-demand

                 2d31.3038.31

172.16.0.17      5674.312d.7465.7374.    Infinite                On-demand

                 2d38.3832.38

172.16.0.18      5674.312d.7465.7374.    Infinite                On-demand

                 2d32.3735.31

Troubleshooting Tips

By default, the Cisco IOS DHCP server on which the ODAP Manager is based attempts to verify an address availability by performing a ping operation to the address before allocation. The default DHCP ping configuration will wait for 2 seconds for an ICMP echo reply. This default configuration results in the DHCP server servicing one address request every 2 seconds. The number of ping packets being sent and the ping timeout are configurable. Thus, to reduce the address allocation time, you can reduce either the timeout or the number of ping packets sent. Reducing the timeout or the ping packets being sent will improve the address allocation time, at the cost of less ability to detect duplicate addresses.

Each ODAP will make a finite number of attempts (up to four retries) to obtain a subnet from DHCP or AAA. If these attempts are not successful, the subnet request from the pool automatically starts when there is another individual address request to the pool (for example, from a newly brought up PPP session). If a pool has not been allocated any subnets, you can force restarting the subnet request process by using the clear ip dhcp pool name subnet * EXEC command.

Monitoring and Maintaining the ODAP

To monitor and maintain the ODAP, use the following EXEC commands:

Command
Purpose

Router# clear ip dhcp [pool name] binding {* | address}

Deletes an automatic address binding or objects from a specific pool from the DHCP server database.

Router# clear ip dhcp [pool name] conflict {* | address}

Clears an address conflict or conflicts from a specific pool from the DHCP server database.

Router# clear ip dhcp [pool name] subnet { * | address}

Clears all currently leased subnets in the named DHCP pool or all DHCP pools if name is not specified.

Router# debug dhcp details

Monitors the subnet allocation/releasing in the on-demand address pools.

Router# debug ip dhcp server events

Reports DHCP server events, like address assignments and database updates.

Router# show ip dhcp import

Displays the option parameters that were imported into the DHCP server database.

Router# show ip interface [type number]

Displays the usability status of interfaces configured for IP.

Router# show ip dhcp pool name

Displays DHCP address pool information.


Note the following behavior for the clear ip dhcp binding, clear ip dhcp conflict, and clear ip dhcp subnet commands:

•If you do not specify the pool name option and an IP address is specified, it is assumed that the IP address is an address in the global address space and will look among all the non-VRF DHCP pools for the specified binding/conflict/subnet.

•If you do not specify the pool name option and the * option is specified, it is assumed that all automatic/ or on-demand bindings/conflicts/subnets in all VRF and non-VRF pools are to be deleted.

•If you specify both the pool name option and the * option, all automatic or on-demand bindings/conflicts/subnets in the specified pool only will be cleared.

•If you specify the pool name option and an IP address, the specified binding/conflict or the subnet containing the specified IP address will be deleted from the specified pool.

Configuration Examples

This section provides the following configuration examples:

•Defining DHCP ODAPs as the Global Default Mechanism Example

•Defining DHCP ODAPs on an Interface Example

•Configuring the DHCP Pool as an ODAP Example

•Configuring the DHCP Pool as an ODAP for Non-MPLS VPNs Example

•IPCP Subnet Mask Delivery Example

•Configuring AAA and RADIUS Example

Defining DHCP ODAPs as the Global Default Mechanism Example

The following example shows that the on-demand address pooling mechanism will be used to serve an address request from a PPP client. 

!

ip address-pool dhcp-pool

!

ip dhcp pool Green-pool

!

Defining DHCP ODAPs on an Interface Example

The following example shows how to configure an interface to retrieve an IP address from an on-demand address pool: 

!

interface Virtual-Template1

 ip vrf forwarding green

 ip unnumbered loopback1

 ppp authentication chap

 peer default ip address dhcp-pool

!

Configuring the DHCP Pool as an ODAP Example

The following example shows two ODAPs configured to obtain their subnets from an external DHCP server: 

Router# show run


Building configuration...


Current configuration : 3943 bytes

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Router

!

no logging console

enable password lab

!

username vpn_green_net1 password 0 lab

username vpn_red_net1 password 0 lab

ip subnet-zero

!

ip dhcp pool green_pool

   vrf Green

   utilization mark high 60

   utilization mark low 40

   origin dhcp subnet size initial /24 autogrow /24

!

ip dhcp pool red_pool

   vrf Red

   origin dhcp

!

ip vrf Green

 rd 200:1

 route-target export 200:1

 route-target import 200:1

!

ip vrf Red

 rd 300:1

 route-target export 300:1

 route-target import 300:1

ip cef

ip address-pool dhcp-pool

!

no voice hpi capture buffer

no voice hpi capture destination 

!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface Loopback1

 ip vrf forwarding Green

 ip address 100.10.10.1 255.255.255.255

!

interface Loopback2

 ip vrf forwarding Red

 ip address 110.10.10.1 255.255.255.255

!

interface ATM2/0

 no ip address

 shutdown

 no atm ilmi-keepalive

!

interface ATM3/0

 no ip address

 no atm ilmi-keepalive

!

interface Ethernet4/0

 ip address 10.0.105.12 255.255.255.224

 duplex half

!

interface Ethernet4/1

 ip address 150.10.10.1 255.255.255.0

 duplex half

!

interface Ethernet4/2

 ip address 120.10.10.1 255.255.255.0

 duplex half

 tag-switching ip

!

interface Virtual-Template1

 ip vrf forwarding Green

 ip unnumbered Loopback1

 ppp authentication chap

!

interface Virtual-Template2

 ip vrf forwarding Green

 ip unnumbered Loopback1

 ppp authentication chap

!

interface Virtual-Template3

 ip vrf forwarding Green

 ip unnumbered Loopback1

 ppp authentication chap

!

interface Virtual-Template4

 ip vrf forwarding Red

 ip unnumbered Loopback2

 ppp authentication chap

!

interface Virtual-Template5

 ip vrf forwarding Red

 ip unnumbered Loopback2

 ppp authentication chap

!

interface Virtual-Template6

 ip vrf forwarding Red

 ip unnumbered Loopback2

 ppp authentication chap

!

router ospf 100

 log-adjacency-changes

 redistribute connected

 network 1.1.1.1 0.0.0.0 area 0

 network 120.10.10.0 0.0.0.255 area 0

 network 150.10.10.0 0.0.0.255 area 0

!

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 neighbor 3.3.3.3 remote-as 100

 neighbor 3.3.3.3 update-source Loopback0

 !

 address-family ipv4 vrf Red

 redistribute connected

 redistribute static

 no auto-summary

 no synchronization

 network 110.0.0.0

 exit-address-family

 !

 address-family ipv4 vrf Green

 redistribute connected

 redistribute static

 no auto-summary

 no synchronization

 network 100.0.0.0

 exit-address-family

 !

 address-family vpnv4

 neighbor 3.3.3.3 activate

 neighbor 3.3.3.3 send-community extended

 exit-address-family

!

ip classless

ip route 172.19.0.0 255.255.0.0 10.0.105.1

no ip http server

ip pim bidir-enable

!

call rsvp-sync

!

mgcp profile default

!

dial-peer cor custom

!

gatekeeper

 shutdown

!

line con 0

 exec-timeout 0 0

line aux 0

line vty 0 4

 password lab

 login

!

end

Configuring the DHCP Pool as an ODAP for Non-MPLS VPNs Example

The following example shows how to configure an interface to retrieve an IP address from an on-demand address pool. In this example, two non-VRF ODAPs are configured. There are two virtual-templates and two DHCP address pools, usergroup1 and usergroup2. Each virtual-template interface is configured to obtain IP addresses for the peer from the associated address pool. 

!

ip dhcp pool usergroup1

 origin dhcp subnet size initial /24 autogrow /24

 lease 0 1

!

ip dhcp pool usergroup2

 origin dhcp subnet size initial /24 autogrow /24

 lease 0 1

!

interface virtual-template1

 ip unnumbered loopback1

 peer default ip address dhcp-pool usergroup1

!

interface virtual-template2

 ip unnumbered loopback1

 peer default ip address dhcp-pool usergroup2

IPCP Subnet Mask Delivery Example

The following example shows a Cisco 827 router configured to use IPCP subnet masks: 

Router# show run


 Building configuration...

 Current configuration :1479 bytes

 !

 version 12.2

 no service single-slot-reload-enable

 no service pad

 service timestamps debug datetime msec

 service timestamps log uptime

 no service password-encryption

 !

 hostname Router

 !

 no logging buffered

 logging rate-limit console 10 except errors

 !

 username 6400-nrp2 password 0 lab

 ip subnet-zero

 ip dhcp smart-relay

 !

 ip dhcp pool IPPOOLTEST

    import all

    origin ipcp

 !

 no ip dhcp-client network-discovery

 !

 interface Ethernet0

  ip address pool IPPOOLTEST

  ip verify unicast reverse-path

  shutdown

  hold-queue 32 in

 !

 interface ATM0

  no ip address

  atm ilmi-keepalive

  bundle-enable

  dsl operating-mode auto

  hold-queue 224 in

 !

 interface ATM0.1 point-to-point

  pvc 1/40 

   no ilmi manage

   encapsulation aal5mux ppp dialer

   dialer pool-member 1

  !

 !

 interface Dialer0

  ip unnumbered Ethernet0

  ip verify unicast reverse-path

  encapsulation ppp

  dialer pool 1

  dialer-group 1

  no cdp enable

  ppp authentication chap callin

  ppp chap hostname Router

  ppp chap password 7 12150415

  ppp ipcp accept-address

  ppp ipcp dns request

  ppp ipcp wins request

  ppp ipcp mask request

 !

 ip classless

 ip route 0.0.0.0 0.0.0.0 Dialer0

 no ip http server

 !

 dialer-list 1 protocol ip permit

 line con 0

  exec-timeout 0 0

  transport input none

  stopbits 1

 line vty 0 4

  login

 !

 scheduler max-task-time 5000

 end

Configuring AAA and RADIUS Example

The following example shows one pool "Green" configured to obtain its subnets from the AAA (RADIUS) server located at IP address 172.16.1.1: 

!

aaa new-model

!

aaa authorization configuration default group radius 

aaa accounting network default start-stop group radius

aaa session-id common

!

ip subnet-zero

!

ip dhcp ping packets 0

!

ip dhcp pool Green

   vrf Green

   utilization mark high 50

   utilization mark low 30

   origin aaa subnet size initial /28 autogrow /28

!

ip vrf Green

 rd 300:1

 route-target export 300:1

 route-target import 300:1

!

interface Ethernet1/1

 ip address 172.16.1.12 255.255.255.0

 duplex half

!

interface Virtual-Template1

 ip vrf forwarding Green

 no ip address

!

ip radius source-interface Ethernet1/1

!

!IP address of the RADIUS server host

radius-server host 172.16.1.1 auth-port 1645 acct-port 1646

radius-server retransmit 3

radius-server attribute 32 include-in-access-req 

radius-server attribute 44 include-in-access-req

radius-server key cisco

radius-server vsa send accounting

radius-server vsa send authentication

Command Reference

This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.

New Commands

•aaa session-id

•clear ip dhcp subnet

•ip address pool

•ip dhcp aaa default username

•origin

•show ip dhcp pool

•utilization mark high

•utilization mark low

•vrf

Modified Commands

•clear ip dhcp binding

•clear ip dhcp conflict

•ip address-pool

•peer default ip address

aaa session-id

To specify whether the same session ID will be used for each AAA accounting service type within a call or whether a different session ID will be assigned to each accounting service type, use the aaa session-id command in global configuration mode. To restore the default behavior after the unique keyword is enabled, use the no form of this command.

aaa session-id [common | unique]

no aaa session-id [unique]

Syntax Description

common

(Optional) Ensures that all session ID information that is sent out for a given call will be made identical. This is the default behavior.

unique

(Optional) Ensures that only the corresponding service access-requests and accounting-requests will maintain a common session ID. Accounting-requests for each service will have a different session ID.


Defaults

The common keyword is enabled.

Command Modes

Global Configuration

Command History

Release
Modification

12.2(4)B

This command was introduced.

12.2(8)T

This command was integrated into Cisco IOS Release 12.2(8)T.


Usage Guidelines

The common keyword behavior allows the first session ID request of the call to be stored in a common database; all proceeding session ID requests will retrieve the value of the first session ID. Because a common sessionID is the default behavior, this functionality is written to the system configuration after the aaa new-model command is configured.

Note The router configuration will always have either the aaa session-id common or the aaa session-id unique command enabled; it is not possible to have neither of the two. Thus, the no aaa session-id unique command will revert to the default functionality, but the no aaa session-id common command will not have any effect because it is the default functionality.

The unique keyword behavior assigns a different session ID for each accounting type (Auth-Proxy, Exec, Network, Command, System, Connection, and Resource) during a call. To specify this behavior, the unique keyword must be specified. The session ID may be included in RADIUS access-requests by configuring the radius-server attribute 44 include-in-access-req command. The session ID in the access-request will be the same as the session ID in the accounting-request for the same service; all other services will provide unique session IDs for the same call.

Examples

The following example shows how to configure unique session IDs: 

aaa new-model

aaa authentication ppp default group radius

radius-server host 10.100.1.34

radius-server attribute 44 include-in-access-req

aaa session-id unique

Related Commands

Command
Description

aaa new model

Enables AAA.

radius-server attribute 44 include-in-access-req

Sends RADIUS attribute 44 (Accounting Session ID) in access request packets before user authentication (including requests for preauthentication).


clear ip dhcp binding

To delete an automatic address binding from the Cisco IOS Dynamic Host Configuration Protocol (DHCP) server database, use the clear ip dhcp binding command in privileged EXEC mode.

clear ip dhcp [pool name] binding {* | address}

Syntax Description

pool name

(Optional) Name of the DHCP pool.

*

Clears all automatic bindings.

address

The address of the binding you want to clear.


Command Modes

Privileged EXEC

Command History

Release
Modification

12.0(1)T

This command was introduced.

12.2(8)T

The pool name keyword and argument combination was added.


Usage Guidelines

Typically, the address denotes the IP address of the client. If the asterisk (*) character is used as the address parameter, DHCP clears all automatic bindings.

Use the no ip dhcp pool global configuration command to delete a manual binding.

Note the following behavior for the clear ip dhcp binding command:

•If you do not specify the pool name option and an IP address is specified, it is assumed that the IP address is an address in the global address space and will look among all the non-VRF DHCP pools for the specified binding.

•If you do not specify the pool name option and the * option is specified, it is assumed that all automatic/ or on-demand bindings in all VRF and non-VRF pools are to be deleted.

•If you specify both the pool name option and the * option, all automatic or on-demand bindings in the specified pool only will be cleared.

•If you specify the pool name option and an IP address, the specified binding will be deleted from the specified pool.

Examples

The following example deletes the address binding 10.12.1.99 from a DHCP server database: 

Router# clear ip dhcp binding 10.12.1.99

The following example deletes all bindings from all pools: 

Router# clear ip dhcp binding *

The following example deletes all bindings from the address pool named red: 

Router# clear ip dhcp pool red binding *

The following example deletes address binding 10.13.2.99 from the address pool named red: 

Router# clear ip dhcp pool red binding 10.13.2.99

Related Commands

Command
Description

show ip dhcp binding

Displays address bindings on the Cisco IOS DHCP server.


clear ip dhcp conflict

To clear an address conflict from the Cisco IOS Dynamic Host Configuration Protocol (DHCP) Server database, use the clear ip dhcp conflict command in privileged EXEC configuration mode.

clear ip dhcp [pool name] conflict {* | address}

Syntax Description

pool name

(Optional) Name of the DHCP pool.

*

Clears all address conflicts.

address

The IP address of the host that contains the conflicting address you want to clear.


Command Modes

Privileged EXEC

Command History

Release
Modification

12.0(1)T

This command was introduced.

12.2(8)T

The pool name keyword and argument were added.


Usage Guidelines

The server detects conflicts using a ping session. The client detects conflicts using gratuitous Address Resolution Protocol (ARP). If the asterisk (*) character is used as the address parameter, DHCP clears all conflicts.

Note the following behavior for the clear ip dhcp conflict command:

•If you do not specify the pool name option and an IP address is specified, it is assumed that the IP address is an address in the global address space and will look among all the non-VRF DHCP pools for the specified conflict.

•If you do not specify the pool name option and the * option is specified, it is assumed that all automatic/ or on-demand conflicts in all VRF and non-VRF pools are to be deleted.

•If you specify both the pool name option and the * option, all automatic or on-demand conflicts in the specified pool only will be cleared.

•If you specify the pool name option and an IP address, the specified conflict will be deleted from the specified pool.

Examples

The following example shows an address conflict of 10.12.1.99 being deleted from the DHCP server database: 

Router# clear ip dhcp conflict 10.12.1.99

The following example deletes all address conflicts from all pools: 

Router# clear ip dhcp conflict *

The following example deletes all address conflicts from the address pool named red: 

Router#