FREEBSD之DHCP安裝 |
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
http://mail.tses.tcc.edu.tw/nuke/sections.php?op=viewarticle&artid=131
dhcp安裝 (已閱讀: 1736 次) (來源:苗栗縣大湖鄉大南國民小學 FreeBSD 全球資訊網路架站日誌) 下載: ftp://ftp.lab.mlc.edu.tw/UNIX/isc/dhcp/dhcp-3.0rc11.tar.gz 編譯與安裝: ./configure make make install 相關程式檔案安裝至/usr/sbin/ touch /var/db/dhcpd.leases echo 255.255.255.255 For-DHCP >> /etc/hosts route add -host For-DHCP -interface vr1(放在rc.local) vr1:網路卡代號,如果您的主機裝有兩塊網卡,這裡的網卡代號表示DHCP要從哪一塊網卡廣播出去。 我的vr0第一塊網卡接真實IP並做為NAT。 -------------/usr/local/etc/dhcpd.conf------------------- server-identifier gateway.nat ; # 標明此伺服器名稱 default-lease-time 21600; # 租約使用時間: 6 小時 max-lease-time 86400; # 最大租期長度: 1 天 option domain-name-servers 168.95.192.1,168.95.1.1 ; # 可用的名稱伺服器 option domain-name "nat"; # 所屬的網域名稱 option routers 192.168.1.254 ; # 子網路路由器(gateway) option broadcast-address 192.168.1.255 ; # 廣播封包位置 option perform-mask-discovery on; option mask-supplier on; ddns-update-style none; #### ------ 宣告 NAT 網域之動態IP ------ #### group { subnet 192.168.1.0 netmask 255.255.255.0 { # 子網路與網路遮罩 range dynamic-bootp 192.168.1.20 192.168.1.30 ; # 動態分配 IP 位置範圍 } } 啟動 /usr/sbin/dhcpd -cf /usr/local/etc/dhcpd.conf vr1(rc.local) /usr/sbin/dhcpd -cf 設定檔 網路卡代號 我發現這一行一定要有,因配合bind-8.2.3-REL,ddns-update-style動態更新DNS資料,設定方式有三種: ddns-update-style ad-hoc ddns-update-style interim ddns-update-style none 執行成功後的訊息畫面。 Internet Software Consortium DHCP Server V3.0rc11 Copyright 1995-2001 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 0 leases to leases file. Listening on BPF/vr1/00:50:ba:cd:08:5e/192.168.1.0 Sending on BPF/vr1/00:50:ba:cd:08:5e/192.168.1.0 Sending on Socket/fallback/fallback-net man dhcpd.conf dhcpd.conf(5) dhcpd.conf(5) NAME dhcpd.conf - dhcpd configuration file DESCRIPTION The dhcpd.conf file contains configuration information for dhcpd, the Internet Software Consortium DHCP Server. The dhcpd.conf file is a free-form ASCII text file. It is parsed by the recursive-descent parser built into dhcpd. The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insen- sitive. Comments may be placed anywhere within the file (except within quotes). Comments begin with the # char- acter and end at the end of the line. The file essentially consists of a list of statements. Statements fall into two broad categories - parameters and declarations. Parameter statements either say how to do something (e.g., how long a lease to offer), whether to do something (e.g., should dhcpd provide addresses to unknown clients), or what parameters to provide to the client (e.g., use gate- way 220.177.244.7). Declarations are used to describe the topology of the net- work, to describe clients on the network, to provide addresses that can be assigned to clients, or to apply a group of parameters to a group of declarations. In any group of parameters and declarations, all parameters must be specified before any declarations which depend on those parameters may be specified. Declarations about network topology include the shared-network and the subnet declarations. If clients on a subnet are to be assigned addresses dynamically, a range declaration must appear within the subnet declara- tion. For clients with statically assigned addresses, or for installations where only known clients will be served, each such client must have a host declaration. If param- eters are to be applied to a group of declarations which are not related strictly on a per-subnet basis, the group declaration can be used. For every subnet which will be served, and for every sub- net to which the dhcp server is connected, there must be one subnet declaration, which tells dhcpd how to recognize that an address is on that subnet. A subnet declaration is required for each subnet even if no addresses will be dynamically allocated on that subnet. Some installations have physical networks on which more than one IP subnet operates. For example, if there is a site-wide requirement that 8-bit subnet masks be used, but a department with a single physical ethernet network expands to the point where it has more than 254 nodes, it may be necessary to run two 8-bit subnets on the same eth- ernet until such time as a new physical network can be added. In this case, the subnet declarations for these two networks must be enclosed in a shared-network declara- tion. Some sites may have departments which have clients on more than one subnet, but it may be desirable to offer those clients a uniform set of parameters which are different than what would be offered to clients from other depart- ments on the same subnet. For clients which will be declared explicitly with host declarations, these declara- tions can be enclosed in a group declaration along with the parameters which are common to that department. For clients whose addresses will be dynamically assigned, class declarations and conditional declarations may be used to group parameter assignments based on information the client sends. When a client is to be booted, its boot parameters are determined by consulting that client's host declaration (if any), and then consulting any class declarations matching the client, followed by the pool, subnet and shared-network declarations for the IP address assigned to the client. Each of these declarations itself appears within a lexical scope, and all declarations at less spe- cific lexical scopes are also consulted for client option declarations. Scopes are never considered twice, and if parameters are declared in more than one scope, the param- eter declared in the most specific scope is the one that is used. When dhcpd tries to find a host declaration for a client, it first looks for a host declaration which has a fixed- address parameter which matches the subnet or shared net- work on which the client is booting. If it doesn't find any such entry, it then tries to find an entry which has no fixed-address parameter. EXAMPLES A typical dhcpd.conf file will look something like this: global parameters... subnet 204.254.239.0 netmask 255.255.255.224 { subnet-specific parameters... range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { subnet-specific parameters... range 204.254.239.42 204.254.239.62; } subnet 204.254.239.64 netmask 255.255.255.224 { subnet-specific parameters... range 204.254.239.74 204.254.239.94; } group { group-specific parameters... host zappo.test.isc.org { host-specific parameters... } host beppo.test.isc.org { host-specific parameters... } host harpo.test.isc.org { host-specific parameters... } } Figure 1 Notice that at the beginning of the file, there's a place for global parameters. These might be things like the organization's domain name, the addresses of the name servers (if they are common to the entire organization), and so on. So, for example: option domain-name "isc.org"; option domain-name-servers ns1.isc.org, ns2.isc.org; Figure 2 As you can see in Figure 2, you can specify host addresses in parameters using their domain names rather than their numeric IP addresses. If a given hostname resolves to more than one IP address (for example, if that host has two ethernet interfaces), then where possible, both addresses are supplied to the client. The most obvious reason for having subnet-specific parame- ters as shown in Figure 1 is that each subnet, of neces- sity, has its own router. So for the first subnet, for example, there should be something like: option routers 204.254.239.1; Note that the address here is specified numerically. This is not required - if you have a different domain name for each interface on your router, it's perfectly legiti- mate to use the domain name for that interface instead of the numeric address. However, in many cases there may be only one domain name for all of a router's IP addresses, and it would not be appropriate to use that name here. In Figure 1 there is also a group statement, which pro- vides common parameters for a set of three hosts - zappo, beppo and harpo. As you can see, these hosts are all in the test.isc.org domain, so it might make sense for a group-specific parameter to override the domain name sup- plied to these hosts: option domain-name "test.isc.org"; Also, given the domain they're in, these are probably test machines. If we wanted to test the DHCP leasing mecha- nism, we might set the lease timeout somewhat shorter than the default: max-lease-time 120; default-lease-time 120; You may have noticed that while some parameters start with the option keyword, some do not. Parameters starting with the option keyword correspond to actual DHCP options, while parameters that do not start with the option keyword either control the behavior of the DHCP server (e.g., how long a lease dhcpd will give out), or specify client parameters that are not optional in the DHCP protocol (for example, server-name and filename). In Figure 1, each host had host-specific parameters. These could include such things as the hostname option, the name of a file to upload (the filename parameter) and the address of the server from which to upload the file (the next-server parameter). In general, any parameter can appear anywhere that parameters are allowed, and will be applied according to the scope in which the parameter appears. Imagine that you have a site with a lot of NCD X-Termi- nals. These terminals come in a variety of models, and you want to specify the boot files for each model. One way to do this would be to have host declarations for each server and group them by model: group { filename "Xncd19r"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } } group { filename "Xncd19c"; next-server ncd-booter; host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } } group { filename "XncdHMX"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } } ADDRESS POOLS The pool declaration can be used to specify a pool of addresses that will be treated differently than another pool of addresses, even on the same network segment or subnet. For example, you may want to provide a large set of addresses that can be assigned to DHCP clients that are registered to your DHCP server, while providing a smaller set of addresses, possibly with short lease times, that are available for unknown clients. If you have a fire- wall, you may be able to arrange for addresses from one pool to be allowed access to the Internet, while addresses in another pool are not, thus encouraging users to regis- ter their DHCP clients. To do this, you would set up a pair of pool declarations: subnet 10.0.0.0 netmask 255.255.255.0 { option routers 10.0.0.254; # Unknown clients get this pool. pool { option domain-name-servers bogus.example.com; max-lease-time 300; range 10.0.0.200 10.0.0.253; allow unknown clients; } # Known clients get this pool. pool { option domain-name-servers ns1.example.com, ns2.example.com; max-lease-time 28800; range 10.0.0.5 10.0.0.199; deny unknown clients; } } It is also possible to set up entirely different subnets for known and unknown clients - address pools exist at the level of shared networks, so address ranges within pool declarations can be on different subnets. As you can see in the preceding example, pools can have permit lists that control which clients are allowed access to the pool and which aren't. Each entry in a pool's per- mit list is introduced with the allow or deny keyword. If a pool has a permit list, then only those clients that match specific entries on the permit list will be eligible to be assigned addresses from the pool. If a pool has a deny list, then only those clients that do not match any entries on the deny list will be eligible. If both per- mit and deny lists exist for a pool, then only clients that match the permit list and do not match the deny list will be allowed access. DYNAMIC ADDRESS ALLOCATION Address allocation is actually only done when a client is in the INIT state and has sent a DHCPDISCOVER message. If the client thinks it has a valid lease and sends a DHCPRE- QUEST to initiate or renew that lease, the server has only three choices - it can ignore the DHCPREQUEST, send a DHCPNAK to tell the client it should stop using the address, or send a DHCPACK, telling the client to go ahead and use the address for a while. If the server finds the address the client is requesting, and that address is available to the client, the server will send a DHCPACK. If the address is no longer avail- able, or the client isn't permitted to have it, the server will send a DHCPNAK. If the server knows nothing about the address, it will remain silent, unless the address is incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn't know about the address. There may be a host declaration matching the client's identification, and that host declaration contains a fixed-address declaration that is valid for the network segment to which the client is connected. In this case, the DHCP server will never do dynamic address allocation. In this case, the client is required to take the address specified in the host declaration. If the client is requesting some other address, the server will respond with a DHCPNAK. When the DHCP server allocates a new address for a client (remember, this only happens if the client has sent a DHCPDISCOVER), it first looks to see if the client already has a valid lease on an IP address, or if there is an old IP address the client had before that hasn't yet been reassigned. In that case, the server will take that address and check it to see if the client is still permit- ted to use it. If the client is no longer permitted to use it, the lease is freed if the server thought it was still in use - the fact that the client has sent a DHCPDISCOVER proves to the server that the client is no longer using the lease. If no existing lease is found, or if the client is forbid- den to receive the existing lease, then the server will look in the list of address pools for the network segment to which the client is attached for a lease that is not in use and that the client is permitted to have. It looks through each pool declaration in sequence (all range dec- larations that appear outside of pool declarations are grouped into a single pool with no permit list). If the permit list for the pool allows the client to be allocated an address from that pool, the pool is examined to see if there is an address available. If so, then the client is tentatively assigned that address. Otherwise, the next pool is tested. If no addresses are found that can be assigned to the client, no response is sent to the client. If an address is found that the client is permitted to have, and that has never been assigned to any client before, the address is immediately allocated to the client. If the address is available for allocation but has been previously assigned to a different client, the server will keep looking in hopes of finding an address that has never before been assigned to a client. IP ADDRESS CONFLICT PREVENTION The DHCP server checks IP addresses to see if they are in use before allocating them to clients. It does this by sending an ICMP Echo request message to the IP address being allocated. If no ICMP Echo reply is received within a second, the address is assumed to be free. This is only done for leases that have been specified in range statements, and only when the lease is thought by the DHCP server to be free - i.e., the DHCP server or its failover peer has not listed the lease as in use. If a response is received to an ICMP Echo request, the DHCP server assumes that there is a configuration error - the IP address is in use by some host on the network that is not a DHCP client. It marks the address as abandoned, and will not assign it to clients. If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses, then the DHCP server will attempt to reclaim an abandoned IP address. It marks one IP address as free, and then does the same ICMP Echo request check described previously. If there is no answer to the ICMP Echo request, the address is assigned to the client. The DHCP server does not cycle through abandoned IP addresses if the first IP address it tries to reclaim is free. Rather, when the next DHCPDISCOVER comes in from the client, it will attempt a new allocation using the same method described here, and will typically try a new IP address. DHCP FAILOVER This version of the ISC DHCP server supports the DHCP failover protocol as documented in draft-ietf-dhc- failover-07.txt. This is not a final protocol document, and we have not done interoperability testing with other vendors' implementations of this protocol, so you must not assume that this implementation conforms to the standard. If you wish to use the failover protocol, make sure that both failover peers are running the same version of the ISC DHCP server. The failover protocol allows two DHCP servers (and no more than two) to share a common address pool. Each server will have about half of the available IP addresses in the pool at any given time for allocation. If one server fails, the other server will continue to renew leases out of the pool, and will allocate new addresses out of the roughly half of available addresses that it had when com- munications with the other server were lost. It is possible during a prolonged failure to tell the remaining server that the other server is down, in which case the remaining server will (over time) reclaim all the addresses the other server had available for allocation, and begin to reuse them. This is called putting the server into the PARTNER-DOWN state. You can put the server into the PARTNER-DOWN state either by using the omshell (8) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server. If you use this last method, be sure to leave the date and time of the start of the state blank: failover peer name state { my state partner-down; peer state state at date; } When the other server comes back online, it should auto- matically detect that it has been offline and request a complete update from the server that was running in the PARTNER-DOWN state, and then both servers will resume pro- cessing together. It is possible to get into a dangerous situation: if you put one server into the PARTNER-DOWN state, and then *that* server goes down, and the other server comes back up, the other server will not know that the first server was in the PARTNER-DOWN state, and may issue addresses previously issued by the other server to different clients, resulting in IP address conflicts. Before putting a server into PARTNER-DOWN state, therefore, make sure that the other server will not restart automatically. The failover protocol defines a primary server role and a secondary server role. There are some differences in how primaries and secondaries act, but most of the differences simply have to do with providing a way for each peer to behave in the opposite way from the other. So one server must be configured as primary, and the other must be con- figured as secondary, and it doesn't matter too much which one is which. FAILOVER STARTUP When a server starts that has not previously communicated with its failover peer, it must establish communications with its failover peer and synchronize with it before it can serve clients. This can happen either because you have just configured your DHCP servers to perform failover for the first time, or because one of your failover servers has failed catastrophically and lost its database. The initial recovery process is designed to ensure that when one failover peer loses its database and then resynchronizes, any leases that the failed server gave out before it failed will be honored. When the failed server starts up, it notices that it has no saved failover state, and attempts to contact its peer. When it has established contact, it asks the peer for a complete copy its peer's lease database. The peer then sends its complete database, and sends a message indicat- ing that it is done. The failed server then waits until MCLT has passed, and once MCLT has passed both servers make the transition back into normal operation. This waiting period ensures that any leases the failed server may have given out while out of contact with its partner will have expired. While the failed server is recovering, its partner remains in the partner-down state, which means that it is serving all clients. The failed server provides no service at all to DHCP clients until it has made the transition into nor- mal operation. In the case where both servers detect that they have never before communicated with their partner, they both come up in this recovery state and follow the procedure we have just described. In this case, no service will be pro- vided to DHCP clients until MCLT has expired. CONFIGURING FAILOVER In order to configure failover, you need to write a peer declaration that configures the failover protocol, and you need to write peer references in each pool declaration for which you want to do failover. You do not have to do failover for all pools on a given network segment. You must not tell one server it's doing failover on a particu- lar address pool and tell the other it is not. You must not have any common address pools on which you are not doing failover. The server currently does very little sanity checking, so if you configure it wrong, it will just fail in odd ways. I would recommend therefore that you either do failover or don't do failover, but don't do any mixed pools. Also, use the same master configuration file for both servers, and have a seperate file that con- tains the peer declaration and includes the master file. This will help you to avoid configuration mismatches. As our implementation evolves, this will become less of a problem. A basic sample dhcpd.conf file for a primary server might look like this: failover peer "foo" { primary; address anthrax.rc.vix.com; port 519; peer address trantor.rc.vix.com; peer port 520; max-response-delay 60; max-unacked-updates 10; mclt 3600; hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00; load balance max seconds 3; } include "/etc/dhcpd.master"; The statements in the peer declaration are as follows: The primary and secondary statements [ primary | secondary ]; This determines whether the server is primary or sec- ondary, as described earlier under DHCP FAILOVER. The address statement address address; The address statement declares the IP address on which the server should listen for connections from its failover peer, and also the value to use for the DHCP Failover Protocol server identifier. Because this value is used as an identifier, it may not be omitted. The peer address statement peer address address; The peer address statement declares the IP address to which the server should connect to reach its failover peer for failover messages. The port statement port port-number; The port statement declares the TCP port on which the server should listen for connections from its failover peer. This statement may not currently be omitted, because the failover protocol does not yet have a reserved TCP port number. The peer port statement peer port port-number; The peer port statement declares the TCP port to which the server should connect to reach its failover peer for failover messages. This statement may not be omitted because the failover protocol does not yet have a reserved TCP port number. The port number declared in the peer port statement may be the same as the port number declared in the port statement. The max-response-delay statement max-response-delay seconds; The max-response-delay statement tells the DHCP server how many seconds may pass without receiving a message from its failover peer before it assumes that connec- tion has failed. This number should be small enough that a transient network failure that breaks the con- nection will not result in the servers being out of communication for a long time, but large enough that the server isn't constantly making and breaking connec- tions. This parameter must be specified. The max-unacked-updates statement max-unacked-updates count; The max-unacked-updates statement tells the DHCP server how many BNDUPD messages it can send before it receives a BNDACK from the failover peer. We don't have enough operational experience to say what a good value for this is, but 10 seems to work. This parameter must be specified. The mclt statement mclt seconds; The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, and may not be specified on the secondary. This is the length of time for which a lease may be renewed by either failover peer without contacting the other. The longer you set this, the longer it will take for the running server to recover IP addresses after moving into PARTNER-DOWN state. The shorter you set it, the more load your servers will experience when they are not communicating. A value of something like 3600 is probably reasonable, but again bear in mind that we have no real operational experience with this. The split statement split index; The split statement specifies the split between the primary and secondary for the purposes of load balanc- ing. Whenever a client makes a DHCP request, the DHCP server runs a hash on the client identification. If the hash comes out to less than the split value, the primary answers. If it comes out to equal to or more than the split, the secondary answers. This value should generally be set to 128, and can only be config- ured on the primary. The hba statement hba colon-seperated-hex-list; The hba statement specifies the split between the pri- mary and secondary as a bitmap rather than a cutoff, which theoretically allows for finer-grained control. In practice, there is probably no need for such fine- grained control, however. An example hba statement: hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00; The load balance max seconds statement load balance max seconds seconds; This statement allows you to configure a cutoff after which load balancing is disabled. The cutoff is based on the number of seconds since the client sent its first DHCPDISCOVER or DHCPREQUEST message, and only works with clients that correctly implement the secs field - fortunately most clients do. We recommend set- ting this to something like 3 or 5. The effect of this is that if one of the failover peers gets into a state where it is responding to failover messages but not responding to some client requests, the other failover peer will take over its client load automatically as the clients retry. CLIENT CLASSING Clients can be seperated into classes, and treated differ- ently depending on what class they are in. This sepera- tion can be done either with a conditional statement, or with a match statement within the class declaration. It is possible to specify a limit on the total number of clients within a particular class or subclass that may hold leases at one time, and it is possible to specify automatic subclassing based on the contents of the client packet. To add clients to classes based on conditional evaluation, you would write a conditional statement to match the clients you wanted in the class, and then put an add statement in the conditional's list of statements: if substring (option dhcp-client-identifier, 1, 3) = "RAS " { add "ras-clients"; } A nearly equivalent way to do this is to simply specify the conditional expression as a matching expression in the class statement: class "ras-clients" { match if substring (option dhcp-client-identifier, 1, 3) = "RAS"; } Note that whether you use matching expressions or add statements (or both) to classify clients, you must always write a class declaration for any class that you use. If there will be no match statement and no in-scope state- ments for a class, the declaration should look like this: class "ras-clients" { } Also, the add statement adds the client to the class as the client's scopes are being evaluated - after any address assignment decision has been made. This means that a client that's a member of a class due to an add statement will not be affected by pool permits related to that class - when the pool permit list is computed, the client will not yet be a member of the pool. This is an inconsistency that will probably be addressed in later versions of the DHCP server, but it is important to be aware of it at least for the time being. SUBCLASSES In addition to classes, it is possible to declare sub- classes. A subclass is a class with the same name as a regular class, but with a specific submatch expression which is hashed for quick matching. This is essentially a speed hack - the main difference between five classes with match expressions and one class with five subclasses is that it will be quicker to find the subclasses. Sub- classes work as follows: class "allocation-class-1" { match pick-first-value (option dhcp-client-identifier, hardware); } class "allocation-class-2" { match pick-first-value (option dhcp-client-identifier, hardware); } subclass "allocation-class-1" 1:8:0:2b:4c:39:ad; subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3; subclass "allocation-class-1" 1:0:0:c4:aa:29:44; subnet 10.0.0.0 netmask 255.255.255.0 { pool { allow members of "allocation-class-1"; range 10.0.0.11 10.0.0.50; } pool { allow members of "allocation-class-2"; range 10.0.0.51 10.0.0.100; } } The data following the class name in the subclass declara- tion is a constant value to use in matching the match expression for the class. When class matching is done, the server will evaluate the match expression and then look the result up in the hash table. If it finds a match, the client is considered a member of both the class and the subclass. Subclasses can be declared with or without scope. In the above example, the sole purpose of the subclass is to allow some clients access to one address pool, while other clients are given access to the other pool, so these sub- classes are declared without scopes. If part of the pur- pose of the subclass were to define different parameter values for some clients, you might want to declare some subclasses with scopes. In the above example, if you had a single client that needed some configuration parameters, while most didn't, you might write the following subclass declaration for that client: subclass "allocation-class-2" 1:08:00:2b:a1:11:31 { option root-path "samsara:/var/diskless/alphapc"; filename "/tftpboot/netbsd.alphapc-diskless"; } In this example, we've used subclassing as a way to con- trol address allocation on a per-client basis. However, it's also possible to use subclassing in ways that are not specific to clients - for example, to use the value of the vendor-class-identifier option to de |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |