Currently, my DHCP server is handing out IP addresses in the range. What would happen if I set a static IP address on a device of, e.g.,

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?

  • 1
    Davidgo addressed (2), but I'll note that you can sidestep this problem if you make such assignments via the DHCP server. Even though DHCP servers are designed to dynamically assign IP addresses, nothing stops you from configuring static IP assignments (or static IP reservations) within the DHCP server itself; some (all?) DHCP servers support this.
    – Brian
    Jan 6, 2021 at 18:49
  • Thanks, I do have some 120 IP reservations in my DHCP server. I only have guest devices getting dynamic IPs (end even then, return guest are often given reservations, since I use ping as a presence detection for home automation, e.g. if my moms phone is on the network, the house is in "Guest Mode" and won't power down when my girlfriend and I are both away from home). I was more wondering in terms of which device (if any) would show up on the assigned IP. The device where I set a static IP on the device, or the device where I give it an IP reservation in the DHCP server. So who trumps who?
    – Aephir
    Jan 6, 2021 at 19:59
  • Wouldn't networking be a better place for this, or it should be answered thoroughly there, and then perhaps summarized here as it could be regarded as a sub discipline of super user? My opinion. Jan 7, 2021 at 11:54
  • @marshalcraft: Networking.SE is focused on professional setups in a business environment. Asking what happens when you intentionally overlap your IP with internal or external subnets is not really a good fit for that. If you interpret this as an XY problem, X might be on topic but Y is not. Note: I'm not mentioning XY problems to fault OP: it's perfectly reasonable to knowingly present an XY problem as a means of better understanding what makes Y a bad solution.
    – Brian
    Jan 7, 2021 at 15:25
  • You are mixing two distinct concepts that are useful understand. Subnets define which other addresses are expected to be reachable on the physical medium (without a router), and address assignment tells each host what address to use. These are obviously related, but they should be examined individually. Jan 8, 2021 at 19:37

6 Answers 6


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

  • Seems like I'll hold off for now, and stick with my DHCP reservations :) I'd accept you answer, but the other one came in first, so though that was more fair. But thanks!
    – Aephir
    Jan 6, 2021 at 9:27
  • 1
    (Not a problem re reputation - both of us have enough we don't really worry about it - but technically my answer was 7 minutes earlier then Tetsujins :)
    – davidgo
    Jan 6, 2021 at 9:32
  • 2
    The last point about duplicate address detection is really important. A significant percentage of systems do not do DAD for statically assigned addresses, they just blindly assume the sysadmin who set the assignment knows what they are doing. I know from personal experience that default behavior on Windows, Linux, and macOS is to not do DAD except for stateless local autoconfiguration setups. Jan 7, 2021 at 1:34
  • 3
    Usually the best answer gets accepted, not the earliest one, so don't worry too much about that checkmark @Aephir
    – Mast
    Jan 7, 2021 at 12:22
  • 1
    @Aephir Rule of thumb: at least 24 hours. Some sites prefer even longer (2-3 days), although on Stack Overflow people are often (incorrectly, IMO) urged to pick faster.
    – Mast
    Jan 8, 2021 at 19:17

Currently, my DHCP server is handing out IPs in the range. What would happen if I set a static IP on a device of e.g.

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:

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

  2. 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 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.)

  • 2
    For wired Ethernet, you "can" use mutually incompatible subnets (i.e., both 192.168.0.x and 192.168.1.x) on the same physical segment or even the same Ethernet switch. If all machines are configured correctly for the subnet they're using, then machines on each subnet will be able to communicate with their own subnet, and will not be bothered by packets on the wire for the other subnet. Jan 6, 2021 at 19:29
  • 1
    The router connecting you to the outside world will probably not see devices on the "wrong" subnet, so they'll be unable to see the Internet, however. Jan 6, 2021 at 19:29
  • The router isn't even involved in communications between devices in the same subnet. The devices communicate directly via the network's switch. Maybe you're conflating the router and switch, since they're combined in SOHO networks.
    – Barmar
    Jan 7, 2021 at 15:24

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

  • Thanks, this is useful. Out of curiosity, do you know what would happen if you assign an IP (static on the device) that is also assigned as a DHCP reservation? Which device, if any, would actually have the IP in question?
    – Aephir
    Jan 7, 2021 at 7:45
  • 2
    @Aephir: That question is a bit undefined. Typically you get unpredictable and unstable effects. Saying that "a particular device has a certain IP" only makes sense in well-configured networks.
    – MSalters
    Jan 7, 2021 at 8:05
  • @MSalters I'll just try to avoid that then :) Thanks
    – Aephir
    Jan 7, 2021 at 8:32
  • Thanks - I completely forgot this part of the question when answering myself!
    – wally
    Jan 7, 2021 at 9:16

First 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 & you also set your DHCP dynamic pool to -
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…

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

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

  • Thanks. I do currently use DHCP reservations for some 120 devices (not on my router, I have a separate DHCP server, my router had issues as number of devices increased). I ask because I an planning an upgrade of my network; I'll set up multiple subnets and vlans for each. I was trying to determine if I could start assigning the important stuff (mainly my server and a few critical devices) to the new IP (on a new subnet) now by assigning them the "new" IP directly on the device. But it seems like I'll wait, since they likely wouldn't work on my current network.
    – Aephir
    Jan 6, 2021 at 9:24
  • Btw, I accepted davidgo's answer, since he was a few minutes earlier (and both of your answers answered the question).
    – Aephir
    Jan 6, 2021 at 10:15
  • No worries - as he mentioned, neither of us really need the rep ;)
    – Tetsujin
    Jan 6, 2021 at 10:25

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 range. What would happen if I set a static IP on a device of e.g.

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 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: ... Gateway: That's saying, "Anything which doesn't match any other rule should be sent to, 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 addresses on it). But let's assume you've told your router that your private network is actually 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, for example!).

What'll happen is - your device will say " 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 network will have a gateway device (router) with one IP inside that range.

If you have a device configured with an IP address inside 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.