What changes when a small office uses separate switches and APs?

Switches and APs can be separate within one access tier ↑

In a single-tier design, there is no dedicated distribution or core tier. One access tier provides the site's LAN connectivity. Adding an AP or an Internet-edge device does not add a tier for each device.

Business endpoints connect to an access switch, and wireless endpoints connect to an AP. The AP's wired connection is part of the same access system. Outbound packets may pass through a separate gateway and firewall, but external connectivity is a different role from the core that connects campus blocks.

Here, one access switch, A1, connects endpoints and APs. E1 provides segment gateways and the Internet edge. Separating logical roles from physical device names avoids calling this two-tier simply because there are two boxes. To distinguish the tiers, check whether multiple access groups are brought together by a dedicated distribution tier.

Cisco's small-campus reference designs include a standalone switch or stack as a single-tier option. If one access system can connect the required endpoints, a separate distribution tier may not be needed. That does not make the same design right for every small office. Verify products and supported features for the combination you will actually deploy.

Next, calculate what the connected endpoints need, rather than counting devices. There may be enough ports but insufficient power for the APs. Even with enough power, the edge device may limit throughput. A single-tier design still requires separate checks of ports, power, and throughput.

In the baseline design, PCs and APs connect to A1, while the gateway is on E1. Moving the gateway to A1 also changes the return path required on E1.

Ports and PoE: calculate both on the same layout ↑

Calculate physical ports and power separately, then apply both to the same endpoint layout. Spare ports do not necessarily mean enough power for every AP and phone.

Assume 24 business endpoints, four APs, and eight phones each use a separate port. They need 36 access ports. A 48-port device has 12 left by count, but check which ports uplinks use and where additional endpoints will connect. Connecting a PC through a phone changes the assumption itself.

For this teaching example, budget 30 W per AP and 7 W per phone: 4×30+8×7=176 W. This is a supply-side planning figure, not actual endpoint consumption or a guaranteed specification for a Cisco device. In practice, verify power negotiation, classes, cable losses, and endpoint requirements.

Some of a device's total power supply capacity serves the switch itself and its internal components. Check how much remains available for PoE and how that budget shrinks if one power supply fails. A design that meets the normal budget but loses power to APs after a supply failure has a different scope of wireless service disruption.

A sufficient total power budget is not enough. Each AP must also be connected to a port that supports its power requirements. This example gives each phone and PC separate ports; if a PC connects through a phone instead, recalculate the required port count. Count any uplinks that share those port resources separately, using the device's actual port layout. Also check the supply limit after switching to backup power.

Record each port number, endpoint purpose, expected power demand, and priority on the layout. Use product policies and tests to establish which endpoints retain power when the budget is insufficient. Recording each AP location together with its supplying switch and electrical circuit also shows where wireless users may be disconnected by a power failure.

Putting port counts and power budgets at their actual connection points makes the calculations easier to follow. Below, PCs, APs, and phones use separate ports on A1. For the APs and phones, the PoE budget is calculated in the same diagram.

The same endpoint layout is calculated separately for port count and power. Spare ports do not settle whether enough power is available for the APs and phones.

VLAN gateways and policies: which device should host them? ↑

Even a small site needs an explicit gateway location. A switch separating VLANs is not performing the same function as connecting different VLANs by forwarding packets.

When PC-A in business VLAN10 determines that an address in guest VLAN30 is on another subnet, it chooses its own gateway as the first recipient. If A1 provides only L2 access, the frame travels to the corresponding VLAN interface on E1. Match the allowed list and connection mode on each port that carries that VLAN.

Another option places the gateway on an SVI on A1. Traffic between VLANs then crosses A1, so policies on E1 alone may not see it. The important change is not just enabling routing on A1: inter-VLAN packets may no longer pass through E1's policies.

Compare both options using the same PC-A and destination. Mark the gateway address, next hop, and any ACL or firewall along the path, then trace the request and response. Verify both that a path between VLANs exists and that it preserves the intended separation of business and guest traffic.

If the gateway moves to A1, E1 also needs a route back to the business subnets. A default route out from A1 does not complete the return path. Follow the request from the endpoint, identify the address it uses outbound, and trace the response back through each device.

E1 is the gateway in our baseline design. We compare the alternative of routing on A1 in the later article on choosing the L2/L3 boundary. If you add a switch and also move the gateway, review addressing, routes, and policies together.

Stack member failures can still disconnect endpoints ↑

A stack's redundancy features do not move the endpoints attached to a failed member onto other ports. Distinguish surviving control functions and paths from physical connections that disappear.

Assume A1 and A2 form one stack with uplinks distributed between them. PC-A, connected only to A1, loses its physical connection when A1 powers off. A2 may remain operational and the stack's management address may respond, yet PC-A's work can still stop.

Check each stack capability separately: control-role switchover, member interconnections, distributed uplinks, and power sharing. Products differ in their support for state retention and nonstop switchover. Specify the software version, supported topology, and failure type so the results can be interpreted correctly.

Trace the actual electrical circuits even when power appears to be separated. Two power supplies on the same circuit share its failure. Physical separation also leaves common causes, such as a stack-wide configuration error or shared software defect.

Test a broken link between stack members separately from a member losing power. Verify the surviving members' behavior for the specific platform and connection arrangement. A stack that normally appears as one management system may handle control and packet forwarding differently after that link breaks; test that failure in its own right.

Do not record only “stack healthy.” Record the status of endpoints on the failed member, endpoints on other members, AP power, external paths, and management access separately. These results also help determine where to connect endpoints with different downtime limits.

Distance, capacity, and maintenance determine when to split the access system ↑

Moving beyond a single-tier design is not just a question of port count. Check whether the current design can accommodate endpoint locations, required aggregate capacity, and maintenance needs for each area.

Before extending cabling into a new space, check the supported distance for the media and equipment, the cable route, and power. Managing distant devices as one system does not remove physical constraints. Separate installation locations also change site access and replacement time.

When traffic from several access groups converges on the same upstream path, consider how to aggregate those groups. Determine what traffic each sends, how much overlaps in time, and how far one group's failure may affect the others. These needs give us a reason to consider a distribution role.

Maintenance needs can change too. If one area must be updated while another stays operational, check whether shared control and the scope of a change allow it. The endpoints affected by a planned change matter to the design just as failures do.

Expansion can be difficult even with spare ports. Power for a new AP, upstream demand, or cable distance may become the first constraint. Record port count, power, uplink capacity, and physical layout separately to identify which requirement calls for a structural change.

Once access roles are defined for the small site, develop a private addressing plan that avoids overlap as devices are added or branches and clouds are connected. Then calculate uplink capacity in both normal and failure conditions. Address allocation rules and actual traffic together help us decide whether the current design is sufficient or needs aggregation devices.