DHCP management

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 the 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 DHCP working group including the following:

  • RFC 1534, Interoperation Between DHCP and BOOTP

  • RFC 2131, Dynamic Host Configuration Protocol

  • RFC 2132, DHCP Options and BOOTP Vendor Extensions

  • RFC 3046, DHCP Relay Agent Information Option

The DHCP operation is shown in IP address assignment with DHCP.

Figure 1. IP address assignment with DHCP
  1. During bootup, the client device sends a DHCP discover message to get an IP address from the DHCP Server. The message contains:

    • destination MAC address

      broadcast

    • source MAC address

      the MAC address of the client device

    • client hardware address

      the MAC address of the 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, and so on, 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 relays the discover message as a unicast packet toward the configured DHCP server. DHCP relay is configured to insert the GIADDR (gateway IP address) to indicate to the DHCP server in which subnet an address should be allocated.

  2. The DHCP server looks up 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 is assigned and a DHCP offer message returned. The BSA or BSR then relays this back to the client device.

  3. It is possible that the discover reached more than one DHCP server and more than one offer is returned. The client selects one of the offered IP addresses and confirms that 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 also contains the Lease Time of the IP address.

DHCP features

DHCP relay

Because DHCP requests are broadcast packets that normally do 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 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 therefore is only supported in IES services and VPRN services. VPRN is only supported on the 7750 SR.

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 VPRN 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 shown in Unicast renewal routing problem. 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 2. Unicast renewal routing problem

The unicast renewal routing problem shown in Unicast renewal routing problem 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 shown in Relay unicast messages:

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

  • In the server to client direction, the GI address field is removed and the destination IP address is updated with the value of the 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 Relay unicast messages.

DHCPv4 FORCERENEW messages that are sent from a trusted external DHCPv4 server to a DHCPv4 relay agent configured as a relay proxy are forwarded to the DHCP client, if a corresponding DHCPv4 lease exists; otherwise, the DHCPv4 FORCERENEW messages are dropped.

Figure 3. Relay unicast messages

The 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 toward 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:

  • In all DHCP messages to the client, the value of the following header fields and DHCP options containing the DHCP server IP address is replaced with the configured IP address:

    • the source IP address

    • the siaddr field in the DHCPv4 header if it is not equal to zero in the message received from the server

    • the Server Identification option (DHCPv4 option 54) if present in the original server message

  • The DHCP OFFER selection occurs 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 is 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.

DHCP server IP address hiding/initial binding 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 4. DHCP server IP address hiding/initial binding

DHCP server IP address hiding/lease renewal 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 shown in DHCP server IP address hiding, lease renewal with active server failure.

Figure 5. DHCP server IP address hiding/lease renewal
Figure 6. DHCP server IP address hiding, lease renewal with active server failure

DHCP server IP address hiding, release 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 7. 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 with a double DHCPv4 relay (Layer 3 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

DHCP lease split

The DHCP lease split function enables the use of shorter lease times toward the DHCP client than the lease time committed by the DHCP server. The DHCP relay lease split function can be used for:

  • liveness detection of DHCP clients, so that addresses or prefixes of inactive clients can be reclaimed sooner without generating a high volume of control traffic toward the DHCP server

  • BNG reachability verification by DHCP clients without the need for an additional protocol

DHCPv4

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 (LTs).

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

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

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

  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 (LTs).

Figure 8. DHCPv4 relay lease split

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 (LTs) in the DHCP ACK message.

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

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

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

  5. When the short lease time (LTs) 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 (LTs) instead of the long lease time (LT).

Figure 9. DHCPv4 lease split – DHCPv4 client disconnects ungracefully

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 (LTs) 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 T2s, the rebinding time of the short lease time (LTs). 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 (LTs) on behalf of the server that committed the lease.

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

    • the remaining long lease time (LTr) is less than the short lease time (LTs) + 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 T2s, the rebinding time of the short lease time (LTs). 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 (LTs) on behalf of the server that committed the lease.

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

  8. The DHCP Relay Agent answers the next DHCP client renew request with the remaining long lease time (LTr) 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 T1r, the renew time of the remaining long lease time (LTr)) 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 T2r, the rebind time of the remaining long lease time (LTr)) and all retransmissions to all configured DHCP servers. No answer is received from any DHCP server.

  11. When the remaining long lease time (LTr) 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.

Figure 10. DHCPv4 lease split unreachable DHCPv4 servers

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 ---
Note:
  • DHCPv4 lease split is supported for routed CO (IES and VPRN services, DHCP relay, and DHCP proxy) and bridged CO (VPLS service and DHCP snooping) deployment models.

  • For bridged CO, the BNG does not answer on behalf of the server when the client is in rebinding state and the DHCP servers are unreachable. The DHCP client lease times out and the corresponding subscriber host state is deleted from the system when the short lease time LTs expires.

DHCPv6

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
Note:
  • DHCPv6 lease split is supported for routed CO DHCP relay deployment models.

  • A Lightweight DHCPv6 Relay Agent (LDRA) in front of the DHCPv6 relay lease split is supported.

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:

  • 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

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

sap-id
the SAP index (only under an IES or VPRN service)
ifindex
the index of the IP interface (only under an IES or VPRN service)
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)
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:

Replace
On ingress, the existing information-option is replaced with the information-option parameter configured. On egress (toward the customer), the information option is stripped (per the RFC).
Drop
The DHCP packet is dropped and a counter is incremented.
Keep
The existing information is kept on the packet and the router does not add more 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 client packet is discarded. This packet size limitation exists to ensure that there is 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 toward 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

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.

