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 -- 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
