DHCP Management

In This Chapter

This chapter provides information about using DHCP, including theory, supported features and configuration process overview.

Topics in this chapter include:

  1. DHCP Principles
  2. DHCP Features
    1. DHCP Relay
    2. Subscriber Identification Using Option 82 Field
    3. DHCP Snooping
    4. DHCP Lease State Table
    5. DHCPv6
    6. DHCPv4 Relay Proxy
    7. Virtual Subnet for DHCPv4 Hosts
  3. Proxy DHCP Server
  4. Local Address Assignment
  5. Configuring DHCP with CLI

DHCP Principles

In a Triple Play network, client devices (such as a routed home gateway, a session initiation protocol (SIP) phone or a set-top box) use Dynamic Host Configuration Protocol (DHCP) to dynamically obtain their IP address and other network configuration information.

DHCP is defined and shaped by several RFCs and drafts in the IETF DHC working group including the following:

  1. RFC 1534, Interoperation Between DHCP and BOOTP
  2. RFC 2131, Dynamic Host Configuration Protocol
  3. RFC 2132, DHCP Options and BOOTP Vendor Extensions
  4. RFC 3046, DHCP Relay Agent Information Option

The DHCP operation is illustrated in Figure 14.

Figure 14:  IP Address Assignment with DHCP 
  1. During boot-up, the client device sends a DHCP discover message to get an IP address from the DHCP Server. The message contains:
    1. Destination MAC address — broadcast
    2. Source MAC address — MAC of client device
    3. Client hardware address — MAC of client device
      If this message passes through a DSLAM or other access node, typically the Relay information option (Option 82) field is added, indicating shelf, slot, port, VPI, VCI etc. to identify the subscriber.
      DHCP relay is enabled on the first IP interface in the upstream direction. Depending on the scenario, the DSLAM, BSA or the BSR will relay the discover message as a unicast packet towards the configured DHCP server. DHCP relay is configured to insert the giaddr in order to indicate to the DHCP server in which subnet an address should be allocated.
  2. The DHCP server will lookup the client MAC address and Option 82 information in its database. If the client is recognized and authorized to access the network, an IP address will be assigned and a DHCP offer message returned. The BSA or BSR will relay this back to the client device.
  3. It is possible that the discover reached more than one DHCP server, and thus that more than one offer was returned. The client selects one of the offered IP addresses and confirms it wants to use this in a DHCP request message, sent as unicast to the DHCP server that offered it.
  4. The DHCP server confirms that the IP address is still available, updates its database to indicate it is now in use, and replies with a DHCP ACK message back to the client. The ACK will also contain the Lease Time of the IP address.

DHCP Features

  1. DHCP Relay
  2. DHCPv4 Relay Proxy
  3. Subscriber Identification Using Option 82 Field
  4. DHCP Snooping
  5. DHCP Lease State Table

DHCP Relay

Since DHCP requests are broadcast packets that normally will not propagate outside of their IP subnet, a DHCP relay agent intercepts such requests and forwards them as unicast messages to a configured DHCP server.

When forwarding a DHCP message, the relay agent sets the giaddr (gateway IP address) in the packet to the IP address of its ingress interface. This allows DHCP clients to use a DHCP server on a remote network. From both a scalability and a security point of view, it is recommended that the DHCP relay agent is positioned as close as possible to the client terminals.

DHCP relay is used in a Layer 3 environment, and thus is only supported in IES services and VPRN services. VPRN is supported on the 7750 SR only.

When DHCP clients and servers are in different VPRN routing instances of which one is the Base routing instance, route leaking (GRT-leaking) should be used to relay DHCPv4 and DHCPv6 messages between a VRPN and the Global Routing Table (GRT).

While DHCP relay is not implemented in a VPLS, it is still possible to insert or modify Option 82 information.

In a Routed CO environment in the 7750 SR, the subscriber interface’s group interface DHCP relay is stateful.

DHCPv4 Relay Proxy

In network deployments where DHCPv4 client subnets cannot be leaked in the DHCPv4 server routing instance, unicast renewal messages (DHCP ACKs) cannot be routed in the DHCPv4 server routing instance, as illustrated in Figure 15. The DHCP server sets the destination IP address of the DHCP ACK to the Client IP address (ciaddr) as received in the DHCP REQUEST message. Because there is no route available for the client subnet in the DHCP server routing instance, the DHCP ACK cannot be delivered.

Figure 15:  DHCPv4 Relay: Unicast Renewal Routing Problem 

The unicast renewal routing problem illustrated in Figure 15 can be solved with a relay proxy function that enhances the DHCPv4 relay. With the relay-proxy command in the DHCPv4 relay on a regular interface or group-interface, the unicast renewals are now also relayed to the DHCPv4 server, as described below and illustrated in Figure 16:

  1. In the client to server direction, the source IP address is updated and the gateway IP address (gi-address) field is added before sending the message to the intended DHCP server (the message is not broadcasted to all configured DHCP servers.
  2. In the server to client direction, the gi-address field is removed and the destination IP address is updated with the value of the your IP address (yiaddr) field.

When relay-proxy is enabled, the gi-address can be configured to any local address that is configured in the same routing instance. The gi-address is the only address that must be leaked in the DHCPv4 server routing instance because a DHCPv4 server always sends the response on a relayed packet to the relay agent using the gi-address as the destination IP address.

By default, unicast DHCPv4 RELEASE messages are forwarded transparently by a relay proxy function. The optional release-update-src-ip flag updates the source IP address with the value that is used for all relayed DHCPv4 messages, as shown in Figure 16.

Figure 16:  DHCPv4 relay-proxy: Relay Unicast Messages 

A relay-proxy command can also be used to hide the DHCPv4 server address for DHCP clients. This prevents the client from learning the DHCPv4 server infrastructure details such as the IP address and number of servers. Hiding infrastructure details helps in Denial of Service (DoS) prevention.

The optional siaddr-override ip-address parameter in relay-proxy enables DHCPv4 server IP address hiding towards the client. The client interacts with the relay proxy as if it is the DHCP server. In addition to the relay proxy functions as described earlier, the following actions are performed when DHCPv4 server IP address hiding is configured:

  1. In all DHCP messages to the client, the value of following header fields and DHCP options containing the DHCP server IP address is replaced with the configured <ip-address>:
    1. the source IP address
    2. the siaddr field in the DHCPv4 header if it is not equal to zero in the message received from the server
    3. the Server Identification option (DHCPv4 option 54) if present in the original server message
  2. The DHCP OFFER selection during initial binding. Only the first DHCP OFFER message is forwarded to the client. Subsequent DHCP OFFER messages from different servers are silently dropped.

The siaddr-override ip-address parameter can be any local address in the same routing instance. If DHCP relay lease split is enabled, siaddr-override ip-address has priority over the emulated-server ip-address configured in the proxy-server and will be used as the source IP address.

The active DHCPv4 server IP address obtained from the DHCP OFFER selection is required for the IP address hiding function and is stored in the lease state record. Therefore lease-populate must be enabled on the interface when siaddr-override ip-address is configured.

Figure 17 shows the initial lease binding phase of a relay proxy with DHCP server address hiding enabled. In the absence of a DHCP lease state in the initial lease binding phase, the DHCP server IP address resulting from the OFFER selection is stored in a DHCP transaction cache. After successful lease binding, the DHCP server IP address is added to the lease state record.

In a host creation failure scenario, if no transaction cache or lease state is available when a DHCP REQUEST message is received, then the DHCP REQUEST is silently dropped. The drop reason can be found by enabling DHCP debug.

Figure 17:  DHCPv4 relay-proxy: DHCP Server IP Address Hiding, Initial Binding 

Figure 18 shows the lease renewal phase of a relay proxy with DHCP server address hiding enabled. A unicast REQUEST (renew) is relayed only to the DHCP server owning the lease. A broadcast REQUEST (rebind) is relayed to all configured DHCP servers.

During lease renewal, the DHCP server IP address can be updated in the lease state if the DHCP ACK is received from a different server. This optimizes the DHCP proxy relay operation in a DHCP server failover scenario. This is depicted in Figure 19.

Figure 18:  DHCPv4 relay-proxy: DHCP Server IP Address Hiding, Lease Renewal 
Figure 19:  DHCPv4 relay-proxy: DHCP Server IP Address Hiding, Lease Renewal With Active Server Failure 

Figure 20 shows the release in a relay proxy scenario with DHCP server address hiding enabled. The RELEASE message is sent only to the DHCP server owning the lease. Optionally, the source Ip address can be updated.

Figure 20:  DHCPv4 relay-proxy: DHCP Server IP Address Hiding, Release 

Relay proxy can be enabled on subscriber group-interfaces and regular interfaces in an IES or VPRN service.

For retail subscriber interfaces, relay-proxy is configured at the subscriber-interface dhcp CLI context, as shown in the example that follows.

A relay proxy function is not supported in combination with a double DHCPv4 relay (L3 DHCPv4 relay in front of a 7750 DHCPv4 relay with relay-proxy enabled).

Configuration example

config>service>vprn>
        interface "lo0" create
            address 192.0.2.10/32
            loopback
        exit
        interface "lo1" create
            address 192.0.2.11/32
            loopback
        exit
        subscriber-interface "sub-int-1" create
            address 10.1.0.254/24
            group-interface "group-int-1-1" create
                dhcp 
                    server 172.16.1.1 
                    lease-populate 32767
                    relay-proxy release-update-src-ip siaddr-override 192.0.2.10
                    gi-address 192.0.2.11 src-ip-addr
                    no shutdown
                 exit 
            exit
        exit

Subscriber Identification Using Option 82 Field

Option 82, or the relay information option is specified in RFC 3046, DHCP Relay Agent Information Option, and allows the router to append some information to the DHCP request that identifies where the original DHCP request came from.

There are two sub-options under Option 82:

  1. Agent Circuit ID Sub-option (RFC 3046, section 3.1): This sub-option specifies data which must be unique to the box that is relaying the circuit.
  2. Remote ID Sub-option (RFC 3046 section 3.2): This sub-option identifies the host at the other end of the circuit. This value must be globally unique.

Both sub-options are supported and can be used separately or together.

Inserting Option 82 information is supported independently of DHCP relay. However in a VPLS (when DHCP Relay is not configured), DHCP snooping must be enabled on the SAP to be able to insert Option 82 information.

When the circuit id sub-option field is inserted, it can take following values:

  1. sap-id: The SAP index (only under a IES or VPRN service)
  2. ifindex: The index of the IP interface (only under a IES or VPRN service)
  3. ascii-tuple: An ASCII-encoded concatenated tuple, consisting of [system-name|service-id|interface-name] (for VPRN or IES) or [system-name|service-id|sap-id] (for VPLS).
  4. vlan-ascii-tuple: An ASCII-encoded concatenated tuple, consisting of the ascii-tuple followed by Dot1p bits and Dot1q tags.

For VPRN, the ifindex is unique only within a VRF. The DHCP relay function automatically prepends the VRF ID to the ifindex before relaying a DHCP Request. VPRN is supported on the 7750 SR only.

When a DHCP packet is received with Option 82 information already present, the system can do one of three things. The available actions are:

  1. Replace — On ingress the existing information-option is replaced with the information-option parameter configured. On egress (towards the customer) the information option is stripped (per the RFC).
  2. Drop — The DHCP packet is dropped and a counter is incremented.
  3. Keep — The existing information is kept on the packet and the router does not add any additional information. On egress the information option is not stripped and is sent on to the downstream node.

In accordance with the RFC, the default behavior is to keep the existing information; except if the giaddr of the packet received is identical to a local IP address on the router, then the packet is dropped and an error incremented regardless of the configured action.

The maximum packet size for a DHCP relay packet is 1500 bytes. If adding the Option 82 information would cause the packet to exceed this size, the DHCP relay request will be forwarded without the Option 82 information. This packet size limitation exists to ensure that there will be no fragmentation on the end Ethernet segment where the DHCP server attaches.

In the downstream direction, the inserted Option 82 information should not be passed back towards the client (as per RFC 3046, DHCP Relay Agent Information Option). To enable downstream stripping of the option 82 field, DHCP snooping should be enabled on the SDP or SAP connected to the DHCP server.

Trusted and Untrusted

There is a case where the relay agent could receive a request where the downstream node added Option 82 information without also adding a giaddr (giaddr of 0). In this case the default behavior is for the router to drop the DHCP request. This behavior is in line with the RFC.

The trusted command is supported which allows the router to forward the DHCP request even if it receives one with a giaddr of 0 and Option 82 information attached. This could occur with older access equipment. In this case the relay agent would modify the request’s giaddr to be equal to the ingress interface. This only makes sense when the action in the information option is keep, and the service is IES or VPRN. In the case where the Option 82 information gets replaced by the relay agent, either through explicit configuration or the VPLS DHCP Relay case, the original Option 82 information is lost, and the reason for enabling the trusted option is lost.

DHCP Snooping

This section discusses the Alcatel-Lucent routers acting as a Broadband Subscriber Aggregator (BSA) with Layer 2 aggregation towards a Broadband Subscriber Router (BSR).

A typical initial DHCP scenario is:

 

But, when the client already knows its IP address, it can skip the discover:

 

The BSA can copy packets designated to the standard UDP port for DHCP (port 67) to its control plane for inspection, this process is called DHCP snooping.

DHCP snooping can be performed in two directions:

  1. From the client to the DHCP server (Discover or Request messages):
    1. to insert Option 82 information (when the system is not configured to do DHCP Relay), see Subscriber Identification Using Option 82 Field);
    2. to forward DHCP requests to a RADIUS server first, and not send them to the DHCP server unless the RADIUS server confirms positive identification.
    For these applications, DHCP snooping must be enabled on the SAP towards the subscriber;
  2. From the DHCP server (ACK messages):
    1. to remove the Option 82 field toward the client
    2. to build a dynamic DHCP lease state table for security purposes, see section DHCP Lease State Table
    3. to perform Enhanced Subscriber Management, see section Triple Play Enhanced Subscriber Management
    For these applications, DHCP snooping must be enabled on both the SAP or SDP towards the network and the SAP towards the subscriber.
    A major application for DHCP response snooping in the context of Triple Play is security: A malicious user A could send an IP packet (for example, requesting a big video stream) with as source the IP address of user B. Any return packets would be sent to B, and thus potentially jam the connection to B.
    As the snooped information is coming straight from the operator's DHCP server, it is considered reliable. The BSA and BSR can use the snooped information to build anti-spoofing filters, populate the ARP table, send ARP replies, etc.

