DHCP management

DHCPv4 relay lease split illustrates the lease split function for the initial connection of a DHCPv4 subscriber host.

1. The initial Discover, Offer, and Request messages are handled by the DHCP Relay Agent as usual.

2. Before forwarding the DHCP ACK message to the DHCP client, the DHCP Relay Agent replaces the long lease time (LT) committed by the DHCP server with a shorter lease time (LT_s).

   The lease split function is active when the configured short lease time (LT_s) is less than half the lease time committed by the server (LT).

3. The DHCP client tries to extend its lease at T1_s, the renewal time of the short lease time (LT_s).

4. The DHCP Relay Agent extends the lease on behalf of the DHCP server by sending a DHCP ACK with the short lease time (LT_s).

5. When the next DHCP client renew request is later than T1, the renewal time of the long lease time (LT), the Relay Agent forwards the request to the DHCP server and re-authenticates when applicable.

6. The DHCP Relay Agent replaces the long lease time (LT) committed by the DHCP server with a shorter lease time (LT_s).

DHCPv4 lease split – DHCPv4 client disconnects ungracefully illustrates the lease split function when the DHCPv4 subscriber host disconnects ungracefully.

1. DHCPv4 lease split is active. When re-authenticating, the DHCP Relay Agent replaces the long lease time (LT) committed by the DHCP server with a shorter lease time (LT_s) in the DHCP ACK message.

2. The DHCP client tries to extend its lease at T1_s, the renewal time of the short lease time (LT_s).

3. The DHCP Relay Agent extends the lease on behalf of the DHCP server by sending a DHCP ACK with the short lease time (LT_s).

4. The DHCPv4 client disconnects ungracefully without sending a DHCP release message to the server.

5. When the short lease time (LT_s) expires, the subscriber host state is deleted from the system and the DHCP Relay Agent sends a release message to the server on behalf of the client. The maximum time before the IPv4 address becomes available for reuse after an ungraceful disconnect of the DHCP client is now determined by the short lease time (LT_s) instead of the long lease time (LT).

DHCPv4 lease split unreachable DHCPv4 servers illustrates the lease split function when the DHCPv4 servers become unreachable.

1. After the initial DHCPv4 session setup with lease split active, all DHCP servers become unreachable.

   The DHCP Relay Agent answers the DHCP client renew requests with the short lease time (LT_s) on behalf of the server until the next client renew request is later than T1, the renewal time of the long lease time (LT).

2. The DHCP Relay Agent re-authenticates (when configured) and forwards the next DHCP client renew request and all retransmissions to the DHCP server that committed the lease. No answer is received from the DHCP server.

3. Because the DHCP servers are unreachable, the client transitions to the rebinding state at T2_s, the rebinding time of the short lease time (LT_s). The DHCP Relay Agent re-authenticates (when configured) and broadcasts the DHCP client rebind request to all configured DHCP servers. No answer is received from any DHCP server.

4. The DHCP Relay Agent answers the first retransmission of the DHCP client rebind request with the short lease time (LT_s) on behalf of the server that committed the lease.

   The DHCP Relay Agent answers subsequent DHCP client renew requests with the short lease time (LT_s) on behalf of the server that committed the lease until either:

   • the remaining long lease time (LT_r) is less than the short lease time (LT_s) + 5 minutes. In this case, the call flow continues as described from Step 8 onward

   • the next client renew request is later than T2, which is the rebind time of the long lease time (LT)

5. The DHCP Relay Agent re-authenticates (when configured) and forwards the next DHCP client renew request and all retransmissions to the DHCP server that committed the lease. No answer is received from the DHCP server.

6. Because the DHCP servers are unreachable, the client transitions to the rebinding state at T2_s, the rebinding time of the short lease time (LT_s). The DHCP Relay Agent re-authenticates (when configured) and broadcasts the DHCP client rebind request to all configured DHCP servers. No answer is received from any DHCP server.

7. The DHCP Relay Agent answers the first retransmission of the DHCP client rebind request with the short lease time (LT_s) on behalf of the server that committed the lease.

   The DHCP Relay Agent answers subsequent DHCP client renew requests with the short lease time (LT_s) on behalf of the server that committed the lease until the remaining long lease time (LT_r) is less than the short lease time (LT_s) + 5 minutes.

8. The DHCP Relay Agent answers the next DHCP client renew request with the remaining long lease time (LT_r) on behalf of the server that committed the lease.

   The DHCP Relay Agent no longer answers on behalf of the DHCP servers until one of the servers responds or until the lease expires.

9. The DHCP Relay Agent re-authenticates (when configured) and forwards the next DHCP client renew request (at T1_r, the renew time of the remaining long lease time (LT_r)) and all retransmissions to the DHCP server that committed the lease. No answer is received from the DHCP server.

