Can I assign any static IP address to a device on my network? Or does it have to be within the DHCP servers (or routers) defined subnet?
Currently, my DHCP server is handing out IP addresses in the 192.168.0.1/24 range. What would happen if I set a static IP address on a device of, e.g., 192.168.1.10?
And just out of curiosity, what would happen if I set the IP address to (1) something that exists elsewhere (e.g. on the www), or (2) something that the DHCP server has been asked to assign to another MAC address address?
56 Answers
It might depend on your router, but generally assigning a static IP address will work regardless of whether or not it is in the range set aside for dynamic allocations - provided it is in the subnet range for that segment/network. In your example, setting 192.168.1.10 won't work on a /24 subnet but will on a /16 subnet.
If you set the IP address to something that has a static IP elsewhere, it depends on the client OS (i.e. it might check and not accept the assignment) - but it is likely that it will work and an IP address conflict will result with complex and undefined results leading to all kinds of weird behaviour/reachability issues for both systems.
7Currently, my DHCP server is handing out IPs in the 192.168.0.1/24 range. What would happen if I set a static IP on a device of e.g. 192.168.1.10?
The DHCP server's configuration is irrelevant – what matters is the subnet that the router itself is configured to use. Often the DHCP range is actually narrower than the whole /24 subnet – e.g. even though a /24 goes from .0 to .255, the DHCP server only gives out the addresses .100-.199.
In short, the you wouldn't be able to communicate with anything, as other devices wouldn't know where to send packets meant for you:
Your other devices wouldn't recognize the address as belonging to a local subnet, and would send the packets through their "default gateway", which is your router.
Your router also wouldn't recognize the address as belonging to any of its local subnets, and would send the packets through its "default gateway", which is your ISP (who will just discard the packet).
However, if you configured two devices to be in the same 192.168.1.0/24 subnet, they would be able to communicate with each other, because packets between devices in the same subnet are directly switched, not routed. (In other words, the router trusts the devices themselves to know which MAC to send the packets to, and won't look at their IP addresses.)
And just out of curiosity, what would happen if I set the IP to (1) something that exists elsewhere (e.g. on the www),
Actually the same thing as above. If the routing table says it doesn't belong to a local subnet, then it doesn't belong to a local subnet, and the packets addressed to "you" will be sent elsewhere. (In this case, they might eventually reach the real owner of that IP address.)
or (2) something that the DHCP server has been asked to assign to another MAC?
If that other device remains offline, then nothing special. It would work.
Note that DHCP servers only issue information for devices to configure themselves with that address. The DHCP service doesn't really tell the router what to do with that address – the router still uses ARP to translate IP addresses to MAC addresses every time, no matter if that address is DHCP-issued or not.
(You may be thinking of a different feature called "static ARP" which some routers have, such as pfSense, and its configuration is often tied to the DHCP lease table for convenience. In pfSense, enabling this feature would actually tell the router to not use ARP for these IP addresses – as long as the DHCP server's database says the address belongs to this MAC address, the router always sends packets to that MAC address too.
But most routers do not implement "static ARP", so trying to use the IP address from a different device will always work regardless of what DHCP says.)
3I skimmed through the existing answers and didn't see this specified.
If you are setting an IP address manually on the device itself you not only can, but should assign an address that's outside the DHCP pool. Otherwise the DHCP server might give another device the same IP address.
Usually you should think up some loose convention, e.g. let DHCP assign three digit addresses (.100-.254) and leave the others for manual assignment.
4First of all, if you want to assign a static IP address internally, the ideal way to do it is from the router, not from individual machines. Sometimes a device address can't be changed, so to prevent conflicts the router must be told which devices these are.
At the same time, you reduce your dynamic pool to exclude these fixed addresses.
So, for example, you set your Mac from the router so that its MAC address (that's the physical address of its ethernet card or wifi connection, looks like 88:63:df:b3:5d:18) maps to to 192.168.0.10 & you also set your DHCP dynamic pool to 192.168.0.11 - 192.168.0.100
Setting the top of the range to something like 100 leaves room for you to also assign other bits of hardware, TVs or printers etc tothat top end.
I tend to set known, repeatedly findable computers to somewhere under 20, other devices above 100 & leave the space in between as dynamic.
This allows all devices to use DHCP, simply & without conflict.
So, to your two points…
It would to all intents & purposes 'fall off' your network. it wouldn't know how to see out & nothing else in the building would find it. It wouldn't report properly to the router, neither would it be seen from the outside world in its new 'mystery' guise.
First come, first served. The first device to get that address would cause a conflict with any subsequent device & it would refuse to connect until you fixed it.
You've asked several things, let me try to unpick each and answer them in turn:
Currently, my DHCP server is handing out IPs in the 192.168.0.1/24 range. What would happen if I set a static IP on a device of e.g. 192.168.1.10?
Firstly we should establish what DHCP is (what problem it solves, and how it works).
Networks can be thought of as having multiple layers (see: OSI layers). IP addresses are a means of identifying who's who at the third layer (Layer 3, Network Layer). IP sits above both the Physical and Data Link layers (L1 and L2). The physical layer is what you "plug into" (literally plugged in the case of your typical Ethernet cable!) and the data link layer deals with how two or more devices may communicate over it.
So yes, two devices can communicate over your home network without IP addresses. They'd likely use "hardware addresses" (or MAC addresses), which are similar to IP addresses - but lower down the layers.
One of the many problems IP (Layer 3) resolves is traversal between physical networks. Not everything uses Ethernet - and we typically want to segregate physical and logical areas for security reasons (and in ways which are beyond the ability of Ethernet, for example).
IP sits atop Ethernet (and many other L2/L1 combinations) and gives every device one or more IP addresses as way of identifying them. Underneath, it still gets translated to the physical addresses.
But there's a minor management problem. We often don't want to deal with setting and changing IP addresses all the time, especially when we have devices joining/leaving our physical network all the time (like the mobile phone in your pocket).
DHCP is a network service/protocol which allocates and tracks IP addresses automatically on a given network. After joining a physical network and establishing a data link (layers 1 and 2), devices can "request" an IP address. Literally, they spew out a message to everyone connected to the same Layer 2 saying "Can anyone give me an IP address?"
Any listening DHCP server may respond. In your home example, it'll allocate a new device an IP address in the 192.168.0.1-254 range. It'll also remember that it's given that device that specific IP address (probably by logging the MAC address in a little registry), so as to ensure nobody else gets the same IP address by mistake.
Also, if the device disconnects and reconnects - the DHCP server can re-assign it the same IP address over and over - which helps higher layers not break unexpectedly.
Added note: In answering, I completely forgot the original question. "What happens if I statically allocate an IP address to device, used by the DHCP pool?". This has been dealt with accurately in another answer.
And just out of curiosity, what would happen if I set the IP to (1) something that exists elsewhere (e.g. on the www)
Now this is a great question. This is a part of the problem that IP (Layer 3) tries to resolve. How do two physically separate Layer 2 networks communicate with one another?
IP can traverse different Layer 2 networks. And it does. In fact, it traverses billions of them, all around the globe. That's worked for a pretty long time (IP version 4 - aka IPv4) as there were enough IP addresses to uniquely identify every connected device on the internet. (Inevitably however, the internet's growth has since outran the number of available IPv4 addresses - which is a separate topic - see IPv6!).
Those who invented IPv4 included technique called Network Address Translation, which allows multiple devices to "hide" behind one IP address. This means your house can be represented as a single IP address on the public internet, and all the devices in your house can have IP addresses also used in other people's houses.
That works on the assumption that everyone agrees to use a strict set of "private" IP address ranges in their houses (and business, etc). There's 3 sets - Class A, Class B, and Class C. One of those will look familiar to you (Class C) - it starts 192.168.x.y.
We've all agreed that those IP addresses will never be used on the public internet. They're reserved for private networks. Network Address Translation allows your home router to hide all your private IP addresses (on your home network) behind a single public IP address on the Internet.
That brings us into the question of what do your home router do (beside provide a DHCP service for your house!).
Your router knows two things. It knows what your private (internal) IP network is. And it knows a route (path) to the public network (the Internet). That route to the Internet is provided by your ISP. Your router doesn't care what your ISP does, but it knows that traffic from your local network headed for the internet needs to go via your ISP. So it does that.
And this is another feature of DHCP. All your home devices, they need to know where the internet is too. They need to know the route. For them, they don't know anything about your ISP. They just know about your router. So they know this: any traffic originating from themselves, destined for the internet, has to be sent (routed) to your router.
You can see this actually - on Windows (assuming that's what you use), open a command prompt and type route print. You'll see a list of IP address ranges and where your computer knows to send traffic destined for them. You should see a "default" route which looks like Dest: 0.0.0.0 ... Gateway: 192.168.0.1. That's saying, "Anything which doesn't match any other rule should be sent to 192.168.0.1, because they know what to do with it.
DHCP, beside allocating IP addresses, can also tell devices what the "default gateway" for the network is. And, your home router does that! When it sends a DHCP reply to a device, it specifies both a private IP address to use, and a default gateway (itself).
Now, to answer your question. Two things will happen.
Firstly, your home router will refuse to do anything with it - because the IP address is on the "wrong side" (it knows your private network should only have 192.168.0.1 addresses on it). But let's assume you've told your router that your private network is actually 8.8.8.0/24 instead. Well, OK, your router might not complain - in which case everything will work just dandy, until a device at your home tries to reach Google (at 8.8.8.8, for example!).
What'll happen is - your device will say "8.8.8.8 is local, I don't need to send it via my default gateway". The traffic will never reach the internet. Maybe another local device will get it instead. Who knows? Your router will also refuse to route it - because you've told it that IP address range is now private (not on the public internet).
or (2) something that the DHCP server has been asked to assign to another MAC?
In this scenario, undefined behavior will occur. IP ultimately sits atop OSI layers 2 and 1. It'll depend entirely on what happens at those layers - the traffic may or may not make it to the correct location - because you have multiple physical devices all thinking they're the same IP. Most operating systems (including Windows) try to detect this scenario (when they see unexpected traffic coming from another device with the same IP address as itself) and alert you.
Functionally this is called an overlay network and may suit your needs.
Your 192.168.0.0/24 network will have a gateway device (router) with one IP inside that range.
If you have a device configured with an IP address inside 172.22.22.0/24 connected to the same wiring, then it won't be able to talk to your router.
Solutions might include giving your router two IP addresses, one in each network (if supported)
Why? An overlay network will permit devices in that 172.22.22.x network to talk directly with each other, which may suit your needs for networked security cameras, or a SAN, or a network of sensors that do not require internet access. Dodgy cameras from China that try to phone home would be a great example and use case.
Downsides Do note that this solution does not provide any security. Any device on your wired/wireless connection will still see broadcasts from both IP ranges, and a malicious user could give themselves an IP in the other range.
Upshot this is a poor-mans VLAN, providing none of the security/protection of a real VLAN or separate physical LAN. Overlay networks have their uses, but also their limitations.
Aside - consider that there's a good chance your networks already have multiple IP networks overlaid. There's your normal IPv4 range, and any network with modern windows/mac/linux devices will have IPv6 traffic in the fe80:: block.
If you have functional IPv6, then you will likely have three different networks overlaying on your LAN right now.
