Segmentation is a design decision and a change project. The design takes an afternoon; the migration takes a term, because every move is a chance to break a service that nobody documented.
This is the method for moving a live district network from one flat zone to several, one zone at a time, after 17:00.
The rule: make before break
Moving a network into a new zone is instantaneous and retroactive. The moment it moves, the old intra-zone allow no longer applies, and every flow is evaluated against the new zone pair.
So the allow rule must exist before the move, and it must match the flows the network needs. If it does not, the next packet is dropped, and the symptom looks like a dead switch rather than a policy change.
1. Create the zone.
2. Create the allow rules, referencing networks still in Internal.
3. Confirm the rules have zero hits (nothing matches yet).
4. Move one network.
5. Watch the hits climb and the service still work.
6. Move the rest of that zone's networks in the next window.
Inventory the dependencies first
Before any move, list what each group of networks talks to. In a district, the same six services appear every time:
| Service | Direction | Ports | Owner |
|---|---|---|---|
| DNS | All zones → DCs | 53 | Identity |
| DHCP relay | Gateway → DHCP server | 67/68 | Network |
| Printing | Staff/student → print server | 9100, 631 | Network |
| Camera client | Staff → NVRs | 554, 80/443 | Security |
| HVAC / controls | Staff → controllers | 443, vendor ports | Facilities |
| Phones | Voice → PBX | 5060, RTP range | Telephony |
If a dependency is missing from the list, the migration will find it. Write the list down and get it confirmed by the people who use each service.
The order
Least user-visible first, so mistakes are cheap:
| Step | Zone | Why first |
|---|---|---|
| 1 | Building Management | Vendor appliances, no users |
| 2 | Guest | Isolated by intent; failures are visible but contained |
| 3 | Quarantine | Enrollment only |
| 4 | Student | Largest blast radius; test with one campus |
| 5 | Voice | Needs the PBX rules in place first |
| 6 | Staff | Every adult notices |
| 7 | Infrastructure | Last, because it holds the services |
Worked example: moving Guest
Guest VLANs currently sit in Internal with full access to everything.
- Create the Guest zone; assign one test guest network.
- Add: Guest → WAN allow; Guest → DNS allow; Guest → everything else deny.
- Move
10.40.50.0/24into the zone. - Test: a guest device gets an address, resolves a name, browses, and cannot reach
10.0.0.3on any other port or a printer. - Check the policy hits: the allow rules climb, the deny rule climbs, nothing unexpected appears in the logs.
- Move the remaining guest networks in the next window.
If step 4 fails, the rollback is a single zone reassignment, which restores the old behavior immediately.
Verify with services, not pings
| Test | What it proves |
|---|---|
| A device gets a DHCP lease | Relay and policy both work |
| It resolves an internal name | DNS path is permitted |
| It reaches the service it needs | Allow rule matches |
| It cannot reach a service it should not | Deny rule works |
| Policy hit counters move | Traffic is traversing the intended path |
Ping proves almost nothing here. A guest device that can ping 10.0.0.3 but cannot resolve is a
different failure from one that cannot ping at all.
What breaks in production
- Moving the network before the rule. The outage looks like a hardware failure and the change log says "policy update."
- A dependency nobody listed. The camera client, the HVAC web UI, the badge system. Ask facilities and security, not just IT.
- DHCP relay in the old zone. Moving a network can move its gateway relationship; confirm leases still appear.
- Asymmetric paths. A service that replies through a different interface now has no state and no policy.
- Moving a whole zone at once. One network at a time, with a test device, is slower and safer.
Rollback is a zone reassignment, not a rule rewrite
If something breaks, move the network back to Internal. Intra-zone allow resumes immediately. That is why the migration is reversible and why it should be done in small steps rather than as one large cutover.
Checklist
- Every zone has a written purpose and an explicit deny.
- The dependency inventory is confirmed by the service owners.
- Allow rules exist and show zero hits before the first move.
- One network moves per step, with a test device.
- Hit counters and service tests are checked after each move.
- The rollback is a single zone reassignment, and it has been tested once.
Next
Segmentation limits where a device can go. Continue with DNS as a Security Control, which limits what it can find.