10. The DHCP Relay Agent re-authenticates (when configured) and broadcasts the next DHCP client rebind request (at T2_r, the rebind time of the remaining long lease time (LT_r)) and all retransmissions to all configured DHCP servers. No answer is received from any DHCP server.

11. When the remaining long lease time (LT_r) expires, the DHCP client transitions to the init state and connectivity is lost.

12. When the long lease time (LT) expires, the subscriber host state is deleted from the system and the DHCP Relay Agent sends a release message to the server on behalf of the client.

To enable DHCPv4 lease split, configure DHCPv4 relay and administratively enable the proxy server. DHCPv4 lease split is active for a lease when the proxy server is enabled and when the configured proxy server lease-time value (the short lease time) is less than or equal to the renew time committed by the server (the long renew time) in the Option 58 Renewal (T1) Time Value or 50% of the lease time committed by the server in the absence of DHCP Option 58 Renewal (T1) Time Value in the DHCP Ack message from the server.

configure service ies service-id subscriber-interface ip-int-name group-
interface ip-int-name
--- snip ---
    dhcp
        proxy-server
            lease-time min 15
            no shutdown
        exit
        server 192.0.2.3 192.0.2.4
        trusted
        gi-address 10.250.13.254 src-ip-addr
        no shutdown
    exit

Use the following show command to verify whether DHCPv4 lease split is active.

# /show service id 1000 dhcp lease-state detail
=====================================================================
DHCP lease states for service 1000
=====================================================================
--- snip ---
Remaining Lease Time : 0d 00:09:56 (Lease Split)
--- snip ---
Lease Info origin    : DHCP
--- snip ---
ServerLeaseStart     : 06/25/2020 07:35:54
ServerLastRenew      : 06/26/2020 14:42:14
ServerLeaseEnd       : 06/26/2020 15:42:14
--- snip ---
Lease-Time           : 1d 00:00:00
DHCP Server Addr     : 192.0.2.4
--- snip ---

The call flows for DHCPv6 lease split are similar to DHCPv4 lease split.

As shown in the following output, in a single DHCPv6 transaction, both IA_NA and IA_PD Identity Association (IA) types can be present, each with their associated timers (renew time T1, rebind time T2, preferred lifetime, and valid lifetime).

 Option : IA_NA (3), Length : 40
         IAID : 0
         Time1: 1800 seconds
         Time2: 2880 seconds
         Option : IAADDR (5), Length : 24
           Address : 2001:db8:100::1
           Preferred Lifetime : 3600 seconds
           Valid Lifetime     : 4500 seconds
       Option : IA_PD (25), Length : 41
         IAID : 1
         Time1: 1800 seconds
         Time2: 2880 seconds
         Option : IAPREFIX (26), Length : 25
           Prefix : 2001:db8:d201::/64
           Preferred Lifetime : 3600 seconds
           Valid Lifetime     : 4500 seconds

DHCPv6 lease split actions are always identical for all leases in the transaction:

• DHCPv6 lease split is active for a lease when DHCPv6 relay lease split is enabled on the group interface or retail subscriber interface and when, for all IA_NA and IA_PD options in the transaction, the configured lease split valid lifetime (short lease time) is less than or equal to the following conditions:

  • the renew time T1 committed by the server (the long renew time) in the IA_NA or IA-PD Option

  • 50% of the preferred lifetime committed by the server in the IA_NA Address Option or IA_PD Prefix Option when the T1 value committed by the server equals zero

• When DHCPv6 lease split is active, the following values are updated for all IA types in the reply to the DHCPv6 client.

  • Valid lifetime (short lease time or short valid lifetime) = configured lease-split valid-lifetime

  • Preferred lifetime (short preferred lifetime) = configured lease-split valid-lifetime

  • T1 (short renew time) = 0.5 * configured lease-split valid-lifetime

  • T2 (short rebind time) = 0.8 * configured lease-split valid-lifetime

  When lease split is active, the short preferred lifetime and short valid lifetime are equal.

• Renew behavior when DHCPv6 lease split is active:

  • A client renew message is authenticated (when applicable) and relayed to the DHCP server when, for at least one of the IA options in the transaction, the next client renew message following the short renew time cycle is later than the long renew time (T1) committed by the server.

  • Otherwise, the client renew message is proxied (in other words, a renew reply is sent to the client on behalf of the server). Proxied client renew messages are not authenticated. For all IA types, the following values are included:

    • Valid lifetime (short lease time or short valid lifetime) = configured lease-split valid-lifetime

    • Preferred lifetime (short preferred lifetime) = configured lease-split valid-lifetime

    • T1 (short renew time) = 0.5 * configured lease-split valid-lifetime

    • T2 (short rebind time) = 0.8 * configured lease-split valid-lifetime

The following output shows an example of a DHCP6 relay configuration.

