|dhcrelay(8)||System Manager's Manual||dhcrelay(8)|
NAME¶dhcrelay - Dynamic Host Configuration Protocol Relay Agent
SYNOPSIS¶dhcrelay [ -4 ] [ -dqaD ] [ -p port ] [ -c count ] [ -A length ] [ -pf pid-file ] [ --no-pid ] [ -m append | replace | forward | discard ] [ -i interface0 [ ... -i interfaceN ] ] [ -iu interface0 [ ... -iu interfaceN ] ] [ -id interface0 [ ... -id interfaceN ] ] [ -U interface ] server0 [ ...serverN ]
dhcrelay -6 [ -dqI ] [ -p port ] [ -c count ] [ -pf pid-file ] [ --no-pid ] [ -s subscriber-id ] -l lower0 [ ... -l lowerN ] -u upper0 [ ... -u upperN ]
DESCRIPTION¶The Internet Systems Consortium DHCP Relay Agent, dhcrelay, provides a means for relaying DHCP and BOOTP requests from a subnet to which no DHCP server is directly connected to one or more DHCP servers on other subnets. It supports both DHCPv4/BOOTP and DHCPv6 protocols.
OPERATION¶The DHCP Relay Agent listens for DHCPv4 or DHCPv6 queries from clients or other relay agents on one or more interfaces, passing them along to ``upstream'' servers or relay agents as specified on the command line. When a reply is received from upstream, it is multicast or unicast back downstream to the source of the original request.
COMMAND LINE¶Protocol selection options:
- Run dhcrelay as a DHCPv6 relay agent. Incompatible with the -4 option.
- Run dhcrelay as a DHCPv4/BOOTP relay agent. This is the default mode of operation, so the argument is not necessary, but may be specified for clarity. Incompatible with -6.
Specifying DHCPv4/BOOTP servers
In DHCPv4 mode, a list of one or more server addresses must be specified on the command line, to which DHCP/BOOTP queries should be relayed.
Options available for both DHCPv4 and DHCPv6:
- -c COUNT
- Maximum hop count. When forwarding packets, dhcrelay discards packets which have reached a hop count of COUNT. Default is 10. Maximum is 255.
- Force dhcrelay to run as a foreground process. Useful when running dhcrelay under a debugger, or running out of inittab on System V systems.
- -p PORT
- Listen and transmit on port PORT. This is mostly useful for debugging purposes. Default is port 67 for DHCPv4/BOOTP, or port 547 for DHCPv6.
- Quiet mode. Prevents dhcrelay6 from printing its network configuration on startup.
- -pf pid-file
- Path to alternate pid file.
- Option to disable writing pid files. By default the program will write a pid file.
Options available in DHCPv4 mode only:
- Append an agent option field to each request before forwarding it to the server. Agent option fields in responses sent from servers to clients will be stripped before forwarding such responses back to the client. The agent option field will contain two agent options: the Circuit ID suboption and the Remote ID suboption. Currently, the Circuit ID will be the printable name of the interface on which the client request was received. The client supports inclusion of a Remote ID suboption as well, but this is not used by default.
- -A LENGTH
- Specify the maximum packet size to send to a DHCPv4/BOOTP server. This might be done to allow sufficient space for addition of relay agent options while still fitting into the Ethernet MTU size.
- Drop packets from upstream servers if they contain Relay Agent Information options that indicate they were generated in response to a query that came via a different relay agent. If this option is not specified, such packets will be relayed anyway.
- -i ifname
- Listen for DHCPv4/BOOTP traffic on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them.
- -iu ifname
- Specifies an upstream network interface: an interface from which replies from servers and other relay agents will be accepted. Multiple interfaces may be specified by using more than one -iu option. This argument is intended to be used in conjunction with one or more -i or -id arguments.
- -id ifname
- Specifies a downstream network interface: an interface from which requests from clients and other relay agents will be accepted. Multiple interfaces may be specified by using more than one -id option. This argument is intended to be used in conjunction with one or more -i or -iu arguments.
- -m append|replace|forward|discard
- Control the handling of incoming DHCPv4 packets which already contain relay agent options. If such a packet does not have giaddr set in its header, the DHCP standard requires that the packet be discarded. However, if giaddr is set, the relay agent may handle the situation in four ways: It may append its own set of relay options to the packet, leaving the supplied option field intact; it may replace the existing agent option field; it may forward the packet unchanged; or, it may discard it.
- -U ifname
- Enables the addition of a RFC 3527 compliant link selection suboption for
clients directly connected to the relay. This RFC allows a relay to
specify two different IP addresses: one for the server to use when
communicating with the relay (giaddr) the other for choosing the subnet
for the client (the suboption). This can be useful if the server is unable
to send packets to the relay via the address used for the subnet.
When enabled, dhcrelay will add an agent option (as per -a above) that includes the link selection suboption to the forwarded packet. This will only be done to packets received from clients that are directly connected to the relay (i.e. giaddr is zero). The address used in the suboption will be that of the link upon which the inbound packet was received (which would otherwise be used for giaddr). The value of giaddr will be set to that of interface ifname.
Only one interface should be marked in this fashion. Currently enabling this option on an interface causes the relay to process all DHCP traffic similar to the -i option, in the future we may split the two more completely.
This option is off by default. Note that enabling this option automatically enables the -a option.
Keep in mind that using options such as -m replace or -m discard on relays upstream from one using -U can pose problems. The upstream relay will wipe out the initial agent option containing the link selection while leaving the re-purposed giaddr value in place, causing packets to go astray.
Options available in DHCPv6 mode only:
- Force use of the DHCPv6 Interface-ID option. This option is automatically sent when there are two or more downstream interfaces in use, to disambiguate between them. The -I option causes dhcrelay to send the option even if there is only one downstream interface.
- -s subscriber-id
- Add an option with the specified subscriber-id into the packet. This feature is for testing rather than production as it will put the same subscriber-id into the packet for all clients.
- -l [address%]ifname[#index]
- Specifies the ``lower'' network interface for DHCPv6 relay mode: the interface on which queries will be received from clients or from other relay agents. At least one -l option must be included in the command line when running in DHCPv6 mode. The interface name ifname is a mandatory parameter. The link address can be specified by address%; if it isn't, dhcrelay will use the first non-link-local address configured on the interface. The optional #index parameter specifies the interface index.
- -u [address%]ifname
- Specifies the ``upper'' network interface for DHCPv6 relay mode: the interface to which queries from clients and other relay agents should be forwarded. At least one -u option must be included in the command line when running in DHCPv6 mode. The interface name ifname is a mandatory parameter. The destination unicast or multicast address can be specified by address%; if not specified, the relay agent will forward to the DHCPv6 All_DHCP_Relay_Agents_and_Servers multicast address.
It is possible to specify the same interface with different addresses more than once, and even, when the system supports it, to use the same interface as both upper and lower interfaces.
SEE ALSO¶dhclient(8), dhcpd(8), RFC3315, RFC2132, RFC2131.
BUGS¶Using the same interface on both upper and lower sides may cause loops, so when running this way, the maximum hop count should be set to a low value.
The loopback interface is not (yet) recognized as a valid interface.