A mature enterprise packet analysis architecture does not wait for an incident before it begins collecting evidence. By combining network TAPs, a Gigamon GigaVUE visibility fabric, and continuous packet recording appliances, the network becomes a persistent flight recorder that can preserve and retrieve traffic from critical links long after an event has occurred.
The short answer
In an enterprise network equipped with Gigamon TAPs, network packet brokers, and continuous packet recording appliances, troubleshooting does not primarily depend on plugging a laptop into a switch or starting an ad hoc capture after an incident has already occurred.
Instead, the architecture creates a permanent observation layer:
Production links
|
v
Network TAPs and mirror sources
|
v
GigaVUE visibility fabric
|
+---- Full or selected packets ----> Packet recorder
|
+---- Sliced or filtered packets ---> NPM, APM, IDS, NDR
|
+---- Replicated traffic -----------> Additional tools
|
v
Search, analytics, and PCAP export
The goal is not merely to copy packets. The goal is to make the right packet data continuously available to the right tools without burdening production routers, switches, firewalls, or applications.
The complete architecture
10G, 25G, 40G, 100G, 400G and beyond
Passive optical TAP, active TAP, SPAN, ERSPAN, cloud mirroring
Aggregate, filter, replicate, deduplicate, slice, decapsulate, and load balance
Phase 1: Establish packet visibility
The first layer is the traffic access layer. It determines which network conversations can be observed and copied into the visibility fabric.
Common traffic sources include:
- Passive optical network TAPs
- Active optical or copper TAPs
- Bypass TAPs for inline security devices
- Switch SPAN sessions
- ERSPAN or other routed mirror technologies
- Virtual switch mirroring
- Cloud traffic mirroring
- Container and Kubernetes visibility sources
A mature design normally combines several of these sources. Critical physical links are often instrumented with permanent TAPs, while remote, virtual, and cloud workloads use the mirroring technology available in those environments.
What a network TAP does
A network TAP, or Test Access Point, is inserted into a physical network link and creates an out of band copy of the traffic crossing that link. The copied traffic is sent to monitoring ports and then into the packet visibility infrastructure.
A TAP is not a packet recorder and normally does not perform analytics. Its primary job is reliable traffic access.
| Function | Performed by TAP | Performed elsewhere |
|---|---|---|
| Copy traffic from the link | Yes | Not required |
| Filter and distribute packets | Usually no | Packet broker |
| Store packet history | No | Recording appliance |
| Analyze applications and threats | No | NPM, APM, IDS, or NDR |
A TAP only exposes traffic that crosses the instrumented link. It does not provide visibility into alternate paths, internal virtual switching, cloud traffic, or links that were never tapped.
Passive optical TAPs
A passive optical TAP uses an optical splitter to divide the incoming light between the production receiver and a monitoring output. It requires no electrical power and normally contains no active signal processing in the production path.
This provides several advantages:
- No software configuration
- No operating system or management plane
- No power requirement
- No ability for monitoring traffic to be transmitted back into the production link
- Very low operational complexity
However, inserting a passive TAP requires disconnecting and recabling the production link. That work normally requires a maintenance window unless the TAP was installed before the link entered service.
Passive TAPs also introduce optical loss. The production and monitoring receivers must both receive sufficient light after the split.
Active TAPs
An active TAP receives and regenerates the signal rather than relying only on a passive optical split. Active TAPs require electrical power and may include additional features such as media conversion, signal regeneration, aggregation, or failover behavior.
Active TAPs are commonly considered when:
- The optical power budget cannot support a passive split
- The monitored link uses copper
- The design requires media or distance conversion
- The link uses Twinax or another medium that cannot be passively split
- Signal regeneration is required
- An inline security appliance requires bypass protection
An active TAP is powered equipment and must be evaluated as part of the failure domain. Verify redundant power, fail open behavior, battery support, relay behavior, throughput limits, and what happens to production traffic during a hardware or power failure.
Fiber types and TAP selection
Selecting a TAP based only on link speed is not sufficient. The TAP must match the physical and optical characteristics of the production link.
Before ordering or installing a TAP, verify:
- Multimode or single mode fiber
- Exact transceiver standard
- Operating wavelength
- Connector type
- Duplex, parallel fiber, or bidirectional design
- Fiber strand count and polarity
- Production link speed
- TAP split ratio
- Production path insertion loss
- Monitoring path loss
Multimode fiber
Multimode fiber has a larger core and is generally used for shorter distances inside data centers, campus buildings, and wiring facilities.
| Fiber type | Core | Typical jacket | General use |
|---|---|---|---|
| OM1 | 62.5/125 micrometers | Orange | Legacy lower speed links |
| OM2 | 50/125 micrometers | Orange | Legacy 1G and limited 10G |
| OM3 | 50/125 micrometers | Aqua | 10G and parallel short range optics |
| OM4 | 50/125 micrometers | Aqua or violet | Higher performance short range links |
| OM5 | 50/125 micrometers | Lime green | Wideband multimode applications |
Common multimode optical standards include 1000BASE SX, 10GBASE SR, 40GBASE SR4, 100GBASE SR4, and newer short range variants. The supported distance depends on the exact standard and fiber grade.
Single mode fiber
Single mode fiber has a smaller core and is normally used for longer distance connections, data center interconnects, campus backbones, metro links, and many modern high speed deployments.
| Fiber type | Core | Typical jacket | General use |
|---|---|---|---|
| OS1 | Approximately 9/125 micrometers | Yellow | Indoor single mode installations |
| OS2 | Approximately 9/125 micrometers | Yellow | Campus, metro, data center, and long distance links |
Common single mode standards include 1000BASE LX, 10GBASE LR, 40GBASE LR4, 100GBASE LR4, 400GBASE LR4, and many wavelength division multiplexed designs.
A passive fiber TAP does not normally convert link speed or wavelength. The monitor output preserves the optical characteristics of the signal entering the splitter. The TAP and downstream optics must therefore support the exact production technology.
Duplex, parallel fiber, and bidirectional links
Traditional duplex links use one strand for each direction. Passive TAP monitor ports are usually transmit only and preserve the two traffic directions separately.
Endpoint A to Endpoint B ---> Monitor output A Endpoint B to Endpoint A ---> Monitor output B
Some 40G, 100G, 200G, 400G, and higher speed links use parallel lanes over MPO or MTP cabling. Those TAPs must match the connector gender, polarity method, fiber count, lane mapping, and transceiver standard.
Bidirectional optics transmit different wavelengths over the same strand. These links require a TAP designed for the wavelengths used by the transceivers. A conventional duplex splitter cannot be assumed to support a BiDi implementation.
Why full duplex capacity matters
A full duplex link can transmit at its rated speed in both directions at the same time.
10 Gbps from Endpoint A to Endpoint B + 10 Gbps from Endpoint B to Endpoint A = Potential 20 Gbps of copied traffic
Combining both directions onto one 10G monitoring interface creates a potential oversubscription condition. Separate monitor outputs preserve direction and allow the packet broker to receive both streams without forcing them onto one undersized interface.
Split ratios
A passive optical TAP divides the available light between the production output and the monitoring output. The ratio is normally written as network percentage followed by monitor percentage.
The correct split ratio is determined by the measured and specified optical power budget. A 70/30 split is not automatically safer because the monitoring receiver may not receive enough light. Gigamon specifically cautions against assuming that a 70/30 split is appropriate for 10G multimode links.
Optical power budget
A passive TAP consumes part of the optical margin already available on the link. The design must account for the production path and the monitoring path separately.
Power budget = transmitter output power - receiver sensitivity Total cable plant loss = fiber attenuation + connector loss + splice loss Available power margin = power budget - existing cable plant loss The TAP is acceptable only when the remaining margin supports: production path insertion loss monitor path loss additional patch cables and connectors engineering margin
Validate the design using actual transceiver specifications and measured optical levels whenever possible. Worst case IEEE values are useful for planning, but measured transmit and receive levels provide a stronger deployment baseline.
Check both minimum receiver sensitivity and maximum receiver input. Too little light can cause errors and link instability. Too much light can overload a receiver on some short single mode links.
Cabling discipline
Many TAP deployment failures are caused by cabling rather than the TAP itself.
During installation:
- Match fiber type and grade throughout the path
- Verify connector type and polarity
- Clean and inspect every optical connector
- Use tested patch cables
- Follow minimum bend radius requirements
- Protect unused ports with dust caps
- Label each traffic direction
- Document the network and monitor ports
- Record optical levels before and after the change
A production link can remain operational while the monitoring side is dark or receives only one direction. Successful link status is not proof that the visibility path is working correctly.
Enterprise TAP deployment best practices
Instrument critical links proactively
The strongest time to create an observation point is before an outage or security event. Critical links should be identified during architecture and capacity planning.
Common locations include:
- Internet edge connections
- WAN and data center interconnects
- Router to firewall links
- Firewall to internal network links
- Core and distribution uplinks
- Load balancer and application delivery links
- Critical server segments
- DMZ boundaries
- Cloud connectivity circuits
- High value east west traffic paths
The practical enterprise principle is not to TAP every interface indiscriminately. It is to install permanent traffic access at critical observation points and use SPAN, ERSPAN, virtual mirroring, or cloud traffic mirroring where physical TAPs are not practical.
Install TAPs during the original build
The best time to install a TAP is when the network link is first built. Retrofitting a TAP later may require a maintenance window, new cabling, rack work, optical validation, acceptance testing, and application coordination.
For a new data center, firewall refresh, WAN deployment, or network redesign, include the following in the low level design and bill of materials:
- TAP model and split ratio
- Fiber and connector type
- Rack and panel location
- Network side cable identifiers
- Monitor side cable identifiers
- Packet broker destination ports
- Optical budget calculations
- Baseline and post change optical measurements
Use TAPs and SPAN intentionally
TAPs and SPAN are not mutually exclusive.
| Source | Best use | Primary limitation |
|---|---|---|
| Physical TAP | Critical physical links and sustained visibility | Requires physical insertion and optical planning |
| SPAN | Temporary, remote, or low utilization observation points | May drop mirrored packets under congestion or platform pressure |
| ERSPAN | Transport mirrored traffic across a routed network | Adds encapsulation and consumes production bandwidth |
| Cloud mirror | Cloud native workloads and virtual interfaces | Provider coverage, cost, and feature constraints |
Connect TAPs to a visibility fabric
Connecting each TAP directly to one tool creates a rigid one to one design. A central packet broker allows the same observation point to support multiple current and future tools.
Rigid design: TAP ---> One tool Scalable design: TAPs and mirror sources ---> GigaVUE fabric ---> Many tools
This separation allows tools to be replaced, upgraded, moved, or load balanced without recabling the production link.
Document every observation point
Each TAP should appear in the physical and logical documentation. Record at least:
- Site, room, rack, and rack unit
- TAP model and serial number
- Production link endpoints and interfaces
- Link speed and optical standard
- Fiber type and connector type
- Split ratio
- Traffic direction for each monitor output
- Packet broker ports
- Optical levels before and after installation
- Installation date and change record
- Support and warranty information
Monitor the monitoring infrastructure
A healthy production link does not prove that packet visibility is healthy. Monitor:
- Packet broker port status
- Optical receive levels
- Input errors and dropped packets
- Oversubscription counters
- GigaSMART processing utilization
- Tool port utilization
- Recorder ingestion drops
- Storage capacity and retention depth
- Time synchronization
- Management platform availability
Phase 2: Control traffic with the packet broker
The raw copied traffic enters the GigaVUE network packet broker. This is the traffic control layer between the production observation points and the tools that consume packet data.
Without a packet broker, each tool would need direct access to each TAP or mirror source. That design creates cabling sprawl, duplicate feeds, tool overload, and limited flexibility.
Flow mapping and filtering
Administrators create traffic maps that select which packets are sent from network ports to tool ports.
Maps may match on:
- Source and destination IP addresses
- Source and destination ports
- Protocol
- VLAN
- MAC address
- Ingress TAP or mirror source
- Tunnel and encapsulation information
- Application identity when supported
For example, DNS traffic can be sent to an NDR platform, selected application traffic can be sent to an APM tool, and complete traffic from a critical data center link can be sent to a packet recorder.
Aggregation and replication
The packet broker can aggregate traffic from multiple observation points into a common tool feed. It can also replicate one packet stream to several tools.
Deduplication
The same packet may be observed at several points as it crosses the network. Sending every copy to the recorder wastes bandwidth and storage and can distort analysis.
When GigaSMART deduplication is enabled and correctly sized, the packet broker can identify redundant packet copies within a correlation window and forward a single copy to the destination tool.
Deduplication can reduce:
- Tool port utilization
- Recorder ingestion load
- Storage consumption
- Duplicate flows and conversations
Deduplication is not automatic in every design. Licensing, configuration, processing capacity, correlation timing, encapsulation, NAT, VLAN changes, and packet modification can affect the result.
Packet slicing
Packet slicing removes a portion of each packet before it is sent to a monitoring tool. This can greatly reduce downstream bandwidth and storage when large payloads are not required.
A sliced packet may retain:
- Ethernet and VLAN headers
- IP addresses and protocol fields
- TCP or UDP ports
- TCP flags
- Sequence and acknowledgment numbers
- Selected application header information
Slicing is useful for transport analysis, metadata generation, and tools that do not require the complete payload.
Once a packet is sliced, the removed bytes cannot be recovered. A sliced feed is not full packet capture and may be unsuitable for application troubleshooting, TLS handshake review, DNS response analysis, malware investigation, file reconstruction, or detailed forensics.
The stronger architecture sends different feeds to different tools:
Selected full packets ---> Packet recorder and forensic tools Sliced packets ---------> Performance and metadata tools Filtered packets --------> IDS, NDR, and specialized analytics
Other packet broker functions
Depending on the hardware, software, licenses, and design, a visibility fabric may also provide:
- Load balancing across multiple tool appliances
- Tunnel decapsulation
- Header stripping
- Packet masking
- Application aware filtering
- Metadata generation
- TLS decryption where authorized
- Traffic grooming and normalization
- Tool chaining and service insertion
Every transformation must be documented. A packet that has been sliced, masked, decapsulated, or modified is not identical to the original packet observed on the wire.
Phase 3: Continuous packet recording
The selected packet stream is sent from the GigaVUE tool ports to a dedicated recording appliance. Examples include platforms from NETSCOUT, Endace, LiveAction, and other purpose built packet capture vendors.
These appliances are designed to ingest, timestamp, index, store, search, and export high volumes of packet data.
High speed capture architecture
Depending on the vendor and model, a recorder may use:
- Hardware timestamping
- FPGA based capture adapters
- SmartNICs
- Direct Memory Access
- Kernel bypass
- Multiple receive queues
- Dedicated indexing engines
- Specialized packet processing hardware
These technologies reduce CPU overhead and help preserve packet timing at high packet rates. The exact hardware architecture and timestamp precision are vendor and model specific.
Storage architecture
Captured packets are written to a high throughput storage subsystem. The platform may use NVMe SSDs, SAS SSDs, SATA SSDs, high capacity hard drives, external shelves, or a hybrid storage design.
The storage system must sustain both the average and peak recording rate. Packet capture is typically written sequentially, while indexes and analytics metadata may create additional write and read activity.
Circular packet storage
Most continuous packet recorders operate as a circular buffer. New packet data is written until the configured storage threshold is reached. The system then progressively overwrites the oldest stored blocks.
The result is a rolling historical window rather than permanent storage.
Retention depends on:
- Average captured traffic rate
- Peak traffic rate
- Number of monitored links
- Filtering and deduplication
- Packet slicing
- Compression
- Usable storage capacity
- Index and metadata overhead
Retention must be calculated
Retention time = usable storage bytes / average captured bytes per second
For example, a sustained 100 Gbps packet stream represents approximately:
100 Gbps / 8 = 12.5 GB per second 12.5 GB per second x 86,400 seconds = approximately 1.08 PB per day
Recording an actual sustained 100 Gbps full packet stream for several days requires multiple petabytes of usable storage before overhead. This is why average traffic measurements, selective filtering, deduplication, and tiered recording policies are essential.
Interface speed is not the same as sustained captured traffic. Retention planning should use real utilization data, packet size distribution, growth assumptions, and the exact recorder overhead.
Phase 4: Retrieve and analyze historical traffic
The operational advantage of this architecture appears when an application owner reports a slowdown, timeout, reset, or intermittent failure that occurred hours earlier.
Step 1: Define the incident window
Collect the most precise information available:
- Date and time zone
- Start and end time
- Client IP address
- Server IP address
- Source and destination port
- Protocol or application
- Site, data center, VLAN, or cloud environment
- User or transaction identifier when available
A narrow time window and accurate endpoint information reduce the amount of data that must be searched and exported.
Step 2: Query the recording platform
The engineer uses the central web interface to search the appropriate recorder. Depending on the platform, the console may present:
- Conversations and packet counts
- Throughput and transaction volume
- TCP response time
- Retransmissions and duplicate acknowledgments
- TCP resets and failed connections
- Application errors
- Network and server delay indicators
- Packet loss indicators
Search speed depends on the time range, index design, packet volume, filter complexity, and storage load. A well indexed recorder can locate a narrow conversation far faster than manually opening a massive unfiltered capture.
Step 3: Extract the relevant packets
Once the correct conversation is found, the system creates a small packet segment containing only the matching traffic.
Instead of exporting terabytes of unrelated data, the engineer may retrieve:
- One client
- One server
- One application port
- One incident window
Step 4: Analyze in the platform or Wireshark
The targeted capture can be reviewed in the vendor console or exported as a standard PCAP or PCAPNG file.
Common findings include:
- Slow TCP connection establishment
- Retransmissions and packet loss
- Duplicate acknowledgments
- Out of order delivery
- Zero window conditions
- TCP resets
- DNS delays
- TLS negotiation failures
- Delayed server responses
- Application error responses
- MTU and fragmentation problems
- Asymmetric traffic visibility
- Firewall and load balancer session interruptions
The primary advantage is evidence preservation. The engineer analyzes the packets that existed during the incident rather than relying entirely on user descriptions, incomplete logs, or attempts to reproduce an intermittent problem.
Full packet capture versus flow and metadata
NetFlow, IPFIX, application telemetry, and packet metadata are valuable, but they are not the same as full packet capture.
| Data source | Best at answering | Does not always provide |
|---|---|---|
| Flow data | Who communicated, when, how much, and over which ports | Packet timing, TCP flags, retransmission details, payload |
| Packet metadata | Indexed conversations, protocol behavior, and selected application fields | Every original packet byte |
| Full packets | Detailed transport, protocol, and forensic reconstruction | Long retention without substantial storage |
The strongest operational model combines several telemetry types:
Packet data + Flow and metadata + Device telemetry + Application metrics + Logs and events
Security and privacy requirements
Continuous packet recording can expose sensitive information. The visibility platform should be treated as a high value security system.
Controls should include:
- Role based access
- Multifactor authentication
- Encryption for management and exported data
- Audit logging
- Segmentation of management interfaces
- Retention and deletion policies
- Approval for TLS decryption
- Payload masking where appropriate
- Restrictions on PCAP export
- Legal, compliance, and privacy review
Recording more data is not automatically better. The collection policy should align with troubleshooting, security, compliance, and privacy requirements.
Capacity planning checklist
| Layer | Validate |
|---|---|
| Traffic access | TAP placement, fiber type, optics, split ratio, optical levels, traffic direction |
| NPB ingress | Port speed, aggregate traffic, packet rate, burst behavior |
| NPB processing | Filtering, deduplication, slicing, tunnel processing, licensing, GigaSMART capacity |
| Tool ports | Oversubscription, load balancing, packet drops, link speed |
| Recorder | Sustained capture rate, packet rate, indexing performance, ingestion drops |
| Storage | Usable capacity, write rate, retention target, growth, overhead |
| Operations | Monitoring, alerting, time synchronization, access, documentation, support |
Common design mistakes
Recommended implementation sequence
The final architecture
Critical production links
|
v
Passive or active TAPs
SPAN, ERSPAN, virtual, and cloud mirrors
|
v
GigaVUE packet visibility fabric
|
+---- Full or selected packet feed ----> Continuous recorder
| |
| v
| Circular historical storage
| |
| v
| Search, analytics, PCAP export
|
+---- Filtered or sliced feeds ---------> NPM and APM tools
|
+---- Security feeds --------------------> IDS and NDR tools
|
+---- Replicated feeds ------------------> Additional consumers
The conclusion
The real value of a Gigamon based packet analysis architecture is not simply that it copies network traffic. Its value is that it creates a permanent and controllable observation layer across the enterprise.
Network TAPs provide reliable access to critical traffic. The GigaVUE packet broker aggregates and optimizes that traffic. Recording appliances preserve a rolling history. Analytics consoles and Wireshark allow engineers to retrieve and inspect the exact packets associated with an incident.
This changes the troubleshooting model:
The enterprise packet analysis architecture is a flight recorder for the network. Its success depends on correct observation point placement, optical engineering, packet broker capacity, recorder sizing, retention planning, operational monitoring, and disciplined access to sensitive packet data.
References
- Gigamon: Understanding Network TAPs, The First Step to Visibility
- Gigamon: Understanding Network TAPs, Part 3, Eight Best Practices
- Gigamon Network TAPs
- Gigamon GigaSMART Deduplication
- Gigamon GigaSMART Packet Slicing
// TAP the critical links. control the packet stream. record the evidence. retrieve the incident.