{"id":269,"date":"2026-10-12T01:34:58","date_gmt":"2026-10-12T01:34:58","guid":{"rendered":"https:\/\/cybertrustify.com\/?p=269"},"modified":"2026-10-12T05:12:24","modified_gmt":"2026-10-12T05:12:24","slug":"how-we-segmented-a-live-flat-network-in-pieces-and-without-any-disruption","status":"publish","type":"post","link":"https:\/\/cybertrustify.com\/?p=269","title":{"rendered":"How We Segmented a Live Flat Network in Pieces and Without Any Disruption"},"content":{"rendered":"\n

Note: The IP addresses, subnets, and network diagrams used in this article are illustrative and are not the real ones used and are just examples. They do not represent actual customer network addressing.<\/p>\n\n\n\n

How we segmented a live flat network in stages and without any disruption<\/h2>\n\n\n\n

We recently worked with a customer who had a very large flat network with a \/20 subnet mask (4096 hosts, 255.255.240.0 subnet mask). The network had originally been designed this way, and the number of hosts had grown over time which means large layers of devices such as Cameras, VoIP phones, IOT and standard hosts were all living in a single broadcast network. The customer was experiencing broadcast storms and traffic congestion amongst other things. A requirement in this project was also replacing the customer\u2019s edge firewall with a new one from a different vendor that the customer had selected.<\/p>\n\n\n\n

Network segmentation looks straightforward on a diagram. Create separate VLAN\u2019s for users, voice, cameras and IOT. Define the appropriate firewall policies and move the devices. But, in an existing production environment, the difficult part is figuring out how to divide the network into 4 subnets, which requires changing the subnet mask on all the hosts, and keep everything running. The key is that instead of planning a large cutover, we divided this into multiple planned stages that allowed the new addressing with 4 VLAN\u2019s and new firewall to be introduced and coexist with the existing large flat network. This allowed us to move phases (vlan\/subnets) one at a time from the old flat network to the new segmented network, of course that did come with its own challenges as we had an addressing overlap to deal with when moving some of the hosts which we will detail later in the article.<\/p>\n\n\n\n

The existing network used a large \/20 subnet which provides 4096 addresses in a single broadcast network. That could be easy to set up initially but over time as different types of systems start sharing the same large network, and user workstations sit alongside phones, devices, cameras, servers and IOT hosts, the network starts getting congested and experiencing random issues.<\/p>\n\n\n\n

Also, from a security perspective, systems with different risk profiles may have unnecessary network visibility to one another. It becomes more difficult to manage and troubleshoot as well.<\/p>\n\n\n\n

Current State \u2013 Large Flat Network<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figure 1<\/p>\n\n\n\n

The temporary transit network with the new firewall<\/h2>\n\n\n\n

After designing the coexistence and migration plan, our first major step was to introduce the new firewall and gateway infrastructure and allow the 4 new VLAN\u2019s to live on the new Firewall device. We also want to be able to move individual devices such as cameras to the new firewall and their new Camera VLAN while allowing them to still have Internet access through the old firewall as we did not move the ISP connection to the new firewall until the final phase of the cutover.<\/p>\n\n\n\n

What we did was establish a dedicated transit subnet and connect the existing legacy firewall to the new firewall over this transit subnet using a single physical connection. We used static routing to provide this connectivity between the legacy network and the newly created VLAN\u2019s. During this coexistence scenario, if we moved a camera from the old large flat network to the new camera VLAN, the camera now had a gateway IP of its new camera VLAN and could still get to the Internet through the transit network using the legacy firewall. This was also important as during our migration, devices still needed to communicate between the old and new networks, so the transit subnet was critical for that communication.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

 Figure 2<\/p>\n\n\n\n

Addressing overlap challenge between the 2 networks<\/h2>\n\n\n\n

One of the challenges we faced during the migration was overlapping subnets between the legacy network and the new address space assigned to the segmented VLANs.<\/p>\n\n\n\n

You may ask why we didn\u2019t simply choose a separate subnet that had nothing to do with the old, large flat network. However, standardizing the new network\u2019s addressing with customer\u2019s other locations was also a requirement, so we had to use a specific address space.<\/p>\n\n\n\n

(This article won\u2019t get into route summarization or the reasons for maintaining a consistent addressing scheme across multiple locations.)<\/p>\n\n\n\n

To give you an idea, the original 10.40.0.0\/20 network and the new voice VLAN, 10.40.8.0\/24, had overlapping address space. A workstation still configured with the original \/20 subnet mask (during coexistence) would consider addresses with the 10.40.8.0\/24 to be local and attempt to reach them directly using ARP rather than forwarding the traffic to its default gateway and onto the transit network.<\/p>\n\n\n\n

Our solution was to migrate the non overlapping networks first and leave the overlapping networks for the final cutover. This sequence allowed us to work around this addressing challenge while continuing to make progress towards our final goal.<\/p>\n\n\n\n

Migrating Devices in Stages<\/h2>\n\n\n\n

With the temporary transit network configured and passing traffic, we began migrating devices into their segmented network starting with individual VLAN\u2019s. Moving the camera VLAN and their back-end systems provided an opportunity to validate the architecture initially before we moved larger groups of hosts.<\/p>\n\n\n\n

We configured the appropriate VLANs and routing, migrated a small number of devices, verified IP addressing and application connectivity and communication with other systems. For this segment, we had to work with static IP addressing instead of DHCP (cameras were all on static IP\u2019s) which wasn\u2019t too hard as we kept track of the old and new addresses using spreadsheets and checklists. Once we moved the first batch and validated connectivity, we used the same process to move the remaining. This approach reduced problems and allowed us to finish the phase without any outages.<\/p>\n\n\n\n

By the time we got close to the final cutover, significant portions of the new network had already been tested under production conditions.<\/p>\n\n\n\n

The Final Cutover<\/h2>\n\n\n\n

The final maintenance window focused on transitioning the remaining networks, and more particularly the user VLAN. Before the cutover, DHCP lease durations were reduced to help endpoints obtain updated addressing information more quickly.<\/p>\n\n\n\n

During the transition, the legacy DHCP service and original gateway were retired, the remaining segmented networks were activated, and the new infrastructure assumed the primary routing and Internet connectivity roles.<\/p>\n\n\n\n

Access points, switches and other supporting infrastructure services received careful attention during the cutover.  Everything was transitioned according to our design and migration plan.<\/p>\n\n\n\n

We then validated network traffic and connectivity, including DNS resolution, Internet access, and inter-VLAN routing. Of course, as with any network migration, a few devices required special attention, but we got through them without too much headache. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the end, the phased approach, temporary transit network, and careful planning allowed us to complete the transition while minimizing disruption to the production environment.<\/p>\n\n\n\n

The final architecture matters but having a well designed migration strategy and a documented plan to get there is just as important. In this project, careful planning was arguably the most important part of the entire migration.<\/p>\n","protected":false},"excerpt":{"rendered":"

A real world network modernization project using a temporary transit network, staged device migrations, and careful planning to segment a live production network without major disruption<\/p>\n","protected":false},"author":3,"featured_media":271,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-269","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-and-infrastructure"],"_links":{"self":[{"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/posts\/269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=269"}],"version-history":[{"count":4,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/posts\/269\/revisions"}],"predecessor-version":[{"id":289,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/posts\/269\/revisions\/289"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=\/wp\/v2\/media\/271"}],"wp:attachment":[{"href":"https:\/\/cybertrustify.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybertrustify.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}