🕸️ What is a Network? (A Journey on the Digital Highway)

In its simplest terms, a network is a transport vehicle that allows systems to communicate with each other. It enables computers to function not as independent islands, but as a massive, interconnected continent.

Why Isn’t a USB Drive Enough? You might use a USB drive to transfer an Excel file or a video to the computer in the next room at home. However, that’s not how things work in the professional world. Imagine you are in an office where 50 people are working on the same file, or you need to send data to a colleague in another city or even another country. In any scenario where the distance is too far or the crowd is too large for manual transfer, the Network—the digital highway—kicks in.

🏭 The Factory Example: “The Server Room” as the Heart of the System

Imagine you are in a factory. The entire memory of the factory is stored on a server in the system room: customer lists, invoices, production stocks, and employee data. Let’s assume there are 100 people in the factory. Each of these 100 people must be able to access this server from their own desk simultaneously, without errors, and at high speed.

The Network Engineer is the person who builds the road between those 100 people and that server, ensures the traffic doesn’t get congested, and secures that path. This is not just about “placing three or five boxes side by side” — it is about designing operational integrity. In today’s world, this structure is managed not only with physical cables but also with smart software layers like SD-WAN and Cloud integrations.

🏠 Home Modem vs. Industrial Infrastructure

Most of us have a modem at home, and all we do is plug it in to connect to the internet. However, in the corporate world (hospitals, hotels, plazas), these home devices are like toys:

• Industrial Product Selection: A home-type modem will overheat, lock up, and crash when it tries to get 100 people online at once. That’s why in the professional world, we use “Industrial Switches” from global giants like Cisco, Arista, HPE (Aruba), or Juniper.
• Ports and Connectivity: These devices usually have 24 or 48 ports. When you say an office of 100 people, don’t just count the laptops; security cameras, printers, fingerprint readers, IP phones, and Access Points are also connected to these switches. This means an office of 100 people is actually 150–200 different cable ends and connections for you to manage.

📶 Wireless World and Roaming

At home, the internet works fine near the modem but drops off in the back room. You cannot solve this with a single device in a factory or a 10-story hotel.

• Army of Access Points (AP): Dozens, sometimes hundreds, of Access Points are installed on ceilings, in warehouses, and in offices.
• Seamless Transition (Roaming): Imagine walking from one end of a factory to the other while on a call with your laptop. The internet must not drop for even a second. Your expertise lies in setting up and managing that smart structure (Wireless Controller) that allows your device to drop one AP and latch onto another without you even noticing.

🛡️ The Gatekeeper of the Internet: Firewall and Leased Lines

Corporate internet operates under much different rules than home internet:

• Metro Ethernet (Dedicated): At home, the internet slows down in the evening because you share the line with your neighbors. In companies, “Dedicated” (exclusive to you) lines are used. Your speed is always constant, and most importantly, your Upload speed is very high.
• Firewall: We place a sentry at the entrance of this valuable internet line. With brands like Palo Alto, Fortinet, or Check Point, you implement who can access which site, how external cyberattacks are blocked, and the Zero Trust philosophy.

Want to understand Zero Trust from an architecture perspective? The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product

🌙 The Other Side of the Coin: Shifts and Responsibility

If you are going to be a network engineer, you must accept this reality: “The system is never shut down while everyone is working.”

• Maintenance Windows: If you are going to update the software inside a switch or change the location of cables, you can’t do this while everyone is in the office. This is why work is often done during late-night hours, weekends, or public holidays.
• Sleepless Nights and Rights: Your phone might ring at 3:00 AM if the system crashes. However, in the professional world, this is a sacrifice, and companies usually balance this by offering overtime pay or “service time” (extra time off) during the week.

🎓 Roadmap: How to Become a Network Engineer?

This profession is learned not just by reading, but by doing and following globally recognized paths:

1. The Foundation of Certification: CCNA This is the “driver’s license” of the network world. Cisco Certified Network Associate (CCNA) training allows you to learn the alphabet of the business (IP, Routing, Switching).

2. Official Education Portals (The Treasure Trove!) Manufacturers offer great resources for you to learn their devices:

   • Cisco Networking Academy (Skills for All): skillsforall.com
   • Palo Alto Networks Education: learning.paloaltonetworks.com
   • Fortinet Training Institute: training.fortinet.com
   • Aruba (HPE) Learning Center: learn.hpe.com/aruba
   • Juniper Learning Portal: learningportal.juniper.net

3. Online and Self-Learning

   • Udemy: You can find very affordable CCNA courses in many languages.
   • CBT Nuggets: The video explanations are of very high quality.
   • Simulation Tools: Don’t just read books! Install Cisco Packet Tracer on your computer. For more advanced levels, use GNS3 or EVE-NG to experience professional device software.

Conclusion

Networking is the foundation of computing. Whether you are a developer or a cybersecurity specialist, you cannot be a true professional without knowing how a packet gets from point A to point B. If you love solving complex puzzles and building the infrastructure of digital worlds, Network Engineering is a prestigious and exciting career path that is always in demand.

Related Articles

Go Deeper into the Architecture

• 📐 IT Infrastructure Is Not a Collection of Products — Why the right mindset matters more than the right products
• 🏗️ Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough — Architecture-first network design
• 🛡️ The Zero Trust Mindset: Engineering Security as an Architecture — Security beyond the perimeter
• 🎯 Network Infrastructure Product Selection: Strategic Criteria — How to evaluate vendors like a professional