DHCP snooping

This section discusses the Nokia routers acting as a Broadband Subscriber Aggregator (BSA) with Layer 2 aggregation toward a Broadband Subscriber Router (BSR).

A typical initial DHCP scenario is shown in Initial DHCP scenario.

Figure 11. Initial DHCP scenario

But, when the client already knows its IP address, it can skip the discover, as shown in DHCP scenario with known IP address.

Figure 12. DHCP scenario with known IP address

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

    • to insert Option 82 information (when the system is not configured to do DHCP Relay), see Subscriber identification using Option 82 field.

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

  2. From the DHCP server (ACK messages):

    • to remove the Option 82 field toward the client

    • to build a dynamic DHCP lease state table for security purposes, see section DHCP lease state table

    • to perform Enhanced Subscriber Management, see Triple Play Enhances Subscriber Management

    For these applications, DHCP snooping must be enabled on both the SAP and SDP toward the network and the SAP toward 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 therefore 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, and so on.

DHCP lease state table

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

Figure 13. 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.

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

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

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

  • To populate the system’s ARP cache using the arp-populate feature. The arp-populate functionality is only available for static and dynamic hosts associated with IES and VPRN SAP IP interfaces.

  • 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 automatically populates into the VPLS forwarding database associated with the SAP on which the host is learned. The dynamic host MAC address overrides 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 to Routed Central Office (CO).

  • To support Enhanced Subscriber Management, see RADIUS Authentication of Subscriber Sessions.

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

Figure 14. CMTS/WAC network configuration example

DHCPv6 snooping

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

Local DHCP servers

Overview

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.

Note: The local DHCP server does 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 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.

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

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

DHCPv6

In the stateful auto-configuration model, hosts obtain interface addresses and 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 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).

Neighbor resolution with DHCPv6 relay

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

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

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

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 addresses. The scope of selection is the pool or a prefix range within the pool.

IPv6 address and 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, 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.

IPv4/IPv6 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 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.

Host connectivity checks for IPv6

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.

Lease query

A lease query by client-id as defined in RFC 5007, DHCPv6 Lease Query, is supported for Local DHCPv6 servers. For security reasons this must be explicitly enabled using the CLI command 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 always returns all addresses for a client. The Relay Data and Client Link options are not supported and are not 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 always takes precedence. The to-client and to-server option is inserted in the inner most level of the DHCPv6 packet. ESM IPoE subscriber can also use the user-db to insert to-server option. IPoE ESM subscribers are not limited to only to-client and to-server option and can use all other parameters configurable under config>subscr-mgmt>loc-user-db>ipoe>host> in LUDB.

Allow client ID change for DHCPv6

The client IDs of incoming DHCPv6 packets are strictly checked. Packets with different client IDs from an existing lease state are treated as suspicious and discarded.

Execute the following commands on a group interface for IES/VPRN or subscriber interface for retailer IES/VPRN, to configure client ID changes for interoperability:

  • MD-CLI
    configure service ies string subscriber-interface string group-interface string ipv6 dhcp6 allow-client-id-change
    configure service vprn string subscriber-interface string group-interface string ipv6 dhcp6 allow-client-id-change
    configure service ies string subscriber-interface string ipv6 dhcp6 allow-client-id-change
    configure service vprn string subscriber-interface string ipv6 dhcp6 allow-client-id-change
  • Classic CLI
    configure service ies subscriber-interface group-interface ipv6 dhcp6 allow-client-id-change
    configure service vprn subscriber-interface group-interface ipv6 dhcp6 allow-client-id-change
    configure service ies subscriber-interface ipv6 dhcp6 allow-client-id-change
    configure service vprn subscriber-interface ipv6 dhcp6 allow-client-id-change

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 through 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 are 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 the 7750 SR and 7450 ESS. 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. When 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 7750 SR and 7450 ESS. This Python script intercepts incoming DHCP messages on the access side (Discover/Solicit/Request/Renew/Rebind) and consequently creates a host identification string based on DHCP options in the packet. This string then is 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 through 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 the correct 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 7750 SR and 7450 ESS. This ensures that the information about the subscriber host is readily available when the DHCP packet from the DHCP server arrives. Furthermore, because 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 ESM module. Python writes the result of its processing to it and the Enhanced Subscriber Management (ESM) module within 7750 SR and 7450 ESS can 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, Advertise>, <Request, Reply>, <Renew, Ack>, and so on).

Flexible creation of DHCPv4/6 host parameters

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

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

  • 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, and so on) present in the DTC 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 by DTC (Python), LUDB and RADIUS, the one provided by DTC is in effect. This prioritization occur automatically without any additional CLI.

For example, if the IPv4 address is provided by DTC during DHCP Discovery processing, then the mode of operation for this host is proxy-to-dhcp (ESM terminates DHCP, without going to the server), regardless of whether the IP address is also provided by 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 or 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 is 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 needed in one or more entries. The key can be any arbitrary string (printable ASCII characters), up to 32 bytes. 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.

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 7750 SR and 7450 ESS by 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)

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 are predefined (only these can be used) and are described in ESM-related Python variables . 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 1. 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.spiSharingGroupId

integer

identification-strings >spi-sharing-group-id

Alc-SPI-Sharing-Id

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

Alc-Secondary-Dns

Client-DNS-Sec

alc.dtc.primNbns

string

options>netbios-name-server

Alc-Primary-Nbns

RB-Client-NBNSPri

alc.dtc.secNbns

string

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.dtc.msapServiceId

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-wan-address-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

alc.dtc.dhcpv4GIAddr

string

