My test setup uses two m5.4xlarge instances to generate a single unidirectional flow of UDP packets from one instance to another at a fixed speed. I have a Traffic Mirror session configured to Mirror all traffic from the instance generating the test traffic. The mirror sends traffic to a third instance (m5zn.2xlarge) which is monitoring the VXLAN mirrored packets. The m5.4xlarge has a min network adapter capacity of 5Gbps and the m5zn.2xlarge has a min network capacity of 10Gbps. Test traffic is a single flow of mixed size UDP traffic averaging 450Bytes. The three instances are in the same region, VPC, and subnet. Using CloudWatch, I monitored NetworkPacketsSkipMirrorIn and NetworkPacketsSkipMirrorOut and compared them to the actual count of packets sent. All network packets were delivered, but I observed the following % packet losses with the mirrored packets:
- 750 Mbps (1.5 Gbps w/Mirrored Traffic) - 0.4% NetworkPacketsSkipMirrorIn+Out
- 1000 Mbps (2.0 Gbps w/Mirrored Traffic) - 1.74% NetworkPacketsSkipMirrorIn+Out
- 1250 Mbps (2.5 Gbps w/Mirrored Traffic) - 6.4% NetworkPacketsSkipMirrorIn+Out
- 1500 Mbps (3.0 Gbps w/Mirrored Traffic) - 12.85% NetworkPacketsSkipMirrorIn+Out
Is this normal? Is there a practical limit to the amount of traffic that can be mirrored in a given Traffic Mirroring session or in a given VPC? Could it be related to using only a single unidirectional flow in my test? I understand that mirrored traffic is the first to be dropped when there is congestion. Can the amount of congestion be measured somehow? Is there a way I can get some additional insight into what is causing the high SkipMirror packet counts?
AWS UFFICIALEAggiornata 2 anni fa