configure service ies service-id subscriber-interface ip-int-name group-
interface ip-int-name
--- snip ---
    ipv6
        dhcp6
            relay
                lease-split
                    valid-lifetime min 15
                    no shutdown
                exit
                server 2001:db8::1
                no shutdown
            exit
        exit
    exit

Use the following command to verify whether DHCPv6 lease split is active.

# /show service id 1000 dhcp6 lease-state detail
======================================================================
DHCP lease states for service 1000
======================================================================
--- snip ---
Remaining Lease Time : 0d 00:12:07 (Lease Split)
--- snip ---
Dhcp6 Server Addr    : 2001:db8::3
--- snip ---
Lease Info origin    : DHCP
ServerLeaseStart     : 12/15/2020 11:13:22
ServerLastRenew      : 12/15/2020 11:13:22
ServerLeaseEnd       : 12/15/2020 12:20:02

As specified in RFC 3046, DHCP Relay Agent Information Option, an SR OS Relay Agent discards a DHCP packet where the gi address is set to 0.0.0.0 but with a Relay Agent Information Option 82 present, unless it arrives on a ‟trusted” circuit.

The dhcp trusted command enables the Relay Agent to forward such DHCP requests. The gi address is updated according the gi-address configuration on the interface.

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 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 the l2-header in the lease-populate command at the DHCP level. Because SR OS routers do not have the ability to verify the DHCP information (both the src-ip and src-mac of the packet are those of the previous relay point) anti-spoofing must be performed at the access node before the SR OS routers. This mode provides compatibility with MAC concentrator devices, and cable modem termination system (CMTS) and WiMAX Access Controller (WAC).

A configuration example of a cable/wireless network together with subscriber management is shown in CMTS/WAC network configuration example. 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 is 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 is no additional Layer 3 route installed pointing to them.

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

• IP-only static host pointing to CMTS/WAC WAN link is needed to allow BSR to reply to ARP requests originated from CMTS/WAC.

• 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 then uses the configured MAC address when instantiating the DHCP lease states.

Like DHCPv4, the subscriber interface SAP must be on the datapath 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, as a Layer 3 aggregation network replaces the client’s MAC with routing. From the perspective of the BNG, all DHCPv6 message from the same downstream router has the same source MAC. By default, the BNG use 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 are 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. 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 to the relay agent, simply add a static route for the relay agent source IP address. The static route has 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 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 the relay-reply 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. Like 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 the IPv6 ESM host, it is mandatory that each host have a unique /64 prefix. Service providers who need to share the /64 prefix among multiple WAN host can use 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 ignores those options set on relay-forward levels.

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

• WLAN-GW

• DHCPv6 Proxy

• Wholesale or Retail

• SHCV

• Layer 2–aware NAT

• GRT leaking or Extranet