gi-address

alc.dtc.dhcv4ServerAddress

string

server

alc.dtc.dhcp4SrcAddr

string

alc.dtc.dhcp4Pool

string

address>pool

Framed-Pool

Ip-Address-Pool-Name

prim | sec (‟|” – delimiter)

alc.dtc.linkAddress

string

link-address

alc.dtc.dhcp6SrcAddr

string

alc.dtc.dhcv6ServerAddr

string

server6

alc.dtc.setDhcpv6LinkAddr

string

link-address

This API applies only to regular numbered or unnumbered IPv6 interfaces (no ESM)

alc.dtc.setDhcpv6ServerAddr

string

server6

This API applies only to regular numbered or unnumbered IPv6 interfaces (no ESM)

alc.dtc.ipv6PrimDns

string

options6>dns-server

Alc-Ipv6-Primary-Dns

alc.dtc.ipv6SecDns

string

Alc-Ipv6-Secondary-Dns

alc.dtc.dhcpv6PreferredLifetime

integer

ipv6-lease-times>preferred-lifetime

Alc-v6-Preferred-Lifetime

alc.dtc.dhcpv6RebindTimer

integer

ipv6-lease-times>rebind-timer

Alc-Dhcp6-Rebind-Time

alc.dtc.dhcpv6RenewTimer

integer

ipv6-lease-times>renew-timer

Alc-Dhcp6-Renew-Time

alc.dtc.dhcpv6ValidLifetime

integer

ipv6-lease-times>valid-lifetime

Alc-v6-Valid-Lifetime

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 with DTC. These options should be configured with RADIUS (Alc-ToCLient-Dhcp-Options IPv4 only) or they can be inserted directly into DHCP messages with Python (bypassing DTC).

