This chapter covers VPC Packet Mirroring in Google Cloud, a powerful feature for copying and analyzing network traffic without disrupting production flows. For the ACE exam, Packet Mirroring appears in roughly 3-5% of questions, often in scenarios involving security monitoring, compliance, or troubleshooting. Understanding how to configure, filter, and troubleshoot Packet Mirroring is essential for the 'Ensure Success' domain, specifically Objective 4.1 on traffic analysis.
Jump to a section
Imagine a library where a security camera is placed at the main entrance, recording every person who enters and exits. This camera does NOT stop anyone, does NOT check IDs, and does NOT alter the path of any visitor. It simply copies the visual data of each person passing through and sends that feed to a security monitor in a back office. The camera is connected via a splitter that duplicates the video signal without introducing any delay or interference to the original flow. In the same way, a VPC Packet Mirroring collector in GCP receives a copy of every packet that matches the mirroring filter, without affecting the original traffic. The library might have multiple cameras at different doors, each feeding into a central recording system, just as you can mirror traffic from multiple sources to a single collector. If the recording system goes down, the cameras keep working – the library doesn't close. Similarly, if the collector fails, mirrored packets are dropped silently, and the original traffic continues unimpeded. The security guard can later review the footage to analyze who entered at a specific time, analogous to using captured packets for forensic analysis or performance troubleshooting.
What is VPC Packet Mirroring?
VPC Packet Mirroring is a Google Cloud feature that clones the traffic of a specified source (a VM instance or a group of instances) and forwards the copies to a collector destination for analysis. The original traffic is never altered or delayed. This is analogous to a network tap in a physical data center, but implemented entirely in software within Google's Andromeda virtualization stack.
Why It Exists
Traditional network monitoring tools often require installing agents on VMs or using port mirroring on physical switches. In a cloud environment, you cannot physically cable a VM to a monitoring device. Packet Mirroring provides a native, agentless method to capture traffic for:
Intrusion detection systems (IDS)
Network forensics
Performance monitoring
Compliance auditing (e.g., PCI DSS, HIPAA)
Troubleshooting application behavior
How It Works Internally
Packet Mirroring operates within the Google Cloud virtual network infrastructure. When a packet is sent from a mirrored source VM, the Andromeda hypervisor (Google's network virtualization stack) intercepts the packet after the source VM's virtual NIC (vNIC) processes it, but before it is placed on the wire. The hypervisor creates an exact copy of the packet (including headers and payload) and encapsulates it in a GENEVE tunnel (Generic Network Virtualization Encapsulation, an IETF standard) before sending it to the collector. The original packet continues unmodified.
Key Components
Mirror Source: A Compute Engine VM instance or a group of instances identified by tags or a label expression. You can mirror all instances in a subnet or specific ones.
Mirror Collector: The destination for mirrored packets. This can be:
An internal load balancer (ILB) – typically used to distribute mirrored traffic across a fleet of analysis VMs.
A single VM instance (by specifying its internal IP).
A forwarding rule (e.g., for a network virtual appliance).
Mirror Filter: Defines which traffic is mirrored. Filters can be based on:
- IP protocol (TCP, UDP, ICMP, etc.) - Source and destination IP ranges - Source and destination port ranges - Traffic direction (INGRESS, EGRESS, or BOTH) - Mirror Policy: A resource that ties together the source, collector, and filter. Multiple policies can exist per VPC network.
Defaults and Limits
Maximum mirroring policies per VPC network: 100 (soft quota, can be increased).
Maximum sources per policy: 2000 VMs.
Maximum collectors per policy: 1.
Maximum filters per policy: 10 filter entries (each entry can have multiple conditions).
Mirrored traffic is not guaranteed delivery: If the collector is overwhelmed or unreachable, mirrored packets are dropped. The original traffic is never affected.
Supported VM types: Most general-purpose and memory-optimized machine types. Preemptible VMs are not supported as sources.
Encryption: Mirrored packets are not encrypted by default. If the collector is in a different VPC or on-premises, consider using VPN or Interconnect for secure transport.
Configuration and Verification Commands
To create a Packet Mirroring policy using gcloud:
gcloud compute packet-mirrorings create MIRROR_NAME \
--region REGION \
--collector-ilb COLLECTOR_ILB_URI \
--network NETWORK \
--mirrored-source-tags TAG \
--filter-direction BOTH \
--filter-ip-protocols TCP,UDP \
--filter-cidr-ranges 10.0.0.0/8To verify:
gcloud compute packet-mirrorings list
gcloud compute packet-mirrorings describe MIRROR_NAMETo check mirrored traffic statistics (e.g., dropped packets):
gcloud compute packet-mirrorings get-snapshot MIRROR_NAMEInteraction with Related Technologies
VPC Flow Logs: Packet Mirroring provides full packet payloads, while Flow Logs only contain metadata (5-tuple, packet count, bytes). Use Flow Logs for lightweight monitoring and Packet Mirroring for deep inspection.
Cloud NAT: Packets that are source NATed by Cloud NAT are mirrored before NAT translation – the mirrored packet shows the original private IP. After NAT, the packet's source IP changes, but the mirror copy already captured the original.
Internal Load Balancer (ILB): When using an ILB as collector, the ILB distributes mirrored packets to its backend VMs. The ILB must be in the same region as the mirror source.
Firewall Rules: Packet Mirroring copies traffic after firewall rules are evaluated. If a firewall rule blocks traffic, the blocked packet is still mirrored (the copy is taken before the drop decision). This allows monitoring of denied traffic.
Private Google Access: Mirrored traffic to Google APIs is not supported – you cannot mirror on-premises traffic that uses Private Google Access.
Performance Considerations
CPU overhead: The Andromeda hypervisor performs the mirroring, so there is minimal overhead on the source VM. However, the collector VMs must have sufficient capacity to process the mirrored traffic volume.
Bandwidth: Mirroring doubles the bandwidth consumed by mirrored flows within the VPC (original copy + mirrored copy). If you mirror all traffic, expect up to 2x network utilization on the path to the collector.
Dropped packets: If the collector cannot keep up, packets are dropped silently. Monitor the packet_mirroring_dropped_packets_count metric in Cloud Monitoring.
Security and Compliance
IAM permissions: To manage Packet Mirroring, you need compute.packetMirrorings.* permissions. The roles/compute.securityAdmin role includes these.
Audit logging: Creating, updating, or deleting a mirroring policy is logged in Cloud Audit Logs.
Data sensitivity: Mirrored packets may contain sensitive data. Ensure the collector is secured and access is restricted.
Identify Mirror Source(s)
Determine which VMs or groups of VMs you want to mirror. You can specify sources by instance tags (e.g., 'monitoring-target') or by a label expression (e.g., 'env=prod'). The source VMs must be in the same region as the mirroring policy. You can also mirror all instances in a subnet by specifying the subnet as the source. Note that you cannot mirror individual instances by name directly; you must use tags or labels.
Set Up the Collector
Configure the destination for mirrored packets. The collector can be an internal load balancer (ILB) with backend VMs running analysis software (e.g., Suricata, Zeek), or a single VM's internal IP. If using an ILB, ensure the ILB is in the same region and VPC as the source. The collector must be reachable from the source VPC. For high availability, use an ILB with multiple backend VMs.
Define Filter Criteria
Create a filter to select which traffic to mirror. Filters can include IP protocols (e.g., TCP, UDP), source and destination CIDR ranges, port ranges, and traffic direction (INGRESS, EGRESS, or BOTH). Filters are inclusive – only matching traffic is mirrored. If no filter is specified, all traffic is mirrored. Remember that filters apply to the original packet before any NAT or encapsulation.
Create the Mirror Policy
Use gcloud or the Cloud Console to create a packet mirroring policy. Specify the region, network, collector, source (tags or labels), and filter. The policy name must be unique per region. After creation, the policy starts mirroring traffic within minutes. There is no need to restart VMs. You can update the policy later to change sources or filters.
Verify and Monitor
After the policy is active, verify that mirrored packets are reaching the collector. Use tools like tcpdump on the collector to capture packets. Monitor Cloud Monitoring metrics such as 'packet_mirroring_dropped_packets_count' and 'packet_mirroring_forwarded_packets_count'. If packets are being dropped, increase collector capacity or narrow the filter. Also check that the collector's firewall rules allow mirrored traffic (GENEVE UDP port 6081).
Scenario 1: Security Monitoring for a Multi-Tier Web Application
A company runs a three-tier web application on Google Cloud: web servers, application servers, and database servers. The security team wants to monitor all traffic between the web and app tiers for signs of SQL injection or other attacks. They create a Packet Mirroring policy with the source being the app servers (tagged 'app-tier'), filter for TCP traffic on port 3306 (MySQL), and collector set to an internal load balancer distributing traffic to a fleet of IDS VMs running Suricata. The collector VMs are in a separate subnet with strict firewall rules only allowing GENEVE traffic (UDP 6081) from the VPC network. The team observes that during peak hours, the collector VMs experience high CPU and some packet drops. They scale the ILB backend to more VMs and also adjust the filter to exclude health check traffic (e.g., filter out source IPs 10.0.0.0/8 if health checks come from that range). This reduces the load and drops to zero.
Scenario 2: Compliance Auditing for Financial Services
A financial institution must retain network logs for seven years to comply with SEC regulations. They use Packet Mirroring to capture all traffic to and from a set of critical VMs that process trades. The mirrored traffic is sent to a collector VM that writes PCAP files to Cloud Storage. The filter is set to BOTH directions, all protocols. The collector VM is a high-memory instance with a large persistent disk for temporary buffering. The team uses a Cloud Function to periodically move completed PCAP files to a Nearline storage bucket, then delete old files after seven years. They also set up a Cloud Monitoring alert if the mirroring drop count exceeds 0.1% of total packets. One issue they encountered: when they migrated the collector to a different zone, they forgot to update the mirror policy's collector IP, causing all mirrored traffic to be dropped for 30 minutes. They now use an ILB as the collector to avoid this single point of failure.
Scenario 3: Troubleshooting Latency Issues
A SaaS provider experiences intermittent high latency for a subset of users. They suspect a misconfigured firewall or routing issue. They create a Packet Mirroring policy mirroring all traffic from the affected VMs to a collector running Wireshark. By analyzing the mirrored packets, they discover that a recent change to a load balancer's health check interval caused the load balancer to send excessive health check packets, which were being processed by the application server as legitimate traffic, causing CPU spikes. Without Packet Mirroring, they would have had to install agents on the VMs or rely on vague metrics. The ability to see the actual packets confirmed the root cause in minutes.
What the ACE Exam Tests
The ACE exam covers Packet Mirroring under Objective 4.1 (Ensure Success – Traffic Analysis). Expect 1-2 questions that test your understanding of:
The purpose and capabilities of Packet Mirroring (agentless, no performance impact on source)
How to configure a mirror policy (source, collector, filter)
The fact that mirrored traffic is encapsulated in GENEVE (UDP port 6081)
That Packet Mirroring does not affect original traffic – if the collector is down, packets are dropped silently
Differences between Packet Mirroring and VPC Flow Logs
Supported collector types: ILB or VM internal IP
That filters are inclusive and can be based on protocol, IP ranges, ports, and direction
Common Wrong Answers and Why
'Packet Mirroring can capture traffic to Google APIs (e.g., storage.googleapis.com).' – WRONG. Traffic to Google APIs is handled differently and cannot be mirrored. The exam may present this as a trick.
'Mirrored packets are guaranteed to be delivered.' – WRONG. There is no guarantee; packets can be dropped if the collector is overwhelmed.
'You can mirror traffic from a VM in one region to a collector in another region.' – WRONG. Both source and collector must be in the same region.
'Packet Mirroring uses VXLAN encapsulation.' – WRONG. It uses GENEVE (not VXLAN). The exam might list VXLAN as a distractor.
Numbers and Terms to Memorize
GENEVE UDP port: 6081
Maximum policies per VPC: 100 (default)
Maximum sources per policy: 2000
Filter fields: IP protocols, source/destination CIDR, ports, direction (INGRESS, EGRESS, BOTH)
Collector options: Internal Load Balancer (ILB) or VM internal IP
IAM role: roles/compute.securityAdmin (or custom with compute.packetMirrorings.*)
Edge Cases the Exam Loves
Preemptible VMs as source: Not supported. If a question asks about mirroring a preemptible VM, the answer is 'cannot be used as a source.'
Mirroring after firewall: Packets are mirrored before firewall drop decisions, so even blocked traffic is captured.
Multiple policies on same VM: If multiple policies match the same source, only one policy applies (the one with the most specific filter? Actually, behavior is undefined – avoid overlapping policies). The exam might test that you should design filters to avoid conflicts.
Collector in different VPC: The collector must be in the same VPC network. If using an ILB, it must be in the same VPC and region.
How to Eliminate Wrong Answers
If an answer says 'install an agent on the source VM' – eliminate it. Packet Mirroring is agentless.
If an answer says 'impact on source VM performance' – eliminate it. Mirroring is done by the hypervisor with negligible overhead.
If an answer mentions 'VPC Flow Logs' as a replacement for deep packet inspection – eliminate it. Flow Logs only have metadata.
If an answer says 'mirrored packets are encrypted by default' – eliminate it. They are not encrypted; you must use VPN/Interconnect if needed.
Packet Mirroring is agentless and does not impact source VM performance.
Mirrored packets are encapsulated in GENEVE on UDP port 6081.
Source and collector must be in the same region and VPC network.
Collector can be an internal load balancer (ILB) or a VM's internal IP.
Filters support IP protocol, CIDR ranges, ports, and direction (INGRESS, EGRESS, BOTH).
Mirrored packets are not guaranteed delivery – drops are silent.
Traffic to Google APIs (e.g., Cloud Storage) cannot be mirrored.
Preemptible VMs are not supported as mirror sources.
Maximum 100 mirror policies per VPC network (default quota).
Use Cloud Monitoring metrics to detect dropped mirrored packets.
These come up on the exam all the time. Here's how to tell them apart.
VPC Flow Logs
Captures only metadata (5-tuple, packet count, bytes, timestamps)
No payload captured
Sampling rate configurable (default 50%)
Low overhead, always on
Used for network monitoring, billing, and security analysis at flow level
VPC Packet Mirroring
Captures full packet payload (headers and data)
Provides deep packet inspection capability
No sampling – mirrors every matching packet
Requires a collector destination (ILB or VM)
Used for IDS, forensics, compliance, and detailed troubleshooting
Mistake
Packet Mirroring can capture traffic to and from Google APIs like Cloud Storage.
Correct
Traffic to Google APIs (e.g., storage.googleapis.com) is routed through Google's internal infrastructure and cannot be mirrored. Only traffic between VMs or between VMs and on-premises can be mirrored.
Mistake
Mirrored packets are guaranteed to be delivered to the collector.
Correct
There is no delivery guarantee. If the collector is unreachable or overwhelmed, mirrored packets are silently dropped. The original traffic is never affected.
Mistake
You can mirror traffic from a VM in one region to a collector in a different region.
Correct
Both the mirror source and collector must be in the same region. Cross-region mirroring is not supported.
Mistake
Packet Mirroring uses VXLAN encapsulation for mirrored packets.
Correct
Mirrored packets are encapsulated using GENEVE (Generic Network Virtualization Encapsulation) on UDP port 6081, not VXLAN.
Mistake
Packet Mirroring requires installing an agent on the source VM.
Correct
Packet Mirroring is completely agentless. The mirroring is performed by the Andromeda hypervisor at the virtual switch level, with zero configuration on the source VM.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but only if the collector is reachable from the source VPC. Typically, you would use VPC peering or Cloud VPN to connect the VPCs. However, the collector must still be in the same region as the source. Also, the collector's firewall rules must allow GENEVE traffic (UDP 6081) from the source VPC.
No, the mirroring is performed by the Andromeda hypervisor at the virtual switch level, not by the source VM. The source VM is unaware of the mirroring and experiences negligible overhead. The collector VM, however, may be impacted by the volume of mirrored traffic.
If the collector becomes unreachable, mirrored packets are silently dropped. The original traffic continues unaffected. You should monitor the 'packet_mirroring_dropped_packets_count' metric in Cloud Monitoring to detect such drops.
No, you cannot directly mirror traffic from a load balancer. You can only mirror traffic from Compute Engine VM instances. However, you can mirror the traffic to/from the backend VMs of a load balancer by setting those VMs as mirror sources.
No, Packet Mirroring does not provide guaranteed delivery. It is a best-effort service. For critical monitoring, ensure your collector is highly available (e.g., using an ILB with multiple backend VMs) and scale it to handle peak traffic. Consider using VPC Flow Logs as a complement for metadata-based monitoring.
Yes, you can mirror traffic from VMs in a managed instance group (MIG) by using instance tags or labels that are applied to the MIG template. The mirror policy will automatically include new VMs created by the MIG as long as they match the tag/label filter.
The default quota is 100 mirror policies per VPC network. You can request a quota increase through the Google Cloud Console. Additionally, each policy can have up to 2000 sources and 10 filter entries.
You've just covered Packet Mirroring and Traffic Analysis — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?