[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]

JUNOSe 9.1.x Broadband Access Configuration Guide > Configuring DHCP Relay > Configuring DHCP Relay and BOOTP Relay

Configuring DHCP Relay and BOOTP Relay

The DHCP relay feature relays a request from a remote client to a DHCP server for an IP address. When the router receives a DHCP request from an IP client, it forwards the request to the DHCP server and passes the response back to the IP client.

Configuring DHCP relay also enables bootstrap protocol (BOOTP) relay. The router relays any BOOTP requests it receives to the same set of servers that you configured for DHCP relay. A DHCP server can respond to the BOOTP request only if it is also a BOOTP server. The router relays any BOOTP responses it receives to the originator of the BOOTP request. If you do not configure DHCP relay, then BOOTP relay is disabled.

The router must wait for an acknowledgment from the DHCP server that the assigned address has been accepted. The IP client must accept an IP address from one of the servers. When the DHCP server sends an acknowledgment message back to the DHCP client via the router, the router updates its routing table with the IP address of the client.

If a DHCP relay request is received on an unnumbered interface, the router determines the loopback address for that interface and passes that IP address to the server.

DHCP carries other important configuration parameters, such as the subnet mask, default router, and DNS server. You can also use the DHCP relay agent information option (option 82) to add information to the DHCP packets sent to DHCP servers—the additional information, in the form of suboptions to the option 82 value, helps you to manage the IP address and service level assignments granted to your subscribers. For example, you can add the E-series hostname or the virtual router name to the front of the Agent Circuit ID suboption (suboption 1) of the DHCP relay agent information option (option 82). See Configuring Relay Agent Option 82 Information.

Enabling DHCP Relay

You use the set dhcp relay command to create and enable DHCP relay in the current virtual router.

Issuing this command also enables relay of BOOTP requests to the configured DHCP servers. If one of the DHCP servers is also a BOOTP server and responds, the router relays the response to the request originator.

host1(config)#set dhcp relay 192.168.29.10

Removing Access Routes from Routing Tables and NVS

You can remove existing access routes for an interface from routing tables and nonvolatile storage (NVS).

Treating All Packets as Originating at Trusted Sources

By default, the DHCP relay treats all packets destined for DHCP servers as if the packets originated at an untrusted source; if the packets have a gateway IP address (giaddr) of 0 and if option 82 information is present, these packets are dropped.

In the trust-all method, the DHCP relay treats the packets as if they are from trusted sources and forwards the packets to the DHCP server. When you enable this command:

Assigning the Giaddr to Source IP Address

As a security measure, DHCP servers typically use the giaddr included in DHCP packets to ensure that the packets come from a recognized DHCP gateway. The servers verify that the giaddr in the DHCP packet matches the source IP address in the IP packet header. You can use the set dhcp relay assign-giaddr-source-ip command to specify that the DHCP relay and DHCP relay proxy assign the giaddr to the source IP packet header of packets they send to DHCP servers—the DHCP servers can then compare the giaddr in the IP packet header to the giaddr in the DHCP packets.

Protecting Against Spoofed Giaddr and Relay Agent Option Values

DHCP relay includes an override feature that provides enhanced security to protect against spoofed giaddr and relay agent option (option 82) values in packets destined for DHCP servers.

DHCP relay can detect spoofed giaddrs when the giaddr value is equal to a local IP address on which the DHCP relay can be accessed; otherwise, DHCP relay does not detect spoofed giaddrs. Also, DHCP relay does not detect spoofed relay agent option values.

Spoofed giaddrs are a concern when the DHCP relay is used if the giaddr value in received DHCP packets is different from the local IP address on which the DHCP relay is accessed. In this situation, DHCP relay always honors the giaddr. To configure DHCP relay to override all giaddrs (including valid giaddrs) that are received from downstream network elements, use the set dhcp relay override command with the giaddr keyword. DHCP relay then takes control of the client, adding its own giaddr to the packets before forwarding the packets to the DHCP server.

Spoofed relay agent options are a concern if the giaddr is not null, or if it is null and the DHCP relay is operating in the trust-all method. In these two situations, DHCP relay always honors the relay agent option value in received DHCP packets.

DHCP relay then overrides all relay agent option values that are received from downstream network elements, performing one of the following actions:

Using the Broadcast Flag Setting to Control Transmission of DHCP Reply Packets

Each DHCP request packet includes a broadcast flag that, if set, specifies how to transmit DHCP Offer reply packets and DHCP ACK and NAK reply packets to DHCP clients during the discovery process. To configure DHCP relay and DHCP relay proxy to use the setting of the broadcast flag to control the transmission of DHCP Offer, DHCP ACK, and DHCP NAK reply packets, use the set dhcp relay broadcast-flag-replies command from Global Configuration mode.