Practical Engineering

• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access when everything fails
• 🛡️ Network Packet Broker (NPB) Masterclass — Traffic visibility and security strategy
• 🔐 802.1X Field Deployment Guide — Identity-based network access control

However, today these devices have evolved into security and automation-oriented professional management platforms that offer much more than a simple serial port multiplexer.

This article is part of a broader series on resilient network design. For the architectural foundation: IT Infrastructure Is Not a Collection of Products

1. Why Do We Need a 48-Port Management Giant?

In enterprise-level data centers, dozens of switches, routers, firewalls, and servers are located in the same cabinet. A 48-port console device allows you to manage an entire cabinet via a single IP, optimizing physical space and ending cabling chaos.

• Space Saving: Taking console control of 48 devices in a single U (unit) space simplifies the intra-cabinet architecture.
• Centralized Entry: By providing access to all devices through a single portal, you minimize management complexity.

2. Smart Ports: Software-Selectable Pinout for Every Device

Every manufacturer (Cisco, Juniper, HP, Palo Alto, etc.) has different console standards and pinouts. We used to have to carry different adapters (dongles) or custom-made cables for every brand. The greatest strength of modern console servers is the Software-Selectable Pinout feature:

• Software Flexibility: Different Baud Rate, Data Bits, and most importantly, Pinout settings can be defined independently for each port.
• Adapter-free Connection: Thanks to software pinout, you can connect to any brand with a standard CAT6 cable without the need for complex converter adapters. This is the ultimate solution to “cable soup” chaos.

3. Flexible Access: HTML5 Web CLI and Software Integration

Diversity in access methods provides engineers with tremendous agility during a crisis:

• Java-Independent HTML5 Support: Say goodbye to the clunky Java applications that were the biggest problem with old-gen devices. You can now open secure and high-speed CLI sessions directly through modern web browsers without installing any applications.
• SecureCRT and SuperPutty Integration: Fully compatible with your favorite CLI software. You can connect to devices over SSH tunnels with a single click through terminal emulators you are used to, managing your sessions professionally. This integration is vital for bulk-pasting complex command sets.

4. Security and Role-Based Access Control (RBAC & TACACS+)

The console port is the “backdoor” of a device, and this door must be protected at the highest level. Someone connecting to a device via console that cannot be reached over IP is touching the very heart of the device.

• Centralized Authorization: Centralized management is provided through TACACS+, RADIUS, or LDAP integration. You can track who entered which port, at what time, and for how long, second by second.
• Role-Based Access (RBAC): Define permissions only for the ports each user is responsible for. For example, let the security team see only Firewall consoles, while the systems team accesses only server consoles.
• Advanced API Support: Bulk commands can be sent to devices via API, or configurations can be automated based on instantaneous conditions.

5. Automation and Traceability: CLI Logging & Config Backup

A console server is no longer just a bridge; it is a recording and post-mortem analysis center:

• Automatic CLI Output Logging: All CLI outputs flowing on the console screen are automatically recorded. When a device crashes or gives a Kernel Panic, you cannot see the logs at that moment because the device has no IP access. However, since the console server records this stream, you can analyze the device’s last “cries” before the crash and find the root cause in seconds.
• Automatic Configuration Backup: Both the console device’s own settings and the critical configurations of the devices it manages are periodically backed up. This is part of the Network Infrastructure as Code (NIAC) vision.

6. Uninterrupted Access: Dual WAN and Out-of-Band (OOBM) Architecture

If the network has completely collapsed, how will you reach the console server? This is where real “engineering” begins:

• Dual WAN & Cellular Support: With two independent internet inputs or internal 4G/5G LTE modules, you continue to reach devices over the cellular network even if your main internet line is cut.
• Out-of-Band Management (OOBM): This isolated path, established over a different service provider completely independent of main data traffic, is the only lifebuoy that gives you a chance to intervene even when the main network is completely “down.”

7. Market Leaders

The following brands set the market standards in high port density, smart automation features, and HTML5 support:

• Opengear: At the top with smart OOBM and high-security features.
• Lantronix: Known for flexible port structures and ease of management.
• Avocent (Vertiv) & Perle: Indispensable for professional data centers with their stable hardware.

Conclusion

The console server is the invisible protector of a complex infrastructure. These features, ranging from SecureCRT integration to automatic CLI logging, and from adapter-free connection to Java-independent HTML5 support, turn crisis moments into manageable operations.

Remember: the best network is the one that always has a “Plan B.”

Related Articles

Architecture & Strategy

• 📐 IT Infrastructure Is Not a Collection of Products — System thinking for resilient infrastructure
• 🏗️ Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough — Architecture-first core network design
• 📊 Monitoring Done Right: How to Build a Proactive IT Operations Culture — Catching problems before users do
• 🎯 Network Infrastructure Product Selection: Strategic Criteria — Evaluating vendors strategically

Practical Engineering

• 🛡️ Network Packet Broker (NPB) Masterclass — Traffic visibility and security strategy
• 🔐 802.1X Field Deployment Guide — Identity-based access control
• 📈 Cisco Nexus NX-OS Upgrade Guide — Safe software upgrade procedures

For the broader architecture context behind visibility strategy, see: IT Infrastructure Is Not a Collection of Products

1. Micro-Second Precision: End of Packet Loss (Buffering & Time-Stamping)

