IP Conflict issue with DHCP

General questions.
User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

IP Conflict issue with DHCP

Post by trymes » September 21st, 2014, 9:59 pm

I have an address, specifically 10.3.0.231, reserved as a fixed address in DHCP on the blue interface (DHCP is not enabled on the Green interface). I installed a new device today and it retrieved that address, even though it is reserved.

This should clearly not happen. Have I configured something wrong, or is there an issue with IPFire?

Tom

User avatar
lucifercipher
Posts: 258
Joined: April 1st, 2014, 7:54 pm
Location: Earth, Moon & Mars

Re: IP Conflict issue with DHCP

Post by lucifercipher » September 22nd, 2014, 7:42 am

Thats weird indeed. Shouldn't happen and it does not happen normally. Unless, you use the same IP class for the green interface but again it doesn't make sense and shouldn't happen.
Image

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 22nd, 2014, 8:04 am

What is your dynamic IP space? Fixed and dynamic sets must not overlap!
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 22nd, 2014, 11:04 am

What? I have never had a device that requires this before! Why should it matter if the spaces overlap? A fixed address should automatically be excluded from provision to another device. This is particularly convenient if you wish to make sure that an address that was originally provided dynamically never changes. Besides, if that is required, it is not possible to define non-contiguous blocks of address space, which is all well and good if you are starting from scratch, but could be a complete pain if you are replacing an existing network that had fixed addresses strewn about throughout the subnet address space.

Tom

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 22nd, 2014, 1:18 pm

Sorry, my answer was not based on documentation of the DHCP server, but on experience with IPFire. I'll check this, or even better you point us to the related definition.
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 22nd, 2014, 1:35 pm

Aha. Perhaps that is how it works, but I would certainly argue that that is not how it SHOULD work!

Here is my dhcp.conf and, as you can see, the fixed range does overlap with the dynamic range:

Code: Select all

[root@ipfire ~]# cat /etc/dhcp/dhcpd.conf
ddns-update-style none;
deny bootp;     #default
authoritative;
option voip-tftp-server code 150=ip-address;
option voip-tftp-server 10.3.0.2;
option tftp-server-name "10.3.0.2";

subnet 10.3.0.0 netmask 255.255.255.0 #BLUE
{
        range 10.3.0.10 10.3.0.254;
        option subnet-mask 255.255.255.0;
        option domain-name "mydomain.dom";
        option routers 10.3.0.1;
        option domain-name-servers 10.3.0.1;
        option ntp-servers 10.3.0.1;
        option netbios-name-servers 192.168.0.254;
        default-lease-time 86400;
        max-lease-time 172800;
} #BLUE

host fix0 # FreePBX
{
        hardware ethernet xx:xx:xx:xx:4b:90;
        fixed-address 10.3.0.2;
}

host fix1 # Vox
{
        hardware ethernet xx:xx:xx:xx:ee:24;
        fixed-address 10.3.0.4;
}

host fix2 # CellX CDMA Gateway
{
        hardware ethernet xx:xx:xx:xx:6e:50;
        fixed-address 10.3.0.231;
}

host fix3 # Cisco Switch
{
        hardware ethernet xx:xx:xx:xx:4d:dd;
        fixed-address 10.3.0.253;
}
include "/var/ipfire/dhcp/dhcpd.conf.local";


Tom

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 22nd, 2014, 3:44 pm

The documentation isn't really clear enough about this problem ( or I didn't get it right ;) ).
But it is safe to separate these two sets of IPs. Further it helps to decide if an IP belongs to a well-known host or is just assigned from the dynamic pool.

For the process "Make a fixed lease" from the WUI, that means you have to edit the definition supplying the host with a free fixed IP.
That's the way, I do it.


Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 22nd, 2014, 4:27 pm

Thanks, Bernhard. I get the benefit of keeping them separate, but that's just not always easily accomplished. As for the documentation, I would think it's supported, given that adding a fixed lease from a dynamic one is possible, and results in this sort of configuration.

I'll file a bug.

Tom

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 23rd, 2014, 1:30 am