Other possible uses for DTC variables are:

  • Assigning routing context information with Python (service-id, msap, msap-policy, retail service-id, and so on). For example, AN can insert specific hints in various DHCP options that would suggest (by Python) the service context to place the subscriber host.

  • IP address assignment by 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, and so on).

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

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 requests 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 also calculates 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 (by SNMP or CLI) with a specific 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 by 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 multichassis synchronization. To support multichassis 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:

  • simplified IP address reservation

    It is not necessary to provision LUDB entries and exclude ranges for sticky leases. After the lease is reserved in the local DHCP server (triggered by an external system by 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.

  • 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 using the sticky lease mechanism and then assign this to a static host without risking overlap.

DHCP message processing overload protection

A DHCP message processing overload condition occurs when the arrival rate of DHCP packets is higher than what the applications can process. For example, when inadequate lease times are used in a scaled BNG setup. The SR OS measures and reports DHCP message processing overload and acts upon it by selectively dropping DHCP messages for new connections before DHCP messages for ongoing sessions. When in overload, DHCP messages are dropped in following order (similar for DHCPv6):

  • Discover

  • Offer

  • Other DHCP messages

  • Renew

  • Ack

When DHCP message drops occurred within the last 5 minute interval, then a ‟DHCP message processing overload detected: true” trap is generated. When no DHCP message drops occurred in the last 5 minutes interval, a ‟DHCP message processing overload detected: false” trap is generated as shown in the following example:

A:pe1# show log event-control "svcmgr" 2572
=======================================================================
Log Events
=======================================================================
Application
ID#    Event Name                       P   g/s     Logged     Dropped
-----------------------------------------------------------------------
   2572 tmnxSubDhcpOverloadDetected      WA  thr          0           0
=======================================================================

The DHCP message processing overload state can also be checked with the show>subscriber-mgmt>status system command. The following output displays an example.

A:pe1# show subscriber-mgmt status system
===============================================================================
Subscriber Management System Status
===============================================================================
Chassis 1
-------------------------------------------------------------------------------
Memory usage high                                       : No
DHCP message processing overload                        : No
Statistics usage high                                   : No
Number of subscribers using statistics                  : 0

Data-trigger statistics
-------------------------------------------------------------------------------
Packets received                                        : 0
Packets dropped                                         : 0
Packets in queue (actual)                               : 0
Packets in queue (peak)                                 : 0

Bridged Residential Gateway statistics
-------------------------------------------------------------------------------
BRG initialized                                         : 0
BRG operational                                         : 0
BRG in connectivity verification                        : 0
BRG on hold                                             : 0
BRG authenticated by proxy                              : 0

Subscriber VLAN statistics resources
-------------------------------------------------------------------------------
Administrative state                                    : out-of-service
Number of entries                                       : 0
===============================================================================

Statistics for dropped DHCP packets can be displayed and cleared with the tools>dump>dhcp-rx-stats command. The following output displays an example.

A:pe1# tools dump dhcp-rx-stats
===============================================================================
DHCP Received Packet Statistics
===============================================================================
     Type                  Received     Forwarded       Dropped  Dropped(ESM)
-------------------------------------------------------------------------------
IPv4 DISCOVER                     0             0             0             0
     OFFER                        0             0             0             0
     REQUEST                      0             0             0             0
     DECLINE                      0             0             0             0
     ACK                          0             0             0             0
     NAK                          0             0             0             0
     RELEASE                      0             0             0             0
     INFORM                       0             0             0             0
     FORCERENEW                   0             0             0             0
     LEASEQUERY                   0             0             0             0
     LEASEUNASSIGNED              0             0             0             0
     LEASEUNKNOWN                 0             0             0             0
     LEASEACTIVE                  0             0             0             0
     RENEW                        0             0             0             0
-------------------------------------------------------------------------------
IPv6 SOLICIT                      0             0             0             0
     ADVERTISE                    0             0             0             0
     REQUEST                      0             0             0             0
     CONFIRM                      0             0             0             0
     RENEW                        0             0             0             0
     REBIND                       0             0             0             0
     REPLY                        0             0             0             0
     RELEASE                      0             0             0             0
     DECLINE                      0             0             0             0
     RECONFIGURE                  0             0             0             0
     INFO_REQUEST                 0             0             0             0
     RELAY_FORW                   0             0             0             0
     RELAY_REPLY                  0             0             0             0
     LEASEQUERY                   0             0             0             0
     LEASEQUERY_REPLY             0             0             0             0
-------------------------------------------------------------------------------
     Total                        0             0             0             0
-------------------------------------------------------------------------------
Maximum queue length          : 0
Maximum outst pbufs total     : 0
Maximum outst pbufs to client : 0
===============================================================================

DHCPv4 offer and DHCPv6 advertise selection parameters for DHCP relay

When multiple DHCP servers in the network offer an IP address or prefix, the DCHP client must choose a server from which to request configuration parameters. In some network designs, such as a stateless multichassis redundant BNG deployment, the load balancing of IPoE subscriber sessions can be optimized by influencing the server selection at the DHCP relay. This is similar to using a pado-delay for PPPoE subscriber sessions. See DHCPv4 relay offer selection parameters.

Figure 15. DHCPv4 relay offer selection parameters

In DHCPv4 relay offer selection parameters, the DHCPv4 client on the RGW connects and broadcasts a DHCPv4 Discover message to obtain an IP configuration. Both the BNG 1 and BNG 2 relay agents receive the Discover message with the Layer 2 aggregation network between the Access Node and the BNGs. The DHCP Relay Agent function on BNG 1 is configured to delay the Discover message before sending it to the DHCPv4 Server S1, while the DHCP Relay Agent function on BNG 2 immediately forwards the Discover message to DHCPv4 server S2. As a result, the DHCP Offer from DHCPv4 Server S2 reaches the DHCP client first. The client selects the Offer from DHCP Server S2 and broadcasts a DHCP Request with the server identifier option set to Server S2. The BNG1 and BNG2 relay agents both forward the Request to their DHCP servers. DHCPv4 Server S1 ignores the Request targeted to server S2. DHCPv4 Server S2 Acknowledges the lease. The subscriber session is created on BNG 2 and the DHCPv4 Ack is sent to the RGW.

Similar results can be achieved for DHCPv6 clients by delaying the DHCPv6 Solicit message or by inserting a Preference Option in the DHCPv6 Advertise message to the client.

Note: The DHCPv4 Offer Selection and DHCPv6 Advertise Selection is a function of the DHCP client. This feature provides a non-standardized mechanism to influence the client's decision at the DHCP Relay, but ultimately the client decides which server is selected.

DHCPv4 offer selection parameters on a subscriber group-interface DHCP relay

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.

DHCPv6 advertise selection parameters on a subscriber group-interface DHCP6 relay

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.

Lightweight DHCPv6 Relay Agent

This section describes Lightweight DHCPv6 Relay Agent (LDRA) functionality.

LDRA in a VPLS service

Note: LDRA is only supported on VPLS SAPs.

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.

Figure 16. DHCPv6 Solicit/Advertise message flow with LDRA 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.

Figure 17. DHCPv6 message forwarding 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.

DHCP release messages

A DHCP client can send a release message to the server to indicate that the address assigned in the lease is not used. The BNG configured as DHCP relay or relay proxy can also send a release message to the server on behalf of the client in the following cases:

  • the drop of a DHCPv4 ACK or DHCPv6 reply message caused by a host creation failure, for example, when there are not enough resources or there is a duplicate host

  • sla-profile or sub-profile host and session limit enforcement

  • lease time expiration when lease split is active

  • Subscriber Host Connectivity Verification (SHCV) connectivity loss with action lease removal

  • an IPoE session timeout

  • manual clearing of an IPoE session or lease state; a DHCP release message is not sent when the optional no-dhcp-release parameter is specified in the clear service id dhcp lease-state or clear service id dhcp6 lease-state commands.

The BNG does not send a DHCP release message on behalf of the client when the remaining lease time is less than 5 minutes.

The release-include-gi-address command configured in the dhcp context of an interface sets the gateway IP Address (giaddr) field in the DHCPv4 release messages to the configured GI address. By default, the giaddr field in a DHCPv4 release message is transparently forwarded as received from the client or set to 0.0.0.0 when the DHCPv4 release message is sent by the BNG on behalf of the client.

Proxy DHCP server

This section describes the implementation of proxy DHCP server capability to provide a standards-based DHCP server which front-ends to a downstream DHCP client, DHCP relay enabled devices, and interfaces with RADIUS to authenticate the IP host and subscriber and obtains 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 (Typical DHCP deployment scenarios).

Figure 18. 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:

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

    • end user notebooks, desktops, and servers

    • residential gateways and CPE routers

    • IP phones

    • set-top boxes

    • wireless access points

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

    • residential gateways and CPE routers

    • DSLAMs

    • edge aggregation routers

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

    • dedicated standalone servers

    • residential gateways and CPE routers

    • edge aggregation routers

    • centralized management systems

DHCP is the predominant address management protocol in the enterprise community, however in the provider market PPP has traditionally been how 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. Most 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 are 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.

  • Interact with downstream DHCP client devices and DHCP relay agents in the path.

  • Interface with RADIUS to authenticate DHCP requests.

  • Receive all the necessary IP information to properly respond to a DHCP client.

  • Override the allocated IP address lease time, if necessary, for improved IP address management.

Aggregation network with DHCP to RADIUS authentication shows a typical DHCP initial bootup sequence with the addition of RADIUS authentication. The proxy DHCP server interfaces with downstream DHCP client devices and then authenticate upstream using RADIUS to a provider’s subscriber management system.

Figure 19. Aggregation network with DHCP to RADIUS authentication

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:

  • Provision objects related to a specific DHCP host such as a subscriber and SLA policy.

  • Provide IP addressing information to a DHCP client.

  • Support the features that leverage DHCP lease state.

    • dynamic ARP population

    • ARP reply agent

    • anti-spoofing filters

    • MAC pinning

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

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:

  • Juniper (vendor-id 4874) attributes 4 (Primary DNS server) and 5 (Secondary DNS server).

  • Redback (vendor-id 2352) attributes 1 (Primary DNS) and 2 (Secondary DNS).

  • Juniper attributes 6 and 7 (Primary and Secondary NetBIOS nameserver).

  • Redback attributes 99 and 100 (Primary and Secondary NetBIOS nameserver).

The following attributes can be sent to RADIUS:

  • Sending authentication requests: (from the DSL Forum) (vendor-id 3561), attributes 1 (Circuit ID) and 2 (Remote ID).

  • 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 Nokia VSAs is available on a file included on the compact flash shipped with the image.

Local DHCP servers

Terminology

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

Overview

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

Table 2. DHCPv4 message flow

DHCP discover

DHCP client — DHCP server

DHCP Offer

DHCP server — DHCP client

DHCP Request

DHCP client — DHCP server

DHCP Sync Message

DHCP server — by MCS to the peering DHCP server

DHCP Ack

DHCP server— DHCP client

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.

Figure 20. 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.

Intercommunication link failure detection

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.

DHCP server failover states

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.

Lease time synchronization

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.

    Figure 21. 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 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

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

Sharing IPv4 address range or IPv6 prefixes

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 .

Table 3. DHCP failover scenarios
Access related failure Inter-chassis link state Number of failures Action

None

None

None

Only the multichassis active BNG (SRRP master state) grants IP leases.

The subnet tied to the SRRP instance is advertised to the network side on the multichassis active BNG.

None

COMM-INT

Possibly multiple

Only the (SRRP master state) BNG (SRRP master state) grants 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 and 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 scenario.

Access Link Towards the multichassis active BNG (SRRP master state)

NORMAL

Single

SRRP switches over. The new IP lease grants continues from new multichassis active BNG (SRRP master state) using the same IP address range. IP leases are synched OK. Subnets are advertised from new multichassis active BNG by SRRP state awareness.

Access Link Towards the multichassis active BNG (SRRP master state)

COMM-INT

Multiple

SRRP switch over. The new leases can be handed from the DHCP server on the newly multichassis active BNG (SRRP master state). However, this DHCP server may not have its lease state table up to date because the inter-chassis communication link is non-operational.

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

Therefore it of the 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 multichassis active BNG (SRRP master state)

PARTNER-DOWN

Multiple

Same as above.

Access Link Towards the multichassis standby BNG (SRRP standby state)

NORMAL

Single

No effect on the operation because everything is active on the multichassis active BNG (SRRP master state) anyway.

Access Link Towards the multichassis standby BNG (SRRP standby state)

COMM-INT

Multiple

Intercommunication link is broken. The multichassis active BNG (SRRP master state) continues handing out the new leases and renewing the old ones. However, they are not synchronized to the peering node.

Access Link Towards the multichassis standby BNG (SRRP standby state)

PARTNER-DOWN

Multiple

Same as above.

Entire multichassis active BNG (SRRP master state)

COMM-INT

Single

SRRP switches over. However, lease duplication may occur on the new multichassis active BNG because the intercommunication link is broken and this new multichassis active BNG is not aware of DHCP leases that the peer (failed node) may have allocated to the clients while the intercommunication-link was broken.

Entire multichassis active BNG (SRRP master state)

PARTNER-DOWN

Single

Same as above.

Entire multichassis standby BNG (SRRP standby state)

COMM-INT

Single

Operation continues, but multichassis redundancy is lost.

Entire multichassis standby BNG (SRRP standby state)

PARTNER-DOWN

Single

Same as above.

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

Figure 22. Failover scenario with SRRP and DHCP in access-driven mode

Fast-switchover of IP address and prefix delegation

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.

DHCP server synchronization and local PPPoX pools

Because there is no classical DHCP lease state maintained for local PPPoX pools, the IP addresses are not synchronized by the DHCP server. Instead they are synchronized through PPPoX clients. After the PPPoX subscriber is synchronized, the respective IP address lease is updated in the respective local pool.

For example:

  • A PPPoE client is created on 7750 SR and 7450 ESS ‛A’.

  • The IP address is assigned from the local poll on 7750 SR and 7450 ESS ‛A’.

  • The PPPoE client is synchronized to the peering node 7750 SR and 7450 ESS ‛B’.

  • After the client is synchronized in the 7750 SR and 7450 ESS ‛B’, the IP address assignment is synchronized by the internal PPPoE process on the 7750 SR and 7450 ESS ‛B’ with the local pool.

One artifact of this behavior (IP address assignment in local DHCP pools is synchronized through PPPoX clients and not by DHCP server synchronization mechanism) is that during the node boot, the DHCP server must wait for the completion of PPPoX subscriber synchronization by MCS so that it learns which addresses and prefixes are already allocated on the peering node. Because the DHCP server can theoretically start assigning IP addresses before the PPPoX sync is completed, a duplicate address assignment may occur. For example, an IP address lease can be granted by DHCP local pools while PPPoX sync is still in progress. After 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 is kept and the other is removed from both systems. To prevent this scenario, a configurable timer can be set to an arbitrary value that renders 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 autoconfiguration

In the stateless autoconfiguration 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 use the local pool for SLAAC prefix assignment, the command local-address-assignment is used under group-interface. The client-application type ppp-slaac or ipoe-slaac must first be specified. Afterwards, the server name of the local-address-server must also be provisioned.

Local address assignment and multichassis redundancy

The internal leases for local address assignment are not synchronized through the local DHCP server multichassis synchronization (MCS) application. Instead, the SLAAC prefix is synchronized to the standby BNG through the subscriber management PPPoE or IPoE application. The standby BNG then creates an internal lease in the local DHCP server to be used for the local address assignment. Local address assignments fail when local DHCP server failover is configured at the server or pool level.

Configuring DHCP with CLI

This section provides information to configure DHCP using the command line interface.

Enabling DHCP snooping

DHCP snooping is the process of copying DHCP packets and using the contained information for internal purposes. The BSA and BSR can use the snooped DHCP information to build anti-spoofing filters, populate the ARP table, send ARP replies, and so on.

For VPLS, DHCP snooping must be explicitly enabled (using the snoop command) on the SAP or SDP where DHCP messages ingress the VPLS instance. It is recommended to enable snooping on both the interface to the DHCP server (to snoop ACK messages) and the interface to the subscriber (to snoop RELEASE messages).

For IES and VPRN IP interfaces (VPRN is supported on the 7750 SR only), lease populate enables DHCP snooping for the subnets defined under the IP interface. The number of allowed simultaneous DHCP sessions on a SAP or interface can be limited using the lease-populate command with the parameter number-of-entries specified. Enabling lease-populate and snoop commands is effectively enabling ‟standard subscriber management”.

The following output displays an example of a partial BSA configuration with DHCP snooping enabled in a service:

*A:ALA-48>config>service# info
----------------------------------------------
...
        vpls 600 customer 701 create
            sap 1/1/4:100 split-horizon-group "DSL-group2" create
                description "SAP towards subscriber"
                dhcp
                    lease-populate 1
                    option
                        action replace
                        circuit-id
                        no remote-id
                    exit
                    no shutdown
                exit
            exit
            mesh-sdp 2:800 create
                dhcp
                    snoop
                exit
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-48>config>service#

Configuring local user database parameters

A local user data base defines a collection of host entries. There are two types of hosts: PPP and IPoE. A local user database can be used to:

  • Authenticate PPP clients. For this only the host entries configured in the ppp CLI are matched.

  • Authenticate IPoE hosts (DHCPv4, DHCPv6 IA-NA/IA-PD, SLAAC). The host entries configured in the ipoe CLI context are matched.

  • Perform authentication and address management for the local DHCPv4 server. For this, both PPP and IPoE sections can be used depending on the client type indicated by a vendor-specific sub-option inside Option 82 of the DHCPv4 message.

Each host can be identified by a set of values. However, at any point in time only four of these values are considered for IPoE as defined by the ipoe match-list option and only three are considered for PPP as defined in the ppp match-list option.

When trying to find a matching host entry, attempts are made to match as many items as possible. If several hosts match an incoming IPoE packet, the one with most match criteria is taken.

One host entry can map on several physical clients. For instance, when using a circuit ID, by masking when the interface ID is used, the host entry is used for all the clients on that same interface.

IPoE host identification includes:

  • circuit ID

    This field also matches the DHCPv6 interface-id field

  • MAC address

  • remote ID

    Matches on the remote-id sub-option in option 82 for DHCPv4 clients and on the remote-id option (including enterprise-id field) for DHCPv6 clients

  • Option 60 from DHCPv4 message

    Only first 32 bytes are looked at

  • SAP ID

  • service ID

  • string from vendor-specific sub-option of Option 82

  • system ID

  • derived-id

    a string provided via a DHCP Python script

  • dual-stack-remote-id

    matches on the remote-id sub-option in option 82 for DHCPv4 clients and on the remote-id field in the remote-id option (without enterprise-id) for DHCPv6 clients

  • encap-tag-range

    matches on VLAN tag ranges

  • IP

    matches on the source IPv4/IPv6 address of a data-trigger packet

PPP host identification includes:

  • circuit ID

  • MAC address

  • remote ID

  • username, either complete username, domain part only, or host part only

  • derived ID

    a string provided by Python script

When a host cannot be inserted in the lookup database, it is placed in an unmatched-hosts list. This can occur because

  • Another host with the same host-identification exists. Only the host-identification that is specified in the match-list is considered.

  • A host has no host-identification specified in the match-list.

When used for PPPoE-authentication, the fields are used as follows:

  • password

    Verifies the PPPoE user password. This is mandatory. If no password is required then it must be explicitly set to ignore.

  • address

    • no address

      No address information. The address must be obtained by other means, either RADIUS or DHCP server.

    • gi-address

      No meaning in this context. The address must be obtained by other means, either RADIUS or DHCP server.

    • use-pool-from-client

      No meaning in this context. The address must be obtained by other means, either RADIUS or DHCP server.

    • pool-name

      The address must be obtained by other means, either RADIUS or a DHCP server. When a DHCP server is used, this pool name is included in Option 82 vendor-specific sub-option.

    • ip-address

      This IP address is offered to the client.

  • identification-strings

    Returns the strings used for enhanced subscriber management (ESM).

  • options

    Only DNS servers and NBNS server are used, others are ignored.

When used from the DHCP server, the following applies:

  • password

    Not used.

  • address

    Defines how the address must be allocated for this host.

    • no address

      The host is not allowed. The clients mapping to this host do not get an IP address.

    • gi-address

      Finds the matching subnet and an IP address is taken from that subnet.

    • pool-name

      A free IP address is taken from that pool.

    • ip-address

      This address is offered to the client.

    • use-pool-from-client

      Use the poolname in the Option 82 vendor-specific sub-option. If no poolname is provided there, falls back to the DHCP server default (none or use-gi-address).

  • identification-strings

    The operator can specify subscriber management strings and in which option the strings are sent back in dhcp-offer and dhcp-ack messages.

  • options

    The operator defines which options specific to this host should be sent back in the dhcp-offer and dhcp-ack messages. The options defined here override options defined on the pool-level and subnet-level inside the local DHCP server.

The circuit ID from PPPoE or from Option 82 in IPoE messages can be masked in following ways:

  • prefix-length

    Drop a fixed number of bytes at the beginning of the circuit-id.

  • suffix-length

    Drop a fixed number of bytes at the end of the circuit-id.

  • prefix-string

    The matching string is dropped from the beginning of the circuit-id. The matching string can contain wildcards (*). For example: incoming circuit-id mybox|3|my_interface|1/1/1:22 masked with *|*| leaves my_interface|1/1/1:22.

  • suffix-string

    The matching string is dropped at the end of the circuit-id. For example: incoming circuit-id mybox|3|my_interface|1/1/1:22 masked with |* results in mybox|3|my_interface.

The following is an example of a local user database used for PPPoE authentication:

*A:ALA-48>config>subscr-mgmt# info
----------------------------------------------
...
        local-user-db "pppoe user db"
            description "pppoe authentication data base"
            ppp
                match-list username circuit-id
                mask prefix-string "*|*|" suffix-string "|*"
                host "john" create
                    host-identification
                        username "john" no-domain
                    exit
                    password pap "23T8yPoe0w1R.BPGHB98i0qhJf7ZlZGCtXBKGnjrIrA" hash2
                    no shutdown
                exit
                host "test.com" create
                    host-identification
                        username "test.com" domain-only
                    exit
                    password ignore
                    no shutdown       
                exit
                host "john@test.com" create
                    host-identification
                        username "john@test.com"
                    exit
                    password pap "23T8yPoe0w0Tlf1yCb4hskknvTYLqA2avvBB567g3eQ" hash2
                    identification-strings 122 create
                        subscriber-id "john@test.com"
                        sla-profile-string "sla prof1"
                        sub-profile-string "subscr profile 1"
                        ancp-string "ancp string"
                        inter-dest-id "inter dest"
                    exit
                    no shutdown
                exit
                host "john@test.com on interface group-if"
                    host-identification
                        circuit-id string "group-if"
                        username "john@test.com"
                    exit               
                    password pap "23T8yPoe0w1R.BPGHB98i0qhJf7ZlZGCtXBKGnjrIrA" hash2
                    address 10.1.2.3
                    no shutdown
                 exit
            exit        
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-48>config>subscr-mgmt# 

The following are some examples when a user tries to set up PPPoE:

  • john@test.com tries to set up PPPoE with circuit-id pe_23|3|group-if|1/1/1: host john@test.com on interface group-if match, the PAP password is checked and the IP address 10.1.2.3 is assigned to the PPPoE to use for this host.

  • john@test.com (on another interface): host john@test.com matches, the PAP password is checked, and identification strings are returned to PPPoE.

  • nokie@test.com: host test.com matches, no password check, the user is allowed.

  • john@nokia.com: host john matches and the password is checked.

  • anybody@anydomain: does not match and is not allowed.

The following is an example of a local user database used for DHCP server for IPoE clients:

*A:ALA-50>config>subscr-mgmt# info
----------------------------------------------
...
        local-user-db "dhcp server user db"
            description "dhcp server user data base"
            ipoe
                match-list circuit-id mac 
                mask prefix-string "*|*|" suffix-string "|*"
                host "mac 3 on interface" create
                    host-identification
                        circuit-id string "group-if"
                        mac 00:00:00:00:00:03
                    exit
                    address 10.0.0.1
                    no shutdown
                exit
                host "maskedCircId" create
                    host-identification
                        circuit-id string "group-if"
                    exit
                    address pool "pool 1"
                    identification-strings 122 create
                        subscriber-id "subscriber 1234"
                        sla-profile-string "sla prof 1"
                        sub-profile-string "sub prof 1"
                        ancp-string "ancpstring"
                        inter-dest-id "inter dest id 123"
                    exit
                    options
                        netbios-name-server 1.2.3.4
                        lease-time min 2
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-50>config>subscr-mgmt# 

The following is an access example:

  • MAC 00:00:00:00:00:03 on circuit-id pe5|3|group-if|1/1/1: host mac 3 on interface is matched and address 10.0.0.1 is offered to the IPoE client.

  • Another MAC on circuit-id pe5|3|group-if|2/2/2: host maskedCircId is matched and an address is taken from pool1 (defined in the DHCP server). The identification-strings are copied to Option 122 in the dhcp-offer and dhcp-ack messages. The options defined here are also copied into dhcp-offer and dhcp-ack messages.

  • The circuit-id pe5|3|other_group_if|1/1/3: no host is matched. The client only gets an IP address if on DHCP server level defined the use-gi-address parameter and the gi-address matches a subnet.

The following is an example of a local user database used for a DHCP server, only for PPPoE clients:

If PPPoE does not get an IP address from RADIUS or the local-user-db used for authentication, the internal dhcp-client is used to access a DHCP server which can be in the same node or in another node. These request are identified by inserting Option 82 sub-option client-id in the dhcp-discover and dhcp-request messages. When the DHCP server receives this request and has a user-db connected to it, then the PPPoE section of that user-db is accessed.

*A:ALA-60>config>subscr-mgmt# info
----------------------------------------------
...
        local-user-db "pppoe user db"
            description "pppoe authentication data base"
            ppp
                match-list username
                host "internet.be" create
                    host-identification
                        username "internet.com" domain-only
                    exit
                    address "pool_1"
                    no shutdown       
                exit
                host "john@internet.com" create
                    host-identification
                        username "john@internet.com"
                    exit
                    identification-strings 122 create
                        subscriber-id "john@test.com"
                        sla-profile-string "sla prof1"
                        sub-profile-string "subscr profile 1"
                        ancp-string "ancp string"
                        inter-dest-id "inter dest"
                    exit
                    address use-gi
                    no shutdown
                exit
                host "malicious@internet.com"
                    host-identification
                        circuit-id string "group-if"
                        username "internet@test.com"
                    exit
                    no shutdown
                 exit
            exit        
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-60>config>subscr-mgmt# 

The following is an access example:

  • john@internet.com: GI is used to find a subnet and a free address is allocated form that subnet. Identification strings are returned in Option 122.

  • anybody@internet.com: pool_1 is used to find a free IP address.

  • malicious@internet.com: no address is defined. This user does not get an IP address.

The following is an example of associating a local user database to PPPoE for authentication for the 7750 SR.

A:pe5>config>service>vprn#
----------------------------------------------
            subscriber-interface "tomylinux" create
               address 10.2.2.2/16
               group-interface "grp_pppoe3" create 
                   pppoe 
                       e "pppoe" 
                   exit 
               exit 
----------------------------------------------
A:pe5>config>service>vprn#

The following is an example of associating a local user database to a local DHCP server.

A:pe7>config>router>dhcp# 
----------------------------------------------
                local-dhcp-server my_server
                    description "my dhcp server"
                    user-db "data base 1"
                        ...     
                exit 
----------------------------------------------
A:pe7>config>router>dhcp# 

In PPPoE access scenarios without access node or with access nodes that do not insert PPPoE vendor specific tags Circuit-ID or Remote-ID, it may be required to configure this information in the local user database so that they can be picked up in pre-authentication phase and used for RADIUS authentication and reporting in RADIUS accounting messages. For example:

config>subscr-mgmt

        local-user-db "ludb-1" create
            ppp
                match-list username
                host "host-1" create
                    access-loop-information
                        circuit-id string "LUDB inserted circuit-id"
                        remote-id string "LUDB inserted remote-id"
                    exit
                    host-identification
                        username "cpe-1@domain1.com"
                    exit
                    auth-policy "auth-policy-1"
                    password ignore   
                    no shutdown
                exit
            exit

With PPPoE, when the system accesses a LUDB during a discovery phase, a matched host could return a second LUDB via a user-db configuration under the LUDB host context. This second database is accessed again during the PAP/CHAP phase. The following is an example:

 local-user-db "padi-db" create
            ppp
                match-list derived-id 
                host "testuser" create
                    host-identification
                        derived-id "testuser"
                    exit
                    msap-defaults
                        group-interface "g1"
                        service 500
                    exit
                    user-db "chap-db"
                    no shutdown
                exit
            exit
            no shutdown
        exit
        local-user-db "chap-db" create
            ppp
                match-list derived-id username 
                host "testuser" create
                    host-identification
                        derived-id "testuser"
                        username "testuser"
                    exit
                    password chap "cYhRmQYWOkLW3s0LrtEnBjWlAwFa/1Kx" hash2
                    identification-strings 254 create
                        sla-profile-string "sla-2"
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit

Configuring Option 82 handling

Option 82, or the Relay Information Option is a field in DHCP messages used to identify the subscriber. The Option 82 field can already be filled in when a DHCP message is received at the router, or it can be empty. If the field is empty, the router should add identifying information (circuit ID, remote ID or both). If the field is not empty, the router can decide to replace it.

The following output displays an example of a partial BSA configuration with Option 82 adding on a VPLS service. Snooping must be enabled explicitly on a SAP.

A:ALA-1>config>service>vpls#
----------------------------------------------
            no shutdown
            description "Default tls description for service id 1"
            sap 1/1/11 split-horizon-group "2dslam" create
                dhcp
                    no description
                    snoop
                    no lease-populate
                    option
                        action replace
                        circuit-id ascii-tuple
                        no remote-id
                    exit
                    no shutdown
                exit
            exit
----------------------------------------------
A:ALA-1>config>service>vpls#

Enabling DHCP relay

Lease populate and DHCP relay are different features in which are not both required to be enabled at the same time. DHCP relay can be performed without populating lease tables.

The following example displays DHCP relay configured on an IES interface:

A:ALA-48>config>service>ies>if# info
----------------------------------------------
                address 10.10.42.41/24
                local-proxy-arp
                proxy-arp
                    policy-statement "ProxyARP"
                exit
                sap 1/1/7:0 create
                    anti-spoof ip
                exit
                arp-populate
                dhcp
                    description "relay_ISP1"
                    server 10.200.10.10 10.200.10.20
                    lease-populate 1
                    no shutdown
                exit
----------------------------------------------
A:ALA-48>config>service>ies>if#