DHCP Lease State Table

The DHCP lease state table has a central role in the BSA operation (Figure 21). For each SAP on each service it maintains the identities of the hosts that are allowed network access.

Figure 21:  DHCP Lease State Table 

When the command lease-populate is enabled on a SAP, the DHCP lease state table is populated by snooping DHCP ACK messages on that SAP, as described in the DHCP Snooping section above.

Entries in the DHCP lease state table remain valid for the duration of the IP address lease. When a lease is renewed, the expiry time is updated. If the lease expires and is not renewed, the entry is removed from the DHCP lease state table.

For VPLS, DHCP snooping must be explicitly enabled (using the snoop command) on the SAP and/or SDP where DHCP messages requiring snooping ingress the VPLS instance. For IES interfaces and VPRN IP interfaces (VPRN is supported on the 7750 SR only), using the lease-populate command also enables DHCP snooping for the subnets defined under the IP interface. Lease state information is extracted from snooped or relayed DHCP ACK messages to populate DHCP lease state table entries for the SAP or IP interface.

For IES and VPRN services, if ARP populate is configured, no statics ARPs are allowed. For IES and VPRN services, if ARP populate is not configured, then statics ARPs are allowed.

The retained DHCP lease state information representing dynamic hosts can be used in a variety of ways:

  1. To populate a SAP based anti-spoof filter table to provide dynamic anti-spoof filtering — Anti-spoof filtering is only available on VPLS SAPs, or IES IP or VPRN IP interfaces terminated on a SAP.
  2. To populate a VPLS SAP-based arp-reply-agent table to provide dynamic ARP replies using the dynamic hosts IP assigned IP address and learned MAC address — ARP reply agent functionality is only available for static and dynamic hosts associated with a VPLS SAP. arp-reply-agent is supported on the 7450 ESS only.
  3. To populate the system’s ARP cache using the arp-populate feature — arp-populate functionality is only available for static and dynamic hosts associated with IES and VPRN SAP IP interfaces.
  4. To populate managed entries into a VPLS forwarding database — When a dynamic host’s MAC address is placed in the DHCP lease state table, it will automatically be populated into the VPLS forwarding database associated with the SAP on which the host is learned. The dynamic host MAC address will override any static MAC entries using the same MAC and prevent learning of the MAC on another interface (implicit MAC Pinning on the 7450 ESS). Existing static MAC entries with the same MAC address as the dynamic host are marked as inactive but not deleted. If all entries in the DHCP lease state associated with the MAC address are removed, the static MAC may be populated. New static MAC definitions for the VPLS instance can be created while a dynamic host exists associated with the static MAC address. To support the Routed CO model, see Routed Central Office (CO).
  5. To support enhanced Subscriber management, see section RADIUS Authentication of Subscriber Sessions.

Note that if the system is unable to execute any of these tasks, the DHCP ACK message is discarded without adding a new lease state entry or updating an existing lease state entry; and an alarm is generated.

DHCP and Layer 3 Aggregation

DHCPv4 Snooping

The default mode of operation for DHCP snooping is that the DHCP snooping agent instantiates a DHCP lease state based on information in the DHCP packet, the client IP address and the client hardware address.

The mode of operation can be changed for DHCP snooping so that the Layer 2 header MAC address is used instead of the client hardware address from the DHCP packet for the DHCP lease state instantiation. This mode is selected by enabling l2-header in the lease-populate configuration command at the DHCP level. Because SR-Series routers do not have the ability to verify the DHCP information (both the src-ip and src-mac of the packet will be those of the previous relay point) anti-spoofing must be performed at the access node prior to the SR-Series routers. This mode provides compatibility with MAC concentrator devices, and cable modem termination system (CMTS) and WiiMAX Access Controller (WAC).

A configuration example of a cable/wireless network together with subscriber management is shown in Figure 22. The subnet used to connect to the CMTS/WAC must be defined as a subnet in the subscriber interface of the Layer 3 CO model under which the hosts will be defined. This means that all subscriber lease states instantiated on BSR must be from a “local” subscriber-subnet, even if those are behind the router, as there will be no additional layer 3 route installed pointing to them.

The important items to notice are static hosts at the subscriber interface side:

  1. IP-only static host pointing to CMTS/WAC WAN link is needed to allow BSR to reply to ARP requests originated from CMTS/WAC.
  2. IP-MAC static host pointing to CMTS/WAC access-facing interface is required to provide BSR with an arp entry for the DHCP relay address.

When dual-homing is used the CMTS/WAC may be configured with the same MAC for both upstream interfaces. If that is not possible the BSR can be configured with an optional MAC address. The BSR will then use the configured MAC address when instantiating the DHCP lease states.

Figure 22:  CMTS/WAC Network Configuration Example 

DHCPv6 Snooping

Similar to DHCPv4, the subscriber interface SAP must be on the data path between the subscriber host and the DHCPv6 server. The SAP snoops the DHCPv6 message exchanged between the server and the client. An ESM host is created upon snooping a “reply” message from the DHCPv6 server.

DHCPv6 messages differ from a DHCPv4 messages because it is not mandatory to have the client MAC inside the header or options. The DUID in the DHCPv6 option can be a random generated number instead of the subscriber host’s MAC. The source MAC of the DHCPv6 Ethernet header cannot be used either, because a Layer 3 aggregation network will replace the client’s MAC via routing. From the perspective of the BNG, all DHCPv6 message from the same downstream router will have the same source MAC. By default, the BNG utilizes the DHCPv6 Ethernet header source MAC as a host entry identifier. Therefore, it is mandatory to use the interface-id in addition to the source MAC to identify a host individually. If the interface-id is unavailable, it is possible to use python to copy another unique ID, such as DUID or remote-id, into the interface id. The interface-id option must be on the same level as the relay-forward header. Together, the interface-id and the DHCP relay MAC address will be used as an identifier internally in the BNG.

If the interface-id option is on the subscriber native DHCP message (such as solicit), it is simply ignored.

The downstream router must resolve the BNG MAC before it is able to route traffic to the BNG. Traditionally, a BNG sends router advertisement to directly connected hosts to help them resolve their default gateway and MAC address. However, routers differ from hosts and neighbor advertisements are used to resolve the neighbor’s MAC instead. The downstream router has two options when programming the BNG as the next hop. It can either use the BNG subscriber interface link-local address or the subscriber interface GUA address. If an IPv6 prefix was configured on the BNG subscriber interface, then the downstream router must use the BNG link local as the next hop. If the subscriber interface is configured as an IPv6 address, then the downstream router can configure the GUA or the link-local as the next hop. In order to forward traffic bidirectionally, the downstream router interface MUST be modeled as a static host with both IP and MAC. IP-only static host is not supported.