Network traffic does not always flow linearly; instantaneous bursts occur. While many standard switches drop packets during these bursts, a professional NPB solves this problem at the hardware level:

• 500 ms Buffer Memory: NPB holds traffic momentarily in its memory, reducing packet loss to 0% during times when your analysis tools (DLP, IDS, Sniffer) cannot keep up with the speed. This is vital for forensics and debugging processes.
• Hardware Time-Stamping: When performing latency analysis, “about an hour” is not a professional answer. With the hardware Time-Stamping feature offered by NPBs, you can stamp every packet with micro-second precision the moment it enters the system. These stamps are life-savers, especially in forensic analysis processes.

2. Intelligent Filtering and Protocol Mastery (L2-L4)

While L2-4 filtering (MAC, IP, Port) exists in many devices, the difference with an NPB is that it performs this process at “wire-speed” without compromising packet integrity and with unparalleled flexibility:

• Flow Aggregation & Deduplication: It analyzes thousands of flows coming from massive 100 GB inputs, cleans duplicate packets (Deduplication), and converts all this chaos into a single optimized flow for analysis devices. Cleaning duplicate packets reduces the CPU load of your analysis devices by 30-50%.
• Packet Slicing (Lighten the Load): You don’t always need to be in love with the entire packet. If your analysis tool only needs header information, perform Packet Slicing on the NPB to trim the payload. This way, you don’t overwhelm the disks and processors of your analysis devices with unnecessary data, gaining 100% efficiency.

3. Flexible Delivery Methods: Getting Traffic to the Target

NPB offers a rich “packaging” menu to deliver your filtered traffic to the analysis device:

• ERSPAN & VXLAN/GRE Tunneling: It carries traffic to remote data centers or cloud-based analysis centers by encapsulating it over Layer 3 networks.
• VLAN Tagging / Stripping: It adds tags for the analysis device to recognize the traffic or cleans these tags to lighten the load on the device.
• Load Balancing: It distributes dense 100G traffic equally to 10G capacity analysis devices without breaking “session stickiness” (session integrity).

4. API Support, Automation, and the NIAC Vision

Manual intervention is a risk in modern IT operations. The automation capabilities offered by NPB provide agility to teams. However, do not view the process as just a simple “backup”; we integrate these devices into Network Infrastructure as Code (NIAC) principles thanks to Rest-API support.

• NIAC & Disaster Recovery (DR): All critical filtering rules and port configurations on the device should be managed with NIAC principles. In the event of a hardware failure, we can migrate the entire architecture to a new device in seconds using automation scripts rather than manual configuration.
• ITSM and SIEM Integration: During a cyber incident, filters can be automatically created via SIEM tools, or existing filters can be edited via API according to the instantaneous situation.

5. Performance and Security (Riverbed, DLP & SSL Offloading)

NPB is like a central “Data Hub” feeding all kinds of analysis devices on the network:

• Network TAP (Inline Data Collection): It can receive traffic directly from cables going to servers (Network TAP), not just switch ports. This allows you to reach the “purest” data without affecting main traffic.
• SSL/TLS Offloading: Don’t exhaust the CPUs of your Firewall or IPS devices with decryption. Handle this load on the NPB and send “clean” and unencrypted traffic to analysis devices. Let your security devices do their actual job; let the NPB handle the heavy lifting of decryption.
• Riverbed Integration: By feeding NPM devices like Riverbed with the most accurate data, it detects application latencies and bottlenecks.
• Call Centers (VoIP): It processes voice traffic in parallel; while one copy goes to the recording system, the user continues the conversation without any delay.

6. Encrypted Traffic and Data Center (DC) Strategy

Although internet traffic is encrypted, “East-West” traffic flowing unencrypted within the data center for performance reasons is still the biggest opportunity. Using NPB at these strategic points where traffic is transparent and mirroring the data provides 100% visibility without incurring decryption costs.

7. Market Leaders

While Keysight (Ixia) and Gigamon set the standards for high-performance solutions; brands like Arista, Garland Technology, and Profitap are indispensable for enterprise networks with their flexible port structures and innovative delivery methods.

Conclusion

The seamless orchestration of traffic mirroring and analysis flows is the definitive proof of how a complex network operation can be rendered controllable. By leveraging NIAC (Network Infrastructure as Code) and robust API integrations, this architecture transforms from a static hardware setup into a dynamic, “living” security platform.

Such a framework ensures that critical data reaches security tools with zero loss and maximum optimization, granting operational teams full visibility and command over the network.

Related Articles

Architecture & Strategy

• 📐 IT Infrastructure Is Not a Collection of Products — The system thinking behind visibility
• 🛡️ The Zero Trust Mindset: Engineering Security as an Architecture — Security as architecture, not a product
• 📊 Monitoring Done Right: How to Build a Proactive IT Operations Culture — Operational visibility beyond dashboards
• 🎯 Network Infrastructure Product Selection: Strategic Criteria — Evaluating security vendors strategically

Practical Engineering

• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access when everything fails
• 🔐 802.1X Field Deployment Guide — Identity-based access control at the network edge

How to evaluate Switch, Firewall, and AP beyond the datasheet

Most enterprise network projects start at the same point: product selection. And most of the time, they fail at the same point: products not working together. Because what we call a “core network” is not just three boxes (switch, firewall, access point) sitting side by side; it is about these three boxes carrying an identity together, generating segments together, enforcing policies together, and most importantly, sustaining operations together.