A local DHCP server functions only if there is a relay agent (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.

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 about one of the following valid addresses:

   • fixed IP address

     The IP address should not overlap with the address ranges configured in the local DHCP server.

   • pool name

     A free address of any subnet in that pool is offered.

   • use-gi-address [scope subnet | pool]

     The GI address is used to find a matching subnet. When scope subnet is configured, 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 when that pool has been selected based on matching the ‟giaddr” field in the DHCP message with any of the configured subnets in the pool.

   • 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:

   • 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.

   • Use the gi address (use-gi-address [scope subnet | pool])

     The gi address is used to find a matching subnet. When the 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 when 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.

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 is then 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 specified combination of MAC and circuit ID, only one IP address can be returned. The same address is returned if a re-request is made.

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

• When a user-db is specified, a host lookup is performed in the local-user-db and the local user-db host defines how to get the IP address or pool to get the IP address from:

  • a fixed IP address

  • a pool

    free address of any subnet in that pool is offered

  • use-pool-from-client

    The pool name is taken from Option 82 vendor-specific sub-option. (If not present, proceed to the next bullet.)

  • use-gi-address

    The gi-address is used to find a matching subnet.

• If no IP address, subnet, or pool is found (see the points 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.

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. The 7450 ESS routers use DHCP relay and proxy DHCP server functionality.

Three applications are targeted for the local DHCP server:

• subscriber aggregation in either a single node (routed CO) or TPSDA

• 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 receives addresses through a relay point in the customer’s network. This option is supported for the 7750 SR only.

• 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 provides the information in PPP format to the client.

DHCP server scenarios include:

• DHCP servers can be integrated with Enhanced Subscriber Management (ESM) for DHCP clients, DHCP relays and PPPoE clients.

• A stand-alone DHCP server can support DHCP clients and DHCP relays.

• 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.

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.

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 are assigned. For example, the delegating router can get a /48 prefix by DHCPv6 and assign /64 prefixes to multiple requesting routers. Prefix delegation is supported for the delegating router (not the requesting router).

This is like ARP populate for IPv4. When it is turned on, an SR OS 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 does not 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 is supported.

The following features are enabled:

• DHCPv6 lease information is reconciled to the standby.

• DHCPv6 lease information can be stored on a flash card.

• 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 is like 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:

• responds to all neighbor solicitation messages received on the interface for IPv6 addresses in the subnets unless disallowed by policy

• forwards traffic between hosts in the subnets of the interface

• drops traffic between hosts if the link-layer address information for the IPv6 destination has not been learned

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.

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

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, after the lease time has expired. A large configured timeout value allows for address and prefix ‟stickiness”. When a subscriber requests a lease through 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.

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 toward 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 the 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.

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

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

debug router router-id ip dhcp enables DHCP debug on Layer 3 interfaces, including subscriber-interfaces.

debug service id service-id dhcp enables DHCP debugging on capture SAP

If the DTC cache is populated with Python, the corresponding DTC entries are shown as part of the matching DHCP message debug.

With the configuration of a discover-delay, the forwarding of a DHCP Discover Message to the DHCP server is delayed, which results in a delayed DHCPv4 Offer to the DHCP client. A discover-delay (in deciseconds) can be configured for DHCP Discover messages, as shown in the following examples:

• originated by DHCP clients with odd or even MAC addresses

  dhcp
      server 192.0.2.1
      offer-selection
          client-mac odd
              discover-delay 5
          exit
      exit
      no shutdown
  exit
  

• sent to a specific DHCP server (a delay for up to eight servers can be configured)

  dhcp
      server 192.0.2.1 192.0.2.2
      offer-selection
          server 192.0.2.2
              discover-delay 5
          exit
      exit
      no shutdown
  exit
  

• for which no per client MAC or per DHCP server discover-delay is configured (for example, a default discover-delay)

  dhcp
      server 192.0.2.1
      offer-selection
          discover-delay 5
      exit
      no shutdown
  exit
  

Additional considerations:

• Configuring a per DHCP server discover-delay and a per DHCP client MAC address discover-delay is mutually exclusive.

• A default discover-delay can be combined with either a per DHCP server or a per DHCP client MAC delay.

• When a new Discover message, such as a retransmitted message is received from the same client while a discover-delay timer is running, the discover-delay timer is stopped, the queued Discover message is discarded, and the new Discover message is immediately forwarded without delay.

With the configuration of a solicit-delay, the forwarding of a DHCP Solicit Message to the DHCP server is delayed resulting in a delayed DHCPv6 Advertise to the DHCP client. A solicit-delay (in deciseconds) can be configured for DHCP Solicit messages, as shown in the following examples:

• originated by DHCP clients with odd or even MAC addresses

  dhcp6
      relay
          advertise-selection
              client-mac odd
                  solicit-delay 5
              exit
          exit
          server 2001:db8::1
          no shutdown
      exit
  exit
  

• sent to a specific DHCP server (a delay for up to eight servers can be configured)

  dhcp6
      relay
          advertise-selection
              server 2001:db8::2
                  solicit-delay 5
              exit
          exit
          server 2001:db8::1
          server 2001:db8::2
          no shutdown
      exit
  exit
  

• for which no per client MAC or per DHCP server solicit-delay is configured (for example, a default solicit-delay)

  dhcp6
      relay
          advertise-selection
              solicit-delay 5
          exit
          server 2001:db8::1
          no shutdown
      exit
  exit
  

With the configuration of a preference-option value, a DHCPv6 Preference Option (7) with the configured value is inserted in the Advertise Message to the DHCP client. A DHCPv6 client can use the preference value to select one out of multiple received Advertise messages. A preference-option value (0 to 255) can be configured for DHCP Advertise Messages, as shown in the following examples:

• sent to DHCP clients with odd or even MAC addresses

  dhcp6
      relay
          advertise-selection
              client-mac odd
                  preference-option
                      value 200
                  exit
              exit
          exit
          server 2001:db8::1
          no shutdown
      exit
  exit
  

• sent to a specific DHCP server (a preference-option value for up to eight servers can be configured)

  dhcp6
      relay
          advertise-selection
              server 2001:db8::2
                  preference-option
                      value 200
                  exit
              exit
          exit
          server 2001:db8::1
          server 2001:db8::2
          no shutdown
      exit
  exit
  

• for which no per client MAC or per DHCP server preference-option value is configured (for example, a default preference-option value)

  dhcp6
      relay
          advertise-selection
              preference-option
                  value 200
              exit
          exit
          server 2001:db8::1
          no shutdown
      exit
  

Additional considerations:

• A solicit-delay and preference-option value can be configured simultaneously.

• Configuring a per DHCP server solicit-delay and preference-option value and a per DHCP client MAC address solicit-delay or preference-option value is mutually exclusive.

• A default solicit-delay and preference-option value can be combined with either a per DHCP server or a per DHCP client MAC configuration.

• When a new solicit message is received from the same client, such as a retransmitted message while a solicit-delay timer is running, the solicit-delay timer is stopped, the queued solicit message is discarded, and the new Solicit message is immediately forwarded without delay.

LDRA, as described in RFC 6221, Lightweight DHCPv6 Relay Agent, resides on the same IPv6 link as the DHCPv6 client and the DHCPv6 relay agent or server and inserts relay agent information options such as the interface ID and remote ID that identify the client-facing interface. A DHCPv6 server can use these options to:

• identify the client
• know where to client is attached to the network
• assign appropriate parameters

The following figure displays an initial DHCPv6 Solicit/Advertise message flow with LDRA enabled in a VPLS service.

An LDRA distinguishes between client-facing interfaces and network-facing interfaces to process DHCPv6 messages.

Use the following command to configure a VPLS SAP as a client-facing interface.

configure service vpls sap dhcp6 ldra interface-type client-facing

A client-facing SAP only accepts DHCPv6 client messages. The client messages are encapsulated in a Relay-Forward message, including the mandatory interface-id option 18 and an optional relay agent remote-id option 37 that can be configured using the following commands.

configure service vpls sap dhcp6 ldra options interface-id
configure service vpls sap dhcp6 ldra options remote-id

The Resulting Relay-Forward message is flooded in the VPLS. For more information about these options, see the following user guides:

• 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide
• 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide

A client-facing SAP is always untrusted: the DHCPv6 client must be directly connected on the same link layer without a relay agent or another LDRA in between. DHCPv6 Relay-Forward, Relay-Reply, Advertise, Reply, and Reconfigure messages received on a client-facing SAP are silently dropped.

Use following command to configure a VPLS SAP as network-facing interface.

configure service vpls sap dhcp6 ldra interface-type network-facing

A network-facing SAP only accepts DHCPv6 Relay-Reply messages. All other DHCPv6 messages are silently dropped on a network-facing SAP. The DHCPv6 Relay-Reply message is decapsulated and the extracted DHCPv6 server message forwarded in the VPLS.

LDRA DHCPv6 messages are forwarded in the VPLS following the VPLS forwarding rules:

• DHCPv6 client messages received on client-facing SAPs and the resulting Relay-Forward message have the multicast destination IP address All_DHCP_Relay_Agents_and_Servers (ff02::1:2) and a multicast destination MAC address (33:33:00:01:00:02). The Relay-Forward message is flooded in the VPLS regardless of the LDRA configuration to all SDPs, all SAPs with LDRA disabled, and all SAPs with LDRA enabled as client-facing or network-facing interfaces.
• DHCPv6 Relay-Reply messages received on network-facing SAPs and the extracted server messages have the link layer address of the DHCPv6 client as a unicast destination MAC address. The extracted server message is forwarded to the client-facing SAP based on a VPLS FDB lookup of the destination MAC address. This requires that MAC learning is enabled in the VPLS, otherwise the server messages are flooded as unknown unicast to all SDPs, all SAPs with LDRA disabled, and all SAPs with LDRA enabled as client-facing or network-facing interface.

The VPLS forwarding of LDRA DHCPv6 messages as described above results in the following requirements for a correct operation when enabling LDRA on a VPLS SAP:

• Only include SAPs in the VPLS (that is, no spoke or mesh SDP)
• Enable MAC learning in the VPLS service
• Enable LDRA on all SAPs in the VPLS
• Configure at least one SAP in the VPLS as a client-facing interface and at least one SAP in the VPLS as a network-facing interface
• Include all client-facing SAPs in a split-horizon group

The following figure displays the DHCPv6 message flow for a VPLS with LDRA enabled.

Use DHCPv6 debug in the VPLS service to troubleshoot LDRA related problems.

Use the show service dhcp6 statistics sap command to display a per SAP statistics of DHCPv6 snooped packets.

• local 7750 SR and 7450 ESS DHCP server

  The DHCP server instantiated on the local 7750 SR and 7450 ESS node.

• remote 7750 SR and 7450 ESS DHCP server

  The DHCP server instantiated on the remote 7750 SR and 7450 ESS node (external to the local 7750 SR and 7450 ESS node).

• 3rd party DHCP server

  The DHCP server external to any 7750 SR and 7450 ESS node and implemented outside of 7750 SR and 7450 ESS.

• intercommunication link

  The logical link between dual-homed 7750 SR and 7450 ESS DHCP servers used for synchronizing DHCP lease states. Multi-chassis Synchronization (MCS) protocol runs over this link. When 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.

• local IP address-range and prefix

  The local failover mode in which the IP address-range and prefix is configured in dual-homed DHCP environment. The local keyword does not refer to the locality (local versus remote) of the server on which the IP address-range and prefix in configured, but rather refers to the ownership of the IP address-range and prefix. The DHCP server on which the local IP address-range and prefix is configured, owns this IP address-range and prefix and consequently can delegate the IP addresses and prefixes from it at any time, regardless of the state of the intercommunication link.

• remote IP address-range and prefix

  The remote failover mode in which the IP address-range and 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 and prefix is configured but rather refers to the ownership of the IP address-range and prefix. The DHCP server on which the remote IP address-range and prefix is configured, but does not own this IP address-range and prefix during normal operation and consequently is not allowed to delegate the IP addresses and prefixes from it. Only when the intercommunication link between the two nodes transition into particular (failed) state, the DHCP server can start delegating new IP addresses from the remote IP address-range and prefix.

• IP address-range and prefix ownership

  The 7750 SR and 7450 ESS DHCP servers that can delegate new leases from an IP address-range and prefix that it owns. For example, an IP address-range and prefix designated as remote is not owned by the DHCP server on which it is configured unless specific conditions are met. Those conditions are governed by the state of the intercommunication link.

• IP address-range and prefix takeover

  The 7750 SR and 7450 ESS DHCP servers that do not own an IP address-range and prefix can take over the ownership of this IP address-range and prefix under specific conditions. When the ownership is taken, the new IP addresses can start being delegated from this IP address-range and prefix. Only the remote IP address-range and prefix can be taken over. Note that the takeover of an IP address-range and prefix has only local significance, in other words, the ownership is not taken away from some other DHCP server that has the same IP address-range and prefix designated as local. It only means that IP address-range and prefix that is configured as remote is available to takeover for new IP address delegation.

• local PPPoX address pools

  The method of accessing an IPv4/v6 address pool in 7750 SR and 7450 ESS DHCP4/6 server. For PPPoX clients, the IPv4/v6 addresses are allocated from those pools without the need for an intermediate DHCP relay-agent (7750 SR and 7450 ESS internal DHCP relay-agent). Although those pools are part of the local DHCP server in 7750 SR and 7450 ESS, 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:

  • IPoE client by DHCP messaging

  • PPPoE by internal API calls

• local PPPoX pool management

  The IPv4 address allocation/management for PPPoX clients independent of DHCP process (DHCP lease state). An IPv4 address allocated by local PPPoX Pool Management is tied to the PPPoX session. It is without the need for an internal DHCP relay-agent.

7750 SR and 7450 ESS DHCP server multihoming ensures continuity of the IP address and prefix assignment and renewal processes when an entire 7750 SR and 7450 ESS DHCP server fails or in case of a failure of the active link that connects clients to one of the 7750 SR and 7450 ESS DHCP servers in the access part of the network. DHCP server multihoming is an integral part of the overall subscriber management multichassis protection scheme.

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

Although the subscriber synchronization process and the DHCP lease states synchronization process use the same synchronization infrastructure within 7750 SR and 7450 ESS (Multi Chassis Redundancy protocol), they are 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 and 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 because the access-link failure coincides with the intercommunication link failure and the other way around. However, link-only failures become critical when it comes to their interpretation by the protection mechanisms (SRRP, MC-LAG, DHCP server multihoming). Regardless of nature of the failure, an overall DHCP server multichassis protection scheme must be devised in so that the two 7750 SR and 7450 ESS DHCP servers never allocate the same IP address and prefix to two different clients. Otherwise, IP address or prefix duplication ensues. Unique IP address and prefix allocation is achieved by making only one 7750 SR and 7450 ESS DHCP server responsible for IP address prefix delegation out of the shared IP address-range or prefix.

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

• Shared IP address-ranges and prefixes are designated as local on one 7750 SR and 7450 ESS 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 and prefix as well as the one with the remote IP address-range and prefix.

  Under normal circumstances, the new IP addresses and prefixes can be only allocated from the DHCP server configured with the local IP address-range and prefix.

  The DHCP server configured with the remote IP address-range and prefix starts delegating new lease from it only when it declares that the redundant peer with the local IP address-range and 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 operator ample time to fix the problem.

  For example, the DHCP server takes over the remote IP address-range and prefix after 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 and prefix is not possible until the preset timers expire. This is needed and justified if 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 and prefix becomes truly unavailable, those additional restoration times causes interruption in service because the new IP addresses from the remote IP address-range and prefix is not immediately available for delegation.

  Only new IP address delegation from the remote IP address-range and 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 and 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:

  • Segment the IP address and prefix space so that each node has an IP address-range and 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 is 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 is always available to assign new leases without any overlap.

  • If 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 with configuration. In this case, a safe operation is warranted only if the operator is confident that the intercommunication link failure is caused by the nodal failure, and not the physical link failure between the two nodes.

• Shared IP address-range and prefix is designated as access-driven on both 7750 SR and 7450 ESS DHCP servers.

  In this scenario, the shared IP address-range and 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 time must be responsible for IP address assignment from this shared IP address-range and prefix.

  This is ensured by the access protection mechanism (SRRP/MC-LAG) that provides 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 and 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:

  • DHCP client A sends DHCP Discover to the DHCP server A

  • DHCP client B sends DHCP Discover to the DHCP server B

  • DHCP server A assigns IP address 10.10.10.10 to the DHCP client A

  • DHCP server B assigns IP address 10.10.10.10 to the DHCP client B

  • This is a legitimate scenario because the DHCP lease states are not synchronized until the DHCP lease assignment is completed.

  • Just before the DHCP ACK is sent to the respective clients from both nodes, the DHCP lease sync messages are exchanged between the peers.

  • DHCP servers do not wait for the reply to the sync message before they send the DHCP Ack to the client.

  • After the DHCP lease syn message is received from the peer, the DHCP server realizes that the IP lease already exist. In this case, the newer IP lease overrides the older.

  • The result is that clients A and B use the same IP address and consequently the forwarding of the traffic is impaired.

  In access-driven model, the ESM subscriber host must be colocated 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 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 when the switchover in the access occurs.

  For example:

  • DHCP server A on BNG A is associated with the IP address 1.1.1.1 (for example loopback interface A on BNG A)

  • 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)

  • DHCP relay on BNG A points to the IP address 1.1.1.1 (DHCP server in BNG A)

  • 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:

• 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 and 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.

  If multiple IP address-ranges and prefixes are deployed, bypass of the timers is not needed because the local IP address-ranges and prefixes are available on both nodes.

• Access-driven model allows a single IP address-range and 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 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 server failover mechanism in the local-remote IP address-range and prefix model relies on the detection of the failure of the link over which DHCP states are synchronized (through the MCS protocol). This link is normally disjointed from the access links toward the clients. MCS protocol normally runs over a direct link between the two redundant nodes (1) or over backbone links (2) if the direct link is not present. This is shown in Redundancy model.

In the access-driven IP address-range and prefix model, the DHCP server address-ranges and 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.

7750 SR and 7450 ESS DHCP server is a client of Multi-chassis Synchronization (MCS) application with 7750 SR and 7450 ESS. After MCS transitions into an out-of-sync state, the 7750 DHCP server redundancy assumes that there is a failure in the network. 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.5 seconds, MCS sends its own keepalive to the peer. If a reply is not received within 3 seconds, MCS declares its operational state as down and the database sync state as out-of-sync. MCS consequently notifies its clients (DHCP Server being one of them) of this condition.

It can take up to 3 seconds before the DHCP client realizes that the interclass 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 use 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 leads to specific failover state transitions on the DHCP server. The DHCP lease handling in the local-remote model depends on the failover state on the DHCP server and the duration of each failover state is determined by preconfigured timers.

The DHCP server, when paired in redundant fashion, can transition through several states:

• TRANSITION

• SHUTDOWN

• INIT

• STARTUP

  In this state, the DHCP server recovers leases from the MCS database and does not respond to any unicast and broadcast messages.

• NORMAL

  In this state, the 7750 SR and 7450 ESS DHCP server is serving all IP leases from the local and access-driven IP addresses-ranges and prefixes (assigning new leases and extending existing ones). Remote IP addresses-ranges and prefixes are not served (new or existing ones).

• P RENORMAL

  In this state, the DHCP recovers leases from the MCS database after a resolved communication failure. The DHCP server responds to unicast and broadcast messages for addresses in the local ranges, and to unicast messages for addresses in the remote ranges.

• COMMUNICATION INTERUPTED

  IP addresses and prefixes under the local and access-driven IP address-range and prefix are served in the same fashion as in the NORMAL state. The IP addresses and prefixes under the remote IP address-range and prefix are renewed. However, the new address and prefix from the remote address-range and prefix are not 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.

• PARTNER DOWN

  After the DHCP Server reaches this state, the remote IP address-range and prefix is taken over and after an additional period of MCLT (Maximum Client Lead Time), the new IP addresses and 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 when all the following conditions are met:

  • The DHCP server nodes become isolated.

  • The failover state is PARTNER-DOWN.

  • DHCP/PPPoX clients have simultaneous access to the same IP address-range and prefix on both DHCP servers.

7750 SR and 7450 ESS DHCP server state synchronization is different from the lease state synchronization of the subscriber host itself.

• Each subscriber host lease state is synchronized by sub-mgmt client application. The host lease state can be seen by 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).

