Packet Mirroring is a Google Cloud service that copies network traffic from your VMs and sends the mirrored packets to your own security appliances for inspection. To build this system, you design a collection infrastructure that uses a regional internal passthrough Network Load Balancer as the main entry point for the mirrored traffic.
The infrastructure for collecting mirrored traffic sits in a producer network. The central piece is a mirroring deployment, which is a zonal resource that connects to a forwarding rule on an internal passthrough Network Load Balancer. This load balancer acts as the front door, distributing the incoming mirrored traffic to a group of your own collector virtual machines (VMs) in a backend instance group. It is critical that this load balancer is created with the Packet Mirroring feature enabled on its forwarding rule; any regular, non-mirrored traffic sent to this load balancer is automatically dropped.
Configuring an internal passthrough Network Load Balancer for Packet Mirroring has specific, unchangeable requirements. The forwarding rule must have the Packet Mirroring feature enabled when it is created. The load balancer must be in the same Google Cloud region as the source VMs you are mirroring. The backend service must use a session affinity setting of NONE (which uses a 5-tuple hash) and must have a feature called backend subsetting turned off. The only supported backend type is an instance group; you cannot use a network endpoint group (NEG) for this purpose.
For mirrored traffic to flow correctly, you must set up VPC firewall rules. Rules must allow your collector VMs to receive traffic from the IP address ranges of all the source VMs being mirrored. You also need rules that permit health check traffic from Google Cloud's own systems to reach your collector instances. These health check IP ranges are 130.211.0.0/22 and 35.191.0.0/16 for IPv4, and 2600:2d00:1:b029::/64 for IPv6. These rules ensure the load balancer can monitor collector health and that the mirrored packets can be delivered.
A Packet Mirroring policy defines exactly which traffic gets copied and sent to your collectors. You create these policies by specifying the source VMs to mirror and then applying fine-grained filters based on IP addresses, protocols, and traffic direction.
You select which VMs to mirror by defining sources in the policy rules. Sources can be specified by subnet, by network tags on the VMs, or by individual VM network interfaces. If a VM has multiple network interfaces, only the interface in the network where the policy applies is mirrored unless another policy is created for the other interfaces. The destination for this mirrored traffic is a forwarding rule on an internal passthrough Network Load Balancer, which then passes the traffic to your collector instances.
Within a policy, mirroring rules let you filter traffic very precisely. You can filter based on source and destination IP addresses (using CIDR ranges), protocols, and destination port ranges. You can choose to mirror traffic or explicitly exclude it from mirroring using mirror or do-not-mirror actions. Since mirroring works on a per-session basis, you can configure rules to capture only one direction of a communication (ingress or egress) or both, depending on your security needs.
Google Cloud offers two types of packet mirroring: VPC Packet Mirroring and the newer Network Security Integration Packet Mirroring. It is important to know that Network Security Integration Packet Mirroring always takes precedence over VPC Packet Mirroring. If a VM is configured with both, the Network Security Integration configuration is used, and any VPC Packet Mirroring rules for that VM are ignored. This can have major implications; for example, if you were using VPC Packet Mirroring to capture ICMP traffic for troubleshooting and then apply a Network Security Integration policy that only mirrors HTTP, the ICMP mirroring will stop.
On the producer side (where your collectors are), mirroring deployments are zonal resources linked to a load balancer's forwarding rule. These deployments can be grouped into a mirroring deployment group for easier management. On the consumer side (where your source VMs are), you create a mirroring endpoint group and associate it with your VPC network. This association is essential—without linking your VPC network to a mirroring endpoint group, any mirroring rules you create will be ignored and no traffic will be sent for inspection.
Several key limitations govern Packet Mirroring. The only supported load balancer type is an internal passthrough Network Load Balancer with an instance group backend. You cannot use Packet Mirroring with regional network firewall policies. Each load balancer forwarding rule can only be linked to one mirroring deployment, and a single VPC network can be associated with at most one mirroring endpoint group. Importantly, when mirroring is enabled, the original and copied packets are processed at a slower rate, which depends on the VM's machine type, packet size, and CPU use. Due to this slower processing, enabling mirroring is not recommended for third-generation machine families and later, as it cancels out their high-bandwidth networking advantages.
Once Packet Mirroring is running, you must monitor its performance, scale your collector capacity, and troubleshoot any issues. This involves using Google Cloud's monitoring tools to track traffic volume and ensure your collector appliances are not overwhelmed.
Packet Mirroring is an out-of-band technology, meaning it copies packets at the hypervisor level without interfering with the original traffic path to your applications. It captures full packet data for analysis without blocking or altering live communications. However, this copying does consume additional resources. The mirrored traffic counts against the source VM's egress bandwidth and requires extra CPU processing. For example, a VM with 1 Gbps of incoming and 1 Gbps of outgoing traffic will generate 2 Gbps of mirrored traffic, resulting in a total of 3 Gbps of egress from the VM's perspective, which can slow down processing if the VM's limits are reached.
Your collector infrastructure must be sized to handle the total volume of mirrored traffic. Collectors are typically VMs in a managed instance group (MIG) behind the internal load balancer. Mirrored traffic is encapsulated using the Geneve protocol over UDP port 6081, which adds overhead. To prevent fragmentation, your entire VPC network path must support a larger Maximum Transmission Unit (MTU), up to 8896 bytes. You should design your collector backend to scale automatically using the MIG's auto-scaling features, adding more collector VMs as traffic volume increases. Using precise traffic filters in your mirroring policies is crucial to avoid sending unnecessary traffic and overloading your collectors.
You use Cloud Monitoring to watch key metrics like mirrored packet volume, load balancer connection counts, and backend collector health. If your collector VMs become saturated—often due to high CPU usage—they may start dropping incoming UDP packets on port 6081, creating gaps in your security monitoring. By comparing the volume of traffic leaving your source VMs against the volume arriving at your collectors, you can identify bottlenecks and verify that auto-scaling is working to prevent packet loss.
When troubleshooting, verify that your mirroring policy and collector load balancer are in the same region. Confirm that the load balancer's forwarding rule was created with Packet Mirroring enabled, that its backend service uses NONE session affinity, and that backend subsetting is disabled. A unique behavior to note is that if a collector instance fails its load balancer health check, Google Cloud will continue to send mirrored traffic to it. Finally, to prevent loops, Google Cloud automatically excludes traffic from being mirrored on the network interfaces that belong to the collector VMs themselves.
StudyCerts
StudyCertsNONE session affinity.Network Security Integration Packet Mirroring is a newer service that offers more granular filtering (like destination port ranges) and always takes precedence over the older VPC Packet Mirroring. If both are configured for a VM, only the Network Security Integration rules are applied.
The Packet Mirroring feature on a forwarding rule cannot be added or changed after the rule is created. This design ensures the load balancer is dedicated solely to handling mirrored Geneve-encapsulated traffic and will drop any standard traffic sent to it.
Packet Mirroring copies packets at the hypervisor level, which consumes additional CPU resources on the source VM and counts the mirrored copy against the VM's egress bandwidth. This can lead to slower packet processing if the VM's network or CPU limits are saturated.
First, use Cloud Monitoring to compare source egress volume against collector ingress volume to confirm saturation. Then, ensure your collector managed instance group is configured for auto-scaling based on CPU utilization or custom metrics, and verify your network path supports the larger MTU required for Geneve encapsulation.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills