3.2.4.1. Trusted and Untrusted

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

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

3.2.7.1. DHCPv4 Snooping

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

The mode of operation can be changed for DHCP snooping so that the Layer 2 header MAC address is used instead of the client hardware address from the DHCP packet for the DHCP lease state instantiation. This mode is selected by enabling l2-header in the lease-populate configuration command at the DHCP level. Because SR 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 prior to the SR OS routers. This mode provides compatibility with MAC concentrator devices, and cable modem termination system (CMTS) and WiiMAX Access Controller (WAC).

A configuration example of a cable/wireless network together with subscriber management is shown in Figure 27. 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:

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 27:  CMTS/WAC Network Configuration Example 

3.2.7.2. DHCPv6 Snooping

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

DHCPv6 messages differ from a DHCPv4 messages because it is not mandatory to have the client MAC inside the header or options. The DUID in the DHCPv6 option can be a random generated number instead of the subscriber host’s MAC. The source MAC of the DHCPv6 Ethernet header cannot be used either, because a Layer 3 aggregation network replaces the client’s MAC via routing. From the perspective of the BNG, all DHCPv6 message from the same downstream router has the same source MAC. By default, the BNG utilizes the DHCPv6 Ethernet header source MAC as a host entry identifier. Therefore, it is mandatory to use the interface ID in addition to the source MAC to identify a host individually. If the interface ID is unavailable, it is possible to use python to copy another unique ID, such as DUID or remote ID, into the interface id. The interface ID option must be on the same level as the relay forward header. Together, the interface ID and the DHCP relay MAC address 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 IPv6 ESM host, it is mandatory that each host have a unique /64 prefix. Service providers who wish to share the /64 prefix among multiple WAN host can utilize the DHCPv6 filter bypass-host-creation na option. All bypass hosts in general require a default host creation as well.

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

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

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

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

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 will not allocate any address if none of the above options are configured (no user-db, no use-gi-address, no use-pool-from-client).

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

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

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

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

DHCP server scenarios include:

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

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

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

3.2.9.3. 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 doesn’t belong to the subnets of the interface, such a neighbor record should not be created. This could happen when there is a downstream DHCPv6 relay router or prefix delegation requesting router.

3.2.9.4. DHCPv6 Lease Persistency

DHCPv6 lease persistency is supported.

The following features are enabled:

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

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

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

3.2.9.8. 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 via DHCPv6 (IA_NA or PD), existing lease is looked-up and handed out. The lease identification match criterion has been extended beyond DUID to also include interface-id or interface-id and link-local address.

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

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

3.2.9.10. Host Connectivity Checks for IPv6

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

3.2.15.1. 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 via Python, the corresponding DTC entries are shown as part of the matching DHCP message debug.

3.3.1.1. Terminology

3.3.1.2. Overview

7750 SR and 7450 ESS DHCP server multi-homing 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 multi-homing is an integral part of the overall subscriber management multi-chassis protection scheme.

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

Although the subscriber synchronization process and the DHCP lease states synchronization process use the same synchronization infrastructure within 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 vice versa. However, link-only failures become critical when it comes to their interpretation by the protection mechanisms (SRRP, MC-LAG, DHCP server multi-homing). Regardless of nature of the failure, an overall DHCP server multi-chassis 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:

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

3.3.1.3. DHCP Lease Synchronization

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

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

DHCP 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 disjoint from the access links towards the clients. MCS protocol normally runs over a direct link between the two redundant nodes (1) or over backbone links (2) if the direct link is not present. This is shown in Figure 30.

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

3.3.1.4. 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. Once MCS transitions into 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 DB 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 interclasses communication link failed.

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

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

The failure detection of the intercommunication link leads to certain 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.

3.3.1.5. DHCP Server Failover States

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

3.3.1.6. Lease Time Synchronization

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

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

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

In point 3, the primary DHCP server renews the lease time but fails to synchronize it due to its own failure (crash). The secondary server (2) has the old lease time A’ in its database. The next time the client tries to REBIND its address 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 DB is active (4) and the server 2 can extend the lease for the client.

3.3.1.7. Maximum Client Lead Time (MCLT)

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 explained 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 Figure 31.

The sequence of events is the following:

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

3.3.1.8. 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 7750 SR and 7450 ESS DHCP servers in redundant configuration. This single active path is ensured via a protection mechanism in dual-homed environment in the access side of the network. The supported protection mechanisms in the access in 7750 SR and 7450 ESS are SRRP or MC-LAG.

In access-driven DHCP redundancy model, the DHCP relay in each 7750 SR and 7450 ESS node must point only to the IP address of the local DHCP server. In other words, the DHCP messages received on one DHCP server should never be relayed to the other. Since the IP address-ranges 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 via 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 or active MC-LAG node). This is performed indirectly via 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 Table 40.

A possible deployment scenario is shown in Figure 32.

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

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

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 importance that in this mode of operation, the intercommunication link is well protected by providing multiple paths between the two DHCP nodes. The only event that should cause intercommunication link to fail is the entire nodal failure. This failure is acceptable since in this case only one DHCP node is available to provide new IP addresses and prefixes.