• The DHCP server lease states can be observed by the following CLI command:

  show routed id dhcp local-dhcp-server name lease

The concern is with the latter, the 7750 SR and 7450 ESS 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 7750 SR and 7450 ESS 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 Potential expiration time:

• The right side does not include any lead time during synchronization.

• The left side includes the lead time during synchronization.

  

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 because of 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 and prefix, the lease in the secondary server expires (4). As a result, the IP address and prefix are not renewed.

To resolve this, the primary server must synchronize the lease time as the current RENEW time plus the next lease time. This way, as depicted in point 3, when the REBIND reaches server 2, the lease in its database is active (4) and the server 2 can extend the lease for the client.

Maximum Client Lead Time (MCLT) is the maximum time that the 7750 SR and 7450 ESS DHCP server can extend the lease time to its clients beyond the lease time currently know by the 7750 SR and 7450 ESS DHCP partner node. By default, this time is relatively short (10 minutes).

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

The local 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 DHCP server failure, the remote DHCP server is not aware of the IP address and prefix that was allocated on the local DHCP server. This condition creates the possibility that the remote DHCP server allocates the same address and prefix to another client. This would cause IP address and prefix duplication. MCLT is put in place to prevent this scenario.

MCLT based solution is shown in Potential expiration time.

The sequence of events is the following:

1. DHCP server 1 is the local DHCP server (with the local address-range and 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 DHCP server fails before it gets a chance to synchronize the lease state with the DHCP Server 2 (remote DHCP server with the remote address-range and prefix).

2. The remote DHCP server transitions into the PARTNER-DOWN state (if the partner-down timer is 0). In this state the remote DHCP server can extend the lease time to the existing clients but it cannot assign a new lease for a period of MCLT. In MCLT/2 a new RENEW request is sent directly to the local DHCP server. This server is DOWN and therefore it cannot reply.

3. The client broadcasts a REBIND request that reaches the remote DHCP server. The remote DHCP server has no knowledge of the requested lease and therefore it does not reply.

4. The lease for the client expires and the client must reinitiate the IP address and prefix assignment process.

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

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

• 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.

  • COMMUNICATION-INTERUPTED

    The remote DHCP server only renews the leases but does not delegate new ones (primary is DOWN).

    The local 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).

  • PARTNER-DOWN

    The remote DHCP server starts delegating new IP addresses and prefixes from the remote address-range and 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.

• The communication channel is down but the remote DHCP server is not (meaning that the clients have still access to both servers). The behavior in this case is following:

  • COMMUNNICATION-INTERUPTED

    The remote DHCP server keeps renewing existing leases but it does not delegate the new leases. There is little chance this could happen as the clients continue to send RENEWS by unicast to the local DHCP server which is still active. The non-synched leases in the remote DHCP server times out. The local DHCP server starts ticking down the lease time to MCLT.

    The local DHCP server continues to delegate the new leases, although with the MCLT lease time.

  • PARTNER-DOWN State

    The local DHCP server continues to extend the existing leases but also starts delegating new IP leases after the initial MCLT elapses.

    Both local and remote DHCP server delegates new leases in the PARTNER-DOWN state (although the remote DHCP server in PARTNER-DOWN state must wait an additional MCLT period before it can start delegating new leases).

