Hallo, dies ist ein Test.

PWD: /www/data-lst1/unixsoft/unixsoft/kaempfer/.public_html

Running in File Mode
Relative path: ./../../../../../../usr/man/man8/dhcpagent.8
Real path: /usr/share/man/man8/dhcpagent.8
Zurück

'\" te .\" Copyright (c) 2009, 2022, Oracle and/or its affiliates. .\" Copyright (c) 1992, 1996, Competitive Automation, Inc. .TH dhcpagent 8 "23 Jan 2017" "Oracle Solaris 11.4" "System Administration Commands" .SH NAME dhcpagent \- Dynamic Host Configuration Protocol (DHCP) client daemon .SH SYNOPSIS .LP .nf /usr/sbin/dhcpagent .fi .SH DESCRIPTION .sp .LP \fBdhcpagent\fR implements the client half of the Dynamic Host Configuration Protocol \fB(DHCP)\fR for machines running Oracle Solaris software. .sp .LP The \fBdhcpagent\fR daemon obtains configuration parameters for the client (local) machine's network interfaces from a \fBDHCP\fR server. These parameters may include a lease on an \fBIP\fR address, which gives the client machine use of the address for the period of the lease, which may be infinite. If the client wishes to use the \fBIP\fR address for a period longer than the lease, it must negotiate an extension using \fBDHCP\fR. For this reason, \fBdhcpagent\fR must run as a daemon, terminating only when the client machine powers down. .sp .LP The \fBdhcpagent\fR daemon is managed by means of the service management facility (SMF), by using the fault management resource identifier (FMRI): .sp .in +2 .nf svc:/network/dhcp/client:default .fi .in -2 .sp .sp .LP For IPv4, the service is started automatically by \fBipadm\fR or \fBifconfig\fR when a DHCP address is created. For IPv6, the service is started automatically by \fBin.ndpd\fR(8). .sp .LP When invoked, \fBdhcpagent\fR enters a passive state while it awaits instructions from \fBipadm\fR(8), \fBifconfig\fR(8) or \fBin.ndpd\fR(8). When it receives a command to configure an interface, it brings up the interface (if necessary) and starts DHCP. Once DHCP is complete, \fBdhcpagent\fR can be queried for the values of the various network parameters. In addition, if DHCP was used to obtain a lease on an address for an interface, it configures the address for use. When a lease is obtained, it is automatically renewed as necessary. If the lease cannot be renewed, \fBdhcpagent\fR will unconfigure the address, but the interface will be left up and \fBdhcpagent\fR will attempt to acquire a new address lease. \fBdhcpagent\fR monitors system suspend/resume events and will validate any non-permanent leases with the DHCP server upon resume. Similarly, \fBdhcpagent\fR monitors link up/down events and will validate any non-permanent leases with the DHCP server when the downed link is brought back up. The lease validation mechanism will restart DHCP if the server indicates that the existing lease is no longer valid. If the server cannot be contacted, then the existing lease will continue. This behavior can be modified with the "\fBverified-lease-only\fR" property in ipadm utility. For more information on this property, see the \fBipadm\fR(8) man page. .sp .LP For IPv4, if the configured interface is found to be unplumbed, or to have a different IP address, subnet mask, or broadcast address from those obtained from DHCP, the interface is abandoned from DHCP control. .sp .LP For IPv6, \fBdhcpagent\fR automatically plumbs and unplumbs logical interfaces as necessary for the IPv6 addresses supplied by the server. The IPv6 prefix length (netmask) is not set by the DHCPv6 protocol, but is instead set by \fBin.ndpd\fR(8) using prefix information obtained by Router Advertisements. If any of the logical interfaces created by \fBdhcpagent\fR is unplumbed, or configured with a different IP address, it will be abandoned from DHCP control. If the link-local interface is unplumbed, then all addresses configured by DHCP on that physical interface will be removed. .sp .LP In addition to \fBDHCP\fR, \fBdhcpagent\fR also supports \fBBOOTP\fR (IPv4 only). See \fIRFC 951, Bootstrap Protocol\fR. Configuration parameters obtained from a \fBBOOTP\fR server are treated identically to those received from a \fBDHCP\fR server, except that the \fBIP\fR address received from a \fBBOOTP\fR server always has an infinite lease. .sp .LP \fBDHCP\fR also acts as a mechanism to configure other information needed by the client, for example, the domain name and addresses of routers. Aside from the IP address, and for IPv4 alone, the netmask, broadcast address, and default router, the agent does not directly configure the workstation, but instead acts as a database which may be interrogated by other programs, and in particular by \fBdhcpinfo\fR(1). .sp .LP On clients with a single interface, this is quite straightforward. Clients with multiple interfaces may present difficulties, as it is possible that some information arriving on different interfaces may need to be merged, or may be inconsistent. Furthermore, the configuration of the interfaces is asynchronous, so requests may arrive while some or all of the interfaces are still unconfigured. To handle these cases, one interface may be designated as primary, which makes it the authoritative source for the values of \fBDHCP\fR parameters in the case where no specific interface is requested. See \fBdhcpinfo\fR(1) and \fBifconfig\fR(8) for details. .sp .LP All DHCP packets sent by \fBdhcpagent\fR include a vendor class identifier (RFC 2132, option code 60; RFC 3315, option code 16). This identifier is the same as the platform name returned by the \fBuname\fR \fB-i\fR command, except: .RS +4 .TP .ie t \(bu .el o Any commas in the platform name are changed to periods. .RE .RS +4 .TP .ie t \(bu .el o If the name does not start with a stock symbol and a comma, it is automatically prefixed with \fBSUNW\fR. .RE .SS "Address Properties" .sp .LP \fBdhcpagent\fR uses the following ipadm DHCP and addrconf type address objects properties: .RS +4 .TP .ie t \(bu .el o \fBverified-lease-only\fR .RE .RS +4 .TP .ie t \(bu .el o \fBoffer-wait\fR .RE .RS +4 .TP .ie t \(bu .el o \fBclient-id\fR .RE .RS +4 .TP .ie t \(bu .el o \fBparam-request-list\fR .RE .RS +4 .TP .ie t \(bu .el o \fBparam-ignore-list\fR .RE .SS "Protocol Properties" .sp .LP \fBdhcpagent\fR uses the following ipadm DHCP properties: .RS +4 .TP .ie t \(bu .el o \fBpacket-burst-limit (dhcpv4 protocol property)\fR .RE .RS +4 .TP .ie t \(bu .el o \fBpacket-burst-limit (dhcpv6 protocol property)\fR .RE .sp .LP See the \fBipadm\fR(8) man page for the definition of these properties. .sp .LP System wide default values for both the above groupings of properties can be specified by using \fBipadm\fR DHCPv4 and DHCPv6 protocol properties of the same names. .SS "Messages" .sp .LP The \fBdhcpagent\fR daemon writes information and error messages in five categories: .sp .ne 2 .mk .na \fBcritical\fR .ad .br .sp .6 .RS 4n Critical messages indicate severe conditions that prevent proper operation. .RE .sp .ne 2 .mk .na \fBerrors\fR .ad .br .sp .6 .RS 4n Error messages are important, sometimes unrecoverable events due to resource exhaustion and other unexpected failure of system calls; ignoring errors may lead to degraded functionality. .RE .sp .ne 2 .mk .na \fBwarnings\fR .ad .br .sp .6 .RS 4n Warnings indicate less severe problems, and in most cases, describe unusual or incorrect datagrams received from servers, or requests for service that cannot be provided. .RE .sp .ne 2 .mk .na \fBinformational\fR .ad .br .sp .6 .RS 4n Informational messages provide key pieces of information that can be useful to debugging a \fBDHCP\fR configuration at a site. Informational messages are generally controlled by the \fB-v\fR option. However, certain critical pieces of information, such as the IP address obtained, are always provided. .RE .sp .ne 2 .mk .na \fBdebug\fR .ad .br .sp .6 .RS 4n Debugging messages, which may be generated at two different levels of verbosity, are chiefly of benefit to persons having access to source code, but may be useful as well in debugging difficult DHCP configuration problems. Debugging messages are only generated when using the \fBconfig/debug\fR SMF property is set. .RE .SS "DHCP Events and User-Defined Actions" .sp .LP If an executable (binary or script) is placed at \fB/etc/dhcp/eventhook\fR, the \fBdhcpagent\fR daemon will automatically run that program when any of the following events occur: .sp .ne 2 .mk .na \fB\fBBOUND\fR and \fBBOUND6\fR\fR .ad .br .sp .6 .RS 4n These events occur during interface configuration. The event program is invoked when \fBdhcpagent\fR receives the DHCPv4 ACK or DHCPv6 Reply message from the DHCP server for the lease request of an address, indicating successful initial configuration of the interface. (See also the \fBINFORM\fR and \fBINFORM6\fR events, which occur when configuration parameters are obtained without address leases.) .RE .sp .ne 2 .mk .na \fB\fBEXTEND\fR and \fBEXTEND6\fR\fR .ad .br .sp .6 .RS 4n These events occur during lease extension. The event program is invoked just after \fBdhcpagent\fR receives the DHCPv4 ACK or DHCPv6 Reply from the DHCP server for the DHCPv4 REQUEST (renew) message or the DHCPv6 Renew or Rebind message. .sp Note that with DHCPv6, the server might choose to remove some addresses, add new address leases, and ignore (allow to expire) still other addresses in a given Reply message. The \fBEXTEND6\fR event occurs when a Reply is received that leaves one or more address leases still valid, even if the Reply message does not extend the lease for any address. The event program is invoked just before any addresses are removed, but just after any new addresses are added. Those to be removed will be marked with the \fBIFF_DEPRECATED\fR flag. .RE .sp .ne 2 .mk .na \fB\fBEXPIRE\fR and \fBEXPIRE6\fR\fR .ad .br .sp .6 .RS 4n These events occur during lease expiration. For DHCPv4, the event program is invoked just before the leased address is removed from an interface. For DHCPv6, the event program is invoked just before the last remaining leased addresses are removed from the interface. .RE .sp .ne 2 .mk .na \fB\fBDROP\fR and \fBDROP6\fR\fR .ad .br .sp .6 .RS 4n These events occur during the period when an interface is dropped. The event program is invoked just before the interface is removed from DHCP control. If the interface has been abandoned due to the user unplumbing the interface, then this event will occur after the user's action has taken place. The interface might not be present. .RE .sp .ne 2 .mk .na \fB\fBINFORM\fR and \fBINFORM6\fR\fR .ad .br .sp .6 .RS 4n These events occur when an interface acquires new or updated configuration information from a DHCP server by means of the DHCPv4 \fBINFORM\fR or the DHCPv6 Information-Request message. These messages are sent using an \fBifconfig\fR(8) \fBdhcp inform\fR command or when the DHCPv6 Router Advertisement \fBO\fR (letter 0) bit is set and the \fBM\fR bit is not set. Thus, these events occur when the DHCP client does not obtain an IP address lease from the server, and instead obtains only configuration parameters. .RE .sp .ne 2 .mk .na \fB\fBLOSS6\fR\fR .ad .br .sp .6 .RS 4n This event occurs during lease expiration when one or more valid leases still remain. The event program is invoked just before expired addresses are removed. Those being removed will be marked with the \fBIFF_DEPRECATED\fR flag. .sp Note that this event is not associated with the receipt of the Reply message, which occurs only when one or more valid leases remain, and occurs only with DHCPv6. If all leases have expired, then the EXPIRE6 event occurs instead. .RE .sp .ne 2 .mk .na \fB\fBRELEASE\fR and \fBRELEASE6\fR\fR .ad .br .sp .6 .RS 4n This event occurs during the period when a leased address is released. The event program is invoked just before \fBdhcpagent\fR relinquishes the address on an interface and sends the DHCPv4 \fBRELEASE\fR or DHCPv6 Release packet to the DHCP server. .RE .sp .LP The system does not provide a default event program. The file \fB/etc/dhcp/eventhook\fR is expected to be owned by root and have a mode of 755. .sp .LP The event program will be passed two arguments, the interface name and the event name, respectively. For DHCPv6, the interface name is the name of the physical interface. .sp .LP The event program can use the \fBdhcpinfo\fR(1) utility to fetch additional information about the interface. While the event program is invoked on every event defined above, it can ignore those events in which it is not interested. The event program runs with the same privileges and environment as \fBdhcpagent\fR itself, except that \fBstdin\fR, \fBstdout\fR, and \fBstderr\fR are redirected to \fB/dev/null\fR. Note that this means that the event program runs with root privileges. .sp .LP If an invocation of the event program does not exit after 55 seconds, it is sent a \fBSIGTERM\fR signal. If does not exit within the next three seconds, it is terminated by a \fBSIGKILL\fR signal. .sp .LP See EXAMPLES for an example event program. .SS "Service Properties" .sp .LP The following SMF properties are supported by the \fBdhcpagent\fR daemon. .sp .ne 2 .mk .na \fB\fBconfig/debug\fR\fR .ad .RS 18n .rt Sets the debug level to n. Two levels of debugging are currently available, 1 and 2. The latter is more verbose. .RE .sp .ne 2 .mk .na \fB\fBconfig/verbose\fR\fR .ad .RS 18n .rt Provide verbose output useful for debugging site configuration problems. .RE .SH EXAMPLES .LP \fBExample 1\fR Example Event Program .sp .LP The following script is stored in the file \fB/etc/dhcp/eventhook\fR, owned by root with a mode of 755. It is invoked upon the occurrence of the events listed in the file. .sp .in +2 .nf #!/bin/sh ( echo "Interface name: " $1 echo "Event: " $2 case $2 in "BOUND") echo "Address acquired from server "\e `/usr/sbin/dhcpinfo -i $1 ServerID` ;; "BOUND6") echo "Addresses acquired from server " \e `/usr/sbin/dhcpinfo -v6 -i $1 ServerID` ;; "EXTEND") echo "Lease extended for " \e `/usr/sbin/dhcpinfo -i $1 LeaseTime`" seconds" ;; "EXTEND6") echo "New lease information obtained on $i" ;; "EXPIRE" | "DROP" | "RELEASE") ;; esac ) >/var/run/dhcp_eventhook_output 2>&1 .fi .in -2 .sp .sp .LP Note the redirection of stdout and stderr to a file. .SH FILES .sp .ne 2 .mk .na \fB\fB/etc/dhcp/\fIif\fR.dhc\fR\fR .ad .br .na \fB\fB/etc/dhcp/\fIif\fR.dh6\fR\fR .ad .br .sp .6 .RS 4n Contains the configuration for interface. The mere existence of this file does not imply that the configuration is correct, since the lease might have expired. On start-up, \fBdhcpagent\fR confirms the validity of the address using REQUEST (for DHCPv4) or Confirm (DHCPv6). .RE .sp .ne 2 .mk .na \fB\fB/etc/dhcp/duid\fR\fR .ad .br .na \fB\fB/etc/dhcp/iaid\fR\fR .ad .br .sp .6 .RS 4n Contains persistent storage for DUID (DHCP Unique Identifier) and IAID (Identity Association Identifier) values. The format of these files is undocumented, and applications should not read from or write to them. .RE .sp .ne 2 .mk .na \fB\fB/etc/dhcp/eventhook\fR\fR .ad .br .sp .6 .RS 4n Location of a DHCP event program. .RE .SH ATTRIBUTES .sp .LP See \fBattributes\fR(7) for descriptions of the following attributes: .sp .TS tab( ) box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) . ATTRIBUTE TYPE ATTRIBUTE VALUE _ Availability system/network _ Interface Stability Committed .TE .sp .SH SEE ALSO .sp .LP \fBdhcpinfo\fR(1), \fBipadm\fR(8), \fBsyslog\fR(3C), \fBattributes\fR(7), \fBdhcp\fR(7), \fBifconfig\fR(8), \fBin.mpathd\fR(8), \fBin.ndpd\fR(8), \fBinit\fR(8) .sp .LP Croft, B. and Gilmore, J.,\fIBootstrap Protocol (BOOTP)\fRRFC 951, Network Working Group, September 1985. .sp .LP Droms, R., \fIDynamic Host Configuration Protocol\fR, RFC 2131, Network Working Group, March 1997. .sp .LP Lemon, T. and B. Sommerfeld. \fIRFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)\fR. Nominum and Sun Microsystems. February 2006. .sp .LP Droms, R. \fIRFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\fR. Cisco Systems. July 2003. .SH NOTES .sp .LP The \fBdhcpagent\fR daemon can be used on IPv4 logical interfaces, just as with physical interfaces. When used on a logical interface, the daemon automatically constructs a Client ID value based on the DUID and IAID values, according to RFC 4361. The "\fBclient-id\fR" property can be specified when the address is created by using \fBipadm\fR, and if provided, overrides this automatic identifier. .sp .LP Unlike physical IPv4 interfaces, \fBdhcpagent\fR does not add or remove default routes associated with logical interfaces. .sp .LP DHCP can be performed on IPMP IP interfaces to acquire and maintain IPMP data addresses. Because an IPMP IP interface has no hardware address, the daemon automatically constructs a Client ID using the same approach described above for IPv4 logical interfaces. In addition, the lack of a hardware address means the daemon must set the "broadcast" flag in all \fBDISCOVER\fR and \fBREQUEST\fR messages on IPMP IP interfaces. Some DHCP servers may refuse such requests. .sp .LP DHCP can be performed on IP interfaces that are part of an IPMP group (to acquire and maintain test addresses). The daemon will automatically set the \fBNOFAILOVER\fR and \fBDEPRECATED\fR flags on each test address. Additionally, the daemon will not add or remove default routes in this case. Note that the actual DHCP packet exchange may be performed over any active IP interface in the IPMP group. It is strongly recommended that test addresses have infinite leases. Otherwise, an extended network outage detectable only by probes may cause test address leases to expire, causing \fBin.mpathd\fR(8) to revert to link-based failure detection and trigger an erroneous repair.