The DHCP relay agent use one of its interface as a IP source address in the DHCP relay-forward message. The BNG forwards a DHCP relay-reply message from the DHCP server back to the relay agent using that exact same source IP address. There are restrictions for the IP source address used by the DHCP relay agent and it depends if the relay agent is a few hops way or is directly connected to the BNG. In the case where relay agent is a few hops away, the source address used by the relay agent must not fall under the subnet or prefix range configured on the subscriber interface. For example, the loopback or the egress interface address of the DHCP relay agent can be used instead. To forward the DHCP6 relay-forward message back to the relay agent, simply add a static route for the relay agent source IP address. The static route will have the static IPv6 host as the next hop. In the case where the relay agent is directly connected to the BNG, there are two options. In the first option, the IPv6 static host configured on the BNG is actually an interface on the relay agent. If the relay agent use this as the relay-forward source address, no additional configuration is required on the BNG to forward relay-reply back to the relay-agent. The other option is to use an interface address on the relay agent which does not fall under the subnet or prefix under the subscriber interface. Similar to the scenario where the relay-agent is a few hops away, a static route is required to forward the DHCP relay-reply message back to the relay agent. Again the static route must use the IPv6 static host as the next hop.

A default host is supported for IPv6 host as well. It is generally used as a failover mechanism where the host can continue to forward traffic without a host entry on the backup BNG.

For IPv6 ESM host, it is mandatory that each host have a unique /64 prefix. Service providers who wish to share the /64 prefix among multiple WAN host can utilize the DHCPv6 filter bypass-host-creation na” option. All bypass hosts in general require a default host creation as well.

While ESM hosts are subject to QoS and filters rules specified in sub-profile and sla-profile, default-host follows the QoS and filters specified directly on the subscriber SAP.

DHCP6 filters perform actions based on the options inside the relay-forward DHCP message. The options must be set on the innermost level, such as, DHCP solicit. The filter will ignore options set on relay-forward levels.

ESMv6 host created via DHCP snooping is not supported with the following:

  1. WLAN-GW
  2. DHCPv6 Proxy
  3. Wholesale/Retail
  4. SHCV
  5. L2-aware NAT
  6. GRT leaking/Extranet

Local DHCP Servers

Overview

The local-dhcp-server functions only if there is a relay (gateway) in front of it. Either a GI address is needed to find a subnet or Option 82, which is inserted by the relay, to perform authentication in the local-user-db.

A local DHCP server functions only if there is a relay agent (gateway) in front of it. The local DHCP server must be configured to assign addresses in one of the following ways:

  1. Use a local user database authentication (user-db local-user-db-name)
    The host is matched against the specified local user database. A successful user lookup should return information on one of the following valid addresses:
    1. A fixed IP address — The IP address should not overlap with the address ranges configured in the local dhcp server.
    2. A pool name — A free address of any subnet in that pool is offered.
    3. use-gi-address [scope <subnet | pool>] — The gi address is used to find a matching subnet. When scope is subnet, an address is allocated in the same subnet as the GI address only. When scope is pool, an address is allocated from any subnet within a local pool once that pool has been selected based on matching the “giaddr” field in the DHCP message with any of the configured subnets in the pool.
    4. use-pool-from-client — The pool name specified in the DHCP client message options and added by the DHCP relay agent is used. A free address of any subnet in that pool is offered.
    When no valid address information is returned from the local user database lookup, no IP address is offered to the client.
  2. without local user database authentication (no user-db)
    One or both address assignment options must be configured:
    1. Use a pool name (use-pool-from-client) The pool name specified in the DHCP client message options and added by the DHCP relay agent is used. A free address of any subnet in that pool is offered.
    2. Use the gi address (use-gi-address [scope <subnet | pool>]) The gi address is used to find a matching subnet. When scope is subnet, an address is allocated in the same subnet as the GI address only. When scope is pool, an address is allocated from any subnet within a local pool once that pool has been selected based on matching the “giaddr” field in the DHCP message with any of the configured subnets in the pool.

When both options are configured and a pool name is specified in the DHCP client message options, then the use-pool-from-client option has precedence over the use-gi-address option.

Note:

Note: The local DHCP server will not allocate any address if none of the above options are configured (no user-db, no use-gi-address, no use-pool-from-client).

Options and identification strings can be defined on several levels. In principle, these options are copied into the DHCP reply, but if the same option is defined several times, the following precedence is taken:

  1. user-db host options
  2. Subnet options
  3. Pool options
  4. From the client DHCP request.

A local DHCP server must be bound to a specified interface by referencing the server from that interface. The DHCP server will then be addressable by the IP address of that interface. A normal interface or a loopback interface can be used.

A DHCP client is defined by the MAC address and the circuit-id. This implies that for a certain combination of MAC and circuit-id, only one IP-address can be returned. If you ask 1 more, you get same address again. The same address will be returned if a re-request is made.

Typically, the DHCP server can be configured to perform as follows:

  1. • When a user-db is specified, a host lookup is performed in the local-user-db and the localuser-db host defines how to get the IP-address or pool to get the IP-address from:
    1. A fixed IP-address.
    2. A pool — A free address of any subnet in that pool is offered.
    3. use-pool-from-client — The pool name is taken from Option 82 vendor-specific suboption. (If not present, proceed to the next bullet.)
    4. use-gi-address — The gi-address is used to find a matching subnet.
  2. • If no IP-address, subnet, or pool is found in the first 2 bullets (above), no IP-address is offered to the client. If a subnet is found, an available address from the subnet is offered to the client. If a pool is found, an available address from any subnet of the pool is offered to the client.
Note:

When the no use-gi, no use-pool-from-client and no user-db commands are specified, the DHCP server does not act.

Local DHCP Server Support

Local DHCP servers provide a standards-based full DHCP server implementation which allows a service provider the option of decentralizing the IP address management into the network. Local DHCP servers are supported on 7750 SR-7, and 7750 SR-12 models. Note that the 7450 ESS-Series routers use DHCP relay and proxy DHCP server functionality.

Three applications are targeted for the local DHCP server:

  1. Subscriber aggregation in either a single node (routed CO) or TPSDA.
  2. Business services — A server can be defined in a VPRN service and associated with different interfaces. Locally attached hosts can get an address directly from the servers. Routed hosts will receive addresses through a relay point in the customer’s network. This option is supported for the 7750 SR only.
  3. PPP clients — Either in a single node or a separate PPPoE server node and a second DHCP server node. The PPPoE server node may be configured to query the DHCP server node for an address and options to provide to the PPPoE client. The PPPoE server will provide the information in PPP format to the client.

DHCP server scenarios include:

  1. DHCP servers can be integrated with Enhanced Subscriber Management (ESM) for DHCP clients, DHCP relays and PPPoE clients.
  2. A stand-alone DHCP server can support DHCP clients and DHCP relays.
  3. IPv4 is supported. DHCP servers provide increased management over the IPv4 address space across its subscriber base, with support for public and private addressing in the same router, including overlapped private addressing in the form of VPRNs in the same SR-series router.

DHCP servers are configurable and can be used in the bridged CO, routed CO, VPRN wholesaler, and dual-homing models.

DHCPv6

In the stateful auto-configuration model, hosts obtain interface addresses and/or configuration information and parameters from a server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful auto-configuration protocol allows hosts to obtain addresses, other configuration information or both from a server.

DHCPv6 Relay Agent

When the server unicast option is present in a DHCP message from the server, the option is stripped from the message before sending to the clients.

DHCPv6 Prefix Options

The prefix delegation options described in RFC 3633, IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6, provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. For example, the delegating router can get a /48 prefix via DHCPv6 and assign /64 prefixes to multiple requesting routers. Prefix delegation is supported for the delegating router (not the requesting router).

Neighbor Resolution via DHCPv6 Relay

This is similar to ARP populate for IPv4. When it is turned on, an SR router needs to populate the link-layer address to IPv6 address mapping into the neighbor database based on the DHCPv6 lease information received.

If the IPv6 address of the host doesn’t belong to the subnets of the interface, such a neighbor record should not be created. This could happen when there is a downstream DHCPv6 relay router or prefix delegation requesting router.

DHCPv6 Lease Persistency

DHCPv6 lease persistency is supported.

The following features are enabled:

  1. DHCPv6 lease information is reconciled to the standby.
  2. DHCPv6 lease information can be stored on a flash card.
  3. When rebooted, DHCPv6 lease information stored on a flash card can be used to re-populate the DHCPv6 table as well as the neighbor database if neighbor-resolution is enabled.

Local Proxy Neighbor Discovery

Local proxy neighbor discovery is similar to local proxy ARP. It is useful in the residential bridging environment where end users are not allowed to talk to each other directly.

When local proxy ND is turned on for an interface, the router:

  1. Responds to all neighbor solicitation messages received on the interface for IPv6 addresses in the subnet(s) unless disallowed by policy.
  2. Forwards traffic between hosts in the subnet(s) of the interface.
  3. Drops traffic between hosts if the link-layer address information for the IPv6 destination has not been learned.

IPv6oE Hosts Behind Bridged CPEs

This feature adds support for dual-stack IPoE hosts behind bridged clients, receiving globally-routable address using SLAAC or DHCPv6. The feature also provides configurable support for handing out /128 addresses to bridged hosts from same /64 prefix or a unique /64 prefix per host. Bridged hosts that share the same /64 prefix are required to be all SLAAC hosts or DHCPv6 hosts, and are required to be associated with the same SAP. For SLAAC based assignment, downstream neighbor-discovery is automatically enabled to resolve the assigned address.

IPv6 Link-Address Based Pool Selection

This feature provides the capability to select prefix pools for WAN or PD allocations based on configured Link-Address. The scope of selection is the pool or a prefix range within the pool.

IPv6 Address/Prefix Stickiness

This feature extends lease identification criterion beyond DUID (default) for DHCPv6 leases held in the lease database for a configured period after the lease times out. DHCPv6 leases can be held in the lease database for a configurable period of time, after the lease time has expired. A large configured timeout value allows for address and prefix “stickiness”. When a subscriber requests a lease via DHCPv6 (IA_NA or PD), existing lease is looked-up and handed out. The lease identification match criterion has been extended beyond DUID to also include interface-id or interface-id and link-local address.

IPv4/v6 Linkage for Dual-Stack Hosts or Layer 3 RGs

In case of dual-stack Layer 3 RGs or dual-stack hosts behind Layer 2 CPEs, it is beneficial to have the ability to optionally link Ipv6oE host management to DHCP state for v4. This feature provides configurable support to use circuit-id in DHCPv4 option-82 to authenticate DHCPv6. Also, a SLAAC host is created based on DHCPv4 authentication if RADIUS returns IPv6 framed-prefix. IPv6oE host is deleted when the linked IPv4oE host is deleted. In addition, with v4 and v6 linkage configured, sending of unsolicited unicast RA towards the client can be configured when v4 host state is created and IPv6 is configured for the client. The linkage between IPv4 and IPv6 is based on SAP and MAC address. The sharing of circuit-id from DHCPv4 for authentication of DHCPv6 (or SLAAC) allows the SR-series router to work around lack of support for LDRA on Access-nodes.

Host Connectivity Checks for IPv6

This feature provides support to perform SHCV checks on the global unicast address (assigned via SLAAC or DHCPv6 IA_NA) and link-local address of a L3 RG or a bridged host. SHCV uses IPv6 NS and NA messages. The configuration is similar to IPv4 support in SHCV. The host-connectivity-check command is extended to be configured for IPv6 or both IPv4 and IPv6.

Lease Query

A lease query by client-id as defined in RFC 5007, DHCPv6 Leasequery, is supported for Local DHCPv6 servers. For security reasons this must be explicitly enabled via the CLI flag allow-lease-query. The user identification option must be set to DUID (default value) for lease-query to work. Lease query by address is not supported. It is not possible to filter out leases with the link address, the server will always return all addresses for a client. The Relay Data and Client Link options are not supported and will not be returned.

DHCPv6 to Server Option

A DHCPv6-relay user-db can be configured on an IES or VPRN IP interface. This allows the insertion of a to-client and to-server option on the client's DHCPv6 message. The VPRN or IES IP interface must be the first relay agent for the subscriber. The interface must also have lease-populate enabled. The interface can store up to eight leases per DHCPv6 (relay) reply. If the interface contains both RADIUS and user-db, RADIUS will always take precedence. The to-client and to-server option will be inserted in the inner most level of the DHCPv6 packet.ESM IPoE subscriber can also utilize the user-db to insert to-server option. IPoE ESM subscribers are not limited to only to-client and to-server option, and can utilize all other parameters configurable under config>subscr-mgmt>loc-user-db>ipoe>host> in LUDB.

Flexible Host Identification in LUDB Based on DHCPv4/v6 Options

Host identification plays a critical role during the assignment of the parameters to the host via LUDB. The parameters that can be assigned to the subscriber host can range from the IP addressing parameters and the subscriber identification string all the way to the parameters that define the service to which the subscriber is entitled.

LUDB access in the context of IPoE hosts is triggered by DHCP messages passing through the interface on which the LUDB access is configured. This is true regardless of the direction of the DHCP message flow (ingress/egress).

The parameters that define the characteristics of the host will be represented by an LUDB host entry. The parameters in the LUDB entry can be unique for each individual host, or they can be shared for a group of hosts. In the former case, the identification field for the LUDB host entry must be host specific while in the latter case the identification field for LUDB host entry could be derived from DHCP options that are common to a set of host.

The host identification in the LUDB can be based on a fixed set of predefined fields within 7x50. If this predefined set of fields is not flexible enough, a custom identification field can be constructed from the DHCP options that are processed by the Python script. Once this custom identifier is constructed, its value can be preserved for the duration of the DHCP transaction and it is used by the LUDB for the host identification.

An example of how this can be used is the following:

A Python script is installed in 7x50. This Python script will intercept incoming DHCP messages on the access side (Discover/Solicit/Request/Renew/Rebind) and it will consequently create a host identification string based on DHCP options in the packet. This string will then be cached and used for host identification in LUDB in both directions (access ingress and network ingress).

This functionality is supported for DHCPv4/DHCPv6 hosts.

DHCP Caching

Subscriber host identification via LUDB is performed upon the arrival of the incoming DHCP messages on both, the access and the network side, while the host instantiation and ESM string assignment is performed only during the processing of the DHCP ACK/Reply messages. In other words, if Python without the caching is used for subscriber host identification and classification (into proper service class by means of deriving ESM strings), the DHCP options required for host identification must be present in all DHCP messages – even the ones sent by the DHCP servers. However, DHCP servers are not required to echo DHCP options sent by the clients and relay-agents. Consequently, the missing options from the server side would cause the subscriber host instantiation to fail.

To remedy this situation and cover all deployments models (even the ones where the DHCP options are not echoed back by the DHCP servers), a caching mechanism is introduced whereby the results of the Python processing on ingress access are locally stored in 7x50. This will ensure that the information about the subscriber host is readily available when the DHCP packet from the DHCP server arrives. Furthermore, since we already have the cached information, no additional Python processing on the network ingress is needed.

The caching is performed in a DHCP Transaction Cache (DTC), which is accessible to Python and to the EMS module. Python will write the result of its processing to it and the Enhanced Subscriber Management (EMS) module within 7x50 will be able to access those results.

The cache entries are relatively short lived, with the lifetime of a DHCP transaction. DHCP transaction is defined as a pair of DHCP messages that have the same DHCP transaction-id number (<Discover, Offer>, <Request, Ack>, <Solicit, Advertize>,<Request,Reply>, <Renew, Ack>, etc).

Flexible Creation of DHCPv4/6 Host Parameters Utilizing Python and Internal Caching

One of the facilities for flexible creation and assignment of subscriber host parameters is through Python scripting.

There are two models that allow assignment of the subscriber hosts parameters based on the Python processing, one without the utilizing the internal cache (DTC) and the other with the internal cache (DTC).

  1. Without utilizing the DTC, Python can process options in DHCP ACK message, derive the subscriber host parameters based on those options and consequently insert those parameters in a pre-configured DHCP option (defined in sub-ident-policy). The ESM module can be then instructed to extract those parameters and consequently instantiate the host with proper service levels. The drawback of this solution is that the DHCP server may not return all DHCP (v4 and v6) options that clients and relay-agents originally transmitted. Since those options are needed for subscriber parameter determination (but may be absent in the DHCP ACK/REPLY messages when the Python script is run), this solution falls short of covering all deployment cases. In addition, the range of parameters that can be assigned to a subscriber host in this fashion is smaller than the set of parameters utilizing the DTC.
  2. The internal cache (DTC) allows us to store the result of Python processing. The result is stored during the lifetime of the DHCP transaction. This method of string assignment does not rely on the DHCP server ability to return client’s options, DHCPv4 and DHCPv6.

Parameters (ESM strings, IP addresses, etc.) present in the DTC will have priority over any other source that is providing overlapping parameters when it comes to ESM processing. In other words, if the same parameter is provided via DTC (Python), LUDB and RADIUS, the one provided via DTC will be in effect. This prioritization will occur automatically without the need for any additional CLI.

For example, if the IPv4 address is provided via DTC during DHCP Discovery processing, then the mode of operation for this host will be proxy-to-dhcp (ESM will terminate DHCP, without going to the server), regardless of whether the IP address is also provided via LUDB or RADIUS.

This functionality is supported for DHCPv4/DHCPv6 hosts.

Python DTC Variables and API

The following are the Python variables and APIs related to DTC:

Subscriber Host Identification

alc.dtc.derivedId — A read/write (from the Python perspective) string to store the LUDB lookup key for subscriber host identification. This key is derived from the contents of the packet. This string will be used as a match criteria in LUDB. The derived-id can only be used when the lookup is performed in ESM. If the LUDB is attached to the local DHCP server, then the lookup based on the derived-id cannot be performed as the DHCP server has no means to derive such an ID from the DHCP message.

Caching Any Data During the Lifetime of a Transaction

alc.dtc.store(key,value) => the operator can store any data he desires in one or more entries. The key can be any arbitrary string (printable ASCII characters), up to 32 bytes in length. The value part is ‘unlimited’ (memory permitting) in size.

alc.dtc.retrieve(key) => retrieve data from the DTC. The key must be an existing key, which is a string consisting of printable ASCII characters, up to 32 bytes in length.

For example, this can be used to cache the DHCP options that the client inserts but the server does not echo back. Those options can still be retrieved in 7x50 via cache in case that their presence is needed for any reason.

The lifespan of the cached data is tied to a DHCP transaction (a pair or corresponding DHCP messages flowing in opposite direction).

ESM Related Parameters (ESM strings, routing context, etc.)

DTC provides an API to supply a subset of configuration parameters that can otherwise come from RADIUS and LUDB and are used by the ESM code to setup the subscriber host.

DTC parameters as defined below should NOT be considered as DHCP options that can be blindly returned to the DHCP client, but instead they should be considered as real configuration settings. For example, the lease-time option is used in LUDB to enforce the lease time for the client. As such, the ESM keeps state of the lease-time. The following parameters can be used to setup a subscriber host:

alc.dtc.setESM (key-from-below, value) => store data that is used by ESM. This data is write-only.  

The keys will be predefined (only these can be used) and are shown in Table 40. These keys are read-only static variables.

The LUDB column indicates the configuration option under the config>subscr-mgmt>loc-user-db>ipoe>host context in LUDB.

Table 40:  ESM-Related Python Variables   

DTC Variable

Type

LUDB

RADIUS Attribute

Comment

alc.dtc.subIdent

string

identification-strings >subscriber-id

Alc-Subsc-ID-Str

alc.dtc.subProfileString

string

identification-strings >sub-profile-string

Alc-Subsc-Prof-Str

alc.dtc.slaProfileString

string

identification-strings >sla-profile-string

Alc-SLA-Prof-Str

alc.dtc.ancpString

string

identification-strings >ancp-string

Alc-ANCP-Str

alc.dtc.appProfileString

string

identification-strings >app-profile-string

Alc-App-Prof-Str

alc.dtc.intDestId

string

identification-strings >inter-dest-id

Alc-Int-Dest-Id-Str

alc.dtc.catMapString

string

identification-strings >category-map-name

Alc-Credit-Control-

CategoryMap

alc.dtc.ipAddress

string

address

Framed-IPAddress

alc.dtc.dhcp4DefaultGateway

string

options>default-router

Alc-Default-

Router

alc.dtc.subnetMask

string

address

Framed-IPNetmask

alc.dtc.ipv4LeaseTime

integer

options>lease-time

Alc-Lease-Time

alc.dtc.ipv4PrimDns

string

options>dns-server

Alc-Primary-Dns

Client-DNS-Pri

alc.dtc.ipv4SecDns

string

NA

Alc-Secondary-

Dns

Client-DNS-Sec

alc.dtc.primNbns

string

options>netbios-name-server

Alc-Primary-Nbns

RB-Client-NBNSPri

alc.dtc.secNbns

string

NA

Alc-Secondary-

Nbns

RB-Client-NBNSSec

alc.dtc.msapGroupInterface

string

msap-defaults>group-interface

Alc-MSAP-Interface

