8. Appendix: DHCP Management

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

8.1. DHCP Principles

Note:

DHCP relay is only supported on the 7210 SAS-R6 and 7210 SAS-R12.

In a Triple Play network, client devices (such as a routed home gateway, a session initiation protocol (SIP) phone or a set-top box) use Dynamic Host Configuration Protocol (DHCP) to dynamically obtain their IP address and other network configuration information. 7210 autoinit procedure also uses DHCP to dynamically obtain the BOF used for first-time booting of the system (along with IP address required to retrieve the BOF, the configuration file and the Timos software image from the network). DHCP is defined and shaped by several RFCs and drafts in the IETF DHC working group including the following

  1. RFC 2131, Dynamic Host Configuration Protocol
  2. RFC 3046, DHCP Relay Agent Information Option

The DHCP operation is shown in Figure 66.

Figure 66:  IP Address Assignment with DHCP 
  1. During boot-up, the client device sends a DHCP discover message to get an IP address from the DHCP Server. The message contains:
    1. Destination MAC address — broadcast
    2. Source MAC address — MAC of client device
    3. Client hardware address — MAC of client device

If this message passes through a DSLAM or other access node (possibly a 7210 SAS device), typically the Relay information option (Option 82) field is added, indicating shelf, slot, port, VPI, VCI and other fields, to identify the subscriber.

DHCP relay is enabled on the first IP interface in the upstream direction. Depending on the scenario, the DSLAM, BSA or the BSR will relay the discover message as a unicast packet toward the configured DHCP server. DHCP relay is configured to insert the giaddr to indicate to the DHCP server in which subnet an address should be allocated.

  1. The DHCP server will lookup the client MAC address and Option 82 information in its database. If the client is recognized and authorized to access the network, an IP address will be assigned and a DHCP offer message returned. The BSA or BSR will relay this back to the client device.
  2. It is possible that the discover reached more than one DHCP server, and therefore that more than one offer was returned. The client selects one of the offered IP addresses and confirms it needs to use this in a DHCP request message, sent as unicast to the DHCP server that offered it.
  3. 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.

8.1.1. DHCP Features

8.1.1.1. Using Option 82 Field

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

There are two sub-options under Option 82:

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

Both sub-options are supported by the Nokia 7210 SAS and can be used separately or together.

Inserting Option 82 information is supported independently of DHCP relay.

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

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

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

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

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

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

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

In the downstream direction, the inserted Option 82 information should not be passed back 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.

8.1.1.2. Trusted and Untrusted

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

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

8.1.1.3. DHCP Snooping

To support DHCP based address assignment in L2 aggregation network, 7210 supports DHCP snooping. 7210 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; 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. For these applications, DHCP snooping must be enabled on both the SAP toward the network and the SAP toward the subscriber.

8.1.2. Common Configuration Guidelines

8.1.2.1. Configuration Guidelines for DHCP relay and snooping

The following configuration guidelines must be followed to configure DHCP relay and snooping.

  1. 7210 SAS devices does not support the ARP populate based on the DHCP lease, assigned to the DHCP client
  2. 7210 SAS devices does not maintain the DHCP lease assigned to the client
  3. 7210 SAS devices do not perform IP spoofing checks and MAC spoofing checks based on the DHCP parameters assigned to the client
  4. MAC learning must be enabled in the VPLS service, for DHCP snooping.
  5. DHCP snooping is not supported for B-SAPs in B-VPLS services and I-SAPs in I-VPLS services.
  6. Ingress ACLs cannot be used to drop DHCP control packet.
  7. DHCP packets received over a SDP cannot be identified and option-82 inserted by the node cannot be removed by the node, in the downstream direction. If this behavior is not needed user should not enable DHCP snooping in the VPLS service, if the DHCP server is reachable over the SDP (either spoke-sdp or mesh-sdp).

8.1.2.2. Configuring Option 82 Handling

Option 82, or “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 shoulMAC learning must be enabled in the VPLS service, for DHCP snooping.d add identifying information (circuit ID, remote ID or both). If the field is not empty, the router can decide to replace it.

The following is a sample partial BSA configuration with Option 82 adding on a VPLS service. Note that snooping must be enabled explicitly on a SAP.

*A:7210SAS>config>service# 
----------------------------------------------
 
vpls 2 customer 1 create
            shutdown 
            stp
                shutdown
            exit
sap 1/1/12:100 create 
                dhcp                    //Configuration example to add option 82
                    option
                        action replace
                        circuit-id
                        no remote-id
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit
----------------------------------------------
 
*A:7210SAS>config>service# 
 

The following example displays a partial BSA configuration to remove the Option 82 on a VPLS.

vpls 2 customer 1 create      
            stp
                shutdown
            exit
            sap 1/1/14:100 create      //Configuration example to remove option 82
                dhcp
                    snoop
                    no shutdown
                exit
            exit