https://www.linkedin.com/company/network-switch/
Introduction
If your priority is "improve security/observability without redesigning the production network", the most reliable approach is to add an observability layer: traffic access (TAP/SPAN/inline-bypass) → NPB (copy/aggregate/filter/replicate/load-balance) → analysis & visualization tools (IDS/NDR/DPI/APM/PCAP/SIEM).
This matters because classic switch mirroring can drop packets under burst/congestion and can filter error frames, which is exactly when security tools need fidelity most.
Fast choice:
- Choose TAP when you need the highest integrity ("what the wire saw is what the tool sees") and want to avoid the mirror limitations above.
- Choose SPAN when you need a quick PoC but can accept that traffic completeness may not be guaranteed during bursts/congestion, and cross-device mirroring adds complexity.
- Choose Inline (with bypass) when you must observe traffic "in-path" but still require fail-safe continuity; with bypass, the main link can keep communicating even if the device loses power.
One more outcome-changing point (often ignored): in many regions, the deep analysis and visualization appliances (NDR/IDS/DPI/PCAP recorders/SIEM dashboards) are bought locally and are constrained by policy and availability (data residency, government security requirements, procurement certifications).
You should validate what tool types/models are sellable and supportable locally before you lock your NPB plan-then you can tune compatibility, port speeds, and traffic steering accordingly. (This is also why NPB projects succeed: they're tool-driven, not "port-count driven.")
TAP vs SPAN vs Inline (bypass) quick selection
| Access Method | What It Is | Best Fit (When to Use) | Strengths | Key Risks / Trade-offs | Typical Tool Fit (After NPB) |
| TAP (Inline, Transparent Copy) | A physical tap inserted into the link to copy traffic | Compliance / audit-grade visibility; security monitoring where “what tools see must match production traffic” | Highest-fidelity capture; designed for 100% traffic replication including error frames | Requires physical insertion + optics/cabling planning; needs clear failover design for critical links | NDR, IDS/IPS, DPI, PCAP recorder, APM (with filtering) |
| SPAN (Switch Mirroring) | Switch mirrors traffic from selected ports/VLANs | Fast PoC, low-risk segments, budget-constrained quick start | Lowest deployment friction; no physical insertion | May drop mirrored packets during bursts/congestion; may filter error frames; RSPAN adds VLAN/routing complexity | Basic IDS/NDR validation, lightweight APM sampling (not ideal for full-fidelity forensics) |
| Inline + Bypass (Fail-safe Inline Visibility) | Inline insertion with a bypass/fail-open mechanism | When you need in-path access but must protect availability | Protects link continuity even if the observation device loses power | More design work: HA, bypass behavior, maintenance procedures; still requires optics/cabling planning | High-availability inline visibility stacks: NDR/IDS/DPI + PCAP (policy-dependent), with controlled NPB output |
Connected" is not "accurate": why the tool chain matters?
A traffic visibility project fails when teams treat the NPB as "a box that mirrors packets." What you're really building is an observability pipeline:
- Access layer (TAP / SPAN / Inline-bypass)
- Visibility layer (NPB / aggregator / broker) - copy, aggregate, filter, replicate, load-balance, preserve sessions
- Deep analysis layer - IDS/IPS, NDR, DPI probes, packet recorders (PCAP), APM analyzers
- Visualization & operations layer - SIEM/SOC dashboards, alerting, ticketing/workflows
The reason NPB/TAP exists is to move monitoring from "best effort" to "deterministic." The background material explicitly frames classic mirroring as unreliable in high-load moments and security-sensitive environments.
It also explains why modern networks demand multi-link aggregation, full-duplex, wire-speed lossless replication-conditions where "ordinary capture tools" struggle.
Why tools change the architecture
Your analysis tools have constraints:
- Port speed (10/25/100/400G) and number of ingest ports
- Whether they need session consistency (many NDR/analytics workflows do)
- Whether they support tunneled traffic (VXLAN/GRE/GTP) or need pre-processing/steering
That's why the NPB must be designed around what your local tool market can supply-not the other way around.
5 questions to answer before buying an NPB
In many countries (especially smaller markets), the security/observability stack is bought locally and shaped by policy and procurement. The background deck highlights compliance drivers (e.g., GDPR-like and "classified protection" requirements) pushing demand for complete, real-time, lossless traffic acquisition.
1. What tool categories are locally available?
Instead of starting with brand names, start with categories (you can then map to local SKUs):
- NDR (Network Detection & Response): behavioral analysis, lateral movement detection, anomaly detection (often needs session consistency and broad coverage)
- IDS/IPS sensors: signature/rule-driven detection, often deployed on critical choke points
- DPI / protocol analyzers: protocol-level visibility, sometimes mandatory in regulated networks
- PCAP recorders / forensics: full packet capture retention and retrospective investigation
- APM / application analytics: performance and user experience visibility
- SIEM/SOC platforms: visualization, correlation, alerts, workflows
The deck explicitly mentions security and compliance scenarios that require tools like IDS/IPS/DPI and insist regulators see traffic identical to production with no omission/modification.
2. What are the policy boundaries?
(General guidance - always confirm locally.)
- Data residency / data export restrictions: can PCAP or metadata leave the country?
- Government security requirements: retention duration, audit trails, who can access
- Encryption controls: whether TLS decryption is permitted and under what governance
- Procurement certifications: which vendors/types are legally purchasable for a sector
3. Why "tool first, NPB second" avoids rework
Tool constraints decide:
- Whether you need many-to-one aggregation or one-to-many replication
- Whether you need session-keeping load-balanced outputs (explicitly supported as a monitoring mode)
- Whether you should pre-handle tunnels (VXLAN/GRE/GTP) to steer inner IP traffic
4. How to make projects succeed?
- Build a local tool bill of materials (category → models → ingest port speeds → HA needs)
- Define your NPB output strategy: full copy to NDR, filtered subsets to IDS/APM, load-balance for scale
- Validate optics/cabling and failover design (bypass if needed)
- Pre-acceptance tests: tool ingest load, packet loss counters, session consistency, tunnel steering
Where to connect and what tool stack fits?
1. Core / aggregation layer "sidecar monitoring" (most common)
Goal: Observe north-south traffic and major inter-zone flows without changing forwarding.
Where to connect:
- Core ↔ aggregation
- Aggregation ↔ firewall / edge
- Firewall ↔ internet uplink
Recommended access:
- TAP for high-integrity visibility (compliance/security)
- SPAN for PoC only (with known completeness risks under load)
- Inline + bypass if you must sit "in-path" while preserving continuity
Recommended tool bundle (typical):
- NDR gets the broadest/fullest feed (for behavior detection)
- IDS/IPS gets policy-relevant segments (edge zones, critical services)
- APM gets filtered business flows (key application VLANs/ports)
What your NPB does here:
- Aggregate multiple links into tool feeds (multi-link aggregation is a core reason for NPB)
- Replicate traffic to multiple tools based on rules
- Load-balance outputs while keeping sessions (if your NDR is clustered)
2. Data center east-west visibility (Leaf/Spine/ToR)
Goal: Catch lateral movement, service-to-service issues, microservice anomalies.
Where to connect:
- ToR ↔ leaf uplinks (often 25G)
- Leaf ↔ spine (100G/400G in modern designs)
The background deck calls out why this is hard: full-duplex and multi-link aggregation drive the need for purpose-built visibility infrastructure.
Recommended tool bundle:
- NDR cluster (session consistency matters)
- APM for service performance (filtered subset)
- Optional PCAP recorder if policy requires retention/audit trails (common in regulated industries)
NPB responsibilities:
- Many-to-one aggregation and one-to-many replication modes
- Flow steering by five-tuple / fields
- Tunnel-aware steering if VXLAN/GRE exists (see Giant 662 features below)
3. Branch / campus edge monitoring
Goal: Monitor WAN egress, VPN, and key outbound services without redesign.
Where to connect:
- Campus aggregation ↔ WAN router
- WAN router ↔ firewall
- Firewall ↔ ISP
Recommended tool bundle:
- Lightweight IDS or NDR (depending on local availability)
- Central SIEM/SOC visualization (on-prem or local managed SOC)
- Optional APM for business-critical apps
NPB responsibilities:
- Provide the right subset to limited tool ports (common in smaller sites)
- Keep it operationally simple (clear "must-have vs optional" accessories)
Two "customer-level" reference designs
These are realistic patterns you can adapt. The exact brands of analysis tools differ by local market; the NPB is the abstraction layer that makes the integration stable.
Case 1 - Dual uplinks (active/standby) + multi-tool distribution (NDR + APM)
Profile (anonymous): regulated enterprise / public sector site with strict audit requirements.
Constraints:
- Local procurement allows NDR and APM appliances, but PCAP retention may be restricted/controlled.
- Auditors require the monitoring system to see traffic identical to production ("no omission/modification").
Design:
- Two 100G uplinks from edge to core (active/standby or ECMP)
- TAP (or inline+ bypass if mandated) feeds NPB
- NPB outputs: Full feed → NDR (session-consistent load-balance if clustered) Filtered business-app subset → APMOptional mirrored subset for IDS
Example port plan:
- Input: 2 × 100G (QSFP28) from TAPs
- Output: 2 × 100G to NDR cluster (session keeping + LB)
- Output: 2 × 25G (SFP28) to APM (filtered)
Why this works:
- Avoids SPAN's burst-loss risk and error-frame filtering concerns in sensitive environments
- Gives APM only what it can process (protecting tool performance)
Case 2 - Many 10/25G links aggregated into one tool port (tool ports are scarce)
Profile (anonymous): manufacturing/campus + small DC. The local market only offers a limited number of high-speed tool ingest ports.
Constraints:
- The tool (e.g., DPI probe or NDR sensor) only has 1-2 high-speed ingest ports.
- Network has multiple 10/25G segments that must be observed.
Design:
- Multiple 10/25G TAPs feed NPB
- NPB performs: Aggregation (many-to-one) Filtering and packet slicing to reduce tool load Replication of specific subsets to different tools
The deck explicitly frames aggregation as solving the "one probe per link" bottleneck.
Example port plan:
- Input: 12 × 25G (SFP28)
- Output: 1 × 100G (QSFP28) to a single high-speed tool port (or 4×25G breakout depending on the tool)
- Secondary output: 2 × 10G to IDS for critical VLANs only
Which model fits which deployment?
1. NSComm Giant 662 - Best for mixed 10/25G edges with 100G uplinks
- Port mix: 48 × 1/10/25G + 8 × 40/100G
- Breakout: 100G can split into 4×10G or 4×25G
- Traffic processing: tagging, aggregation, filtering, replication, copy-to-multiple-output, load-balancing output
- Classification: by input interface, five-tuple, fixed fields
- Tunnel support: GTP/GRE/VXLAN with inner IP steering and tunnel header stripping
- Ops/management: CLI, Web, SNMP
Use it when: campus edge, ToR visibility, many 25G feeds into a smaller number of tool ports.
2. NSComm Giant 663 - Best for high-density 100G environments
- Port density: 32 × 40/100G ports
- Breakout: supports 4×10/25G via breakout mode
- Performance claim: full-duplex line-speed processing with zero packet loss at full line speed
- Monitoring modes: aggregation, replication, uplink/downlink separation, load-balanced source-destination split outputs
- Management: CLI/web/SNMP
Use it when: data center cores, multiple 100G links, you need dense 100G tool connectivity.
3. NSComm Giant 674 - Best when you need 400G evolution and session-keeping load balance
- Ports: 24 × 40/100G + 8 × 100/400G
- Breakout: 400G can split into 4×100G (and 100G can split into 4×10/25G)
- Wire-speed claim: full-duplex wire-speed without packet loss
- Session-aware distribution: supports aggregation/distribution with "user session" integration and session-keeping load balancing output
- Tunnels: supports GTP/GRE and inner-layer distribution
- Management: CLI/Web/SNMP
Use it when: you're moving to 400G, or your NDR tool cluster requires session-keeping load-balanced feeds at very high rates.
"Must-have vs optional" supporting upgrade lists
Access-side checklist (capture layer)
| Item | Must-have | Optional | Why it matters |
| TAP modules / access method | ✅ | Determines integrity of visibility; TAP/NPB is positioned as a deterministic solution vs mirror limitations | |
| Inline bypass appliance | ✅ | For inline designs to preserve link continuity even if the box loses power | |
| Mirror port planning (if SPAN) | ✅ | Minimizes risk, but still cannot guarantee completeness under burst/congestion | |
| Direction separation (uplink/downlink) design | ✅ | Needed because full-duplex traffic is harder for ordinary capture tools to collect consistently |
NPB-side checklist (broker layer)
| Item | Must-have | Optional | Notes |
| Correct port mix (10/25/100/400G) | ✅ | Choose based on tool ingest + capture links (see model section) | |
| Replication / filtering / aggregation | ✅ | Core NPB value: aggregation, filtering, replication, load-balancing | |
| Session-keeping load-balance | ✅ | Especially for clustered NDR, highlighted as a monitoring mode | |
| Tunnel steering (VXLAN/GRE/GTP) | ✅ | Useful for DC overlays and mobile/telecom-style tunneling | |
| Management integration (CLI/Web/SNMP) | ✅ | Operational requirements for multi-site rollouts |
Tool-side checklist (deep analysis & visualization)
| Tool type | Must-have | Optional | What to confirm locally (availability/policy) |
| NDR / analytics | ✅ | Ingest port speed, clustering, session consistency needs | |
| IDS/IPS sensors | ✅ | Supported TAP/SPAN input modes, rule capacity | |
| DPI/protocol probe | ✅ | Regulatory fit, protocol support, local certification | |
| PCAP recorder / forensics | ✅ | Data retention laws, storage requirements, access control | |
| SIEM/SOC visualization | ✅ | Integration methods, local hosting constraints |
Quick Notes
Network-switch.com supplies multi-brand networking hardware and optics, with certified engineers supporting design-to-delivery. If you're planning an observability build, we can help validate port-speed matching, optics, and tool compatibility so your NPB deployment works cleanly in the real topology-before it hits production.
Did this article help you or not? Tell us on Facebook and LinkedIn . We’d love to hear from you!