When you issue the set dhcp relay broadcast-flag-replies command, the method that DHCP relay and DHCP relay proxy use to transmit DHCP Offer reply packets and ACK and NAK reply packets depends on whether the broadcast flag in the DHCP request packet is set or not set, as follows:

There are exceptions to this behavior for DHCP relay proxy when the DHCP client is already bound to an IP address or is renewing the lease on its IP address. For information, see Behavior for Bound Clients and Address Renewals.

To display whether support for broadcast flag replies is currently on or off on the router, use the show dhcp relay command. For information, see Chapter 22, Monitoring and Troubleshooting DHCP.

To troubleshoot applications that use this feature, you can use the dhcpCapture system event log category. For information about how to log system events, see JUNOSe System Event Logging Reference Guide, Chapter 1, System Logging Overview.

Interaction with Layer 2 Unicast Transmission Method

As described in Configuring Layer 2 Unicast Transmission Method for Reply Packets to DHCP Clients, you can use the set dhcp relay layer2-unicast-replies command to configure DHCP relay and DHCP relay proxy to use the layer 2 unicast and layer3 broadcast transmission method to send DHCP Offer reply packets and DHCP ACK and NAK reply packets to clients.

The set dhcp relay broadcast-flag-replies command and the set dhcp relay layer2-unicast-replies command are mutually exclusive. If you attempt to issue the set dhcp relay broadcast-flag-replies command when the set dhcp relay layer2-unicast-replies command is already in effect, the operation fails and the router displays the following message:

% layer2-unicast-replies and broadcast-flag-replies are mutually exclusive

If this message appears, you must first issue the no set dhcp relay layer2-unicast-replies command to disable layer 2 unicast replies, and then issue the set dhcp relay broadcast-flag-replies command again to enable broadcast flag replies.

Table 96 summarizes how the configuration of the set dhcp relay broadcast-flag-replies command and the set dhcp relay layer2-unicast-replies command interacts with the setting of the broadcast flag in DHCP request packets to control how the router transmits DHCP reply packets to clients during the discovery process. Because these commands are mutually exclusive, broadcast flag replies and layer 2 unicast replies cannot both be enabled on the router at the same time.

Table 96: Router Configuration and Transmission of DHCP Reply Packets 
Broadcast Flag Replies
Layer 2 Unicast Replies
Router Behavior if Broadcast Flag Set
Router Behavior if Broadcast Flag Not Set

Enabled (on)

Disabled (off)

DHCP relay and DHCP relay proxy broadcast DHCP reply packets to clients.

DHCP relay and DHCP relay proxy use layer 2 unicast and layer 3 unicast transmission to send DHCP reply packets to clients.

Disabled (off)

Enabled (on)

DHCP relay and DHCP relay proxy use layer 2 unicast and layer 3 broadcast transmission to send DHCP reply packets to clients.

DHCP relay and DHCP relay proxy use layer 2 unicast and layer 3 broadcast transmission to send DHCP reply packets to clients.

Disabled (off)

Disabled (off)

DHCP relay and DHCP relay proxy broadcast DHCP reply packets to clients. For information about exceptions to this behavior for DHCP relay proxy, see Behavior for Bound Clients and Address Renewals.

DHCP relay and DHCP relay proxy broadcast DHCP reply packets to clients. For information about exceptions to this behavior for DHCP relay proxy, see Behavior for Bound Clients and Address Renewals.

Preventing DHCP Relay from Installing Host Routes by Default

The Address Resolution Protocol (ARP) performs spoof checking on all incoming ARP requests by default. For each incoming packet, ARP does a route lookup on the source IP address to determine the interface on which that IP address was routed. ARP then verifies that the interface on which the packet was received matches the routed interface. If the interface on which the packet was received does not match the routed interface, the router drops the packet.

When you configure applications such as DHCP relay that automatically install routes, you must ensure that the routes are correctly installed for your configuration. DHCP relay installs host routes by default, which is required in certain configurations to enable address renewals from the DHCP server to work properly. However, the default installation of host routes might cause a conflict when you configure DHCP relay with static subscriber interfaces. To avoid these configuration conflicts, use the set dhcp relay inhibit-access-route-creation command to prevent DHCP relay from installing host routes by default.

Configuration Example—Preventing Installation of Host Routes

This example describes a sample procedure for configuring multiple subscribers over a particular static subscriber interface (ip53001 in this example)—you might use commands similar to the following to create demultiplexer table entries and a subnet route that points to the static subscriber interface.