What I have seen over the years is this: a company’s network doesn’t struggle because it’s “bad,” but because the decision mechanism of the network is fragmented. You have the most expensive devices, the best licenses, the highest throughput — but when an incident occurs, no one knows which device decides with which context, where the traffic diverges, or where it is controlled. The result: you have a “network,” but you don’t have “network behavior.”

In this article, I will share a field-tested framework for evaluating core network products across three pillars: Firewall, Switching, and Access (Wi-Fi). But before we begin, two factors are as decisive as “technical specifications” — and most teams realize them too late: reports/validation and support/lifecycle.

For the architectural philosophy behind this selection process, see: IT Infrastructure Is Not a Collection of Products

Step 1: Filtering Reports, Tests, and Marketing Noise

One of the first references in product selection is, yes, Gartner reports. Reports like Gartner give you an idea of a product’s market position: who is the leader, who is the visionary, who is playing in a niche. This is especially useful for convincing decision-makers; it provides a structured answer to “why this brand?” at the budget table.

But there is a critical trap: Gartner doesn’t tell you which product is right for your specific scenario. Gartner is a market map; your job is to draw the architectural map. Use Gartner as an initial filter — it narrows options but doesn’t make the final decision.

Beyond Gartner, performance and security tests from manufacturers or independent labs, comparative reports, and real-world benchmarks must be considered. The throughput on a datasheet is not the same as throughput in production when IPS is on, SSL decryption is active, and app-control is running. Reports serve as a second filter: you look for a non-marketing answer to “What does this box do under this specific load?”

Step 2: Support and Lifecycle — The Invisible Pillars

A product’s technical capabilities are only half the story. Its support model and lifecycle are equally critical. Network design doesn’t end on installation day. The real question is: what happens 3 years later?

• What are the EoL / EoS dates?
• How fast are patches, bugfixes, and security updates?
• Is TAC/Support truly accessible, and how do escalations work?
• What is the reality of RMA processes and spare parts availability?
• Will the licensing model cause surprises after year one?
• Is the vendor’s roadmap aligned with your strategic direction?

The most common problem I see in the field: the team chooses a technically sound product, but because support/lifecycle was deprioritized, operations turn into a nightmare 12 months later. The device gets the blame — but the real problem was never the device.

Step 3: Evaluating the Firewall Layer

The firewall has long passed being just a “security device at the edge.” Positioned correctly, it is the policy brain of the architecture. Positioned incorrectly, it becomes the bottleneck where everything collapses.

UTM vs. NGFW — a necessary distinction:

The UTM approach follows the “everything in one box” philosophy: firewall + IPS + web filter + AV + gateway functions. Preferred in smaller environments for management simplicity and bundled licensing.

NGFW is positioned around application awareness, user/identity context, and deeper policy control. In modern enterprise environments, running security on port/protocol alone is no longer sufficient — this is where NGFW becomes necessary.

Why two or three firewalls in the same organization is normal:

• Perimeter/Internet Edge Firewall: Internet egress, VPN, NAT, inbound/outbound policy
• Internal Segmentation Firewall (ISFW): East-west control, internal segmentation, critical zone isolation
• Data Center / High-performance FW: DC traffic, high session count, high PPS, low latency
• In some architectures: WAF or Cloud FW as additional components

This doesn’t mean “buy two firewalls” — it means “assign two different jobs to the right tools.”

For a deeper look at firewall architecture within the broader network design: Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough

Step 4: Firewall Capacity Planning — Throughput Can Lie

The most dangerous mistake in firewall selection is focusing solely on Gbps throughput. In practice, firewalls rarely fail because of throughput — they fail because of:

• PPS (packets per second)
• Concurrent session count
• New session rate
• NAT table and state handling
• Performance with active IPS/AV/App-ID
• SSL/TLS decryption load
• Log generation and SIEM transport

A real-world example: “We bought a 10 Gbps firewall” means nothing in isolation. That 10 Gbps is an ideal-condition measurement on most vendor datasheets. With IPS, URL filtering, app control, and decryption active, real capacity changes dramatically. The right question is always:

“With the security features I will enable and my specific traffic profile — how much load can this firewall actually handle?”

If there is no credible answer to this question, the selection is risky.

Step 5: Switch Evaluation — Role and Load Over Port Count

Switch selection often starts with port counts: copper ports, fiber ports, PoE requirements. These matter — but from a core network perspective, they aren’t sufficient. A switch is not just a socket; it is a decision point determining where traffic concentrates, diverges, and is carried upward.

The most common access layer mistake: planning for today’s needs only. The access layer is the fastest-changing layer in the network. A point with adequate 1G copper today may host high-bandwidth APs or edge devices tomorrow. Multi-Gig ports (2.5G/5G), per-port PoE sustainability, and real uplink capacity all become critical.

Uplinks are consistently underestimated. “2×10G uplinks are enough” is heard often — without analyzing the actual traffic profile. As user count grows and east-west traffic patterns shift, uplinks reach saturation faster than expected. Backplane capacity and oversubscription ratios matter as much as uplink speed.

Edge switch vs. datacenter switch: these boundaries are often blurred in projects. Edge switches optimize for port density and PoE; datacenter switches optimize for throughput, low latency, high PPS, and east-west traffic. Expecting both from a single device usually inflates cost or drops performance below expectations.

When designing the core network, the question “Where will this switch stand and what traffic will it carry?” must come before “How many ports does it have?”

Step 6: Wireless — Uplink and Controller Architecture