OK, so I have dug into this a little further, and I found this link (among others). It appears that any address defined as a fixed lease must be excluded from the range statement in the subnet declaration. IPFire does not do this, so that address can inadvertently be given out to two clients. There are a number of safety features built-in to avoid this, but they are not foolproof, so it is a bad idea to rely on them.

While it is ideal to administratively reserve a portion of the subnet for fixed leases (i.e.: start the DHCP pool at .20 and define fixed leases as .2 to .19), that is not always convenient in practice. Having said that, there is a relatively easy workaround to this problem: Multiple range statements.

For example: If you have a DHCP range of 10.1.0.2-20 and you want to define one host as fixed with the address 10.1.0.10, you use two range statements:

range 10.3.0.2-10.3.0.9;
range 10.3.0.11 10.3.0.20

Then you define the host with the fixed address and this problem will not recur.

If, however, IPFire wishes to REQUIRE its users to keep its fixed addresses outside of the DHCP scope, then the proper solution is to modify the WUI to not allow you to define a fixed address in that range. However, I would suggest that the better solution is to change the WUI to write multiple range entries when a fixed address falls within the dynamic range.

Tom

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 23rd, 2014, 9:40 am

Thanks for the link. It proofs my conjecture.

Reading the docs for the openDHCP server at sourceforge confirmed it too. Dynamic allocation choses one free IP out of the pool and/range for the subnet. The attribute state=free is usually determined by a ping at the IP, if the state is not known for sure. For Windows clients properly shutdown this isn't even necessary. The DHCP client sends a "DHCP RELEASE" message before closing. This IP is free!

Back to the IPFire implementation. I don't think we should define several ranges. This produces more complexity in the WUI than necessary. The process of defining the two IP sets ( dynamic, static ) is better done by the administrator. ( There is more computing power, I think ;) )
Having two contiguous sets it much easier to interpret IPs in case of an investigation of problems.

Regarding the check for a fixed IP is contained in the dynamic set, you are right. We should implement that. I'll describe that in your bugzilla entry about this topic ( exactly about enabling by default ). We should improve the functionality "Add a dynamic lease as fixed" too.

Thanks for pointing us to this problem. Maybe most ( all? ) core developpers came from IPCop project and did this definitions right. IPCop documentation states this necessary separation. We should expand our wiki with this.

-Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 23rd, 2014, 2:42 pm

Bernhard,

I see you found bug #10629, which I filed about the duplicate address problem, but I am posting it here for everyone else.

I must take this time, though, to STRONGLY disagree with your analysis of the proper steps forward. While I can appreciate the preference for keeping the fixed and dynamic spaces separate, that is simply not always convenient or practicable in the real world. In the end, if IPFire chooses to REQUIRE the strict separation of the ranges, what you are in effect doing is telling the administrator what s/he may or may not do with his/her network. I think it should be perfectly clear why that is a bad thing.

The two simplest solutions here are:

1.) Modify the WUI to write dhcp.conf with multiple range statements.
2.) Modify the WUI to perform data validation of entered fixed leases and reject those that overlap the dynamic pool, plus modify the process of creating fixed leases from existing dynamic leases to ensure that they are not created and/or enabled until the address has been modified such that it does not overlap.

If one agrees with my earlier statement about it being best not to tell users what they may or may not do on their own networks, I would suggest that #1 is preferable. Combine that with the fact that #1 should also be easier to develop, then I cannot imagine why pursuing #2 would make any sense.

To put it another way: I can understand why you choose to run your network the way you; please try to understand that others may prefer to do things differently.

Thank you,

Tom

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 23rd, 2014, 3:42 pm

Tom,

I cannot see an advantage in "mixing" IP spaces. We talk about IPs managed at IPFire by the admin. In case of really static IPs, I'll agree with you. But this would demand to define several ranges in the WUI.

On solution #2 I'm working at the moment, as I mentioned in Bugzilla. This checking is necessary nevertheless because of the operation of the DHCP server. You cannot mix the pools of dynamic IPs and fixed leases IPs.

Therefore solution #2 is in fact solution #1. Your #1 is an extension to that.

BTW: In which scenario are you really urged to split the dynamic range?

- Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 24th, 2014, 5:40 pm

BeBiMa wrote:I cannot see an advantage in "mixing" IP spaces. We talk about IPs managed at IPFire by the admin.


The advantage is more flexibility versus less. There is no functional downside to overlapping IP spaces, but there is added flexibility, and more flexibility is generally better, all other things being equal.

In case of really static IPs, I'll agree with you. But this would demand to define several ranges in the WUI.


It would not require multiple ranges in the WUI, the WUI would look identical to how it does today. To fix this problem would only involve changing how the WUI writes out the dhcp.conf file. Specifically, the script would have to evaluate the DHCP pool and the fixed addresses, then write the range statements such that any defined fixed lease is excluded from the dynamic pool. To the user it would (and should) be invisible. Please correct me if I am wrong, but I cannot see how the changes I propose would be more complex or difficult than the data validation changes you are proposing.

On solution #2 I'm working at the moment, as I mentioned in Bugzilla. This checking is necessary nevertheless because of the operation of the DHCP server. You cannot mix the pools of dynamic IPs and fixed leases IPs.


This is not accurate; you CAN mix the pools. What you cannot do is BOTH mix the pools AND only write a single range statement. If you properly write multiple range statements to exclude the fixed leases, it works just fine. To reiterate, the script should be writing the multiple ranges in the background, it should be invisible to the user.

Therefore solution #2 is in fact solution #1. Your #1 is an extension to that.

Certainly not. If the range statements are written properly (to exclude defined fixed leases from the dynamic pool), then no additional data validation is required, which means that #2 is moot.

BTW: In which scenario are you really urged to split the dynamic range?


There are many potential situations, but here are two:

  1. I install a new device, but forget to give it a fixed IP while testing it (this happened recently with a CDMA to SIP gateway we added to our Asterisk PBX). The new device acquires an address from the DHCP pool, and I proceed to test and write configurations based on that IP Address. At a certain point I am ready to place it into production, but I really do not want to rewrite all of the configuration files, etc to reference a new, fixed address. Not only is it additional work for no functional benefit, but it could result in errors that I will have to spend time tracking down (typos, an instance of the old address I forgot to change, etc). It is far simpler to just assign the originally dynamic address to that device as a fixed lease and move on from there.
  2. You inherit a pre-existing LAN from a now-departed administrator. You replace the existing, outdated router and DHCP server with IPFire. The DHCP range is 10.7.5.10-254, but a printer with a fixed address is at 10.7.5.50. It is far simpler to reserve 10.7.5.50 in DHCP than to manually change the printer to 10.7.5.9 and then reconfigure all of the clients, and once again you avoid the possibility of errors during the IP reconfiguration process. More importantly, all you gain by moving the IP Address is a little neatness: it is functionally identical.

Lastly, I would pose this question: "It is quite simple to write the dhcp.conf file to allow fixed leases to overlap the dynamic lease with no adverse affects to functionality. Why, then, would you force users to do it another way?"

Tom

BeBiMa
Posts: 2811
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: IP Conflict issue with DHCP

Post by BeBiMa » September 24th, 2014, 6:46 pm

trymes wrote:The advantage is more flexibility versus less. There is no functional downside to overlapping IP spaces, but there is added flexibility, and more flexibility is generally better, all other things being equal.

More flexibility is more complexity!

trymes wrote:It would not require multiple ranges in the WUI, the WUI would look identical to how it does today. To fix this problem would only involve changing how the WUI writes out the dhcp.conf file. Specifically, the script would have to evaluate the DHCP pool and the fixed addresses, then write the range statements such that any defined fixed lease is excluded from the dynamic pool. To the user it would (and should) be invisible. Please correct me if I am wrong, but I cannot see how the changes I propose would be more complex or difficult than the data validation changes you are proposing.

The computation of the various sets (ranges) is more complex.

trymes wrote:This is not accurate; you CAN mix the pools. What you cannot do is BOTH mix the pools AND only write a single range statement. If you properly write multiple range statements to exclude the fixed leases, it works just fine. To reiterate, the script should be writing the multiple ranges in the background, it should be invisible to the user.
Sorry, I was not exactly enough. I looked at the problem from the technical side, the usage of the DHCP server. From a users side, surely you can define the range of IPs with exceptions as fixed leases. But this is not the interface defined ( at the moment ).

trymes wrote:Certainly not. If the range statements are written properly (to exclude defined fixed leases from the dynamic pool), then no additional data validation is required, which means that #2 is moot.

That's not quite right. There is some validation required: double definitions for same MAC in one subnet ( = interface; dhcpd selects according to the interface the request is received), fixed leases MUST adhere to one of the defined nets ( as you can see in the WUI, there is a special colour for this; but it is not implemented at the moment). The check against the dynamic range is just a small further condition.

trymes wrote:There are many potential situations, but here are two:

  • I install a new device, but forget to give it a fixed IP while testing it (this happened recently with a CDMA to SIP gateway we added to our Asterisk PBX). The new device acquires an address from the DHCP pool, and I proceed to test and write configurations based on that IP Address. At a certain point I am ready to place it into production, but I really do not want to rewrite all of the configuration files, etc to reference a new, fixed address. Not only is it additional work for no functional benefit, but it could result in errors that I will have to spend time tracking down (typos, an instance of the old address I forgot to change, etc). It is far simpler to just assign the originally dynamic address to that device as a fixed lease and move on from there.

This is a case of a static IP

trymes wrote:
  • You inherit a pre-existing LAN from a now-departed administrator. You replace the existing, outdated router and DHCP server with IPFire. The DHCP range is 10.7.5.10-254, but a printer with a fixed address is at 10.7.5.50. It is far simpler to reserve 10.7.5.50 in DHCP than to manually change the printer to 10.7.5.9 and then reconfigure all of the clients, and once again you avoid the possibility of errors during the IP reconfiguration process. More importantly, all you gain by moving the IP Address is a little neatness: it is functionally identical.

Why do you want to take over a misconfiguration? If the dynamic range contains a fixed/static address there is a chance that the DHCP server choses this IP, if the printer is offline.

trymes wrote:Lastly, I would pose this question: "It is quite simple to write the dhcp.conf file to allow fixed leases to overlap the dynamic lease with no adverse affects to functionality. Why, then, would you force users to do it another way?"

The way I described, is the way dhcpd is implemented in IPFire. It wasn't documented in the wiki 'til now, that's right. But the fact, you are the first(?) user having this problem, shows most users made it intuitively right.
The real bug at the moment is the activation of faulty definitions ( IP not in a net etc. ). This bug must be fixed! And with this fix comes a check for dynamic range violation.

Your suggestion of cutting the dynamic lease range into parts by means of fixed leases isn't forgotten. We should discuss this further.

Double IPs in a net are a real problem. Users comfort is sufficient but not necessary, spoken in formal logic.

BTW: The splitting of the dynamic range introduces the necessity of some sort of garbage collection. Not with the complexity as in case of memory allocation, but non-trivial.

-Bernhard
Last edited by BeBiMa on September 24th, 2014, 7:03 pm, edited 1 time in total.
Image
Unitymedia Cable Internet ( 32MBit )

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IP Conflict issue with DHCP

Post by trymes » September 24th, 2014, 9:01 pm

Bernhard,

I think we may be talking past each other here?

I will try to boil it down some here:

  1. Keeping the dynamic and fixed lease spaces separate is NOT a requirement of ISC DHCP. Many prefer to do it that way, and many others don't care. Regardless, it will work perfectly well if you allow the address spaces to overlap (provided you write the config file properly).
  2. The current implementation in IPFire DOES require you to keep those spaces separate, because it does not do anything to exclude the fixed lease addresses from the dynamic pool.
  3. You presume that I am the first person to run into this problem because nobody else does it this way. I would argue that many others do it the same way I do, but the ISC safety features (ping, etc) have simply prevented those others from being bitten by this particular bug. I was dealing with an odd-ball device that must have caused those safety features to fail.
  4. My suggestion does not involve any changes to the interface/WUI from the users' point of view. All that should change is the background process that writes the dhcp.conf file.

Tom

Post Reply