In the example, the host routes are associated with the primary IP interface on Gigabit Ethernet 1/0. Because the host routes are statically configured with the subscriber interface, there is no need for the router to install DHCP host routes. Therefore, in step 7, the set dhcp relay inhibit-access-route-creation command is used to prevent DHCP relay from installing host routes.

  1. Create a shared IP interface.
    2. host1(config)#interface ip ip53001
  2. Associate the shared IP interface with a static layer 2 interface.
    3. host1(config-if)#ip share-interface gigabitEthernet 1/0
  3. Make the shared interface an unnumbered interface.
    4. host1(config-if)#ip unnumbered loopback 53
  4. Specify the source addresses that the subscriber interface uses to demultiplex traffic.
    5. host1(config-if)#ip source-prefix 10.10.10.0 255.255.255.252
  5. Exit Interface Configuration mode.
    6. host1(config-if)#exit
  6. Create a static route that sends traffic for destination address 10.10.10.0 to subscriber interface ip53001.
    7. host1(config)#ip route 10.10.10.0 255.255.255.252 ip ip53001
  7. Prevent DHCP relay from installing host routes—this avoids a conflict that can cause undesirable ARP behavior. 
    8. host1(config)#set dhcp relay inhibit-access-route-creation

In the example, if you do not prevent DHCP relay from installing host routes, the ARP spoof-checking mechanism associates the ARP traffic with the primary IP interface (Gigabit Ethernet 1/0), although packets actually arrive on the subscriber interface (ip53001), causing the router to detect a spoof and drop the packet.

Including Relay Agent Option Values in the PPPoE Remote Circuit ID

You can enable the router to capture and format a vendor-specific tag containing a PPPoE remote circuit ID value transmitted from a digital subscriber line access multiplexer (DSLAM) device. The router can then send this value to a Remote Authentication Dial-In User Service (RADIUS) server or to a Layer 2 Tunneling Protocol (L2TP) network server (LNS) to uniquely identify subscriber locations.

By default, the router formats the captured PPPoE remote circuit ID to include only the agent-circuit-id suboption (suboption 1) of the DHCP relay agent information option (option 82). You can use the radius remote-circuit-id-format command to configure the following nondefault formats for the PPPoE remote circuit ID value:

For information about configuring the PPPoE remote circuit ID, see Using the PPPoE Remote Circuit ID to Identify Subscribers and Configuring PPPoE Remote Circuit ID Capture in JUNOSe Link Layer Configuration Guide, Chapter 10, Configuring Point-to-Point Protocol over Ethernet.

Using the Giaddr to Identify the Primary Interface for Dynamic Subscriber Interfaces

When creating dynamic subscriber interfaces, the router builds the dynamic interfaces on the associated primary interface. By default, the router identifies the primary interface based on the interface on which DHCP client discover packets are received. The router then builds all dynamic interfaces on that primary interface.

In some cases you might want more control over the determination of the primary interface and you might not want to use the primary interface that is determined by the default behavior. The JUNOSe software enables you to configure DHCP relay to use information in the giaddr in DHCP ACK messages to specify which interface is to be used as the primary interface. This capability allows you to build dynamic interfaces on the primary interface of your choice.

Configuring Layer 2 Unicast Transmission Method for Reply Packets to DHCP Clients

By default, DHCP relay and relay proxy broadcast DHCP Offer reply packets and DHCP ACK and NAK reply packets to DHCP clients during the discovery process. In some environments, this default broadcast method might be a security concern because all clients can receive packets intended for all other clients.

You use the set dhcp relay layer2-unicast-replies command in Global Configuration mode to configure the optional layer 2 unicast and layer 3 broadcast transmission method for DHCP relay and DHCP relay proxy. This method uses the client's layer 2 (MAC) address and layer 3 (IP) broadcast address to provide secure transmission of DHCP Offer reply packets and ACK and NAK reply packets. The optional layer 2 unicast method enables reply packets to be broadcast through the layer 3 network but received only by the specified client.

There are exceptions to this behavior for DHCP relay proxy when the DHCP client is already bound to an IP address or is renewing the lease on its IP address. For information, see Behavior for Bound Clients and Address Renewals.

To display whether the layer 2 unicast method is currently on or off on the router, use the show dhcp relay command. For information, see Chapter 22, Monitoring and Troubleshooting DHCP.

The dhcpRelayGeneral logging event category uses the debug severity level to log DHCP reply packets that are transmitted to clients using a layer 2 unicast address and a layer 3 broadcast address.

The set dhcp relay broadcast-flag-replies command configures the router to use the setting of the broadcast flag in DHCP request packets to control the transmission of DHCP reply packets. The set dhcp relay layer2-unicast-replies command and the set dhcp relay broadcast-flag-replies command are mutually exclusive. For more information, see Interaction with Layer 2 Unicast Transmission Method.

