Choose a packet broker by evidence risk. In Australian enterprise and data center environments, the broker is not just a port multiplier; it decides which packets reach IDS, NDR, packet capture, and forensic workflows during the incident you will later need to explain. The correct design documents feed priority, drop policy, tunnel handling, tool protection, and inline failure behavior before a purchase order is issued.
Quick Recommendation
| Need | Recommended fit | Why it fits |
|---|---|---|
| High-density data center | XS-PB-32X100-G1 | 32x 100G ports for large-scale traffic aggregation and distribution. |
| Enterprise campus | XS-PB-24X10G-4X100G-G1 | 24x 10G + 4x 100G for campus monitoring with mixed-speed tools. |
| Inline security | XS-PB-16X10G-BYPASS-G1 | 16x 10G with bypass for inline IPS deployments. |
How to Decide
| Design question | Accept when | Reject when |
|---|---|---|
| Can the broker drop packets? | Drop policy is documented by feed, tool, and traffic class, with counters visible to operators. | Drops are explained only as oversubscription or are invisible to incident review. |
| Can tools survive bursts? | Load balancing, packet slicing, and deduplication keep tool ports inside their tested limits. | One tool overloads while another eligible tool remains underused. |
| Can overlays be inspected? | VXLAN, VLAN, and encapsulation handling are tested against the monitoring tool parser. | Tunnel handling strips the context the security workflow needs. |
Choose high-port-count brokers for data centers
Data centers with many SPAN ports need brokers that can aggregate dozens of feeds and distribute them to multiple monitoring tools without oversubscription.
Choose bypass-enabled brokers for inline security
If deploying inline IPS or firewalls, bypass functionality ensures traffic continues flowing even if the security tool fails. This prevents single points of failure.
Engineering Acceptance Checkpoint
A packet broker is acceptable only if it preserves the evidence chain expected by the monitoring tools. Before procurement, run a 4 feed lab with mixed 10G and 100G ingress, at least 2 tool groups, a 30 minute oversubscription test, and one forced tool-port failure. Validate that packet slicing, timestamping, deduplication, tunnel handling, and load balancing do not hide the traffic needed by IDS, NDR, packet capture, or forensic workflows.
| Acceptance item | Evidence to collect | Reject condition |
|---|---|---|
| Packet integrity | Ingress and egress counters, drop counters, timestamp checks, and tool-side packet counts. | Unexplained packet loss, reordered evidence, or missing VLAN/VXLAN context. |
| Tool protection | Load-balance distribution, burst behavior, and failover logs for 2 monitoring tools. | One overloaded tool receives traffic while another eligible tool remains underused. |
| Inline failure behavior | Bypass transition timing, link state, and traffic continuity during a forced tool outage. | Traffic stops without an explicit policy decision or documented rollback path. |
Failure modes to watch
Packet brokers fail quietly when the monitoring design assumes every feed is equally important. In practice, mirror ports burst, tool ports saturate, timestamp settings drift, and tunnel traffic can be stripped of context. A good acceptance run proves which packets may be dropped, which must never be dropped, and how the operator will prove that decision after an incident review.
Tip: xSONiC packet brokers support advanced features like packet slicing, timestamping, and deduplication to optimize tool performance and reduce storage requirements.
Related Guides
- How to Choose a Data Center Switch - for spine-leaf and ToR switching in data center fabrics.