alc.dtc.msapPolicy

string, integer

msap-defaults>policy

Alc-MSAP-Policy

alc.ServiceId

string, integer

msap-defaults>service

Alc-MSAP-Serv-Id

alc.dtc.retailServiceId

string

Retail-service-id

Alc-Retail-Serv-Id

alc.dtc.ipv6Address

string

ipv6-address

Alc-Ipv6-Address

alc.dtc.ipv6DelegatedPrefix

string

ipv6-delegated-prefix

Delegated-IPv6-

Prefix

alc.dtc.ipv6SlaacPrefix

string

ipv6-slaac-prefix

Framed-IPv6-

Prefix

alc.dtc.ipv6WanPool

string

ipv6-slaac-prefix-pool

Framed-IPv6-Pool

alc.dtc.ipv6PrefixPool

string

ipv6-delegated-prefix-pool

Alc-Delegated-

IPv6-Pool

alc.dtc.ipv6DelegatedPrefixLength

integer

ipv6-delegated-prefix-len

Alc-Delegated-

IPv6-Prefix-

Length

alc.dtc.accountingPolicy

string

acct-policy

N/A

alc.dtc.dhcpv4GIAddr

string

gi-address

N/A

alc.dtc.dhcv4ServerAddress

string

server

N/A

alc.dtc.dhcp4Pool

string

address>pool

Framed-Pool

Ip-Address-Pool-

Name

prim | sec (“|” – delimiter)

alc.dtc.linkAddress

string

link-address

N/A

alc.dtc.dhcv6ServerAddr

string

server6

N/A

alc.dtc.ipv6PrimDns

string

options6>dns-server

Alc-Ipv6-Primary-

Dns

alc.dtc.ipv6SecDns

string

NA

Alc-Ipv6-

Secondary-Dns

For example, an IP address is assigned to a DTC variable as a string:

alc.dtc.ipAddress = “192.168.0.10” — This is performed through the following ALU API: alc.dtc.setESM(alc.dtc.ipAddress,’192.168.0.10’). The DTC logic then parses this variable and converts it into appropriate format for consumption by ESM code.

The values defined above are the ones that are mostly defined in the LUDB. Main use, however, is assigning ESM strings for the subscriber host instantiation phase during the processing of DHCP ACK/Reply messages. Consequently the Python script needs to be run only on DHCP Request messages (no need to run it on Discoveries for ESM string assignment, unless the LUDB derived-id is also needed).

DHCP options that are blindly returned to the DHCP client without the ESM code being aware of them cannot be configured via DTC. Such options should be configured via RADIUS (Alc-ToCLient-Dhcp-Options – IPv4 only) or they can be inserted directly into DHCP messages via Python (bypassing DTC).

Other possible uses for DTC variables are:

  1. Assigning routing context information via Python (service-id, msap, msap-policy, retail service-id, etc). For example AN can insert certain ‘hints’ in various DHCP options that would suggest to us (via Python) in which service context to place the subscriber-host.
  2. IP address assignment via Python (DTC). This would address the DTC-to-DHCP-Proxy case where Python script is invoked on DHCP Discovery/Solicit. For example:
    1. Discover arrives
    2. Python generates an IP address, for example based on some DHCP options
    3. The script stores the IP address by using alc.dtc.setEsm(alc.dtc.ipAddress, "10.0.1.2");
    4. After the script is finished, ESM starts processing the packet (no LUDB/RADIUS authentication configured)
    5. ESM finds the IP address already in DTC and decides to handle all DHCP and execute proxy function instead of relay
    6. ESM sends an offer with the address that python generated
    7. DHCP options should be provided as well in this case (lease-times, etc.)
    8. The same applies to the DHCP Request

DTC Debugging Facility

DTC debugging is part of the generic DHCP debugging facility that is enabled by the flowing commands:

debug router <router-id> ip dhcp --> Enable DHCP debug on Layer 3 interfaces, including subscriber-interfaces.

debug service id <service-id> dhcp --> Enable DHCP debugging on capture SAP.

If the DTC cache is populated via Python, the corresponding DTC entries will be shown as part of the matching DHCP message debug.

Virtual Subnet for DHCPv4 Hosts

The virtual-subnet command in the sub-if>dhcp context allows the system to snoop and record the default router address in DHCP ACK messages for a DHCPv4 ESM host. The system can answer ping or traceroute request even if the default router address is not configured on the subscriber-interface.

This feature eliminates the need to configure every default-gw address on subscriber interface.

Beside default router address, the system will also calculate host’s subnet by using an assigned address and the subnet mask option in ACK. Both recorded default router address and the subnet can be displayed with the show service id virtual-subnet command.

Every ESM subscriber only has one set of default router address and subnet.

Address Reservation for Sticky Leases

Address reservation for sticky leases adds support in local DHCP servers to provide IP address reservation for the assignment of sticky leases. These leases are pre-provisioned in the server (via SNMP or CLI) with a given set of user-identification parameters. This set of parameters must be unique for each pool to avoid duplicate leases. For management purposes, these leases also have an additional hostname parameter to easily retrieve them via SNMP. When a sticky lease is created, the corresponding requested IP address is allocated from the specified pool and this address afterwards can only be used by DHCP if they match the specified user identification parameters. It is not possible to make an existing DHCP lease sticky.

Sticky leases are persistent but not synchronized in multi-chassis synchronization. To support multi-chassis redundancy, a management system can allocate the lease on one 7750 SR, immediately retrieve the lease and populate it again on the redundant router. For this to work sticky leases should not be combined with any other allocation method (for example, regular DHCP leases, or Local Address Assignment because these methods can already allocate the address on the standby node).

This feature targets two scenarios

  1. Simplified IP address reservation. It is not necessary to provision LUDB entries and exclude ranges for sticky leases. Once the lease is reserved in the local DHCP server (triggered by an external system via SNMP or CLI), the external system can then subsequently assign the corresponding IP address to a DHCP client that matches the configured lease. A use case of this related to virtual residential gateway (vRGW) application and is described in the vRGW section.
  2. Pool management without DHCP. In pure management cases, this provides an easy method to perform pool management without implementing DHCP-specific configurations. For example, a management platform can allocate an IP address from a pool via the sticky lease mechanism and then assign this to a static host without risking overlap.

Proxy DHCP Server

This section describes the implementation of a proxy DHCP server capability provide a standards- based DHCP server which will front end to downstream DHCP client and DHCP relay enabled devices and interface with RADIUS to authenticate the IP host and subscriber and will obtain the IP configuration information for DHCP client devices.

The proxy DHCP server is located between an upstream DHCP server and downstream DHCP clients and relay agents when RADIUS is not used to provide client IP information.

Service providers can introduce DHCP into their networks without the need to change back-end subscriber management systems that are typically based around RADIUS (AAA). Service providers can support the use of DHCP servers and RADIUS AAA servers concurrently to provide IP information for subscriber IP devices.

Figure 23:  Typical DHCP Deployment Scenarios 

DHCP is the predominant client-to-server based protocol used to request IP addressing and necessary information to allow an IP host device to connect to the network.

By implementing DHCP, the complexity of manually configuring every IP device that requires connectivity to the network is avoided. IP devices with DHCP can dynamically request the appropriate IP information to enable network access.

DHCP defines three components that are implemented in a variety of device types:

  1. The DHCP client allows an IP device (host) to request IP addressing information from a DHCP server to enable access to IP based networks. This is typically found in:
    1. End user notebooks, desktops and servers
    2. Residential gateways and CPE routers
    3. IP phones
    4. Set-top boxes
    5. Wireless access points
  2. The DHCP relay agent passes (relays) DHCP client messages to pre-configured DHCP servers where a DHCP server is not on the same subnet as the IP host. This feature optionally adds information into DHCP messages (Option 82) which is typically used for identifying attaching IP devices and their location as part of subscriber management. This is typically found in:
    1. Residential gateways and CPE routers
    2. DSLAMs
    3. Edge aggregation routers
  3. The DHCP server receives DHCP client messages and is responsible for inspecting the information within the messages and determining what IP information if any is to be provided to a DHCP client to allow network access. This is typically found in:
    1. Dedicated stand alone servers
    2. Residential gateways and CPE routers
    3. Edge aggregation routers
    4. Centralized management systems

DHCP is the predominant address management protocol in the enterprise community, however in the provider market PPP has traditionally been the means by which individual subscribers are identified, authenticated and provided IP addressing information.

The use of DHCP in the provider market is a growing trend for managing subscriber IP addressing, as well as supporting newer devices such as IP-enabled IP phones and set-top boxes. The majority of subscriber management systems rely heavily on RADIUS (RFC 2865, Remote Authentication Dial In User Service (RADIUS)) as the means for identifying and authorizing individual subscribers (and devices), deciding whether they will be allowed access to the network, and which policies should be put in place to control what the subscriber can do within network.

The proxy DHCP server capability enables the deployment of DHCP into a provider network, by acting as a proxy between the downstream DHCP devices and the upstream RADIUS based subscriber management system.

  1. Interact with downstream DHCP client devices and DHCP relay Agents in the path
  2. Interface with RADIUS to authenticate DHCP requests
  3. Receive all the necessary IP information to properly respond to a DHCP client
  4. Ability to override the allocate IP address lease time, for improved IP address management.
Figure 24:  Example of Triple Play Aggregation Network With DHCP to RADIUS Authentication 

Figure 24 displays a typical DHCP initial boot-up sequence with the addition of RADIUS authentication. The proxy DHCP server will interface with downstream DHCP client devices and then authenticate upstream using RADIUS to a providers subscriber management system.

In addition to granting the authentication of DHCP hosts, the RADIUS server can include RADIUS attributes (standard and vendor-specific attributes (VSAs)) which are then used by the edge router to:

  1. Provision objects related to a given DHCP host — Subscriber and SLA policy
  2. Provide IP addressing information to a DHCP client
  3. Support the features that leverage DHCP lease state
    1. Dynamic ARP population
    2. ARP reply agent
    3. Anti-spoofing filters
    4. MAC pinning
  4. Leverage host-connectivity-verify to determine the state of a downstream IP host

This feature offers the ability for a customer to integrate DHCP to the subscriber while maintaining their existing subscriber management system typically based around RADIUS. This provides the opportunity to control shifts to an all DHCP environment or to deploy a mixed DHCP and RADIUS subscriber management system.

In order to maximize its applicability VSAs of legacy BRAS vendors can be accepted so that a network provider is not forced to reconfigure its RADIUS databases (or at least with minimal changes).

