Assigning IP Addresses

[Fyew-jit-tiv]

Just a quick question.

When assigning ip addresses within the Asus GUI (LAN>DHCP) Should this be done outside the DHCP range?

For example.

DHCP is set by default to run .2 to .255 so should i be moving this to .2 to 100 and manually assign my devices from .101 to 255?

 

[Wade Coxon]

Ideally, yes. You should set your static DHCP addresses outside of the configured dynamic range.

 

[Fyew-jit-tiv]

Ideally, yes. You should set your static DHCP addresses outside of the configured dynamic range.

Thanks for confirming this. Another Q.

When disabling DHCP the router pops up a message warning regards the mesh nodes being effected. will this cause problems with static devices connecting to the node?

 

[Wade Coxon]

If you disable DHCP, then all addresses need to be assigned within the client devices themselves, as the router will no longer hand out any addresses.

The node itself gets its IP via DHCP, so if that is disabled, you will prevent the node from getting an address as there is no easy to configure that manually. I'm not sure what will happen if you have a non-asus DHCP server on your network.

 

[ColinTaylor]

Just a quick question.

When assigning ip addresses within the Asus GUI (LAN>DHCP) Should this be done outside the DHCP range?

For example.

DHCP is set by default to run .2 to .255 so should i be moving this to .2 to 100 and manually assign my devices from .101 to 255?

There is no right or wrong way to do this. Either is acceptable to the router and which method you choose is a matter of personal choice. Personally I put them inside the DHCP range.

This is distinctly different from "static" IP addresses which are manually configured on a client's network adapter. As the DHCP server has no knowledge of these addresses you must use an address that is outside the DHCP range, or create a bogus DHCP reservation for it (which again can be inside or outside of the range).

 

[MarkyPancake]

The node itself gets its IP via DHCP, so if that is disabled, you will prevent the node from getting an address as there is no easy to configure that manually. I'm not sure what will happen if you have a non-asus DHCP server on your network.

I've manually assigned my AiMesh node an IP address outside my DHCP pool via the router's LAN > DHCP Server page and it still works as it did when it was getting its IP from the DHCP pool.

 

[eibgrad]

I remember many years ago (on other firmware) allowing static leases to be assigned within the DHCP pool. But I ran into a problem where that would sometimes lead to two devices being assigned the same IP! IOW, DNSMasq didn't acknowledge the IP was already reserved if it was also in the DHCP pool. It just blindly allocated IPs from the DHCP pool w/ no respect to the static leases.

Now whether this was a design flaw, bug, intentional, or if it even is an issue these days, I don't know. But ever since, I've taken no chances and vowed to never assign static leases from the DHCP pool. Just better to avoid even the possibility of a conflict imo.

 

[Wade Coxon]

I've manually assigned my AiMesh node an IP address outside my DHCP pool via the router's LAN > DHCP Server page and it still works as it did when it was getting its IP from the DHCP pool.

That's what I do too. But that's not what I said in my quote.

What I said was that I don't know what will happen if the node gets its address from a DHCP server that is not your AiMesh master node. I don't know if there is some special bit of code that ties the mesh functions to an address based on the address given out via DHCP.

 

[dosborne]

Typically, and to ensure you don't have duplicate IP address issues, you assign static IP addresses outside the DHCP range. The best, although not the only way to do it, is to have 3 scenarios.
1 - Static IPs for resources (network infrastructure, printers, switches, servers,...) you access on the network
2 - Reserved addresses for resources that may move around, but you may want to manage.
3 - DHCP assigned addresses for transient devices that you essentially don't care about.


For servers and such, I usually set a static IP *AND* put a reservation into the DHCP table so that on the off chance a device resets to defaults (and a DHCP assigned address) it will still be where I expect it to be.

This is all in conjunction of course with deciding if a device is wired, 2.4Ghz WifFi, 5GHz Wifi, Main SSID, guest SSID, etc

 

[RMerlin]

Best practice guidelines states that:

1) If you are configuring a reservation within the DHCP server, then these should be within the DHCP scope (because a static lease is still a lease, therefore it should be within the scope)
2) If you are configuring a static IP on the client device, then these should be outside the DHCP scope (to ensure that DHCP leases won't conflict with static IPs it doesn't know about)

 

[eibgrad]

Best practice guidelines states that:

1) If you are configuring a reservation within the DHCP server, then these should be within the DHCP scope (because a static lease is still a lease, therefore it should be within the scope)
2) If you are configuring a static IP on the client device, then these should be outside the DHCP scope (to ensure that DHCP leases won't conflict with static IPs it doesn't know about)

As an experiment, I took one of my lab routers (running FreshTomato, if it matters) and configured a *one* IP DHCP pool, then created a static lease based on that same IP. When I attempted to connect to the router from a client, it received an APIPA address (169.254.x.x). If I increased the DHCP pool to two IPs, it immediately assigned that additional IP.

