Understanding Network Infrastructure · Part 4 · How do we use these principles to design a real network?
How do large enterprise networks split a home router's roles?
Separating device roles by failure, change, and state boundaries—not just a feature list
One home router handles switching, DHCP, routing, NAT, and firewall functions. Enterprise networks divide those roles among devices and operational teams according to the impact of failures and changes. We follow the packet path and the state each function keeps to explain where to separate responsibilities and what redundancy requires.
Even one router handles a connection through several functions in sequence↑
A home router combines a wireless access point, an Ethernet switch, a DHCP server, a default gateway, NAT, and a stateful firewall in one product. One configuration interface keeps a small network simple to operate.
A function and a product are not the same thing. Confusing them makes enterprise networks harder to understand. Even inside one router, a packet goes through distinct decisions: L2 switching, L3 routing, address translation, and security policy.
When a laptop sends an Internet server a packet, several roles take turns even within that one box. The wireless AP receives the frame, and the built-in switch forwards it within a VLAN. The gateway function uses the destination IP for a route lookup. The DHCP server supplied the client's configuration earlier. Toward the Internet, firewall policy and NAT/PAT handle permission and address mappings. One physical device contains several successive packet-processing boundaries.
Diagnose an outage by separating the functions. If only Wi-Fi endpoints disconnect, examine the wireless segment. If wired and wireless endpoints cannot get addresses, check DHCP first. If internal servers are reachable but the Internet is not, check the default route, NAT, and WAN. The same reasoning applies in an enterprise network: moving a function to another device does not change the need to understand its role and the paths on either side.
Functions housed in one device still have different operating conditions. A DHCP address does not guarantee an external route, and a route does not guarantee connectivity if firewall policy or NAT settings prevent it. Beside the device diagram, record where the packet enters—the ingress port—which routes and policies are consulted, which addresses and state change, and the egress port. This lets you compare where the same functions sit in small and enterprise networks.
Sources for this section IETF RFC 1122 · IETF RFC 1812
What to look for in the diagram Follow a SOHO router's L2/L3 processing and PAT header changes, then the path through ISP access, an IXP, and the destination server. Use the arrows and numbers to trace how the PC's header values change at the router and which segments carry the packet to the server.
↔ Scroll horizontally to explore the diagram.
Failure and change impact matter more than user count when separating roles↑
Traffic volume is not the only reason to separate enterprise network roles. User access policy changes frequently, core routes need stability, and the Internet firewall needs security changes and audits. Combining different change cycles in one device widens the impact of each change.
Separation does not always mean separate physical devices. VRFs and virtual firewalls can separate routing domains and security policies logically within one system. However, control-plane and data-plane independence depends on the implementation. Virtual chassis and stacks combine devices into one logical device, so do not assume their failure domains and management responsibilities are independent.
Even with 100 users, a site that combines 24-hour production equipment and office systems has good reason to separate failure domains. A 500-person training center with one policy and short operating hours may benefit from a simpler design. Choose device counts by the work one failure or change can interrupt, acceptable downtime, responsible teams, and approval procedures—not in proportion to headcount.
Putting frequently changing access policy and stable core routing in one configuration unit can give a small user change a wide routing impact. Besides physical separation, VRFs, virtual contexts, and independent configuration pipelines can limit changes. Shared chassis, power, or control planes still leave common failures. Mark logical separation and physical independence separately so redundancy is not overstated.
Throughput, port density, encryption performance, state capacity, policy complexity, and team responsibilities also guide separation. Conversely, integrated equipment may be simpler for a small site run by one team in the same change window. Instead of prescribing a fixed number of tiers for every enterprise, compare each function's capacity, failure impact, change frequency, and recovery time in a table, weighing the benefits of separation against added dependencies.
Sources for this section IETF RFC 1812 · Cisco Design Zone
To reach devices during an outage, keep user packet paths separate from management access↑
User packets enter at access, pass through a VLAN and gateway, and continue to internal services or the Internet edge. Separately from this data-plane path, operators need access to management interfaces, authentication, logs, and time synchronization.
If production traffic and management access share a path, an outage may prevent operators from checking device state or rolling back changes. Whether a separate management network is necessary depends on recovery requirements, but the design must identify how operators will connect when the primary path fails.
The management path supports more than SSH and HTTPS. It also carries AAA, DNS, NTP, syslog, telemetry, and software distribution. A live device may still be inaccessible if its TACACS server or DNS is unreachable; incorrect NTP makes log timelines hard to correlate. With a management VRF or dedicated interface, design the routes and firewall policies used by these dependencies too.
For failure isolation, an out-of-band network must use switches and circuits separate from the production data plane. Sharing switches, the same core, and power leaves common failures even with different VLANs. Test complete loss of the primary path, including console servers, cellular backup, and on-site recovery procedures. Protect authentication and access logs separately so management does not become another single point of failure.
Putting management addresses in another VLAN does not make access independent. Shared core equipment, power, DNS/AAA servers, or WAN circuits can still fail together. Draw the path from the management endpoint to each device, including its route, authentication, name resolution, time synchronization, and emergency local-access procedure. Use it to find the real shared failure points.
Sources for this section IETF RFC 6192
Why don't two devices alone guarantee uninterrupted service?↑
Two devices do not deliver the expected recovery unless the design defines how gateway state, routing, NAT, and firewall sessions transfer. Look beyond active/standby and active/active labels: verify failure detection, state synchronization, loss during switchover, and failback.
Redundancy everywhere also adds complexity. Start where it is needed most, comparing the impact of single points of failure, acceptable recovery times, and the team's ability to operate the design.
For default-gateway redundancy, determine where the client-facing virtual IP and MAC move and whether upstream and downstream routes point to the new active device. A firewall cluster also needs defined synchronization coverage for sessions, NAT mappings, and VPN security associations. In split-brain, both devices believe they are active and may advertise the same virtual IP or create asymmetric paths. Heartbeats and failure-detection boundaries are part of the design too.
After failover, test more than a new ping. Check existing TCP connections, new connections, long-lived UDP flows, and inbound DNAT sessions separately. Measure packet loss and recovery time, then check path and session stability when returning to the primary. Besides total device failure, test uplink loss, an unavailable upstream route, and loss of the state-synchronization link. These reveal the actual failure scope and conditions for session continuity.
Two paths are not independent if they share power, a fiber conduit, a carrier PoP, or configuration deployment. Alongside the normal topology, record the active path and convergence time when a device, link, power supply, circuit, control plane, or state synchronization fails. For stateful devices, test new and existing sessions separately. Also check whether preemption or asymmetric paths cause a second outage during failback.
Sources for this section IETF RFC 1812 · Cisco Design Zone
NAT and firewall inspection may happen at different points↑
On a home router, NAT and firewall settings share a screen and can look like one function. Enterprise networks may have several policy boundaries: internal segmentation firewalls, Internet-edge NAT, and cloud security groups.
Document which device changes addresses and which device applies policy or records logs using the original addresses. Without a link between original and translated addresses, incident investigation and service troubleshooting lose continuity.
A firewall may evaluate policy before NAT, using the original source 10.20.30.25, or after NAT, using the public source. It depends on the product's packet-processing order and policy location. Internet-edge logs may show only the external tuple, while an internal segmentation firewall may see only the original tuple. Incident investigation and application allowlists require the two logs to be correlated using synchronized timestamps and the pre- and post-translation address and port mappings recorded by the translating device. A translation ID can serve as an additional identifier if the device provides one; do not assume that different devices use the same ID.
In the cloud, route tables, security groups, network firewalls, and NAT gateways may be separate services. Draw where a packet's source or destination changes and where stateful decisions occur. Automatically equating a security zone with a NAT boundary can leave internal east-west traffic or IPv6 flows that do not use NAT outside the intended policy. Set policy boundaries by trust and visibility needs; set address translation by routing and address-space requirements.
Place functions according to whether the security device needs the original source, whether policy uses the address before translation or after it, and where replies travel. For a service exposed through DNAT, label the public destination, the translated internal server address, and allowed ports. Check how the server's reply source address and port are restored to the publicly advertised values. With multiple firewalls or load balancers, record each point's addresses and ports, the device holding connection state, and the conditions under which asymmetric paths are allowed.
Sources for this section IETF RFC 3022 · NIST SP 800-41 Rev. 1
What to look for This example distributes functions across access, distribution, core, and external connectivity. Authentication, access controls, and firewalls are combined according to the traffic path and the resources they protect. A list of appliances or multiple layers of security does not, on its own, establish zero trust. Policies must evaluate the user, device, and requested resource to determine access permissions. The device types, link speeds, and session counts in the figure are illustrative, not mandatory enterprise specifications or performance guarantees.
↔ Scroll horizontally to explore the diagram.
Before choosing equipment, map each function's failure impact and owner in one table↑
Scenario: An office is expanding from 80 to 500 people and replacing its existing router.
- List the existing device's Wi-Fi, DHCP, switching, routing, NAT, VPN, and firewall roles.
- For each role, identify the users and services an outage would affect and the acceptable recovery time.
- Define boundaries for internal gateways, the Internet edge, and management.
- Record state synchronization, flows that fail during switchover, operational owners, and log locations.
- Validate normal, failure, and maintenance paths rather than relying on maximum specifications.
Use rows for Wi-Fi access, L2 switching, DHCP, the default gateway, internal routing, Internet routing, NAT, the firewall, VPN, and management. Use columns for the current and target implementations, the person responsible for configuration, monitoring, normal dependencies, failure impact, HA approach, and rollback procedure. It is fine for one product to appear in several rows. That repetition reveals which roles and shared failures are concentrated in one box.
Once the design is set, trace representative traffic on the diagram: endpoint address assignment, communication between internal VLANs, Internet access, inbound public-service access, and management. For normal, failure, and maintenance conditions, mark next hops, applicable policies, and the device holding connection state. Compare these paths with failure-test results to find missing settings or design conditions. The diagram also becomes a troubleshooting reference for operators.
In a test environment, check the effects of link loss, device restart, lost state synchronization, and policy changes separately. Compare measured recovery time and existing-session continuity with business requirements, then adjust device placement or operating procedures where needed.
Sources for this section IETF RFC 6192 · Cisco Design Zone
FAQ↑
Must every enterprise network have three tiers: core, distribution, and access?
Does separating more functions always improve reliability?
Can virtual devices provide role separation too?
Glossary↑
Sources and verification
- IETF RFC 1122 — layered communication requirements for Internet hosts
- IETF RFC 1812 — IPv4 router forwarding and control requirements
- IETF RFC 6192 — protecting management interfaces on network infrastructure devices
- Cisco Design Zone — official starting point for vendor design examples and validation documents
- IETF RFC 3022 — NAT/NAPT address and port translation
- NIST SP 800-41 Rev. 1 — security guidance distinguishing firewall policy from NAT
This article does not prescribe equipment counts or throughput. Verify redundancy behavior and performance against the chosen platform, version, and test results.