https://network-switch.com/pages/about-us
Introduction
In a leaf-spine data center, "the right" Network Packet Broker (NPB) is the one that can be proved in acceptance testing:
(1) high 100G density today,
(2) a clean path to 400G (including breakout),
(3) full-duplex wire-speed behavior,
(4) session-keeping load balancing for clustered NDR/DPI,
(5) VXLAN/GRE inner-header steering (not just outer UDP ports),
(6) a lossless verification plan with counters and repeatable tests.
Which companies offer NPB appliances for data center environments?
Instead of a single "company list," it helps to understand vendor archetypes-because you'll often be comparing an "observability fabric" platform against a "rack NPB," and their strengths differ.
A) Enterprise visibility / deep observability vendors
These vendors position NPB as part of a broader visibility/observability platform:
- Keysight offers network packet brokers and emphasizes line-rate performance with hardware acceleration and "no dropped packets" positioning.
- Arista DANZ Monitoring Fabric (DMF) describes itself as a next-generation NPB designed for pervasive visibility, multi-tenancy, and scale-out operations.
- Gigamon markets "next-generation network packet broker" capabilities like aggregation and load balancing to connect security/monitoring tools.
B) Data center monitoring fabric / tool-chain oriented NPBs
Some vendors focus heavily on data center monitoring use cases, higher-speed interfaces, and scale-up/scale-out architectures. (Depending on your region, you'll see different players in this category.)
C) Integrated TAP + NPB and pragmatic "visibility kits"
If you're building visibility from the ground up, you'll also see vendors that pair TAPs with NPB functionality:
- Garland Technology positions integrated TAP + NPB solutions for packet access and monitoring, emphasizing aggregation/filtering/load balancing without license/port fees.
D) Value-oriented, fast-to-buy options
If your goal is faster procurement and clearer "box pricing," value-focused vendors may show up in searches:
- Network-Switch.com(NSComm) publishes NPB content spanning 10G-400G and positions NPBs for aggregation/filtering/routing across multiple speeds for monitoring and troubleshooting.
How to use this section: shortlist vendors by deployment model (platform fabric vs rack appliance) and then decide by acceptance outcomes (Sections 2-4). "Company reputation" matters less than whether the box can be proven under peak traffic, overlays, and tool-chain constraints.
What a "top-rated" data center NPB must deliver?
The 6 capabilities that actually decide 100G/400G visibility outcomes
| Must-have capability | Why it matters in leaf-spine DC | What to verify in PoC / acceptance |
| 1) 100G port density | Your best capture points are often leaf↔spine, ToR uplinks, and DC edge-many are already 100G | Interface mix matches your capture map (how many links you truly need to tap/mirror) |
| 2) 400G evolution + breakout | 400G is not "one day"; it arrives gradually and often requires 400G→4×100G planning | Breakout support, cabling plan, tool-port readiness |
| 3) Full-duplex wire-speed | East-west traffic is bidirectional and bursty; a half-duplex assumption hides drops | Test both directions concurrently (peak + bursts) |
| 4) Session-keeping load balancing | NDR/DPI clusters need session consistency; splitting sessions breaks detections | Confirm session-keeping and verify "same session → same sensor node" |
| 5) VXLAN/GRE inner steering | Overlay is normal; steering by outer headers alone makes rules "not work" | Inner 5-tuple matching, tunnel awareness, rule hit counters |
| 6) Lossless verification plan | "No drops" must be proven at peak, during replication, across packet sizes | Counters at each hop + repeatable test flow + tool ingest validation |
Data center traffic reality: 3 traffic classes your NPB must handle
A leaf-spine data center is not a single "traffic problem." Your NPB selection should start with what you're trying to see.
1. East-West (service-to-service / lateral movement)
Where it lives: leaf↔spine links, ToR uplinks, VTEP-heavy segments.
Why it's hard: high fan-out, microbursts, lots of short-lived flows, and clustering requirements.
Tool profile: NDR cluster + APM + DPI; session consistency is often mandatory.
2. North-South (edge / ingress-egress)
Where it lives: DC edge, firewall/load balancer, inter-DC links, internet edge.
Why it's hard: policy and compliance often demand "no blind spots," and you may need full-fidelity capture for incident response.
Tool profile: IDS/NDR + SIEM + PCAP.
3. Overlay / Encapsulated traffic (VXLAN/GRE)
Where it lives: almost everywhere in modern multi-tenant DC fabrics.
Why it's hard: if your NPB can't steer by inner headers, your "application-based" steering becomes guesswork, and rules appear to fail.
Tool profile: NDR/DPI benefit the most from correct inner visibility.
DC visibility capacity budget formula
Most NPB buying mistakes come from one blind spot: replication multiplies traffic. In data centers, you rarely send "all traffic" to just one tool.
1. The formula
Visibility Capacity Budget = Input Peak × Replication Multiplier × Safety Margin
- Input Peak: peak rate at your capture points (not average).
- Replication Multiplier: how many output copies you create (NDR + IDS + APM + PCAP, etc.), after filtering/slicing.
- Safety Margin: typically 1.2-1.5 for bursts, headroom, growth, and imperfect traffic prediction.
2. Capacity budget worksheet
| Capture point | Link speed | Peak utilization (%) | Peak input (Gbps) | Outputs (tools) | Replication multiplier | Safety margin | Budgeted output (Gbps) | Tool-port plan (count × speed) |
| Leaf↔Spine #1 | 100G | 65% | 65 | NDR, IDS | 2.0 | 1.3 | 169 | 2×100G (or NDR cluster) |
| Leaf↔Spine #2 | 100G | 55% | 55 | NDR, APM | 2.0 | 1.3 | 143 | 1×100G + 4×25G |
| DC Edge | 100G | 40% | 40 | IDS, SIEM, PCAP | 3.0 | 1.4 | 168 | 1×100G + capture storage |
Leaf/Spine NPB insertion topology reference
100G vs 400G visibility evolution
100G → 400G Roadmap
| Stage | What's typical in the DC | NPB interface needs | Breakout strategy | Tool-port reality | What to plan early |
| Today (100G dominant) | Many leaf↔spine links at 100G | Dense 100G ports; strong filtering | Optional (100G→4×25G) | Tools often 10/25/100G mixed | Session LB, rule observability, peak budget |
| Transition (mixed 100/400) | First 400G spines/agg | Mix of 100G + some 400G | 400G→4×100G to match tools | Tools usually lag; clusters needed | Cabling/FEC consistency, breakout mapping, tool scaling |
| Target (400G mainstream) | High-density 400G core | 400G-ready NPB with robust observability | 400G→4×100G (and beyond) | Tools must be upgraded or scaled out | Tool refresh roadmap + capture storage strategy |
NSComm Giant 663 vs Giant 674
This section does not claim "best overall." It maps capabilities to the exact DC needs above-100G density vs 400G readiness and session consistency.
1. Giant 663 - 100G dense visibility for leaf-spine environments
If your DC is primarily 100G today and your biggest challenge is port density + line-rate behavior + tunnel steering, Giant 663 aligns with the "Tier 2 / 100G Dense Visibility" role:
- Interface profile: 32 × 40/100G (QSFP28).
- Positioning: full-duplex line-speed, "zero packet loss even at full line speed."
- Overlay relevance: supports tunnel protocols such as GTP/GRE and can steer based on inner-layer IP addresses.
Where it fits best:
- Leaf↔spine capture at 100G, feeding an NDR cluster and secondary tools (IDS/APM) with filtering and replication.
- Data centers where 400G is not yet required, but loss behavior at peak is a hard requirement.
2. Giant 674 - 400G-ready visibility plus session-keeping output
If you're planning for 400G adoption, or you have a larger NDR/DPI cluster where session consistency and high-speed uplinks drive the design, Giant 674 fits the "Tier 3 / 400G-ready Visibility Fabric" role:
- Interface profile: 24 × 40/100G + 8 × 100/400G.
- Breakout path: supports 400G to 4×100G breakout (useful for tool alignment).
- Positioning: "full-duplex wire-speed ... without any packet loss."
- Session consistency: "session keeping load balancing output."
- Overlay relevance: supports GTP/GRE and inner IP-based distribution.
Where it fits best:
- DC aggregation/core visibility where 400G uplinks are appearing, and you want a practical transition strategy using breakout while tools scale out.
- Environments where session-keeping must be explicitly guaranteed for NDR/DPI accuracy.
How to evaluate vendors fairly
If you only compare "port count and speed," vendors will all look similar. Use this DC-specific PoC checklist instead:
1. Lossless verification
- Test at peak rate and add bursts (microburst-like patterns).
- Include replication scenarios (one input to multiple outputs).
- Validate at three points: NPB input counters → NPB output counters → tool ingest counters.
2. Session consistency validation (for NDR/DPI clusters)
- Generate controlled bidirectional flows and confirm they stay on the same cluster node.
- Re-run with ECMP-like behavior (asymmetric paths often exist in real DCs).
3. Overlay steering validation (VXLAN/GRE)
- Validate that rules can match inner 5-tuple and that you have rule hit counters to prove behavior.
4. Operability / observability
- If you cannot see per-port utilization, drops, and rule hits, you are buying future downtime.
- Ensure you can export evidence for incident reports and change audits.
Conclusion (what to do next)
If you're buying a data center NPB, treat it like a visibility infrastructure layer-not a "mirror accessory." Your fastest path to a defensible choice is:
- Map capture points (leaf↔spine, ToR uplinks, edge).
- Run the capacity budget formula (Input Peak × Replication × Margin).
- Decide whether you're a 100G-dense DC (often a 663 fit) or 400G-evolving DC (often a 674 fit) based on tool readiness and session consistency needs.
- Write acceptance tests that prove loss behavior, session keeping, and overlay steering-then ask vendors to pass them.
If you're sourcing NPBs across regions, it helps to work with a distributor that can align optics, cabling, tool-port requirements, and acceptance testing.
Network-switch.com supplies multi-brand hardware and can help validate compatibility and deployment plans end-to-end.
Did this article help you or not? Tell us on Facebook and LinkedIn . We’d love to hear from you!