NOTE: When you enable the layer 2 unicast transmission feature, the DHCP relay and DHCP relay proxy instance must be the next hop from the DHCP clients. Otherwise, the DHCP reply packets might be discarded.

The layer 2 unicast transmission method is not supported on non-ASIC line modules.

Using Option 60 Strings to Forward Client Traffic to Specific DHCP Servers

The DHCP functionality supports the DHCP vendor class identifier option (option 60). This support allows DHCP relay to compare option 60 strings in received DHCP client packets against strings that you configure on the router. You can use the DHCP relay option 60 feature when providing converged services in your network environment—option 60 support enables DHCP relay to direct client traffic to the specific DHCP server (the vendor-option server) that provides the service that the client requires. Or, as another option, you can configure option 60 strings to direct traffic to the DHCP local server in the current virtual router.

For example, you might have an environment in which some DHCP clients require only Internet access, while other clients require IPTV service. The clients that need Internet access get their addresses assigned by the DHCP local server on the E-series router (in equal-access mode). Clients requiring IPTV must be relayed to a specific DHCP server that provides the service. To support both types of clients, you configure two option 60 strings on the DHCP relay. Now, when any DHCP client packets are received with option 60 strings configured, the strings are matched against all strings configured on the DHCP relay. If the client string matches the first string you configured, that client is directed to the DHCP local server and gains Internet access. Client traffic with an option 60 string that matches your second string is relayed to the DHCP server that provides the IPTV service. In addition, you can configure a default action, which DHCP relay performs when a client option 60 string does not match any strings you have configured—for example, you might specify that all clients with non-matching strings be dropped.

You use the set dhcp vendor-option command to configure vendor-option (option 60) strings to control DHCP client traffic Create DHCP vendor-option servers by configuring DHCP relay to match DHCP option 60 strings and to specify what action to use for the traffic.Use the following guidelines when configuring the set dhcp vendor-option command:

You can map multiple strings to the same DHCP server, and you can map a single string to multiple servers. However, mapping one string to more than five DHCP vendor-option servers might impact performance.

You can configure a maximum of 100 option 60 strings per DHCP relay. Strings can contain a maximum of 254 characters.

Client packets that have option 60 configured but have no string specified (a string of 0 length) are treated as nonmatching strings and handled accordingly.

Configuration Example—Using DHCP Relay Option 60 to Specify Traffic Forwarding

You use the DHCP relay option 60 feature to specify the action performed on DHCP client traffic. The DHCP relay uses the option 60 string in the client traffic to determine what action to take with the incoming traffic.

The following example describes a sample procedure that creates three actions for incoming DHCP client traffic, depending on the traffic's option 60 string.

  1. Enable the DHCP relay. Do not specify an IP address when you configure DHCP relay to support vendor-option strings.
    2. host1(config)#set dhcp relay
  2. Configure the action DHCP relay takes when the incoming traffic has an exact option 60 string of myword. DHCP relay forwards this traffic to the DHCP server with an IP address of 192.168.7.7. 
    3. host1(config)#set dhcp vendor-option equals myword relay 192.168.7.7
  3. Configure the action DHCP relay takes when the incoming traffic has a partial match, from left-to-right, with an option 60 string you have configured. For this command, matching strings include a, ab, abc, and abcd. DHCP relay forwards matching traffic to the DHCP server with IP address 192.168.15.2. 
    4. host1(config)#set dhcp vendor-option starts-with abcd relay 192.168.15.2
  4. Configure the default option 60 action. DHCP relay takes this action when the incoming traffic has an option 60 string that does not match any of the option 60 strings that you have configured. In this example, the traffic is sent to the DHCP local server. 
    5. host1(config)#set dhcp vendor-option default local-server
  5. (Optional) View your DHCP relay vendor-option configuration.
    6. host1(config)#run show dhcp vendor-option

    Codes:

     *       - the configured vendor-string is an exact-match

     default - all DHCP client packets not matching a configured vendor-string

     implied - the DHCP application is configured but has not been enabled

               with the vendor-option command

     drop    - the DHCP application responsible for the action has not been

               configured yet therefore all packets for this application

               will be dropped

     Total 3 entries.

             Vendor-option                            Action              

    -------------------------------- ----------------------------------------

    abcd                             relay to 192.168.15.2 (rx: 0)               

    default(*)                       local-server (rx: 0, no-match: 0)   

    myword(*)                        relay to 192.168.7.7 (rx: 0)

Relaying DHCP Packets that Originate from a Cable Modem