When discussing wireless, focus usually shifts to Wi-Fi standards: Wi-Fi 6, 6E, 7. In practice, wireless performance is often limited not by the radio — but by the cable. No matter how powerful the AP, if the uplink cannot carry it, theoretical speeds are meaningless.

Many enterprise APs cannot use their full potential on a 1 Gbps uplink. 2.5G and 5G copper uplink support is not a luxury in high-density environments — it is a design requirement. And critically: if the AP supports 2.5G but the switch port does not, the entire investment is wasted. AP and switch selection must be done together.

Controller architecture is equally critical. The number of supported APs, simultaneous client capacity, and roaming behavior determine real-world stability. A controller that “supports 500 APs” on paper may struggle far earlier in high-density, fast-roaming environments. Controller capacity must be evaluated across CPU, memory, session handling, and policy enforcement — not just license count.

Wireless is often treated as an edge topic, but it strains the core network faster than any other layer. Small design errors at the access layer create unexpected loads at the core. AP selection is not a coverage calculation — it is a core network architectural decision.

Step 7: Vendor Evaluation — Field Realities

The following assessments are based entirely on my personal field experience. The goal is not to praise or criticize — but to honestly identify where each vendor is strong and where they struggle.

Cisco remains one of the strongest players in switching and routing, especially in large campus and datacenter environments. Wireless has been mature for years. On the firewall side, significant development followed acquisitions like Sourcefire. The caveat: a full Cisco environment is powerful but rarely simple. Integration is possible — but requires significant experience and effort.

HPE Aruba has grown substantially through acquisitions, most recently Juniper. Switching is widely adopted with a loyal user base. Wireless, in my personal view, is among the strongest in the industry. Historical routing gaps should largely close with the Juniper product family. The absence of a strong native firewall family remains a gap.

Fortinet offers one of the broadest portfolios under a single roof. Firewall competency is strong — it’s their foundation. The switching family matured later but is increasingly present in the field. The biggest operational advantage: relative ease of integration and management. This difference is clearly felt in organizations with smaller IT teams.

Palo Alto Networks is a clear leader in firewalls — deliberately not entering switching or wireless. Many organizations use Palo Alto exclusively for firewalls, for very good reasons. Application visibility, policy depth, and SASE leadership are where they create the most differentiation.

In practice, organizations use all combinations: single-vendor, dual-vendor, or best-of-breed. These decisions are as organizational as they are technical.

My personal view: where teams are mature enough, specialized vendors per layer tend to produce stronger technical results. Where simplicity and a single support channel matter more, a single-vendor approach is completely valid.

One final point: API support is no longer a bonus — it is a selection criterion. The question “How will I automate this architecture?” should come before choosing the switch, firewall, or AP. In my view, good core network design starts exactly here.

The Server Room and Cabling: What Nobody Talks About But Everyone Pays For

In network projects, the “shiny” topics dominate: which switch, which firewall, which wireless solution. But a significant portion of field problems starts at a much more basic level: server room design and cabling infrastructure.

No matter how good the products or how correct the architecture — if the server room and cabling are weak, that network will eventually produce problems. These problems appear as “network failures,” but the root cause is almost never the network itself.

Server rooms are still treated as equipment closets in most organizations. Racks grow, cables pile up, temporary solutions become permanent. Eventually, an area is created that nobody wants to touch — but everyone depends on. The real risk starts there.

Heat, power, airflow, accessibility, and order must be considered together. Redundant power supplies are purchased without checking whether they actually connect to separate power lines. UPS capacity is never calculated. These seem like small details — until a crisis makes the entire architecture meaningless.

Cabling is the longest-lasting component of the network. Switches, firewalls, and APs change — cables stay. Planning cabling for today’s needs is a guaranteed mistake. A 1G design hits its limit quickly when 2.5G/5G APs arrive.

Physical access security to the server room is equally overlooked. Without clear controls on who enters, when, and how changes are logged, even the best logical security policies lose their meaning.

In my view, the server room and cabling are not the “lower layer” of architecture — they are the foundation. A well-functioning network is invisible precisely because the foundation is solid. Nobody notices. And in my view, that is the greatest praise any infrastructure design can receive.

Note

This article was originally published on Substack in a shorter, narrative form. This version expands on the architectural foundation of the series.

👉 Read the article on Substack: Click Here

Related Articles

Architecture & Strategy

• 📐 IT Infrastructure Is Not a Collection of Products — The foundational article of this series
• 🏗️ Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough — Architecture-first core network design
• 🛡️ The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product — Security as architecture

Technical Engineering

• 📊 The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively — Operational visibility
• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access
• 🛡️ Network Packet Broker (NPB) Masterclass — Traffic visibility and security strategy

Architecture, capacity planning, and the vendor reality no one talks about

Most enterprise network projects start at the same point: product selection. And most of them break at the same point: products that do not work well together. Because what we call a “core network” is not three boxes (switch, firewall, access point) standing side by side; it is those three boxes carrying identity together, producing segmentation together, enforcing policy together, and most importantly, sustaining operations together.

What I have observed for years is this: companies do not suffer because their network is bad, but because the network’s decision-making mechanism is fragmented. The most expensive devices, the best licenses, the highest throughput… all are there; yet when an incident happens, who knows what, which device decides based on which context, where traffic is separated, where it is controlled—there are no clear answers. The result: “there is a network,” but there is no “network behavior.”

