Subnets

[Michael]

Morning all,

 

I have a query hopefully someone can clarify for me -

 

I have a network on a /22 subnet with DHCP handled on the FW, however the DC was set to a /24 subnet, using the same IP range (static IP and gateway, just different subnet).

 

Clients (all DHCP) were still able to authenticate against AD and for print services; everything else is in the cloud.

 

The problem only came about whereby the first DHCP octet became full and clients couldn't contact the DC from within the second octet. With me so far?

 

I corrected the problem by changing the DC to a /22 subnet and now DHCP clients in both the first and second octet can communicate with the DC fine.

 

Question is, how were DHCP clients on a /22 able to communicate with a DC on a /24. This is on a flat network, single VLAN. TIA.

[Sephiroth]

This would be because the first segment of the subnet was in both the /22 and /24 ranges. The DC accepted these packets as they were in it's expected range. Outside of this, the packets came from outside the DCs expected subnet, so would have been rejected as unknown packets.

 

I am not an expert and I'm sure someone else can explain far better than I can, but hopefully that helps.

[synaesthesia]

In laymans terms, they're unaware of the subnet. My 7 layers memory is a bit Uncle Albert, but from I recall it's not transmitted as part of the packets (please correct me if wrong!) so as long as the receiving system gets the traffic on what it perceives as the right subnet it will reply (i.e. only the traffic marked for that first /24 and not the second /24).

[Michael]

Thanks both this makes sense now - /24 has 256 IPs and /22 has 1024 IPs, so effectively that's why the 257th IP couldn't see the DC.

[psydii]

I had an almost identical mistake in a firewall rule. It was there for ten years before we had a device with an IP address the wrong side of the bit mask. If I hadn't been looking at the firewall config for another ticket at the time the new device failed to work properly, I don't know whether I'd have ever got to the bottom of it.

[Michael]

I had an almost identical mistake in a firewall rule. It was there for ten years before we had a device with an IP address the wrong side of the bit mask. If I hadn't been looking at the firewall config for another ticket at the time the new device failed to work properly, I don't know whether I'd have ever got to the bottom of it.

 

Similar for me - the issue was there for years too and had gone unnoticed, but only because the number of active devices on site have increased.

 

It did completely throw me, as the errors the Windows client displays suggests it's a more major issue with the DC being offline or unavailable, with all other devices working normally, it does make you think it's a client issue.

[DavonPotter]

It's possible that because both the /22 and /24 subnets were within the same IP range, routing might not have been strictly enforced at the subnet level, especially in a flat network with a single VLAN. It's likely that the DC and DHCP clients could communicate due to the subnet mask allowing them to see each other within the broader range. Changing the DC to a /22 subnet seems to have aligned everything correctly with your IP addressing scheme.

[k-strider]

yes you need to change the DC over as others have said from /24 to /22 which is from 255.255.255.0 (24) to 255.255.252.0 (22) if the DC is also the DHCP server you might want to see how that is setup

[GeneMoody-Action1]

In case anyone comes across something similar in the future or finds this looking for similar...

 

When a DHCP discover packet is sent it is neither aware of IP OR SubNet

The process takes place over broadcast of 255.255.255.255 meaning anything in my broadcast domain (Which can be used interchangeably for the most part with VLAN, or absence of one as default VLAN)

Think about it, you get your IP/Subnet *from* DHCP.

 

So you have DORA (Discover, Offer, Request, Acknowledge)

 

Discover - "Anyone out there to give me an IP?"

Offer - "Sure would you like this one."

Request "Either 'I'll take that one.' or 'I would really like this one instead.'"

Acknowledge - "Alright, I have you marked as having that one proceed.'

 

With that exchange comes an IP AND subnet, and if any host lives in the broadcast domain on a higher subnet, you just made orphans...

 

Subnets overlapping is almost always a bad idea because it can lead to this and other confusions, thus unpredictable behaviors. If you are sub-netting for a reason, it is assumed to be logical isolation, and you should be routing between them.

Otherwise, you have IPs that can send to other IP endpoints that have no way to respond, for which I can think of no valid reason.

Edited October 25, 2024 by GeneMoody-Action1
sp