Collision and Broadcast Domains based on my Understanding
Collision Domain vs Broadcast Domain: VLANs, DHCP, and Real-World Network Troubleshooting
What happens when a network has multiple DHCP servers, improperly configured VLANs, and access points that were never moved to the new VLAN?
Networking concepts such as collision domains, broadcast domains, VLANs, and DHCP can sound intimidating when first encountered. In theory, they are relatively straightforward. In a real network, however, these concepts can become the difference between a network that works reliably and one that suddenly causes users to lose access to critical systems.
This article explains these concepts in a practical and beginner-friendly way while still keeping the technical details useful for network administrators and IT professionals.
I'll also share a recent real-world lesson involving two DHCP servers operating within the same network, as well as a VLAN implementation issue where existing access points were not properly included in the new VLAN design.
What Is a Collision Domain?
Let's start with the term that usually appears first in networking lessons: collision domain.
A collision domain is a portion of a network where devices can potentially compete for the same transmission medium.
The easiest way to understand this is to imagine a room full of people.
Imagine a room where everyone is talking at the same time. Multiple people speaking simultaneously can make communication difficult. That is roughly the idea behind an Ethernet collision.
Older Ethernet networks commonly used hubs, where multiple devices shared the same physical communication medium.
PC 1 | PC 2 ---- HUB ---- PC 3 | PC 4
Because all devices shared the same medium, simultaneous transmissions could result in collisions.
Modern switched Ethernet works differently. With full-duplex connections, each switch port normally represents its own collision domain, and traditional Ethernet collisions are generally no longer the problem network administrators spend most of their time troubleshooting.
So What Should We Worry About Today?
In modern networks, a more useful concept to understand is the broadcast domain.
What Is a Broadcast Domain?
A broadcast domain is the group of devices that can receive Layer 2 broadcast traffic from one another.
This matters because several important network protocols rely on broadcasts.
- ARP – used to discover the MAC address associated with an IP address.
- DHCP – used by clients to obtain IP configuration automatically.
Think of a broadcast as someone shouting across a room:
Every device within that broadcast domain can potentially hear the request.
This is where network segmentation becomes important.
VLANs: Dividing One Physical Network Into Logical Networks
A VLAN (Virtual Local Area Network) allows us to divide a physical switching infrastructure into multiple logical networks.
For example, instead of placing everything into one large network, we could create:
VLAN 10 - Office Users VLAN 20 - Servers VLAN 30 - Voice VLAN 40 - CCTV VLAN 50 - Guest Wi-Fi VLAN 60 - Access Point Management VLAN 70 - Network Management
Each VLAN represents a separate Layer 2 broadcast domain.
This provides several benefits:
- Better network organization
- Reduced broadcast scope
- Improved security segmentation
- Better traffic control
- Easier policy enforcement
- More predictable troubleshooting
Creating a VLAN does not automatically move devices into that VLAN.
The VLAN Exists, But the Device Still Doesn't Work
This is one of the easiest mistakes to make during a network migration.
Imagine creating a dedicated management VLAN for access points:
VLAN 60 AP-MGMT 192.168.60.0/24
The router has the VLAN.
The DHCP server has a scope.
The firewall rules are configured.
Everything looks correct.
But an access point still cannot obtain an IP address.
Why?
Because the VLAN needs to exist across the entire path.
Access Point
|
v
Switch Port
|
v
Switch Trunk
|
v
Router / Firewall
|
v
DHCP Service
Every section of that path needs to understand how VLAN 60 should be handled.
If the access point's switch port is still assigned to the old network, or VLAN 60 is not allowed across a trunk, the AP will never reach the intended DHCP service.
The Access Point Migration Trap
I recently encountered this kind of situation while working with VLAN changes. A new VLAN was created, but some existing access points were not properly included in the migration.
The VLAN configuration itself was not necessarily the problem. The problem was that the physical and logical configuration did not completely match.
This is a valuable troubleshooting lesson:
Verify that the VLAN can actually travel from the device to its destination.
Real-World Scenario: Two DHCP Servers on One Network
Now we get to the more interesting part.
During a recent network incident, I encountered an environment where two DHCP servers were active within the same network.
At first glance, it is easy to say:
But that statement is actually incomplete.
Multiple DHCP Servers Are Not Automatically Bad
There are perfectly valid reasons to have multiple DHCP servers.
- DHCP redundancy
- High availability
- DHCP failover
- Different DHCP servers for different VLANs
- Different network segments with different addressing requirements
For example:
VLAN 10 - Office
192.168.10.0/24
|
DHCP Server A
VLAN 20 - Guest
192.168.20.0/24
|
DHCP Server B
There is nothing inherently wrong with this design because the two networks are separated.
The Real Problem: Uncoordinated DHCP Servers
The problem occurs when two independent DHCP servers are both responding to clients within the same broadcast domain without proper coordination.
Same Network
192.168.10.0/24
|
+------+------+
| |
v v
DHCP Server A DHCP Server B
192.168.10.1 192.168.10.254
A client sends a DHCP Discover as a broadcast. Both servers may receive the request and respond.
The client may then receive different network parameters depending on which DHCP offer it accepts.
One client could receive:
IP: 192.168.10.50 Gateway: 192.168.10.1 DNS: 192.168.10.1
While another client could potentially receive:
IP: 192.168.10.200 Gateway: 192.168.10.254 DNS: 192.168.10.254
Suddenly, users start experiencing symptoms that appear random:
- Some users can access the server while others cannot.
- Some machines have Internet access while others don't.
- Users receive unexpected IP addresses.
- DNS resolution behaves differently between machines.
- Connectivity appears to work and fail intermittently.
In a hospital environment, this becomes much more serious. Network instability can affect access to critical applications, including Electronic Medical Records (EMR).
The important point is that this was not simply a "collision" problem. It was fundamentally a DHCP and broadcast-domain design problem.
Why Multiple DHCP Servers Can Be Perfectly Fine
It is important not to oversimplify the lesson.
Multiple DHCP servers are not inherently bad.
A properly designed network may use multiple DHCP servers for redundancy, failover, high availability, or different network segments.
The real question is:
If two independent DHCP servers are answering clients inside the same broadcast domain without coordination, that is when trouble begins.
In contrast, multiple DHCP servers serving different VLANs or properly configured for redundancy can be completely normal.
Why This Matters in a Hospital Network
Network problems in a home lab are usually annoying.
Network problems in an organization can be expensive.
And network problems in a hospital can affect critical operations.
When a client receives the wrong gateway, DNS server, or other network parameters, it may still appear "connected" while being unable to reach an important application.
That is what makes these problems particularly difficult to diagnose.
The user may say:
From the user's perspective, the Wi-Fi appears to be working.
From the network administrator's perspective, however, the device may have simply ended up in the wrong network configuration.
Scenario: A Small Office
Not every network needs a complicated VLAN design.
A small office might simply look like this:
Internet | Router | Switch | | | | | PC PC PC Printer AP
If the environment is small and the security requirements are modest, a single broadcast domain may be perfectly reasonable.
The lesson is that VLANs should solve a problem, not simply be added because they are available.
Scenario: Office and Guest Wi-Fi
As the network grows, segmentation becomes more useful.
VLAN 10 Office Users 192.168.10.0/24 VLAN 20 Guest Wi-Fi 192.168.20.0/24
Guests can be placed in VLAN 20 while company devices remain in VLAN 10.
The firewall can then control whether communication between the two networks is permitted.
Scenario: Hospital or Enterprise Network
Larger environments have much more to consider.
VLAN 10 - Administrative Users VLAN 20 - Application / EMR Systems VLAN 30 - Medical Devices VLAN 40 - Voice VLAN 50 - Guest Wi-Fi VLAN 60 - Access Point Management VLAN 70 - Network Management
Segmentation allows administrators to define which systems can communicate with each other.
But every additional VLAN also introduces additional configuration requirements.
A VLAN design is only successful if the switch, router, firewall, DHCP service, access points, and endpoints are all configured consistently.
Scenario: The Network Loop
Another classic Layer 2 problem is a network loop.
+-------- Switch A --------+
| |
| |
+-------- Switch B --------+
Without appropriate loop-prevention mechanisms such as Spanning Tree Protocol (STP), frames can circulate continuously.
This can result in excessive Layer 2 traffic, broadcast storms, and severe network instability.
Again, the lesson is simple: a Layer 2 network is not just about connecting everything together. The topology and traffic flow need to be intentionally designed.
Practical Troubleshooting Checklist
When a device suddenly cannot connect to the network, don't immediately blame the application, server, or Internet connection.
Start from the client and work your way through the network.
1. Check the Client's IP Configuration
Check the IP address, subnet mask, default gateway, and DNS server.
2. Find the DHCP Server
Determine which DHCP server actually provided the lease. If the answer is unexpected, investigate.
3. Verify the VLAN
Confirm which VLAN the device is actually connected to. Do not assume that because the VLAN exists, the device is automatically using it.
4. Check the Switch Port
Verify whether the port is configured as an access port or trunk and whether the expected VLAN is present.
5. Check the Trunk
Make sure the required VLAN is allowed across every trunk between the endpoint and its gateway.
6. Check DHCP
Confirm that the correct DHCP scope exists and that there are no unexpected or rogue DHCP servers.
7. Check Routing and Firewall Rules
A device can have the correct IP address and VLAN but still be unable to communicate because routing or firewall policies are blocking the traffic.
8. Follow the Entire Path
Client ↓ Access Point / Network Port ↓ Switch ↓ Trunk ↓ Router / Firewall ↓ Server / Internet
This approach is often much more effective than changing several configurations at once.
The Most Important Lesson
Networking is not just about memorizing definitions.
Collision domains explain one part of Ethernet communication. Broadcast domains explain where Layer 2 broadcasts can travel. VLANs allow us to separate those broadcast domains. DHCP provides automatic network configuration. Routing and firewalls determine how those separate networks communicate.
But all of these components have to work together.
A perfectly configured VLAN is useless if the trunk does not carry it.
A properly configured DHCP scope is useless if the client cannot reach it.
A working access point is useless if it is connected to the wrong VLAN.
And multiple DHCP servers are perfectly acceptable—until independent servers start answering clients that they were never supposed to serve.
In real-world troubleshooting, the question is therefore not simply:
The better question is:
Final Thoughts
The best network designs are not necessarily the ones with the most VLANs, the most complicated firewall rules, or the most expensive equipment.
The best designs are the ones where the network's behavior is predictable, documented, segmented where necessary, and easy to troubleshoot when something goes wrong.
Sometimes the solution is a sophisticated VLAN architecture.
Sometimes it is simply disabling an old DHCP server that should no longer be running.
And sometimes the biggest lesson is discovering that the VLAN you carefully created never reached the access point you forgot to migrate.
Good networking is not just about making things work. It's about knowing why they work, knowing where they can fail, and being able to find the problem when they do.
Pinoy IT Share — Practical networking lessons from real-world IT experience.
Comments
Post a Comment