In this guide
What topology means
Network topology describes how devices and links are arranged and how traffic is expected to move between them. It is useful to distinguish three related concepts:
- Physical topology: where cables, radios and devices are physically connected.
- Logical topology: how VLANs, IP networks, routing domains and forwarding paths are arranged.
- Security topology: where firewalls, policy enforcement points and trust boundaries sit in the traffic path.
A switch stack, for example, may physically present as several switches in one rack while operating as one logical switching system. Likewise, a pair of firewalls may be physically redundant but appear as a single logical default gateway to the rest of the network.
Common physical topologies
Bus
Devices share a common communications medium. Classic coaxial Ethernet used this model. It is simple conceptually but suffers from shared-medium contention and a single physical segment becoming a major failure domain. It is not a normal design for modern switched Ethernet.
Star
Endpoints connect to a central switch or access point. This is the dominant physical topology for modern Ethernet. A failed endpoint cable normally affects one device; a failed central switch can affect many.
Extended star / tree
Access switches connect to distribution or core switches, creating a hierarchy. This scales well and makes it possible to define clear aggregation points, but upstream links and devices become important failure domains.
Ring
Each device connects to two neighbours. Rings can provide path redundancy when a protocol or technology can reconverge around a failed link, but a ring must be deliberately engineered to avoid loops and unpredictable traffic paths.
Mesh
Devices have multiple interconnections. A full mesh maximises path diversity but becomes expensive as the number of nodes grows. Partial mesh is more common, with redundancy concentrated around important nodes.
Point-to-point
A dedicated link joins two devices. WAN circuits, routed switch uplinks and many inter-site links use this model because the forwarding relationship is simple and the failure domain is easy to understand.
Common enterprise and campus designs
Three-tier campus
The traditional three-tier model separates access, distribution and core functions. Access switches connect users and devices; distribution provides aggregation, Layer 3 boundaries and policy; the core provides fast, resilient transport between distribution blocks.
CORE
+---------------+
| Core 1 Core 2|
+---+---------+-+
| |
+------+--+ +--+------+
|Distribution| |Distribution|
+--+------+--+ +--+------+--+
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
|Access| |Access| |Access| |Access|
+-----+ +-----+ +-----+ +-----+
| ENDPOINTS |
This model is useful where scale, resilience and clear fault domains justify the additional layers. Smaller sites often do not need a dedicated core and distribution layer.
Collapsed core
A collapsed-core design combines core and distribution functions into one resilient switching layer. Access switches connect to the collapsed core, which performs inter-VLAN routing and upstream connectivity. It is common in small and medium environments where a full three-tier hierarchy would add complexity without enough benefit.
Internet / WAN
|
+-----+-----+
| Firewall(s)|
+-----+-----+
|
+------+------+
| Collapsed |
| Core / Dist |
+--+--+--+--+-+
| | | |
Access switches
| | | |
Users / APs / IoTSpine-and-leaf
Spine-and-leaf is common in data centres. Every leaf connects to multiple spines, giving predictable paths and high east-west capacity. Endpoints and servers normally connect to leaves; spines provide the fabric between them. Modern implementations commonly use Layer 3 routing and ECMP rather than relying on a large Layer 2 domain.
Router-on-a-stick
Router-on-a-stick places the Layer 3 gateway for multiple VLANs on a single router interface. The interface is configured as an 802.1Q trunk towards a switch, with logical subinterfaces representing the VLANs.
VLAN 10 clients --\
VLAN 20 clients ---- [Switch] ===== 802.1Q trunk ===== [Router]
VLAN 30 clients --/ |-- VLAN 10 GW
|-- VLAN 20 GW
`-- VLAN 30 GW
For example, the router might have subinterfaces such as G0/0.10, G0/0.20 and G0/0.30. Each subinterface has an IP address in its VLAN's subnet and becomes the default gateway for that network.
The main limitation is that multiple VLANs share one physical router interface and therefore one link's bandwidth and failure domain. Inter-VLAN traffic also has to traverse that router interface. In larger environments, a Layer 3 switch can normally perform inter-VLAN routing at much higher throughput.
| Router-on-a-stick | Layer 3 switching |
|---|---|
| Gateway functions live on router subinterfaces. | Gateway functions usually live on SVIs/VLAN interfaces on a Layer 3 switch. |
| One physical trunk is a major bottleneck/failure point unless deliberately made redundant. | Can provide high-speed local routing and multiple routed uplinks. |
| Simple for small environments and labs. | Usually better for medium/large campus networks. |
Linear core → firewall → internet
A very common small-site topology is a linear path where the internal switching infrastructure connects to a firewall, and the firewall connects to the ISP or internet edge.
NORTH-SOUTH TRAFFIC
[Clients / Servers]
|
[Core / L3 Switch]
|
[Firewall]
|
[ISP Router / ONT]
|
INTERNET
The attraction is simplicity. The core knows about internal networks, while the firewall provides the boundary between trusted/internal networks and the external network. NAT, internet policy, VPN termination and sometimes additional security inspection can be concentrated at the firewall.
There is an important architectural choice here: where should inter-VLAN routing happen? If the core is Layer 3, VLAN gateways can live on the core and traffic between internal VLANs may stay on the switch. If the firewall is the Layer 3 gateway for every VLAN, inter-VLAN traffic is forced through the firewall. Neither is universally correct; the decision depends on security requirements, firewall capacity, policy needs and the desired failure domain.
Variant: firewall as the VLAN gateway
VLAN 10 --\
VLAN 20 ---- [Core L2 switch] ==== trunk ==== [Firewall]
VLAN 30 --/ |-- GW 10
|-- GW 20
`-- GW 30
|
ISP
This resembles router-on-a-stick, except the security appliance provides the subinterfaces and Layer 3 gateways. It is attractive when policy between VLANs is important. The firewall must, however, be sized for both internet traffic and internal inter-VLAN traffic.
Firewall-centric and DMZ designs
A firewall can provide several security zones rather than simply an inside and outside interface. A common example is an internal network, an internet-facing network and a DMZ for services that must be reachable from outside.
INTERNET
|
[Edge / ISP]
|
+-----+-----+
| FIREWALL |
+--+-----+--+
| |
LAN DMZ
| |
Internal Public-facing
networks services
The security benefit comes from policy between zones. A DMZ host should not automatically have unrestricted access to internal networks merely because it is connected to the same firewall. Rules should reflect the minimum required flows, and return traffic should be considered as part of the stateful policy.
Layer 3 core designs
In a modern campus, the core or collapsed core often acts as the Layer 3 boundary for internal VLANs. Access switches carry VLANs locally, while routed links connect the access or distribution layer to the core.
Users -- [Access SW] -- routed link --+ APs -- [Access SW] -- routed link --+-- [L3 Core] -- [Firewall] -- Internet IoT -- [Access SW] -- routed link --+ VLAN gateways / SVIs: on L3 Core Internal routing: on L3 Core Internet policy/NAT: on Firewall
This separates responsibilities cleanly: the switching core handles high-volume internal routing and the firewall handles the security boundary. ACLs on the core can still provide local segmentation where appropriate, while traffic requiring deeper inspection can be sent to a firewall.
Another option is to keep a small number of security-sensitive VLANs behind the firewall while ordinary internal VLANs route on the core. This creates a hybrid architecture and can be useful when only selected traffic needs inspection.
Redundancy and failure domains
A topology should be evaluated by what happens when a link or device fails, not only by what happens when everything is working.
| Design choice | Typical benefit | Question to ask |
|---|---|---|
| Dual core / distribution switches | Removes a single central switching failure. | Can every access switch reach both members? |
| Dual firewall HA | Protects the security boundary against appliance failure. | Are state, interfaces, routes and upstream links also redundant? |
| Dual uplinks | Protects against one link or transceiver failure. | Are both links genuinely independent, or do they share one hidden failure point? |
| Layer 3 routed uplinks | Reduces dependence on large Layer 2 domains and STP. | Is routing configured correctly on both paths? |
| Switch stacking / virtual chassis | Simplifies management and can provide multi-link designs. | What happens if the stack link or one member fails? |
Redundancy is only real if the failure domains are independent. Two switches fed from the same power source, two fibre paths through the same physical cable route, or two firewalls connected through one upstream switch can still share a single point of failure.
Choosing a topology
| Environment | Often suitable | Why |
|---|---|---|
| Lab / very small network | Single switch + router-on-a-stick | Low cost and simple to understand. |
| Small business / branch | Collapsed core → firewall → ISP | Clear boundary and relatively simple operations. |
| Campus with multiple buildings | Redundant core/distribution + access | Resilience, scale and controlled Layer 3 boundaries. |
| High-density data centre | Spine-and-leaf | Predictable paths and strong east-west scalability. |
| Security-heavy environment | Core + firewall zones / segmented security architecture | More control over which flows cross security boundaries. |
Do not choose a topology solely because it is fashionable. Start with traffic flows, required availability, scale, operational capability, security policy and budget. Then place routing and security boundaries where they solve an actual requirement.
Troubleshooting by topology
Router-on-a-stick
- Confirm the switch-to-router link is a trunk and the required VLANs are allowed.
- Check whether the native/untagged VLAN is consistent at both ends.
- Verify each router subinterface is up and has the correct VLAN ID.
- Check the endpoint's default gateway and ARP table.
- Check router CPU, interface utilisation and errors if performance is poor.
Core → firewall → internet
- Test from the endpoint to its default gateway.
- Test from the core to the firewall's inside interface.
- Check routing between the core and firewall, including the return path.
- Check firewall policy and NAT.
- Check the firewall's outside interface and ISP handoff.
- Test DNS separately from raw IP connectivity.
Layer 3 core
- Confirm the SVI is up and the VLAN exists where required.
- Check the endpoint's ARP/ND entry and default gateway.
- Inspect the routing table for the destination prefix.
- Check ACLs on the SVI or routed interfaces.
- Trace the route to identify where the forwarding decision stops.
General rule
Trace the expected packet path hop by hop. At every boundary ask: Who is the gateway? Who is routing? Who is inspecting? Which VLAN or subnet is the packet in? What is the return path?
Key takeaways
- Star, tree, ring, mesh and point-to-point describe fundamental physical arrangements.
- Three-tier and collapsed-core designs describe common campus architectures.
- Router-on-a-stick puts multiple VLAN gateways on router subinterfaces reached over one 802.1Q trunk.
- A linear core → firewall → internet design is simple and common, but the location of inter-VLAN routing determines whether internal traffic traverses the firewall.
- Layer 3 routing on the core usually provides efficient internal routing, while the firewall can remain the security and internet boundary.
- Redundancy should be assessed by independent failure domains, not by counting devices.
- The best topology is the one that matches traffic flows, security requirements, scale, resilience and operational reality.