Access-driven DHCP server redundancy model ensures uninterrupted IP address assignment service from a single IP address-range and prefix if 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 SR OS-based DHCP servers in redundant configuration. This single active path is ensured by a protection mechanism in dual-homed environment in the access side of the network. The supported access redundancy mechanisms are SRRP or MC-LAG.

In the access-driven DHCP redundancy model, the DHCP relay in each router of the redundant pair must point only to the IP address of its local DHCP server. In other words, the DHCP messages received on one DHCP server should never be relayed to the other. Because the IP address-ranges and 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 allows 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 by SRRP awareness. The 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 are advertised to the network side only from the actively serving node (SRRP master state or active MC-LAG node). This is performed indirectly with the corresponding subscriber-interface route that is aligned (by configuration) with the DHCP address range or prefix in access-driven mode.

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

Multi-chassis redundancy relies on MCS to synchronize various client applications. (subscriber states, DHCP states, IGMP states, and so on) between the two chassis. Therefore, the links over which MCS peering session is established must be highly redundant. Failed MCS peering session renders 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 described in DHCP failover scenarios .

A possible deployment scenario is shown in Failover scenario with SRRP and DHCP in access-driven mode.

Some deployments require that the remote IP address and prefix range starts delegating new IP addresses and 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 and 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:

• The partner-down-delay must be set to 0. This causes 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 and prefix can be taken over only in PARTNER-DOWN state, when the MCLT expires.

• The ignore-mclt-on-takeover flag must be enabled. With this flag enabled, the remote IP address and 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. By setting this flag, the lease times of the existing DHCP clients, while the intercommunication link is in the PARTNER-DOWN state, are reduced to the MCLT over time and all new lease times are set to MCLT. This behavior remain the same as originally intended for MCLT. this functionality must be exercised with caution. Be mindful 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 because of the failure of intercommunication link. These timers (partner-down-delay and MCLT) would ensure that during their duration, the new IP addresses and prefixes are delegated only from one node, the one with local IP address-range and prefix. The drawback is that the new IP address delegation is delayed and service is impacted.

If the intercommunication link could be guaranteed to always available, then the DHCP nodes would stay in sync and the two timers would not be needed. Therefore it is important 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 because in this case only one DHCP node is available to provide new IP addresses and prefixes.