This page is about design, not about products. It sets out how to choose a topology, size an access layer, decide where the Layer 3 boundary sits, plan VLANs and addressing, calculate oversubscription and PoE budgets, and write a switching specification that a bidder cannot wriggle out of. When you reach the point of choosing hardware, we hand you over to the NetForce switching hub, which is where models, port configurations and buying guidance live.
Almost every switched network in the world is a variation on two shapes. The classical three-tier design separates access, distribution and core into distinct devices, each with a single well-defined job. The collapsed-core design folds distribution and core into one pair of devices, so access switches uplink directly into the thing that also routes and connects onward to the gateway. Neither is superior. They answer different questions, and the question they answer is about scale, physical spread and operational headcount rather than about budget.
A collapsed core is the right answer for a single building, or a small cluster of buildings within a couple of hundred metres of each other, where the total access switch count is modest and where every uplink can reasonably terminate in one comms room. Fewer devices means fewer configurations to keep consistent, fewer places for a routing decision to hide, and a much shorter fault tree when something breaks at two in the morning. If your entire estate is forty access ports across three floors, a three-tier design is not sophistication, it is overhead you will pay for every time you make a change.
Three tiers earn their keep when the site spreads out. Once you have several buildings, or one very large building with distinct vertical risers, aggregating each block locally and then carrying only the aggregated traffic to a core reduces the fibre count between blocks dramatically, keeps failure domains contained to one block, and gives you a natural boundary at which to apply policy per building. A campus with hostels, an academic block and an administration block, or a plant with a production shed, a warehouse and an office wing, is a three-tier network whether you draw it that way or not.
A word on redundancy before we go further. Both shapes are frequently drawn with duplicated devices and dual paths, and dual uplinks from an access switch to two upstream devices is a sound general design principle wherever the cabling supports it. What we will not do on this page is tell you how any particular switch behaves during a failure, because that behaviour is model-specific and version-specific. Resilience is something to establish for your exact models, in your exact configuration, and to record in a signed design document before you commit. Ask us to confirm current specifications in writing for the specific model, and treat any resilience claim that is not in that document as unverified.
Port count is the easiest thing to get wrong because it is the easiest thing to estimate carelessly. The habit of counting desks and rounding up to the nearest twenty-four fails in modern buildings, where the desk is often the smallest consumer of ports. Count instead: wireless access points, fixed cameras, door controllers and access readers, IP handsets, printers and multifunction devices, digital signage, building management sensors, time-and-attendance terminals, projectors and room systems, plus fixed workstations. In a typical Indian office floor the non-desk devices now outnumber the desks, and in a hospital or a warehouse they outnumber them heavily.
Once you have that inventory, apply three multipliers. First, spare ports for growth: fifteen to twenty percent is a reasonable planning figure over a five-year horizon, more if the site has an active expansion plan. Second, ports consumed by the infrastructure itself, since uplinks, management ports and inter-switch links are ports you cannot sell to a user. Third, an allowance for the awkward reality of cable routes, because two cupboards each half-full is a common and entirely defensible outcome when the horizontal cabling cannot reach a single location within the distance limit.
Placement follows the cabling, not the org chart. Horizontal copper has a hard practical distance limit, and every access switch must sit inside that radius of the devices it serves. In a long floorplate that usually means two cupboards rather than one. In a warehouse with high-bay access points it may mean intermediate cabinets at intervals down the length of the shed, which is exactly the pattern discussed on our warehouse Wi-Fi solutions page. In a hospital, the constraint is often that certain wings cannot be taken out of service for cabling work at all, which pushes you towards more, smaller access switches placed where work is permitted; see hospital Wi-Fi solutions for how that interacts with segmentation.
Finally, size the access layer with the wireless plan in hand rather than after it. Access point count drives both port count and power draw, and a wireless design that lands after the switch order is placed is the most common cause of a mid-project change note. Our campus wireless page covers the density side of that conversation, and the NetWave access point range is where the port and power implications of specific access points are set out.
The distribution layer has one structural job and one policy job. Structurally, it takes many access uplinks and turns them into a small number of links onward, which is what keeps the core small and the inter-building fibre count manageable. In policy terms, it is the natural home of the Layer 3 boundary: the place where a VLAN stops being a flat broadcast domain and becomes a routed subnet with an address, a gateway and an access control policy attached to it. Concentrating routing at this tier means that when someone asks "where does traffic between the guest network and the corporate network get controlled", there is exactly one answer, and it is written down.
The core layer, where it exists as a separate tier, should be deliberately boring. It carries aggregated traffic between distribution blocks and onward to the gateway or WAN edge, and it should do as little else as possible. Access ports at the core are a smell. Complex policy at the core is a smell. Every feature you add to the core is a feature that can fail in a way that affects the entire site rather than one block. Keep it fast, keep it simple, keep its configuration short enough that a new engineer can read it in ten minutes.
Where the network meets the outside world, the boundary between switching and security needs to be explicit. Internet policy, content control, remote access and inspection belong at the gateway, not scattered across the switching fabric; our network security page covers that division, and the NetGuard controller range is where the gateway side of the design lives. A common and avoidable mistake in Indian campuses is to route all internal, east-west traffic through the firewall simply because the firewall was installed first. That works until the firewall becomes the busiest device in the building, at which point you are troubleshooting a capacity problem that was created by an architectural decision nobody consciously made.
A VLAN plan should be designed once, written down once, and then followed. The failure mode we see most often is a network where VLANs accreted over five years, each added by a different engineer for a different reason, until nobody can say with confidence what VLAN 47 is for or whether anything still lives in it. Start from traffic classes, not from departments: users, voice, wireless infrastructure, surveillance, building systems and IoT, servers, guest, and management. Departments change; traffic classes rarely do.
Number them systematically and reserve blocks. If you allocate VLAN 10 to 19 for user traffic, 20 to 29 for voice, 30 to 39 for wireless, 40 to 49 for surveillance and so on, then five years later a new VLAN slots into the scheme without a debate. Reserve a management VLAN that carries switch management traffic only, keep it out of the user address space, and do not use VLAN 1 for anything you care about.
The next decision is where routing between those VLANs happens. Three approaches are common. Routing at the gateway keeps switch configuration trivial and is entirely adequate for a small site with light east-west traffic. Routing at the distribution tier keeps internal traffic internal, shortens the path, and takes load off the gateway, which is the pattern that suits most campuses. Routing all the way down at the access edge, so that every access switch is a routed device and VLANs do not span switches, eliminates large broadcast domains and confines loops to a single closet, but it multiplies the number of devices holding routing state and it demands a team that can operate that. If your support model is two people covering fifteen sites, routed access is a liability, not an upgrade.
Layer 2 remains entirely sufficient at the edge in most designs, and there is no engineering virtue in pushing routing further down than your operations can carry. The honest test is this: can traffic on this switch reach everything it needs to reach without crossing a subnet boundary? If yes, Layer 2 is enough here. If no, something upstream must route, and you should decide deliberately which device that is. Our guide on how to choose an enterprise switch walks through the same trade-off from the buying side.
Static routing is deterministic, auditable and completely predictable. In a collapsed-core site with one routed boundary and a default route to the gateway, static routing is not a compromise, it is the correct engineering answer, and adding a routing protocol to that site introduces a moving part that solves no problem you have. The threshold at which static routing stops being sensible is not a number of subnets, it is the point at which a single topology change requires you to edit several devices by hand, because that is the point at which human error becomes the dominant failure mode.
A dynamic interior gateway protocol earns its place when there are multiple routed devices, multiple paths between them, and a genuine expectation that the network should reconverge without an engineer typing. OSPF is the usual choice in enterprise campuses: it is standards-based, well understood, widely supported across vendors, and it lets you divide a large campus into areas that limit the scope of any single change. Where a site has multiple routed blocks and you want changes in one block not to ripple across the whole estate, area design is the tool. Multi-site organisations with WAN links between locations should also decide explicitly what is advertised across those links and what is summarised, because the most common WAN incident in a multi-branch network is a routing table that grew without anyone noticing; our enterprise networking page covers the multi-site framing.
Whichever you choose, document the routing design as a design, not as a configuration dump. Which device is authoritative for which subnet, what the default path is, what happens to traffic when a path is unavailable, and which routes are permitted to be advertised: those four answers belong in the design document that both you and your supplier sign, alongside the specification confirmation for each model proposed.
Any Layer 2 network with more than one path between two switches will loop unless something stops it, and a broadcast storm from an accidental loop takes a floor down faster than almost any other fault. Spanning tree is the mechanism that prevents this, by blocking redundant paths until they are needed. The important design points are generic and vendor-neutral. Decide deliberately which device is the root of the spanning tree rather than letting an election pick the oldest switch in the building, because an unplanned root turns your carefully drawn topology into something quite different in practice. Use the rapid variant rather than the original, since convergence times differ by an order of magnitude. Protect edge ports so that a user-facing port cannot suddenly claim to be a better path to the root. And accept that spanning tree is a safety net, not a load-balancing strategy: it blocks links, and a blocked link is bandwidth you have paid for and cannot use.
Which is why link aggregation matters. Bundling two or more physical links between the same pair of switches into one logical link gives you the aggregate bandwidth and keeps all members forwarding, instead of one forwarding while the other sits blocked. Two practical cautions. First, aggregation distributes traffic by hashing flows, not by splitting packets, so a single large flow will not exceed the speed of one member link; four bundled one-gigabit links do not make a four-gigabit conversation possible. Second, bundle configuration must match at both ends, and mismatched configuration is one of the more entertaining ways to build a loop. Where aggregation crosses between two upstream devices rather than terminating on one, the behaviour is entirely dependent on the platform, so establish it for your specific models in writing and record it in the signed design document.
Oversubscription is the ratio between the total access bandwidth a switch can present and the uplink bandwidth it has to carry that traffic away. It is not a defect. Every practical campus network is oversubscribed, because users do not all transmit at line rate simultaneously. The design task is to choose a ratio you can defend. In general campus practice, ratios in the region of 20:1 at the access layer and around 4:1 between distribution and core are widely used starting points, tightened where traffic is heavy and predictable, loosened where it is light and bursty. What matters is that you calculate it and write it down, rather than discovering it later.
Work the arithmetic for each closet. Take the number of access ports and their speed, take the uplink count and speed, and divide. Then sanity-check the result against what the ports actually carry: a floor of wireless access points aggregating hundreds of clients is a very different load from a floor of IP cameras streaming continuously, which is in turn different from a floor of desktops doing email. Surveillance is the classic trap, because camera traffic is constant, unidirectional and entirely predictable, so it does not benefit from statistical averaging in the way user traffic does.
The PoE budget follows the same discipline. Build the powered-device list for each closet, take each manufacturer's stated maximum draw rather than typical draw, add an allowance for cable loss that grows with run length, and sum. Then check that sum against two separate limits: what a single port can deliver, and what the switch can deliver across all ports simultaneously. A design can satisfy one limit and fail the other. Leave headroom, because the device list on day one is never the device list in year three, and outdoor cameras with heaters and high-density access points are the usual causes of an overrun. Our explainer on PoE, PoE+ and PoE++ covers how the classes work.
Uplink media is the other half of this. Distance decides most cases, because copper Ethernet has a hard practical limit that fibre does not, so anything between buildings or up a tall riser goes on fibre. Electrical environment decides most of the rest, since fibre carries no shared electrical path between buildings and is immune to interference, which matters in plants and in older buildings with questionable earthing. Where fibre is used, keep the optic estate consistent so that diagnosing a degraded link is a short exercise rather than a process of elimination across four brands; the NetBeam optics range is intended to be specified alongside the switching, and our comparison of fibre versus copper in enterprise networks sets out the trade-offs at length.
Allocate by site and then by function so that addresses summarise cleanly, and a routing table stays short. Size subnets for the device count plus growth rather than defaulting to a /24 everywhere: a closet with nine cameras does not need two hundred and fifty addresses, and a hostel block with a thousand devices needs more than one. Keep management addressing in its own range, keep guest addressing well away from internal ranges, and record the whole allocation in one document that is updated when it changes.
Quality of service is only useful where there is contention, which in a campus means the uplinks. Classify and mark traffic as close to the source as possible, trust those markings consistently across the fabric, and give voice a strict-priority queue because voice cares about delay and jitter far more than about bandwidth. Video conferencing sits in a lower priority class; surveillance video, which is constant but tolerant of a little delay, belongs in a class of its own so that it cannot crowd out interactive traffic.
Segmentation is the cheapest security control in the building because it limits what a compromised device can reach. Put building systems, cameras and IoT on their own segments and permit only the specific flows they need, rather than permitting everything and hoping. Authenticate devices at the port where the environment supports it. Keep guest traffic entirely off the internal routing table. The network security page covers where enforcement belongs.
These three plans share a property: they outlive the hardware. Switches get replaced every five to seven years; a VLAN scheme, an address plan and a QoS policy will carry across two or three hardware generations if they are designed well and documented honestly. That is why we push customers to settle them on paper before any purchase order is raised, and why our engineers will ask for them before quoting.
Very few Indian enterprises get to build on a clean site. Most switching projects are refreshes, carried out in a live building where the network cannot stop. The sequence that works, almost universally, is to build the new core and aggregation first alongside the old, prove it in isolation, then migrate access closets one at a time onto the new aggregation, and decommission the old core last. Migrating the core first is tempting because it looks like progress, but it puts every user behind an unproven device on night one.
Plan the migration closet by closet with a defined rollback for each. A rollback plan that says "revert the patching" is only credible if the old switch is still powered, still configured and still connected, which means you need physical space and power for both during the transition. Budget for that. Agree change windows with the business early, particularly in hospitals and hotels where the windows are short and the tolerance for overrun is nil. Label everything before you start rather than during, because nobody labels accurately at three in the morning.
Refresh planning also deserves a mention on the commercial side. Standardising on a small number of models across an estate makes spares strategy simple, makes firmware management tractable and makes the twelfth site as quick to commission as the second. Central visibility across sites through a platform such as NetCloud Central is worth deciding on at design time rather than retrofitting, because it changes how you name and address things. System integrators managing multi-site rollouts on behalf of clients will find the commercial and pre-sales arrangements set out on our partner programme page.
Everything above is design guidance, and it applies whoever you buy from. At the point where a design becomes a bill of materials, the questions change: which model, how many ports, what power budget, which uplink cages, what does it cost, and how is it procured. Those questions are answered on our product pages, not here, and we keep the division deliberate so that you are not reading the same content twice.
The NetForce switches hub is the product starting point. It covers what the family contains, how the lines are organised, how the L2 and L3 buying decision is framed commercially, procurement and certification documentation, and how to brief us for a quotation. If you are ready to specify hardware, start there.
The NetForce L2 line is the managed access-layer hardware that implements the port density, VLAN and PoE decisions described on this page. Port configurations and power budgets differ by model and between production runs, so ask us to confirm current specifications in writing for the specific model.
The NetForce L3 line is the hardware for the distribution and core roles, where the Layer 3 boundary and inter-VLAN policy described above are implemented. Again, ask us to confirm current specifications in writing for the specific model, and have resilience behaviour recorded in the signed design document.
Around the switching sit the other elements of the same design: NetWave access points at the wireless edge, NetGuard controllers at the gateway, NetBeam optics lighting the fibre uplinks, and NetCloud Central for visibility across sites. Because these come from one Indian OEM with design and manufacturing in Sanand GIDC, Gujarat and a head office in Powai, Mumbai, the integration questions that normally take three vendor calls take one.
A switching RFP that describes only port counts and speeds will attract bids that are technically compliant and operationally useless. The checklist below is what we would want to see if we were on your side of the table, and it is deliberately vendor-neutral. Ask every bidder the same questions and compare the answers rather than the prices alone.
Describe the design, not just the boxes. State the topology you intend, three-tier or collapsed core, and where the Layer 3 boundary sits. Give the VLAN scheme, the addressing plan and the routing approach. A bidder who does not know where routing happens cannot size anything correctly.
Give the full device inventory per location. Access points, cameras, handsets, workstations, sensors, controllers and anything else that occupies a port, with a clear marker against every device that needs power from the switch. This single list drives port count, power budget and the layer decision.
State the oversubscription ratio you will accept at each tier, and require bidders to show their calculation rather than assert compliance. Ask for the uplink count and speed per closet as part of the response.
Specify the PoE requirement as two numbers, per-port class and total simultaneous budget, and require written confirmation of both for each proposed model. Require the bidder to show the powered-device arithmetic with cable-loss allowance included.
Require written, dated, per-model specification confirmation on letterhead against the exact configuration and quantity being quoted, and state that marketing pages and brochures will not be accepted as specification evidence. This applies to us as much as to anyone else.
Ask for certification status in writing, per model, dated. Indian buyers are increasingly required to demonstrate MTCTE registration, TEC-related requirements and, where radio equipment is involved, WPC clearance. Certification is granted against specific models with validity periods, so a brand-level claim is not sufficient for a tender file. Ask every vendor for written per-model confirmation and check the dates; our position on documentation is set out on the certifications page.
Require a signed design document, not just a bill of materials. It should state the topology, the routing design, the VLAN and address allocation, the QoS policy, and the expected behaviour of the network during a link or device failure. Resilience behaviour in particular should be written down and signed rather than inferred from a diagram or a sales conversation.
Specify the operational deliverables. As-built documentation, port and cable labelling standard, configuration backups, firmware versions at handover, named escalation contacts, and the response times you expect. Ask who performs the work and where they are based.
State the growth assumption you are buying against, in device counts three years out, and require the bidder to show headroom against it. Headroom bought at purchase is cheap; headroom retrofitted is not.
Ask for the cabling position. Whether the bidder has surveyed the existing horizontal cabling, what category it is, and what they will do if it does not support the specified port speeds. On retrofits this is the single most common cause of a project going sideways after the switches have already been delivered.
Describe the buildings, the device inventory and the segmentation you need. Our India-based engineers will come back with a topology, a VLAN and addressing plan, an oversubscription and power calculation, and a hardware proposal across the NetForce L2 and NetForce L3 lines with written specification confirmation for every model named.
Count buildings and cable routes rather than users. If every access uplink can physically reach one comms room within the distance limit, and the total access switch count is modest, a collapsed core is simpler to operate and cheaper to own. Once you have several buildings, long risers, or a need to apply policy per block, aggregating locally and carrying only aggregated traffic to a core reduces inter-building fibre, contains failure domains and gives you a cleaner policy boundary. Operational headcount matters too: fewer devices means fewer configurations to keep consistent.
There is no universal number, but ratios in the region of 20:1 at the access layer and 4:1 between distribution and core are widely used starting points in general campus practice. Tighten them where traffic is constant and predictable, such as surveillance, and loosen them where it is light and bursty. The important discipline is to calculate the ratio per closet from access port count and speed against uplink count and speed, then sanity-check it against what those ports actually carry, and record the result in your design document.
Usually not. Routed access eliminates large broadcast domains and confines loops to a single closet, which is genuinely valuable at scale, but it multiplies the number of devices holding routing state and demands a team that can operate that. For most Indian campuses, Layer 2 at the access edge feeding a Layer 3 boundary at the distribution tier is the right balance. The honest test is whether traffic on a given switch can reach everything it needs without crossing a subnet boundary. If it can, Layer 2 is enough there.
Static routing is correct, not a compromise, in a collapsed-core site with one routed boundary and a default route to the gateway. The threshold at which it stops being sensible is when a single topology change requires editing several devices by hand, because that is when human error becomes the dominant failure mode. A dynamic interior gateway protocol such as OSPF earns its place when there are multiple routed devices, multiple paths and a real expectation of reconvergence without an engineer typing.
Design from traffic classes rather than departments, because departments change and traffic classes rarely do. Reserve numbering blocks by class so that a new VLAN slots in without a debate. Keep a dedicated management VLAN outside the user address space. Keep guest traffic off the internal routing table entirely. Then document the scheme in one place and update it when it changes, which is the part most organisations skip and later regret.
Build the powered-device list per closet, use each manufacturer's stated maximum draw rather than typical draw, add an allowance for cable loss that grows with run length, and sum. Then check that sum against two separate limits: the maximum a single port can deliver, and the total the switch can deliver across all ports at once. A design can pass one and fail the other. Leave headroom for growth, and remember that outdoor cameras with heaters and high-density access points are the usual causes of an overrun. Our explainer on PoE, PoE+ and PoE++ covers the classes.
Quality of service only does useful work where there is contention, which in a campus is the uplinks rather than the access ports. Classify and mark traffic as close to the source as possible and trust those markings consistently across the fabric. Voice needs a strict-priority queue because it is sensitive to delay and jitter rather than bandwidth-hungry. Video conferencing sits below it, and surveillance video, being constant but delay-tolerant, belongs in its own class so it cannot crowd out interactive traffic.
Three things. A dated, per-model specification confirmation on letterhead against the exact configuration and quantity, since port configurations, power budgets and supported features can differ between models and production runs. A dated, per-model certification confirmation, because Indian buyers increasingly need to demonstrate MTCTE registration, TEC-related requirements and WPC clearance where radio equipment is involved, and certification is granted per model with validity periods. And a signed design document that states the topology, routing design, addressing and the expected behaviour of the network during a link or device failure. This advice applies to every vendor, including us. See the certifications page and ask our team for current written confirmation.