In this article, I will examine the core network across three pillars: Firewall, Switching, and Access (Wi-Fi). But before that, I want to clearly state one thing: in the selection process, there are two factors that are just as decisive as “technical specifications,” and most teams realize them too late: reports/validation and support/lifecycle.

Filtering reports, tests, and “marketing noise”

One of the references to look at when selecting a product is, yes, Gartner reports. Because reports like Gartner give you an idea of a product’s “position in the market”: who is a leader, who is a visionary, who plays in a niche. This is especially useful for convincing decision-makers; it provides a framework for answering the question “why this brand?” at the budget table.

But there is a critical trap here: Gartner does not tell you which product is right for your specific scenario. Gartner is a “market map”; your job is to draw an “architectural map.” That is why it is more accurate to use Gartner as an initial filter: it narrows down options but does not make the final decision.

In addition to Gartner, performance and security tests conducted by vendors or independent laboratories, comparative reports, and “real-world” benchmarks must also be considered. Because the throughput listed on a datasheet is not the same as the throughput achieved in real life when IPS is enabled, SSL decryption is active, and application control is running. Reports serve as a second filter here: you look for a non-marketing answer to the question, “What does this box do under this load?”

Support and lifecycle: the invisible column that keeps the project standing

Just as critical as a product’s technical capabilities are its support model and lifecycle. Because network design is not limited to “installation day.” The real issue is what happens three years later:

• What are the EoL / EoS dates of this product?
• How fast are patches, bug fixes, and security updates delivered?
• Is TAC/Support truly accessible, and how does the escalation process work?
• What is the reality of RMA processes and spare parts availability?
• Does the licensing model create surprises after one year?
• Is the vendor roadmap aligned with the direction you are heading?

I want to emphasize this because the most common problem I see in the field is this: the team selects a product that is technically close to the right choice, but due to support/lifecycle issues, operations turn into a nightmare after 12 months. Then the blame is placed on the device; whereas the real problem is not the device itself, but the lack of seriousness given to the “support” side of the decision.

Firewall: UTM, NGFW, or multiple roles?

A firewall has long ceased to be merely a “security device at the edge of the network.” When positioned correctly, it becomes the policy brain; when positioned incorrectly, it turns into a bottleneck because everything collapses onto it.

It is useful to clarify terminology from the start: UTM and NGFW are often mixed up in many environments.

The UTM approach generally aligns with the idea of “everything in a single box”: basic firewall + IPS + web filtering + AV + some gateway features… Especially in small to mid-sized environments, it is preferred due to ease of management and bundled offerings.

NGFW, on the other hand, is positioned around application awareness, user/identity awareness, more advanced security services, and deeper policy control. In today’s enterprise needs, running security based solely on port and protocol is often insufficient; this is where NGFW comes into play.

But the most critical point is this: a company’s needs may not be satisfied by a single “type of firewall.” Because what we call a firewall can actually take on different roles at different layers for different purposes.

Why is it normal to have two (or even three) firewalls in the same company?

In many organizations, the following scenarios are very reasonable:

• Perimeter/Internet Edge Firewall: Internet access, VPN, NAT, inbound/outbound policy.
• Internal Segmentation Firewall (ISFW): Internal network segmentation, east-west control, critical zones.
• Data Center / High-performance FW: DC traffic, high session count, high PPS, low latency requirements.
• In some architectures, additional components such as WAF or Cloud FW.

For a deeper look at how identity and segmentation fit into a broader security philosophy, see: The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product

This does not mean “buying two firewalls”; it means “assigning two different jobs to the right tools.” When you pile everything into a single box, you lose either performance, manageability, or security. Usually, at least one of the three is lost.

And this takes us directly to capacity planning.

Firewall capacity planning: throughput alone can be misleading

The most dangerous mistake in firewall selection is looking only at the “Gbps throughput” number. Because in real life, what kills a firewall is often not throughput:

• PPS (packets per second)
• Number of concurrent sessions
• New session rate
• NAT tables and state handling
• Performance with IPS/AV/App-ID enabled
• Heavy workloads such as SSL/TLS decryption
• Log generation and log transport (SIEM integration)

A real example: the statement “we bought a 10 Gbps firewall” means nothing by itself. Because that 10 Gbps is measured under “ideal conditions” in most vendor datasheets. In your environment, if IPS, URL filtering, application control, and decryption are enabled, the actual capacity changes dramatically. That is why the right question should be: “With the security features I will enable, and with my traffic characteristics, how much load can this firewall actually handle?”

Switching: role and load matter more than port count

Switch selection often starts with port count: how many copper ports, how many fiber ports, whether PoE is needed or not… These are of course important, but from a core network perspective, they are not sufficient. Because a switch is not just a power socket connecting endpoints; it is a decision point that determines where traffic concentrates, where it separates, and where it is carried upward.

One of the most common mistakes on the access switch side is planning based on today’s needs. Yet the access layer is the fastest-changing layer in the network. A location that seems fine with copper ports today may host a high-bandwidth AP, a camera, or a different edge device tomorrow. Therefore, the speed capability of copper ports (1G vs. 2.5G/5G), the sustainability of PoE budgets not only in total watts but per port, and the real capacity of uplinks become critical.