To receive data from the RADIUS server the following are supported:

  1. Juniper (vendor-id 4874) attributes 4 (Primary DNS server) and 5 (Secondary DNS server)
  2. Redback (vendor-id 2352) attributes 1 (Primary DNS) and 2 (Secondary DNS).
  3. Juniper attributes 6 and 7 (Primary and Secondary NetBIOS nameserver).
  4. Redback attributes 99 and 100 (Primary and Secondary NetBIOS nameserver).

The following attributes can be sent to RADIUS:

  1. Sending authentication requests: (from the DSL Forum) (vendor-id 3561), attributes 1 (Circuit ID) and 2 (Remote ID).
  2. DSL Forum attributes 129 and 130 (Actual Data Rate Upstream and Downstream), 131 and 132 (Minimum Data Rate Upstream and Downstream) and 144 (Access Loop Encapsulation).

The complete list of TiMetra VSAs is available on a file included on the compact flash shipped with the image.

Local DHCP Servers

Terminology

  1. Local 7x50 DHCP Server – DHCP server instantiated on the local 7x50 node.
  2. Remote 7x50 DHCP Server – DHCP server instantiated on the remote 7x50 node (external to the local 7x50 node).
  3. 3rd party DHCP server – DHCP server external to any 7x50 node and implemented outside of 7x50.
  4. Intercommunication link – the logical link between dual-homed 7x50 DHCP servers used for synchronizing DHCP lease states. Multi-chassis Synchronization (MCS) protocol runs over this link. Once this link is interrupted, synchronization of the leases between redundant DHCP servers is impaired. This link should be well protected with multiple underlying physical paths.
  5. Local IP address-range/prefix – refers to the local failover mode in which the IP address-range/prefix is configured in dual-homed DHCP environment. The local keyword does not refer to the locality (local vs remote) of the server on which the IP address-range/prefix in configured, but rather refers to the ownership of the IP address-range/prefix. The DHCP server on which the local IP address-range/prefix is configured, owns this IP address-range/prefix and consequently is allowed to delegate the IP addresses/prefixes from it at any time, regardless of the state of the intercommunication link.
  6. Remote IP address-range/prefix – refers to the remote failover mode in which the IP address-range/prefix is configured in dual-homed DHCP environment. The remote keyword does not refer to the locality of the server on which the IP address-range/prefix is configured, but rather refers to the ownership of the IP address-range/prefix. The DHCP server on which the remote IP address-range/prefix is configured, but does not own this IP address-range/prefix during normal operation and consequently is NOT allowed to delegate the IP addresses/prefixes from it. Only when the intercommunication link between the two nodes transition into particular (failed) state, the DHCP server is allowed to start delegating new IP addresses from the remote IP address-range/prefix.
  7. IP address-range/prefix ownership – 7x50 DHCP server can delegate new leases from an IP address-range/prefix that it owns. For example, an IP address-range/prefix designated as remote is not owned by the DHCP server on which it is configured unless certain conditions are met. Those conditions are governed by the state of the intercommunication link.
  8. IP address-range/prefix takeover – a 7x50 DHCP server that does not own an IP address-range/prefix can take over the ownership of this IP address-range/prefix under certain conditions. Once the ownership is taken, the new IP addresses can start being delegated from this IP address-range/prefix. Only the remote IP address-range/prefix can be taken over. Note that the takeover of an IP address-range/prefix has only local significance – in other words, the ownership is not taken away from some other 7x50 DHCP server that has the same IP address-range/prefix designated as local. It only means that IP address-range/prefix that is configured as remote is available to takeover for new IP address delegation.
  9. Local PPPoX Address Pools – this term refers to the method of accessing an IPv4/v6 address pool in 7x50 DHCP4/6 server. For PPPoX clients, the IPv4/v6 addresses are allocated from those pools without the need for an intermediate DHCP relay-agent (7x50 internal DHCP relay-agent). Although those pools are part of the local DHCP server in 7x50, the method of accessing them is substantially different than accessing local DHCP address pools for IPoE (DHCP) clients. IPoE (DHCP) and PPPoX hosts can share the same pool and yet each client type can access them in their own unique way:
    1. IPoE client via DHCP messaging
    2. PPPoE via internal API calls
  10. Local PPPoX Pool Management – IPv4 address allocation/management for PPPoX clients independent of DHCP process (DHCP lease state). An IPv4 address allocated via local PPPoX Pool Management is tied to the PPPoX session. It is without the need for an 7x50 internal DHCP relay-agent.

Overview

7x50 DHCP server multi-homing will ensure continuity of IP address/prefix assignment/renewal process in case that an entire 7x50 DHCP server fails or in case of a failure of the active link that connects clients to one of the 7x50 DHCP servers in the access part of the network. DHCP server multi-homing is an integral part of the overall subscriber management multi-chassis protection scheme.

DHCP server multi-homing can be implemented outside of the BNG, without subscriber management enabled. However, in the following text, it is assumed that the subscriber management multi-homing (SRRP/MC-LAG, subscriber synchronization) is deployed along with DHCP server multi-homing.

Although the subscriber synchronization process and the DHCP lease states synchronization process use the same synchronization infrastructure within 7x50 (Multi Chassis Redundancy protocol), they are in essence two separate processes that are not aware of each other. As such, the mechanisms that drive their switchover are different. For example, the mechanism that drives subscriber switchover from one node to the other is driven by the access protection mechanism (SRRP/MC-LAG) while the switchover (or takeover) of the IP address-range/prefixes in a DHCP pool is driven by the state of the intercommunication link over which the leases are synchronized. The failure of an entire node makes those differences irrelevant since the access-link failure coincides with the intercommunication link failure and vice versa. However, link-only failures become critical when it comes to their interpretation by the protection mechanisms (SRRP/MC-LAG/DHCP server multi-homing). Regardless of nature of the failure, overall DHCP server multi-chassis protection scheme must be devised in such fashion that the two 7x50 DHCP servers never allocate the same IP address/prefix to two different clients. Otherwise IP address/prefix duplication will ensue. Unique IP address/prefix allocation is achieved by making only one 7x50 DHCP server responsible for IP address/prefix delegation out of the shared IP address-range/prefix.

There are two basic models for DHCP server dual-homing:

  1. Shared IP address-range/prefix is designated as local on one 7x50 DHCP server and as remote on the other.
    In this case, the dhcp-relays must point to both DHCP servers; the one configured with the local IP address-range/prefix as well as the one with the remote IP address-range/prefix.
    Under normal circumstances, the new IP addresses/prefixes can be only allocated from the DHCP server configured with the local IP address-range/prefix.
    The DHCP server configured with the remote IP address-range/prefix will start delegating new lease from it only when it declares that the redundant peer with the local IP address-range/prefix becomes unavailable.
    Detection of the peer unavailability is triggered by the failure of the intercommunication link which can be caused either by the nodal failure or simply by the loss of connectivity between the two nodes protecting each other. Thus, the loss of intercommunication link does not necessarily mean that the peering node is truly gone. It can simply mean that the two nodes became isolated and unable to synchronize their DHCP leases between each other. In such environment, both nodes can potentially allocate the same IP address at the same time. To prevent this, additional intercommunication link states and associated timers are introduced to give the chance the operator ample time to fix the problem.
    For example, the DHCP server will take over the remote IP address-range/prefix once the MCLT period expires while the intercommunication link is in PARTNER-DOWN state. The PARTNER-DOWN state is entered after a preconfigured timer (partner-down-delay) expires. The consequence of these two additional timers (partner-down-delay and MCLT) is that the new IP address delegation from the remote (shared) IP address-range/prefix will not be possible until the preset timers expire. This is needed and justified in case that the intercommunication link is interrupted, the nodes become isolated and consequently the DHCP lease state synchronization becomes impaired. On the other hand, if the DHCP server with local IP address-range/prefix becomes truly unavailable, those additional restoration times will cause interruption in service since the new IP addresses from the remote IP address-range/prefix will not be immediately available for delegation.
    Note that only new IP address delegation from the remote IP address-range/prefix is affected by this behavior. The existing IP leases can be extended on both nodes at any time irrespective of whether the configured address-range/prefix is designated as local or remote.
    To ensure uninterrupted service even for new lease delegation in this model (local-remote), two approaches can be adopted:
    1. Segment the IP address/prefix space so that each node has an IP address-range/prefix designated as local. For example, instead of designating IP address-range 10.10.10.0/24 as local on DHCP server A and as remote on DHCP server B, the 10.10.10./24 IP address will be split into two: 10.10.10.0/25 and 10.10.10.128/25. The 10.10.10.0/25 would be designated as local on the DHCP server A and as remote on DHCP server B. The 10.10.10.128/25 would be designated as remote on the DHCP server A and as local on DHCP server B. In this fashion, one node will always be available to assign new leases without any overlap.
    2. In case that only one shared IP address-rage/prefix is deployed, the operator can bypass the timers (partner-down-delay and MCLT) that are put in place in case that DHCP server nodes become isolated. This bypass of the timers can be achieved via configuration. In this case, a safe operation is warranted only if the operator is certain that the intercommunication link failure will be caused by the nodal failure, and not the physical link failure between the two nodes.
  2. Shared IP address-range/prefix is designated as access-driven on both 7x50 DHCP servers.
    In this scenario, the shared IP address-range/prefix is owned by both nodes and the ownership is not driven by the state of the intercommunication link.
    To avoid IP address duplication, only one DHCP server at any given time must be responsible for IP address assignment from this shared IP address-range/prefix.
    This will be ensured by the access protection mechanism (SRRP/MC-LAG) that will provide a single active path from the clients to the one of the DHCP servers.
    In case that clients have access to the same IP address-range/prefix on both DHCP servers at the same time, the IP address duplication may occur.
    Consider the following case:
    Two DHCP clients send DHCP Discovers in the following fashion:
    1. DHCP client A sends DHCP Discover to the DHCP server A
    2. DHCP client B sends DHCP Discover to the DHCP server B
    3. DHCP server A assigns IP address 10.10.10.10 to the DHCP client A
    4. DHCP server B assigns IP address 10.10.10.10 to the DHCP client B
    5. This is a legitimate scenario since the DHCP lease states are not synchronized until the DHCP lease assignment is completed.
    6. Just before the DHCP ACK is sent to the respective clients from both nodes, the DHCP lease sync messages are exchanged between the peers.
    7. DHCP servers do not wait for the reply to the sync message before they send the DHCP Ack to the client.
    8. Once the DHCP syn message is received from the peer, the DHCP server will realize that the IP lease already exist. In this case, the newer IP lease will override the older.
    9. The result is that clients A and B use the same IP address and consequently the forwarding of the traffic will be impaired.
    In access-driven model, the ESM subscriber host must be collocated with the DHCP server. In other words, the DHCP server must be instantiated in redundant BNGs. The dhcp-relays must point to the respective local 7x50 DHCP servers. There must be no cross-referencing of DHCP servers in this model. In addition, the IP address that the DHCP servers are associated with, must be the same on both DHCP servers. This is necessary to ensure uninterrupted service levels once the switchover in the access occurs.
    For example:
    1. DHCP server A on BNG A is associated with the IP address 1.1.1.1 (for example loopback interface A on BNG A)
    2. DHCP server B on the peering BNG B is associated with the IP address 1.1.1.1 (configured in BNG B under loopback interface B)
    3. Dhcp-relay on BNG A points to the IP address 1.1.1.1—DHCP server in BNG A
    4. Dhcp-relay on BNG B points to the IP address 1.1.1.1—DHCP server in BNG B.