So it would appear you're correct, and it is consistent with how most GUIs assign static leases. They don't require you to change the IP already assigned from the DHCP pool.

Although once burned, you never forget. In all likelihood my experience was an early design flaw/bug.

I suppose you might be justified assigning static leases *outside* the DHCP pool if you had a LOT of static leases and a small DHCP pool. But given how easily you can expand the DHCP pool (even if that means changing the network size, say /24 to /23), that would still seem unnecessary.

 

[MarkyPancake]

Interesting. I've always assigned static IPs that are outside the DHCP pool via the LAN > DHCP Server page and never had any issues. E.g. pool goes from .100 to .149. Manually assigned IPs are currently .10 to .24. Unless I've misunderstood the previous posts.

 

[eibgrad]

Interesting. I've always assigned static IPs that are outside the DHCP pool via the LAN > DHCP Server page and never had any issues. E.g. pool goes from .100 to .149. Manually assigned IPs are currently .10 to .24. Unless I've misunderstood the previous posts.

In the end, I don't think it really matters, just so long as DNSMasq behaves correctly when assigning static leases inside the pool (which my testing seems to confirm). Inside, outside, take your pick. I've been specifying static leases outside the DHCP pool for ages, w/ no known negative effects. Defining static lease outside the DHCP pool also helps to quickly distinguish static leases from pool leases in any device lists.

 

[RMerlin]

As an experiment, I took one of my lab routers (running FreshTomato, if it matters) and configured a *one* IP DHCP pool, then created a static lease based on that same IP. When I attempted to connect to the router from a client, it received an APIPA address (169.254.x.x). If I increased the DHCP pool to two IPs, it immediately assigned that additional IP.

The idea is that a static lease is, in the end, still a lease (this is why terminology is important here - a static lease is NOT a static IP). The only difference is you are telling the DHCP server on a lease request to always allocate that particular IP for that specific MAC.

Some DHCP servers will enforce it, others won't. So, it's safer (and more logical) to have static leases be taken from your lease pool.

 

[Dabombber]

Since as you mention it depends on the server, wouldn't it be best to follow the dnsmasq documentation?

Addresses will be given out from the range <start-addr> to <end-addr> and from statically defined addresses given in --dhcp-host options.

and

Addresses allocated like this are not constrained to be in the range given by the --dhcp-range option, but they must be in the same subnet as some valid dhcp-range.

 

[ColinTaylor]

Since as you mention it depends on the server, wouldn't it be best to follow the dnsmasq documentation?

But the documentation doesn't state any particular method. It just says it will accept any address (so long as it is within the subnet).

RMerlin's method will be familiar to people that have worked with commercial DHCP servers, like Microsoft's. There you would create "scopes", "reservations" (what people here are calling static leases) and "exclusions". The way these three things interact with each other is obvious from the layout in the management interface. You just don't have all those options using the Asus' GUI so the distinctions are less clear.

 

[Dabombber]

But the documentation doesn't state any particular method.

I'm not sure what you mean by this, method for what?

There you would create "scopes", "reservations" (what people here are calling static leases) and "exclusions".

If you do want to compare dnsmasq to Microsoft's DHCP server, a "reservation" would be an assigned address (--dhcp-host) on a DHCP range declared with the static keyword (--dhcp-range=...,static,...). Since a static DHCP range isn't possible using only the GUI, and is unnecessary for assigned address on the same subnet as an existing DHCP range, then you might as well consider a reservation to be equivalent to an assigned address outside the dhcp-range.

 

[ColinTaylor]

I'm not sure what you mean by this, method for what?

Whether a reserved IP address should be inside or outside of the dhcp range.

... then you might as well consider a reservation to be equivalent to an assigned address outside the dhcp-range.

You could, although personally I wouldn't. Either way is possible. Given the limited options in the GUI (inside, outside or a mixture) I prefer to assume all addresses outside the DHCP range are static (manually set on the client) and everything inside the range is an address given out by the DHCP server (either dynamic or reserved).

 

[eibgrad]

Given the limited options in the GUI (inside or outside) I prefer to assume all address outside the DHCP range are static (manually set on the client) and everything inside the range is an address given out by the DHCP server (either dynamic or reserved).

Makes sense. But out of all the devices I have here (and I have as many as most techies), I don't have even a single one using a manually set static IP. And that includes servers, NAS, printers, etc., that might traditionally have this done. I got away from that years ago in favor of DHCP everywhere given it was possible to bind an IP to a MAC address via DHCP. I suppose you could always find some old device w/o the DHCP option, but it seems to be pretty rare these days. As a result, I just find it more useful to keep static leases defined outside the pool, which lets me distinguish them from those inside the pool.

I suppose it's just a matter of what you personally find useful.

 

[RMerlin]

Since as you mention it depends on the server, wouldn't it be best to follow the dnsmasq documentation?

They merely state that they don't enforce it. See my last sentence in the previous post.

Can, should and must have very different meanings.