The uplink topic is often underestimated. Statements like “2×10G uplink is enough” are frequently heard, but the traffic characteristics those uplinks will carry are rarely discussed. As user counts increase at the access layer and east-west traffic and broadcast behavior change, uplinks can reach saturation much faster than expected. At this point, it is necessary to look not only at uplink speed but also at the switch’s backplane capacity and oversubscription ratios. Because an uplink may be 10G, but if the internal architecture of the switch cannot sustain it, the bottleneck is inevitable.

The difference between edge switches and datacenter switches is also not clearly defined in many projects. Edge switches are typically optimized for user and device density: many ports, PoE, access-focused features. Datacenter switches come with architectures designed for high throughput, low latency, high PPS, and east-west traffic. Expecting both roles from the same device often either unnecessarily increases cost or delivers performance below expectations. When designing a core network, the question “where will this switch sit and what will it carry?” should come before “how many ports does it have?”

Inter-VLAN routing decisions are also directly related to switch selection. If routing is to be performed on the switch, it is not enough for the switch to simply support Layer 3; route scale, TCAM capacity, policy applicability, and how these decisions integrate with the firewall must be considered. Otherwise, a design that initially appears to deliver performance gains can later turn into an unmanageable complexity.

ACCESS / AP

Access / Wi-Fi: uplink and control plane are as much a part of the architecture as the radio

When wireless networks are discussed, the focus usually shifts to Wi-Fi standards: Wi-Fi 6, 6E, 7… Yet in practice, wireless performance is often limited not by the air, but by the cable. No matter how powerful an access point is, if the uplink behind it cannot carry the load, theoretical speeds mean nothing.

Today, many enterprise APs cannot utilize a significant portion of their potential when limited to a 1 Gbps uplink. That is why 2.5G and 5G copper uplink support is not a “luxury” but a direct design requirement, especially in high-density user environments. But here, too, the chain must not break: an AP may support 2.5G, but if the switch port it connects to does not, the entire investment is wasted. That is why AP and switch selection must be done together, not separately.

Another critical topic on the Wi-Fi side is controller architecture. The number of APs supported by the controller, concurrent client capacity, and roaming behavior determine the real-world stability of the network. A controller that claims to “support 500 APs” on paper may struggle much earlier in a high-density environment requiring fast roaming. Controller capacity must be evaluated not only by license count, but together with CPU, memory, session handling, and policy enforcement capacity.

Wireless networks are often thought of as “edge,” but in reality, they are the layer that stresses the core network the fastest. Users are mobile, connections are frequently dropped and re-established, and authentication and policy enforcement cycles are far more intensive than in wired networks. That is why a small design mistake at the access layer can create unexpected loads in the core network. AP selection is not just a coverage calculation; it is an architectural decision that directly affects core network behavior.

Closing: Vendor Selection, Architectural Maturity, and Reality

At this point, I want to clearly state that what I describe below is entirely based on my personal field experience and observations. My intention is not to praise or criticize any vendor, but to openly state where they are strong and where they struggle. Because core network design is not done with brand fanaticism, but with real needs and operational realities.

Starting with Cisco is natural. They are still one of the strongest players in switching and routing. Especially in large and complex environments, they have serious maturity in campus and datacenter switching. They have also been strong in wireless for many years, with a significant ecosystem and accumulated experience. On the firewall side, especially after expansions in Asian markets and acquisitions such as Power, they have shown serious development and are now in a more competitive position in the NGFW space.
However, it must be clearly stated: when you choose Cisco for everything, integrating these products with each other often becomes exhausting and labor-intensive for an administrator. Everything is possible, but it is rarely “easy”; integration requires significant effort and experience.

The HPE Aruba side, which I have followed closely for nearly a decade, tells a different story. When I first entered this ecosystem, the product portfolio was quite limited. Over time, with HP’s European acquisitions, the portfolio expanded; today, with the addition of the Juniper product family, it is growing significantly. On the switching side, the Aruba family has a wide and friendly user base. On the wireless side, influenced by its European-origin infrastructure, my personal view is that they offer one of the strongest Wi-Fi solutions in the industry.
In the past, there were gaps on the routing side; however, I believe these gaps will largely be closed with the Juniper product family. On the other hand, the lack of a strong standalone firewall product family causes them to fall somewhat short in this area.

Fortinet offers a very broad product portfolio. Their ability to provide a complete solution under a “single roof” across firewall, switching, and wireless is a significant advantage for many organizations. Due to Fortinet’s security-focused origins, they are known to be very strong on the firewall side. The switching product family matured later, which slowed its adoption, but in recent years it has appeared more frequently in the field.
In my view, one of the biggest advantages of the Fortinet ecosystem is ease of use and interface simplicity. Integration between products is relatively less painful, which can significantly reduce operational load. This difference is especially noticeable in organizations with limited IT teams.

When it comes to Palo Alto Networks, the picture is clearer: Palo Alto is very strong in firewalls and is unquestionably one of the leading vendors in this area. However, they deliberately do not enter areas such as switching or wireless; that is simply not their focus. Many organizations choose Palo Alto solely for firewall purposes, and there are very sound reasons for this.
I believe Palo Alto creates a serious difference in application visibility, policy depth, and especially in areas such as SASE. The fact that they are one of the world’s largest cybersecurity vendors today is no coincidence. It is entirely natural for many organizations seeking “the best” on the firewall side to gravitate toward Palo Alto.

In real life, companies make very different choices across these three main product groups. Some organizations prefer to move forward with a single vendor: switch, wireless, and firewall from the same brand; integration and support from a single point of contact; a clear counterpart when problems arise. Others choose one vendor for firewalls and another for switching and wireless. In more mature environments, selecting each layer from different vendors is also quite common.