Consider the following when contemplating deployment of the two described models:

  1. Local-remote model is agnostic of the access protection mechanism. In fact, the access protection mechanism is not needed at all for safe operation.
    Fast takeover of the single shared (remote) IP address-range/prefix can be provided only in cases where the operator can guarantee that the intercommunication link failure is caused by the nodal failure (entire DHCP server node becomes unavailable). Fast takeover is provided by bypassing the partner-down-timer and MCLT.
    In case that multiple IP address-ranges/prefixes are deployed, bypass of the timers is not needed since the local IP address-ranges/prefixes are available on both nodes.
  2. Access-driven model allows a single IP address-range/prefix to be shared across the redundant DHCP server nodes. The access to the single DHCP server node from the client side is ensured by the protection mechanism deployed in the access part of the network (SRRP or MC-LAG).

DHCP Lease Synchronization

DHCP server leases are synchronized over Multi-Chassis Synchronization (MCS) protocol. A DHCP lease synchronization message is sent to the peering node just before the DHCP ACK/Reply is sent to the client.

For example, the message flow for DHCPv4 lease establishment is the following:

DHCP Discover

; DHCP client — DHCP server

DHCP Offer

; DHCP server — DHCP client

DHCP Request

; DHCP client — DHCP server

DHCP Sync Message

; DHCP server — via MCS to the peering DHCP server

DHCP Ack

; DHCP server— DHCP client

DHCP server failover mechanism in the local-remote IP address-range/prefix model relies on the detection of the failure of the link over which DHCP states are synchronized (via MCS protocol). This link is normally disjoint from the access links towards the clients. MCS protocol normally runs over a direct link between the two redundant nodes (1) or over backbone links (2) in case that the direct link is not present.

Figure 25:  Redundancy Model 

In the access-driven IP address-range/prefix model, the DHCP server address-ranges/prefixes are not tied to the state of the intercommunication link. Instead, the DHCP server selection for IP address assignment is only governed by the path selected by the path protection mechanism (SRRP/MC-LAG) deployed in the access part of the network.

Intercommunication Link Failure Detection

7x50 DHCP Server is a client of Multi-chassis Synchronization (MCS) application with 7x50. Once MCS transitions into out-of-sync state, the 7750 DHCP server redundancy assumes that there is a failure in the network. In essence, the DHCP server failure in dual-chassis configuration relies on the failure detection mechanism of MCS.

MCS runs over TCP, port 45067 and it is using either data traffic or keepalives to detect failure on the communication link between the two nodes. In the absence of any MCS data traffic for more than 0.5sec, MCS will send its own keepalive to the peer. If a reply is NOT received within 3sec, MCS will declare its operational state as DOWN and the DB Sync state as out-of-sync. MCS will consequently notify its clients (DHCP Server being one of them) of this condition.

In essence, it can take up to 3 seconds before the DHCP client realizes that the interclasses communication link failed.

MCS Clients (applications) can optimally send their own proprietary keepalive messages to its partner over MCS to detect failure. DHCP Server does not utilize this method and it strictly relies on the failure notifications by MCS.

Note that the intercommunication link failure does not necessarily assume the same failed fate for the access links. In other words, it is perfectly possible (although unlikely) that both access links are operational while the inter-chassis communication link is broken.

The failure detection of the intercommunication link will lead to certain failover state transitions on the DHCP server. The DHCP lease handling in the local-remote model will depend on the particular failover state on the DHCP server and the duration of each failover state is determined by preconfigured timers.

DHCP Server Failover States

DHCP Server when paired in redundant fashion can transition through several states:

  1. TRANSITION
  2. SHUTDOWN
  3. INIT
  4. STARTUP
  5. NORMAL – In this state, the 7x50 DHCP Server is serving all IP leases from the local and access-driven IP addresses-ranges/prefixes (assigning new leases and extending existing ones). Remote IP addresses-ranges/prefixes are not served (new or existing ones).
  6. COMMUNICATION INTERUPTED – IP addresses/prefixes under the local and access-driven IP address-range/prefix are served in the same fashion as in the NORMAL state. The IP addresses/prefixes under the remote IP address-range/prefix will be renewed. However, the new address/prefix from the remote address-range/prefix will not be allocated until the partner-down timer expires, the failover state consequently transitions into PARTNER DOWN and the MCLT timer while in the PARTNER-DOWN state expires. This is necessary in case that the failure occurred only on the intercommunication link while the access link is still operational (DHCP server nodes become isolated).
    COMMUNICATION INTERUPTED state indicates that there is a failure of some kind, but it cannot be determined whether an entire node failed or only the inter-chassis link. The access layer may still be fully operational, but the new leases (including RENEWS/REBINDS) cannot be synchronized between the two peers.
  7. PARTNER DOWN – Once the DHCP Server reaches this state, the remote IP address-range/prefix is taken over and after an additional time period of MCLT (Maximum Client Lead Time), the new IP addresses/prefixes from it can be delegated to clients. PARTNER-DOWN state is an indication (and assumption at the same time) that the remote node is truly down.
    Otherwise, the IP address duplication may occur in case that all of the following conditions are met:
    1. the DHCP server nodes become isolated
    2. the failover state is PARTNER-DOWN
    3. DHCP/PPPoX clients have simultaneous access to the same IP address-range/prefix on the both DHCP servers.

Lease Time Synchronization

7x50 DHCP server state synchronization is different from the lease state synchronization of the subscriber host itself.

  1. Each subscriber host lease state is synchronized via sub-mgmt client application. The host lease state can be seen via the output of following CLI command:
    show service id id dhcp lease-state
    The output of this command represents the state of our internal DHCP relay (client).
  2. On the other hand, the DHCP server lease states can be observed via the following CLI command:
    show routed id dhcp local-dhcp-server name lease

The concern is with the latter, the 7x50 DHCP server lease state synchronization. To ensure un-interrupted IP lease renewal process after a failure in the network, the DHCP server lease time that is synchronized between the 7x50 DHCP servers must always lead the currently assigned lease time for the period of the anticipated lease time in the next period.

For comparison purposes the two flow diagrams are juxtaposed in Figure 26:

  1. The right side does not include any lead time during synchronization
  2. The left side includes the lead time during synchronization
    Figure 26:  Potential Expiration Time 

On the left side of the graph, the lease time is synchronized to the same value to which it was renewed.

In point 3, the primary DHCP server renews the lease time but fails to synchronize it due to its own failure (crash). The secondary server (2) has the old lease time A’ in its database. The next time the client tries to REBIND its address/prefix, the lease in the secondary server will be expired (4). As a result, the IP address/prefix will not be renewed.

To remedy this situation, the primary server must synchronize the lease time as the current RENEW time + the next lease-time. In this fashion, as depicted in point 3, when the REBIND reaches server 2, the lease in its DB will still be active (4) and the server 2 will be able to extend the lease for the client.

Maximum Client Lead Time (MCLT)

Maximum Client Lead Time (MCLT) is the maximum time that the 7x50 DHCP Server can extend the lease time to its clients beyond the lease time currently know by the 7x50 DHCP partner node. By default this time is relatively short (10min).

The purpose of the MCLT is explained in the following scenario:

The local 7x50 DHCP server assigns a new IP lease to the client but it crashes before it sends a sync update to the partner server. Because of the local 7x50 DHCP server failure, the remote 7x50 DHCP server is not aware of the IP address/prefix that has been allocated on the local 7x50 DHCP server. This condition creates the possibility that the remote 7x50 DHCP server allocates the same address/prefix to another client. This would cause IP address/prefix duplication. MCLT is put in place to prevent this scenario.

MCLT based solution is shown in Figure 27.

Figure 27:  Address/Prefix Allocation without Synchronization 

The sequence of events is the following:

  1. 7x50 DHCP Server 1 is the local DHCP server (with the local address-range/prefix) that creates the IP lease state for a new client. The initial lease-time assigned to the client is MCLT which is normally shorter than the requested lease time. This 7x50 DHCP server fails before it gets a chance to synchronize the lease state with the 7x50 DHCP Server 2 (remote 7x50 DHCP server with the remote address-range/prefix).
  2. The remote 7x50 DHCP server transitions into the PARTNER-DOWN state (assuming that the partner-down timer is 0). In this state the remote 7x50 DHCP server can extend the lease time to the existing clients but it can NOT assign a new lease for a period of MCLT. In MCLT/2 a new RENEW request is sent directly to the local 7x50 DHCP server. This server is DOWN and therefore it cannot reply.
  3. The client broadcasts a REBIND request that reaches the remote 7x50 DHCP server. The remote 7x50 DHCP server has no knowledge of the requested lease and therefore it does not reply.
  4. The lease for the client will expire and the client will have to reinitiate the IP address/prefix assignment process.

Since the remote 7x50 DHCP server is not aware of the lease state that was assigned by the local 7x50 DHCP server, there is a chance that the remote 7x50 DHCP server assigns to the new client the same IP address/prefix already allocated by the local 7x50 DHCP server just before it crashed. This is why the remote 7x50 DHCP server needs to wait for the MCLT time to expire so that the IP addresses/prefixes allocated (but never synchronized) by the local 7x50 DHCP server can time out.

