El RFC 3203, habla sobre FORCERENEW http://www.ietf.org/rfc/rfc3203.txt
Tendrías que ver si tu servidor DHCP tiene algo para eso... Lázaro Armando cogió un teclado y escribió: > > Thread name: "Re: [Gutl-l] forza dhcp-server" > Mail number: 3 > Date: Wed, Nov 19, 2014 > In reply to: Javier Santiesteban > > > > ya lo he puesto en el mínimo pero quería saber si existe algun > > comando que puediera ejecutarse y forzar a toda la red > > > > Mira a ver si te juega esto: > > > > lazaro@leviatan:~$ w3m -T text/html -dump > http://wiki.nil.com/DHCP_client_address_change > DHCP client address change > > From CT3 > > Jump to: navigation, search > > By Ivan Pepelnjak > > The DHCP protocol specifications do not specify the exact mechanisms a DHCP > server can use to force the address change on the DHCP client. It’s assumed > that once a DHCP client received the IP address from a DHCP server, the > address > remains valid for the duration of the lease period. A DHCP server can > influence > the client’s IP address only when the client asks the server for lease > extension or address validation using the DHCPREQUEST message. > > A DHCP client asks for a lease extension when the T1 timer expires (usually at > half the lease period) but could verify its IP address at any time, for > example > when the LAN interface becomes operational or when a workstation reboots or > wakes from suspended/hibernated state. > > When a DHCP server does not want to extend the IP address lease, it can: > > • Acknowledge the IP address without extending the lease by responding with > the DHCPACK packet. > • Reject the client’s IP address with the DHCPNAK packet. > • Ignore the DHCPREQUEST packet and wait for the client’s lease to expire. > > Internet Systems Consortium has decided to use the term authoritative DHCP > server for the server that actively rejects client’s DHCPREQUEST packet with a > DHCPNAK packet. > > Contents > > • 1 DHCP server behavior > □ 1.1 Linux DHCP server > □ 1.2 Cisco IOS DHCP server > • 2 Cisco IOS DHCP client behavior > □ 2.1 Lease expiration behavior > □ 2.2 Address change behavior > • 3 References > > DHCP server behavior > > Linux DHCP server > > The ISC DHCP server available in most Linux distributions tries to accommodate > the client’s requests. When a server that lost its bindings receives a > DHCPREQUEST packet from a client, it responds with a DHCPACK message (and > stores the client-ID-to-IP-address binding in its database) if the client’s IP > address belongs to the correct subnet and is not already used by some other > client. In other cases, the server does not respond to the request unless it’s > configured to be authoritative. An authoritative ISC DHCP server rejects all > mismatched DHCPREQUEST messages with a DHCPNAK response, causing the client to > enter the INIT state immediately. > > Cisco IOS DHCP server > > Cisco IOS does not use the DHCPREQUEST packets to repopulate its DHCP binding > database. The DHCPREQUEST packets coming from clients that are not in the DHCP > binding database are ignored; the clients’ lease period has to expire before > its IP address can be changed. > > The Cisco IOS DHCP server rejects all DHCPREQUEST packets with invalid IP > addresses (IP addresses not belonging to the subnet from which the DHCPREQUEST > packet was received) with a DHCPNAK packet, causing the DHCP client to > reacquire its IP address. > > Requests with unexpected IP addresses coming from clients with known > (statically mapped) Client-IDs are also rejected immediately with the DHCPNAK > response. > > Cisco IOS DHCP client behavior > > Although the client DHCP state transition diagram treats lease expiration > (timeout) and lease extension rejection (indicated by the DHCPNAK response) in > an almost identical way (both events lead to the INIT state), the Cisco IOS > DHCP client reacts to them in a completely different manner: > > • If the lease expires, the interface is bounced, new address is acquired > and > reported in a syslog message (DHCP_6-ADDRESS_ASSIGN). > • If the DHCP server rejects the IP address included in the lease extension > request, the DHCP client quietly acquires a new address and does not > report > the event. The only noticeable change is a slight disruption in the IP > routing table which you can [with EEM IP routing detector]. > > Both behaviors were tested with IOS release 12.4(24)T and several earlier > releases. The printouts included in the following sections were generated with > the debug dhcp and debug ip routing commands. > > Lease expiration behavior > > When a DHCP lease expires, the Cisco IOS DHCP client shuts down the interface, > resulting in route removal from the IP routing table. > > DHCP lease expires > > 09:33:50.052: DHCP: SRequest attempt # 1 for entry: > 09:33:50.052: DHCP: SRequest - ciaddr: 192.168.0.12 > 09:33:50.056: DHCP: SRequest placed lease len option: 60 > 09:33:50.056: DHCP: SRequest: 281 bytes > 09:33:50.056: DHCP: SRequest: 281 bytes > 09:33:50.056: B'cast on FastEthernet0/0 interface from > 192.168.0.12 > 09:33:59.052: DHCP: Address lease expired. Attempting Shutdown > > Interface is shut down, connected and static routes are removed from the IP > routing table > > 09:33:59.052: %DHCP-5-RESTART: Interface FastEthernet0/0 is being restarted > by DHCP > 09:33:59.056: RAC: DHCP stopped on interface FastEthernet0/0 > 09:33:59.064: RT: Pruning routes for FastEthernet0/0 (1) > 09:33:59.072: RT: delete route to 192.168.0.0 via 0.0.0.0, FastEthernet0/0 > 09:33:59.072: RT: no routes to 192.168.0.0, flushing > 09:33:59.072: RT: NET-RED 192.168.0.0/24 > 09:34:01.072: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to > administratively down > 09:34:02.072: %LINEPROTO-5-UPDOWN: Line protocol on Interface > FastEthernet0/0, changed state to down > > The interface is immediately re-enabled (although the corresponding syslog > messages appear after a few seconds) and the DHCP process is restarted: > > DHCP is restarted > > 09:34:02.116: DHCP: DHCP client process started: 10 > 09:34:02.124: RAC: Starting DHCP discover on FastEthernet0/0 > > The DHCP client sends DHCPDISCOVER and DHCPREQUEST messages ... > > Initial DHCP messages > > 09:34:02.124: DHCP: Try 1 to acquire address for FastEthernet0/0 > 09:34:02.136: DHCP: allocate request > 09:34:02.136: DHCP: zapping entry in DHC_PURGING state for Fa0/0 > 09:34:02.136: DHCP: deleting entry 6808A734 192.168.0.12 from list > 09:34:02.136: DHCP: new entry. add to queue, interface FastEthernet0/0 > 09:34:02.136: DHCP: SDiscover attempt # 1 for entry: > 09:34:02.136: DHCP: SDiscover: sending 275 byte length DHCP packet > 09:34:02.136: DHCP: SDiscover 275 bytes > 09:34:02.136: B'cast on FastEthernet0/0 interface from 0.0.0.0 > 09:34:04.092: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up > 09:34:04.124: DHCP: Received a BOOTREP pkt > 09:34:04.128: DHCP: offer received from 192.168.0.2 > 09:34:04.128: DHCP: SRequest attempt # 1 for entry: > 09:34:04.132: DHCP: SRequest- Server ID option: 192.168.0.2 > 09:34:04.132: DHCP: SRequest- Requested IP addr option: 192.168.0.13 > 09:34:04.132: DHCP: SRequest placed lease len option: 60 > 09:34:04.132: DHCP: SRequest: 293 bytes > 09:34:04.132: DHCP: SRequest: 293 bytes > 09:34:04.132: B'cast on FastEthernet0/0 interface from 0.0.0.0 > > ... and sets the interface IP address once it receives the DHCPACK response: > > IP address is set on the interface > > 09:34:04.136: DHCP: Received a BOOTREP pkt > 09:34:05.092: %LINEPROTO-5-UPDOWN: Line protocol on Interface > FastEthernet0/0, changed state to up > 09:34:07.152: DHCP Client Pooling: ***Allocated IP address: 192.168.0.13 > > Once the interface has an IP address, the connected route is inserted in the > IP > routing table, followed by a DHCP-generated default route: > > Connected and static routes are inserted in the IP routing table > > 09:34:07.152: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 > has_route: True > 09:34:07.152: RT: add 192.168.0.0/24 via 0.0.0.0, connected metric [0/0] > 09:34:07.156: RT: NET-RED 192.168.0.0/24 > 09:34:07.156: RT: interface FastEthernet0/0 added to routing table > 09:34:07.156: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 > has_route: True > 09:34:07.260: Allocated IP address = 192.168.0.13 255.255.255.0 > > Last but not least, a syslog message reports the new IP address: > > DHCP client reports the new IP address in a syslog message > > 09:34:07.264: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP > address 192.168.0.13, → > mask 255.255.255.0, hostname Client > > Address change behavior > > When the Cisco IOS DHCP client receives a DHCPNAK response to a lease > extension > request, it removes the interface IP address, resulting in loss of IP routes > associated with the interface. > > DHCP server sends a DHCPNAK response to the DHCPREQUEST message > > 09:37:49.604: DHCP: SRequest attempt # 1 for entry: > 09:37:49.604: DHCP: SRequest - ciaddr: 10.17.1.30 > 09:37:49.604: DHCP: SRequest placed lease len option: 30 > 09:37:49.604: DHCP: SRequest: 281 bytes > 09:37:49.604: DHCP: SRequest: 281 bytes > 09:37:49.604: DHCP: Received a BOOTREP pkt > > Connected and static routes are removed from the IP routing table > > 09:37:49.604: RT: del 0.0.0.0 via 10.17.1.2, static metric [254/0] > 09:37:49.604: RT: delete network route to 0.0.0.0 > 09:37:49.604: RT: NET-RED 0.0.0.0/0 > 09:37:49.604: RT: NET-RED 0.0.0.0/0 > 09:37:49.640: RT: Pruning routes for FastEthernet0/1 (1) > 09:37:49.648: RT: delete route to 10.17.1.0 via 0.0.0.0, FastEthernet0/1 > 09:37:49.648: RT: no routes to 10.17.1.0, flushing > 09:37:49.648: RT: NET-RED 10.17.1.0/24 > > The DHCP client then starts the address acquisition process: it sends the > DHCPDISCOVER message followed by the DHCPREQUEST message. > > DHCP address acquisition process > > 09:37:49.656: DHCP: SDiscover attempt # 1 for entry: > 09:37:49.656: DHCP: SDiscover: sending 275 byte length DHCP packet > 09:37:49.656: DHCP: SDiscover 275 bytes > 09:37:49.656: B'cast on FastEthernet0/1 interface from 0.0.0.0 > 09:37:50.468: DHCP: Received a BOOTREP pkt > 09:37:50.472: DHCP: offer received from 10.17.1.2 > 09:37:50.472: DHCP: SRequest attempt # 1 for entry: > 09:37:50.472: DHCP: SRequest- Server ID option: 10.17.1.2 > 09:37:50.472: DHCP: SRequest- Requested IP addr option: 10.17.1.17 > 09:37:50.472: DHCP: SRequest placed lease len option: 30 > 09:37:50.472: DHCP: SRequest: 293 bytes > 09:37:50.472: DHCP: SRequest: 293 bytes > 09:37:50.472: B'cast on FastEthernet0/1 interface from 0.0.0.0 > 09:37:50.476: DHCP: Received a BOOTREP pkt > > After the DHCP client receives IP address from the DHCP server, it sets the > interface IP address and inserts the DHCP-generated default route in the IP > routing table. The change of interface IP address triggers the insertion of > connected route in the IP routing table. > > Connected and static default routes are inserted in the IP routing table > > 09:37:53.500: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 > has_route: True > 09:37:53.500: RT: network 10.0.0.0 is now variably masked > 09:37:53.500: RT: add 10.17.1.0/24 via 0.0.0.0, connected metric [0/0] > 09:37:53.500: RT: NET-RED 10.17.1.0/24 > 09:37:53.500: RT: interface FastEthernet0/1 added to routing table > 09:37:53.504: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 > has_route: True > 09:37:54.496: DHCP Client Pooling: ***Allocated IP address: 10.17.1.17 > 09:37:54.504: RT: add 0.0.0.0/0 via 10.17.1.2, static metric [254/0] > 09:37:54.508: RT: NET-RED 0.0.0.0/0 > 09:37:54.512: RT: default path is now 0.0.0.0 via 10.17.1.2 > 09:37:54.512: RT: new default network 0.0.0.0 > 09:37:54.512: RT: NET-RED 0.0.0.0/0 > > References > > • RFC 2131: State transition diagram for DHCP clients > • DHCP client finite state machine from the TCP/IP guide > > Retrieved from "http://wiki.nil.com/DHCP_client_address_change"; > Category: DHCP > > Views > > • Page > • Discussion > • View source > • History > > Personal tools > > • Log in / create account > > CT^3 > > Main menu > > • Training > • Community > > > > Navigation > > • Main Page > • Authors > • Related blogs > • Training > • Contribute > • Help > > What's new > > • Recent changes > • New pages > • Random page > > Search > > [ ] [Go] [Search] > Toolbox > > • What links here > • Related changes > • Special pages > • Printable version > • Permanent link > > Share This! > > • Add to BlogMarks BlogMarks > • Add to del.icio.us del.icio.us > • Add to digg digg > • Add to Facebook Facebook > • Add to LinkedIn LinkedIn > • Add to Newsvine Newsvine > • Add to reddit reddit > • Add to Slashdot Slashdot > > Powered by MediaWiki > > • This page was last modified on 13 November 2009, at 09:52. > • This page has been accessed 19,475 times. > • Privacy policy > • About CT3 > • Disclaimers > > > -- -------- Warning! ------------ 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. A continuación, la firma de una herramienta inútil: -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio.
______________________________________________________________________ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