You can use the DHCP vendor class identifier option (option 60) to configure DHCP relay to relay DHCP packets that originate from a cable modem to an external DHCP server that provides the cable modem with the configuration it requests.

Configure the vendor class identifier option to match the string used by cable modems—DHCP relay then forwards the packets to each DHCP server that you configured with the set dhcp vendor-option command (these servers are also considered to be cable-modem DHCP servers).

Configuring Relay Agent Option 82 Information

You can specify the type the relay agent option 82 information that the router adds to DHCP packets before it relays the packets to the DHCP server. You can use one of the following keywords to add either the hostname or virtual router name to the front of the Circuit-Id field or to strip the subinterface ID from the Interface-Id field:

The hostname and vrname keywords are a toggle; that is, specifying either hostname or virtual router name turns off the other selection.

Preventing Option 82 Information from Being Stripped from Trusted Client Packets

You can configure DHCP relay or DHCP relay proxy to preserve option 82 information for trusted clients. This ensures that DHCP relay and DHCP relay proxy prevent option 82 information from being stripped off packets destined for a trusted client. A trusted client has a giaddr value of 0. If DHCP relay is configured not to remove option 82 and the giaddr field is 0, option 82 information remains in the packets.

Configuring Relay Agent Information Option (Option 82) Suboption Values

The DHCP relay agent information option (option 82) enables you to include additional useful information in the client-originated DHCP packets that the DHCP relay forwards to a DHCP server.

When the DHCP relay agent information option is enabled, the DHCP relay adds the option 82 information to packets it receives from clients, then forwards the packets to the DHCP server. The DHCP server uses the option 82 information to decide which IP address to assign to the client—the DHCP server might also use information in the option 82 field for additional purposes, such as determining which services to grant to the client. The DHCP server sends its reply back to the DHCP relay, which removes the option 82 information field from the message, and then forwards the packet to the client.

The option 82 information is made up of a sequence of suboptions. JUNOSe software supports the following DHCP relay agent information suboptions.

The Agent Circuit ID suboption (suboption 1) and the Agent Remote ID suboption (suboption 2) are typically determined by the client network access device and depend on the network configuration. The Vendor-Specific suboption (suboption 9) is more flexible and can be used by administrators to associate specific data with the DHCP messages relayed between the DHCP relay and the DHCP server. For example the Vendor-Specific suboption can include the client's IEEE 802.1p value, which identifies the client's user priority.

NOTE: The DHCP relay agent replaces any existing Vendor-Specific value in the client packet with the relay agent's value.

The JUNOSe software provides two commands that you can use to configure DHCP relay agent information suboptions.

The set dhcp relay agent sub-option command enables you to manage specific option 82 suboptions without impacting the configuration of other suboptions. The legacy set dhcp relay agent command, however, changes the configuration of suboptions in some cases.

Table 97 indicates the effect each command has on enabling or disabling relay agent information suboptions. 





 Table 97:  Effect of Commands on Option 82 Suboption Settings


 Command


 Suboption and Status


 



 Agent Circuit ID


 Agent Remote ID


 Vendor-Specific




 set dhcp relay agent sub-option circuit-id



 Enable



 No change



 No change





 set dhcp relay agent sub-option remote-id



 No change



 Enable



 No change





 set dhcp relay agent sub-option vendor-specific suboption-type



 No change



 No change



 Enable specified suboption type





 no set dhcp relay agent sub-option circuit-id



 Disable



 No change



 No change





 no set dhcp relay agent sub-option remote-id



 No change



 Disable



 No change





 no set dhcp relay agent sub-option vendor-specific suboption-type



 No change



 No change



 Disable specified suboption type





 set dhcp relay agent



 Enable



 Enable



 Not supported





 set dhcp relay agent circuit-id-only



 Enable



 Disable



 Not supported





 set dhcp relay agent remote-id-only



 Disable



 Enable



 Not supported





 no set dhcp relay agent



 Disable



 Disable



 Disable

Format of the JUNOSe Data Field in the Vendor-Specific Suboption for Option 82

RFC 4243 describes support for data fields from multiple vendors in the Vendor-Specific suboption for option 82. The JUNOSe software DHCP relay agent, however, supports only the JUNOSe software data field.

RFC 4243 supports the following format of the Vendor-Specific suboption:



       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |   Code (9)    |    Length     |        Enterprise Number 1    |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                               |  DataLen 1    |               |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +

      \                         Suboption Data 1                      \

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      .                                                               .

      .                                                               .

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The JUNOSe software data field appears after the JUNOSe software enterprise number and data length fields in the Vendor-Specific suboption. The format of the JUNOSe data field is a sequence of type/length/value (TLV) tuples. The type field and length field (the length of the following value field) are each 1 byte in size. The JUNOSe data length field specifies the total length of all TLV tuples. The JUNOSe software enterprise number is 4874 (0x130a.)

The format of the Layer 2 Circuit ID type field (type 1) is hexadecimal. The data field length of a normal non-stacked VLAN is 2 bytes, with the VLAN ID occupying the 12 low-order bits of the value; the 4 high-order bits are 0. The data field length of a stacked VLAN is 4 bytes, with the SVLAN ID occupying the 12 low-order bits of the 2 high-order bytes, and the VLAN ID occupying the 12 low-order bits of the 2 low-order bytes; the unused bits are 0. The data field length of a VPI/VCI is 4 bytes, with the VPI occupying the 8 to 10 low-order bits of the 2 high-order bytes, and the VCI occupying the 16 bits of the 2 low-order bytes; the unused bits are 0.

The format of the UPC data field (type 2) is hexadecimal; its data field length is 1 byte, with the UPC occupying the 4 low-order bits of the value; the 4 high-order bits are 0.

Example 1—The Vendor-Specific suboption for a VLAN ID of 2468 (0x09a4) and a UPC of 5 is formatted as follows:

09 0c 00 00 13 0a 07 01 02 09 a4 02 01 05

|  |  |           |  |  |  |     |  |  |

|  |  |           |  |  |  |     |  |  UPC val: 5

|  |  |           |  |  |  |     |  UPC len: 1 byte

|  |  |           |  |  |  |     UPC type: 2

|  |  |           |  |  |  L2 Circuit ID val: 09 a4

|  |  |           |  |  L2 Circuit ID len: 2 bytes

|  |  |           |  L2 Circuit ID type: 1

|  |  |           JUNOSe data len: 7 bytes

|  |  JUNOSe IANA: 13 0a

|  subopt 9 len: 12 bytes

subopt code: 9

Example 2—The Vendor-Specific suboption for a VLAN ID of 135-2468 (0x87-0x09a4, format <SVLAN ID>-<VLAN ID>) and a UPC of 5 is formatted as follows:

09 0e 00 00 13 0a 09 01 04 00 87 09 a4 02 01 05

|  |  |           |  |  |  |           |  |  |

|  |  |           |  |  |  |           |  |  UPC val: 5

|  |  |           |  |  |  |           |  UPC len: 1 byte

|  |  |           |  |  |  |           UPC type: 2

|  |  |           |  |  |  L2 Circuit ID val: 00 87 09 a4

|  |  |           |  |  L2 Circuit ID len: 4 bytes

|  |  |           |  L2 Circuit ID type: 1

|  |  |           JUNOSe data len: 9 bytes

|  |  JUNOSe IANA: 13 0a

|  subopt 9 len: 14 bytes

subopt code: 9

Example 3—The Vendor-Specific suboption for a VPI/VCI of 123.45678 (0x7b.0xb26e, format <VPI>.<VCI>) and a UPC of 5 is formatted as follows:

09 0e 00 00 13 0a 09 01 04 00 7b b2 6e 02 01 05

|  |  |           |  |  |  |           |  |  |

|  |  |           |  |  |  |           |  |  UPC val: 5

|  |  |           |  |  |  |           |  UPC len: 1 byte

|  |  |           |  |  |  |           UPC type: 2

|  |  |           |  |  |  L2 Circuit ID val: 00 7b b2 6e

|  |  |           |  |  L2 Circuit ID len: 4 bytes

|  |  |           |  L2 Circuit ID type: 1

|  |  |           JUNOSe data len: 9 bytes

|  |  JUNOSe IANA: 13 0a

|  subopt 9 len: 14 bytes

subopt code: 9

Using the set dhcp relay agent sub-option Command to Enable Option 82 Suboption Support

NOTE: We recommend that you use the set dhcp relay agent sub-option command for new option 82 suboption configurations. However, JUNOSe software continues to support the set dhcp relay agent command, with option 82 suboptions, to provide backward-compatibility for existing scripts.


You use the set dhcp relay agent sub-option command to enable support for a specific DHCP relay agent option 82 suboption—Agent Circuit ID (suboption 1), Agent Remote ID (suboption 2), and Vendor-Specific (suboption 9). When you issue this command, the router adds DHCP relay agent information suboption 1 to every packet it relays from a DHCP client to a DHCP server. The Agent Circuit ID suboption identifies the interface on which DHCP packets are received. When the packets are received on a LAG interface, the router clearly identifies the interface.

The suboptions include information from the DHCP relay agent that the DHCP server can use to implement parameter assignment policies. The DHCP server echoes the suboptions when it replies to the DHCP client, but the DHCP relay strips the suboptions before relaying the packets to the client.