These choices are often as organizational as they are technical. An organization’s view of IT, team structure, and the habits and past experiences of the network team significantly influence these decisions. There is no single right answer here.
My personal view is this: there are vendors who have proven themselves more strongly in specific areas, and if the IT team is mature enough to manage this distinction, selecting different vendors for different layers can produce much stronger technical results. On the other hand, some organizations prefer to move forward with a single vendor to avoid integration issues, installation complexity, and configuration errors, and to resolve all problems through a single support channel. This is also a completely valid approach.

Finally, there is one point I want to emphasize strongly: today, almost all major vendors are making serious investments in automation. At this point, API support is no longer an “extra,” but a direct selection criterion. What can be done via APIs, what can be automated, and how open the integration is must be on the table when selecting products.

For a practical framework on building visibility into your infrastructure, see: The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively

As I mentioned in my first article, in my opinion, automation processes should not be considered as a layer added later during product selection. On the contrary, automation and operational processes should be placed at the top of the pyramid, and products should be selected according to this framework. The question of which switch, which firewall, and which AP should come after the question: “How will I manage this architecture automatically?” In my view, correct core network design starts exactly here.

Server Room and Cabling: The Reality No One Wants to Talk About, but Everyone Pays For

In network projects, the most talked-about topics are usually the most “shiny” ones: which switch, which firewall, which wireless solution… But a significant portion of the problems experienced in the field start at a much more fundamental place than these products: server room design and cabling infrastructure.

There is one reality I have seen repeatedly over the years: no matter how good the products you choose, no matter how correctly you design the architecture; if the server room and cabling infrastructure are weak, that network will eventually produce problems. And these problems often appear as “network outages,” but the root cause is almost never the network itself.

In many organizations, the server room is still treated like a “storage room.” Initially, a few racks are placed in a small area; as operations grow, new devices are added to the same room, cables pile up, and temporary solutions become permanent. At some point, a space emerges that no one wants to touch, but everyone depends on. This is where the real risk begins.

A server room is not just a place where devices sit. It is the heart of the network. Heat, power, airflow, accessibility, and order must all be considered together. Cooling, for example, is often realized too late. Devices may seem to be working, but operating continuously at high temperatures significantly affects both performance and hardware lifespan. Sudden reboots, unexpected freezes, or “intermittent” issues are very often traced back to inadequate cooling.

The power side is similarly underestimated. Devices with redundant power supplies are purchased, but it is not verified whether these power supplies actually connect to different power lines. There is a UPS, but capacity calculations are not done. It is unclear how long systems will remain operational during a power outage. These may seem like small details on paper, but in a crisis, they render the entire architecture meaningless.

Cabling infrastructure is often thought of as something “done once and forgotten.” Yet cabling is the longest-lived component of the network. You change switches, firewalls, access points; but the cable remains. One of the biggest mistakes, therefore, is designing cabling based on today’s needs. An infrastructure planned for 1G today can hit a serious limit tomorrow with APs requiring 2.5G/5G uplinks or edge devices demanding higher speeds.

Deciding where to use fiber and where to use copper is also an architectural decision. Pulling fiber everywhere just because “fiber is faster” is not correct; there are still many cases where copper is advantageous, especially where PoE is required or distances are short. The real issue is designing cabling to allow for future expansion. Patch panel organization, cable labeling, rack-to-rack and in-rack cable management… These are not aesthetic concerns; they are operational ones.

Every change in a poorly labeled cabling infrastructure is a risk. You affect the wrong device when shutting down a port, you take down another service when unplugging a cable. Then people say, “the network went down again.” But the problem is not the network; it is the careless cabling done years ago.

Physical access security to the server room is also often overlooked. If it is not clear who can enter this room, at what times, and how changes are logged, even the best security policies lose their meaning at some point. In an environment where you cannot control physical access, discussing logical security often remains theoretical.

From my perspective, the server room and cabling are not the “lower layer” of core network design; they are the foundation. No matter how sophisticated the solutions you place on top, if the foundation is weak, the structure will shake. That is why when designing a network, it is necessary to look not only at diagrams, but also at the physical environment where those diagrams will be realized. Rack layout, cable paths, power, and cooling plans are all part of the architecture.

These topics are generally not exciting, they do not take up much space in presentations, and they are hard to put on a CV. But the truth is this: behind a well-functioning network, there is often a well-designed server room and a clean cabling infrastructure. No one notices this; because nothing goes wrong. And in my view, that is the greatest praise an infrastructure design can receive.

Not

This article was originally introduced on Substack in a shorter, narrative form. This version expands the architectural foundation for the series.

👉 Read the article on Substack: Click Here

Related Articles

If you found this article useful, you may also be interested in these related deep-dives:

Architecture & Security Design

• 📐 IT Infrastructure Is Not a Collection of Products — The foundational article for this series
• 🛡️ The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product — Why Zero Trust is a philosophy, not a product you can buy
• 📊 The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively — How to build real visibility into your infrastructure

Technical Engineering

• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access when everything else fails
• 🛡️ Network Packet Broker (NPB) Masterclass — Advanced traffic visibility and security strategy
• 🔐 Unlocking Success in 802.1X Projects: Field Insights — Identity-based access in enterprise networks
• ⚙️ Nexus Software Upgrade Guide — Zero-downtime NX-OS upgrade walkthrough