When the communication channel between the chassis is interrupted, two scenarios are possible:

  1. The entire node becomes unavailable. In this case the redundant node takes over and it starts reducing the lease time until the lease time reaches MCLT.
    1. COMMUNICATION-INTERUPTED
      The remote 7x50 DHCP server only renews the leases but does not delegate new ones (primary is DOWN).
      The local 7x50 DHCP server renews the leases (which eventually trickle down to MCLT) and delegates the new ones with the lease time of MCLT (secondary is down).
    2. PARTNER-DOWN
      The remote 7x50 DHCP server starts delegating new IP addresses/prefixes from the remote address-range/prefix after MCLT (primary is down). The lease time of the new clients is MCLT. A lease cannot be assigned for a period longer than what is agreed with the peer incremented with the MCLT. As for a “new” lease nothing is agreed yet so the sum falls back to the MCLT itself.
  2. The communication channel is down but the remote 7x50 DHCP server is not (meaning that the clients have still access to both servers). The behavior in this case is following:
    1. COMMUNNICATION-INTERUPTED
      The remote 7x50 DHCP server keeps renewing existing leases but it does not delegate the new leases. The chances that this will happen are low as the clients will keep sending RENEWS via unicast to the local 7x50 DHCP server which is still active. The non-synched leases in the remote 7x50 DHCP server will time out. The local 7x50 DHCP server will start trickling down the lease time to MCLT.
      The local 7x50 DHCP server will keep delegating the new leases, although with the MCLT lease time.
    2. PARTNER-DOWN State
      The local 7x50 DHCP server will keep extending the existing leases but it will also start delegating new IP leases once the initial MCLT elapses.
      Note that both local and remote 7x50 DHCP server will delegate new leases in PARTNER-DOWN state (although the remote 7x50 DHCP server in PARTNER-DOWN state will have to wait an additional MCLT period before it can start delegating new leases).

Sharing IPv4 Address-Range or IPv6 Prefix Between Redundant 7x50 DHCP Servers in Access-Driven Mode

Access-driven DHCP server redundancy model will ensure uninterrupted IP address assignment service from a single IP address-range/prefix in case that an access link forwards BNG fails. To avoid duplicate address allocation, there MUST be a single active path available from the clients to only one of the 7x50 DHCP servers in redundant configuration. This single active path is ensured via a protection mechanism in dual-homed environment in the access side of the network. The supported protection mechanisms in the access in 7x50 are SRRP or MC-LAG.

In access-driven DHCP redundancy model, the DHCP relay in each 7x50 node must point only to the IP address of the local DHCP server. In other words, the DHCP messages received on one DHCP server should never be relayed to the other. Since the IP address-ranges/prefixes are shared between the DHCP servers, accessing both DHCP servers with the same DHCP request can cause DHCP lease duplication. Moreover, the IP addresses of both DHCP servers must be the same in both nodes. Otherwise the DHCP renew process would fail.

Granting new leases out of the shared IP address-ranges or prefixes that are configured as access-driven is not dependent on the state of the inter-chassis communication link (MCS). Instead, the new leases can be granted from both nodes simultaneously and it is the role of the protection mechanism in the access to ensure that a single path to either server is always active.

This model will allow the newly active node, after a SRRP/MC-LAG switchover, to be able to serve new clients immediately from the same (shared) IP range or prefix. At the same time, upon the switchover, the corresponding subscriber-interface route is re-evaluated for advertisement with a higher routing metric to the network side via SRRP awareness. The end result is that by aligning the subscriber-interface routes or prefixes with access-driven DHCP address ranges or prefixes in DHCP server, the IP address ranges or prefixes will be advertised to the network side only from the actively serving node (SRRP Master or active MC-LAG node). This will be performed indirectly via the corresponding subscriber-interface route that is aligned (by configuration) with the DHCP address range or prefix in access-driven mode.

In case that SRRP or MC-LAG is not deployed in conjunction with the access-driven configuration option, the IP address duplication could occur.

Note that multi-chassis redundancy relies on MCS to synchronize various client applications. (subscriber states, DHCP states, IGMP states, etc) between the two chassis. Therefore the links over which MCS peering session is established must be highly redundant. Failed MCS peering session will render dual-chassis redundancy non-operational. Considering this fact, the DHCP failover scenario with SRRP/MC-LAG and shared IP address range should be evaluated considering the following cases:

Table 41:  DHCP Failover Scenarios   

Access Related Failure

Inter-Chassis Link State

Number of Failures

Action

None

None

None

Only the MASTER SRRP BNG will grant IP leases.

The subnet tied to the SRRP instance is advertised to the network side on the MASTER SRRP node.

None

COMM-INT

Possibly multiple

Only the MASTER SRRP BNG will grant IP leases.

Communication link between the two chassis has failed and the DHCP states cannot be synchronized. Operator is required to restore the links between the chassis.

None

PARTNER-DOWN

Possibly multiple

Same as above. The premise of this deployment model in general (SRRP/MC-LAG + access-driven) is that there is only one path leading to the DHCP server active. This path is governed by SRRP. Therefore there is no change in behavior between the PARTNER-DOWN and COMM-INT states in this particular scenario.

Access Link Towards the Master SRRP

NORMAL

Single

SRRP will switch over. The new IP lease grants will continue from new SRRP Master using the same IP address range. IP leases will be synched OK. Subnets will be advertised from new Master via SRRP awareness.

Access Link Towards the Master SRRP

COMM-INT

Multiple

SRRP will switch over. The new leases can be handed from the DHCP server on the newly SRRP Master node. However, this DHCP server may not have its lease state table up to date since the inter-chassis communication link is non-operational.

Consequently, new SRRP Master node may start handing out leases that are already allocated on the node with the failed link. In this case, IP address duplication would ensue.

This is why it of utmost importance that the intercommunication chassis link is well protected and the only event that causes it to go down is when the entire node goes down. Otherwise the nodes becomes isolated from each other and synchronization becomes non-operational.

Access Link Towards the Master SRRP

PARTNER-DOWN

Multiple

Same as above.

Access Link Towards the Standby SRRP

NORMAL

Single

No effect on the operation since everything is active on the Master SRRP node anyway.

Access Link Towards the Standby SRRP

COMM-INT

Multiple

Intercommunication link is broken. The Master SRRP node will continue handing out the new leases and renewing the old ones. However, they will not be synchronized to the peering node.

Access Link Towards the Standby SRRP

PARTNER-DOWN

Multiple

Same as above.

Entire Master Node

COMM-INT

Single

SRRP will switch over. However, lease duplication may occur on the newly Master since the intercommunication link is broken and this newly SRRP Master is not aware of DHCP leases that the peer (failed node) may have allocated to the clients while the intercommunication-link was broken.

Entire Master Node

PARTNER-DOWN

Single

Same as above.

Entire Standby Node

COMM-INT

Single

Operation continues OK but multi-chassis redundancy is lost.

Entire Standby Node

PARTNER-DOWN

Single

Same as above.

A possible deployment scenario is shown in Figure 28.

Figure 28:  Failover Scenario with SRRP and DHCP in Access-Driven Mode 

Fast-Switchover of IP Address/Prefix Delegation For Remote IP Address/Prefix Range

Some deployments require that the remote IP address/prefix range starts delegating new IP addresses/prefixes upon the failure of the intercommunication link, without waiting for the intercommunication link to transition from the COMM-INT state into the PARTNER-DOWN state and the MCLT to expire while in PARTNER-DOWN state.

In other words, the takeover of the remote IP address-range/prefix should follow the failure of the intercommunication link, without any significant delays.

This can be achieved by configuring both of the following two items under the dhcp failover CLI hierarchy:

  1. The partner-down-delay must be set to 0. This will cause the intercommunication link to bypass the COMM-INT state upon the failure and transition straight into the PARTNER-DOWN state. The remote IP address-range/prefix can be taken over only in PARTNER-DOWN state, once the MCLT expires.
  2. The ignore-mclt-on-takeover flag must be enabled. With this flag enabled, remote IP address/prefix can be taken over immediately upon entering the PARTNER-DOWN state of the intercommunication link, without having to wait for the MCLT to expire. Note that by setting this flag, the lease times of the existing DHCP clients, while the intercommunication link is in the PARTNER-DOWN state, will still be reduced to the MCLT over time and all new lease times will be set to MCLT  this behavior remain the same as originally intended for MCLT. this functionality must be exercised with caution. One needs to keep in mind that the partner-down-delay and MCLT timers were originally introduced to prevent IP address duplication in cases where DHCP redundant nodes transition out-of-sync due to the failure of intercommunication link. These timers (partner-down-delay and MCLT) would ensure that during their duration, the new IP addresses/prefixes are delegated only from one node – the one with local IP address-range/prefix. The drawback is of course that the new IP address delegation is delayed and thus service is impacted.

But if one could ensure that the intercommunication link is always available, then the DHCP nodes would stay in sync and the two timers would not be needed. This is why it is of utmost importance that in this mode of operation, the intercommunication link is well protected by providing multiple paths between the two DHCP nodes. The only event that should cause intercommunication link to fail is the entire nodal failure. This failure is acceptable since in this case only one DHCP node is available to provide new IP addresses/prefixes.

DHCP Server Synchronization and Local PPPoX Pools

Since there is no classical DHCP lease state maintained for local PPPoX pools, the IP addresses will not be synchronized via DHCP Server. Instead they will be synchronized via PPPoX clients. Once the PPPoX subscriber is synchronized, the respective IP address lease will be updated in the respective local pool.

For example:

  1. A PPPoE client is created on 7x50 ‘A’.
  2. The IP address is assigned from the local poll on 7x50 ‘A’.
  3. The PPPoE client will be synchronized to the peering node 7x50 ‘B’.
  4. Once the client is synchronized in 7x50 ‘B’, the IP address assignment will be synchronized by our internal PPPoE process on 7x50 ‘B’ with the local pool.

One artifact of this behavior (IP address assignment in local DHCP pools is synchronized via PPPoX clients and not via DHCP server synchronization mechanism) is that during the node boot, the DHCP server must wait for the completion of PPPoX subscriber synchronization via MCS so that it learns which addresses/prefixes are already allocated on the peering node. Since the DHCP server can theoretically start assigning IP addresses before the PPPoX sync is completed, a duplicate address assignment my occur. For example an IP address lease can be granted via DHCP local pools while PPPoX sync is still in progress. Once the PPPoX sync is completed, the DHCP server may discover that the granted IP lease has already been allocated by the peering node. The most recent lease will be kept and the other will be removed from both systems. To prevent this scenario, a configurable timer can be set to an arbitrary value that will render sub-if non-operational until the timer expires. The purpose of this timer is to allow the PPPoX sync to complete before subscribers under the sub-intf can be served.

Local Address Assignment

Stateless Address Auto-configuration

In the stateless auto-configuration model, hosts can be assigned address statically or dynamically. For static prefix assignment, LUDB and RADIUS can be used. For dynamic assignment, a pool name returned from LUDB or RADIUS and the local DHCPv6 server is used for address management. Although, the DHCPv6 server is used there are no lease time associated with the SLAAC prefix assigned to hosts. To utilize the local pool for SLAAC prefix assignment, the command local-address-assignment is used under group-interface. The client-application type ppp-slaac and/or ipoe-slaac must first be specified. Afterwards, the server name of the local-address-server must also be provisioned.