The Agent Circuit ID suboption identifies the interface on which the DHCP packets are received. This suboption contains the following information, based on interface type:

Examples: 

atm 4/1.2:0.101

relayVr:atm 4/1:0.101

bostonHost:atm 4/1.2:0.101

Examples:

fastEthernet 1/2

relayVr:fastEthernet 1/2

bostonHost:fastEthernet 1/2

Examples:

fastEthernet 1/2.3:4

relayVr:fastEthernet 1/2:4

bostonHost:fastEthernet 1/2.3:4

Examples: 

fastEthernet 1/2.3:4-5

relayVr:fastEthernet 1/2:4-5

bostonHost:fastEthernet 1/2.3:4-5

Examples:

lag bundleA

relayVr:lag bundleA

bostonHost:lag bundleA

Examples:

lag bundleA.1:2

relayVr:lag bundleA:2

bostonHost:lag bundleA.1:2

Examples:

lag bundleA.1:2-3

relayVr:lag bundleA:2-3

bostonHost:lag bundleA.1:2-3

The Agent Remote ID suboption contains a value only when (1) the interface is a dynamic ATM interface and (2) the subscriber command is used to configure a username and domain name for the interface. If both conditions are met, the suboption contains a string with the username and domain name in the format: username@domainname.

The Vendor-Specific suboption contains a value that includes a JUNOSe data field. You can configure the data field to support one or both of the following values:

Configuration Example—Using DHCP Relay Option 82 to Pass
IEEE 802.1p Values to DHCP Servers

Using the DHCP relay agent option 82 feature, you can configure an environment in which a customized DHCP server assigns an IP address that provides the desired service to the DHCP client.

The DHCP server uses information based on the IEEE 802.1p values, which are extracted from the DHCP packets using JUNOSe software layer 2 policies, to determine the appropriate IP address to assign to the client.

This type of environment, which is illustrated in Figure 13, includes the following components:


Figure 13: Passing 802.1p Values to the DHCP Server

The following example describes a sample procedure that creates an environment that passes 802.1p values to the DHCP server, which then assigns an IP address that enables the desired service to the DHCP client.

  1. Configure a layer 2 policy that maps 802.1p values to user packet class values for a VLAN interface.
    2. host1(config)# vlan classifier-list dot1p0 user-priority 0

    host1(config)# vlan classifier-list dot1p1 user-priority 1

    host1(config)# vlan classifier-list dot1p2 user-priority 2

    host1(config)# vlan classifier-list dot1p3 user-priority 3

    host1(config)# vlan classifier-list dot1p4 user-priority 4

    host1(config)# vlan classifier-list dot1p5 user-priority 5

    host1(config)# vlan classifier-list dot1p6 user-priority 6

    host1(config)# vlan classifier-list dot1p7 user-priority 7 

    host1(config)# vlan policy-list dot1pToUpc

    host1(config-policy-list)# classifier-group dot1p0

    host1(config-policy-list-classifier-group)# user-packet-class 0

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p1

    host1(config-policy-list-classifier-group)# user-packet-class 1

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p2

    host1(config-policy-list-classifier-group)# user-packet-class 2

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p3

    host1(config-policy-list-classifier-group)# user-packet-class 3

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p4

    host1(config-policy-list-classifier-group)# user-packet-class 4

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p5

    host1(config-policy-list-classifier-group)# user-packet-class 5

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p6

    host1(config-policy-list-classifier-group)# user-packet-class 6

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)# classifier-group dot1p7

    host1(config-policy-list-classifier-group)# user-packet-class 7

    host1(config-policy-list-classifier-group)#exit

    host1(config-policy-list)#exit

    host1(config)# profile atm1483BaseProfile

    host1(config-profile)# vlan policy input dot1pToUpc statistics enabled

    host1(config-profile)#exit

    host1(config)#
  2. (Optional) Verify the policy list configuration.
    3. host1(config)# run show policy-list dot1pToUpc

    

                                      Policy Table

                                      ------ -----

    VLAN Policy dot1pToUpc

       Administrative state: enable

       Reference count:      1

       Classifier control list: dot1p0, precedence 100

          user-packet-class 0

       Classifier control list: dot1p1, precedence 100

          user-packet-class 1

       Classifier control list: dot1p2, precedence 100

          user-packet-class 2

       Classifier control list: dot1p3, precedence 100

          user-packet-class 3

       Classifier control list: dot1p4, precedence 100

          user-packet-class 4

       Classifier control list: dot1p5, precedence 100

          user-packet-class 5

       Classifier control list: dot1p6, precedence 100

          user-packet-class 6

       Classifier control list: dot1p7, precedence 100

          user-packet-class 7

    

       Referenced by interface(s):

          None

    

       Referenced by profile(s):

          atm1483BaseProfile  input policy, statistics enabled

    

       Referenced by merged policies:

          None
  3. Configure the DHCP relay to use the option 82 suboptions. This configuration includes the command that specifies the mapping of the user packet class values from the layer 2 policy to the user-packet-class type in the option 82 Vendor-Specific suboption. 
    4. host1(config)# set dhcp relay 192.168.32.1 proxy

    host1(config)# set dhcp relay 192.168.32.2

    host1(config)# set dhcp relay agent sub-option circuit-id

    host1(config)# set dhcp relay agent sub-option remote-id

    host1(config)# set dhcp relay agent sub-option vendor-specific 
