0001050: Force DHCP to send DHCPNACKs to client that juste changed VLAN that insist on getting an invalid IP - PacketFence

(0001637)
obilodeau (reporter)
2010-09-02 01:53

Problem reproduced today, switching was longer than supposed to. Windows apparently does 3 DHCPREQUEST first with it's old IP before going back to a DHCPDISCOVER so it takes longer to get an IP.

Problem was worse due to the fact that all DHCP scopes (prod and pf's) were running on the same server.

we should look into having a shared {} statement that would bind tightly to an interface and NACK everything else in order to provide faster switching from VLAN

(0002033)
user201
2011-04-19 11:04

quick update... example of syntax for the deny all clients... : a pool must be define to allow a NACK...

subnet 192.168.61.0 netmask 255.255.255.0 {

        option routers 192.168.61.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.61.255;

        pool {
                range 192.168.61.0 192.168.61.40;
                deny all clients;
        }
        pool {
                range 192.168.61.41 192.168.61.199;

        }
}

(0002193)
fgaudreault (viewer)
2011-09-09 15:38

Just doing some round up on tickets.

This issue will only happen if PF is the production DHCP or if you switch between registration <-> isolation.

I think we should only care about the registration<-> isolation part, and make the proper changes in the dhcpd.conf template. You are technically not supposed to use PF as your enterprise server.

(0002197)
fgaudreault (viewer)
2011-09-12 15:46

It will imply to change the way we start dhcpd process, and build the configuration.

Won't be for 3.0.

(0003727)
lmunro (administrator)
2015-02-13 15:26

Old issues.
Most are not relevant to PF 4 and up.

Let's reopen the ones that matter when we move to github.

Issue History
Date Modified	Username	Field	Change
2010-08-24 13:53	obilodeau	New Issue
2010-08-24 13:53	obilodeau	Status	new => assigned
2010-08-24 13:53	obilodeau	Assigned To	=> obilodeau
2010-09-02 01:53	obilodeau	Note Added: 0001637
2010-11-19 14:25	obilodeau	Target Version	1.10.0 => 2.0.0
2010-12-01 12:07	obilodeau	Relationship added	related to 0001132
2011-01-18 09:47	obilodeau	Target Version	2.0.0 => 2.1.0
2011-03-03 15:15	obilodeau	Target Version	2.1.0 => +1
2011-03-03 15:18	obilodeau	Target Version	+1 => +2
2011-04-19 11:04	user201	Note Added: 0002033
2011-09-09 15:38	fgaudreault	Note Added: 0002193
2011-09-12 15:46	fgaudreault	Note Added: 0002197
2015-02-13 15:26	lmunro	Note Added: 0003727
2015-02-13 15:26	lmunro	Status	assigned => closed

Notes
(0001637) obilodeau (reporter) 2010-09-02 01:53	Problem reproduced today, switching was longer than supposed to. Windows apparently does 3 DHCPREQUEST first with it's old IP before going back to a DHCPDISCOVER so it takes longer to get an IP. Problem was worse due to the fact that all DHCP scopes (prod and pf's) were running on the same server. we should look into having a shared {} statement that would bind tightly to an interface and NACK everything else in order to provide faster switching from VLAN

(0002033) user201 2011-04-19 11:04	quick update... example of syntax for the deny all clients... : a pool must be define to allow a NACK... subnet 192.168.61.0 netmask 255.255.255.0 { option routers 192.168.61.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.61.255; pool { range 192.168.61.0 192.168.61.40; deny all clients; } pool { range 192.168.61.41 192.168.61.199; } }

(0002193) fgaudreault (viewer) 2011-09-09 15:38	Just doing some round up on tickets. This issue will only happen if PF is the production DHCP or if you switch between registration <-> isolation. I think we should only care about the registration<-> isolation part, and make the proper changes in the dhcpd.conf template. You are technically not supposed to use PF as your enterprise server.

(0002197) fgaudreault (viewer) 2011-09-12 15:46	It will imply to change the way we start dhcpd process, and build the configuration. Won't be for 3.0.

(0003727) lmunro (administrator) 2015-02-13 15:26	Old issues. Most are not relevant to PF 4 and up. Let's reopen the ones that matter when we move to github.