user-packet-class

    host1(config)# set dhcp relay agent sub-option vendor-specific 
layer2-circuit-id

    host1(config)# set dhcp relay options hostname

    host1(config)# set dhcp relay options exclude-subinterface-id

    host1(config)# set dhcp relay inhibit-access-route-creation

    host1(config)# set dhcp relay trust-all

    host1(config)# set dhcp relay override agent-option
  4. (Optional) Verify the DHCP Relay configuration.
    5. host1(config)# run show dhcp relay

    

    DHCP Relay Configuration

    ------------------------

    Mode: Proxy

      Restore Client Timeout: 72

    Inhibit Access Route Creation: off

    Assign Giaddr to Source IP: off

    Layer 2 Unicast Replies: off

    Giaddr Selects Interface: off

    Relay Agent Information Option (82):

      Override Giaddr: off

      Override Option: on

      Trust All Clients: on

      Preserve Option From Trusted Clients: off

      Circuit-ID Sub-option (1): on

        select - hostname

        select - exclude-subinterface-id

      Remote-ID Sub-option (2): on

      Vendor-Specific Sub-option (9): on

        select - layer2-circuit-id

        select - user-packet-class

    

    DHCP Server Addresses

    ---------------------

    192.168.32.1

    192.168.32.2

Using the set dhcp relay agent Command to Enable Option 82 Suboption Support

NOTE: The set dhcp relay agent command, when used to configure option 82 suboptions is a legacy command, which JUNOSe software continues to support to provide backward-compatibility for existing scripts. We recommend that you use the dhcp relay agent sub-option command for new option 82 suboption configurations.

You can use the set dhcp relay agent command to enable support for DHCP relay agent option, which includes the option 82 suboptions—Agent Circuit ID (suboption 1) and Agent Remote ID (suboption 2). This command does not support the Vendor-Specific option (suboption 9).

The suboptions include information from the DHCP relay agent that the DHCP server can use to implement parameter assignment policies. The DHCP server echoes the suboptions when it replies to the client—the DHCP relay agent can optionally strip the option 82 information before relaying the packets to the client. (Use the CLI command set dhcp relay preserve-trusted-client-option to configure this behavior for trusted clients.)

When you issue the set dhcp relay agent command, the router adds the configured DHCP relay agent information suboptions to every packet it relays from a DHCP client to a DHCP server.

The circuit-id-only keyword specifies the Agent Circuit ID suboption, which contains the following information, based on interface type. This keyword disables support for the Agent Remote ID suboption.

Examples: 

atm 4/1.2:0.101

relayVr:atm 4/1:0.101

bostonHost:atm 4/1.2:0.101

Examples:

fastEthernet 1/2

relayVr:fastEthernet 1/2

bostonHost:fastEthernet 1/2

Examples:

fastEthernet 1/2.3:4

relayVr:fastEthernet 1/2:4

bostonHost:fastEthernet 1/2.3:4

Examples: 

fastEthernet 1/2.3:4-5

relayVr:fastEthernet 1/2:4-5

bostonHost:fastEthernet 1/2.3:4-5

Examples:

lag bundleA

relayVr:lag bundleA

bostonHost:lag bundleA

Examples:

lag bundleA.1:2

relayVr:lag bundleA:2

bostonHost:lag bundleA.1:2

Examples:

lag bundleA.1:2-3

relayVr:lag bundleA:2-3

bostonHost:lag bundleA.1:2-3

The remote-id-only keyword specifies the Agent Remote ID suboption, which contains a value only when (1) the interface is a dynamic ATM interface and (2) the subscriber command is used to configure a username and domain name for the interface. If both conditions are met, the suboption contains a string with the username and domain name in the format: username@domainname. The remote-id-only keyword disables support for the Agent Circuit ID suboption.

If you do not explicitly specify the circuit-id-only or remote-id-only keyword, both suboptions are used.

Related Topics

[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]