Lightweight cloud native traffic detection and protection engine configuration method

Abstract

A lightweight cloud native traffic detection and protection engine configuration method comprises the following steps: when an engine is started, creating a first veth device pair in a Pod of the engine; in the initial state of the Pod, creating a second veth device pair connected with the service workload pod and the virtual network bridge; after the Pod enters the protection mode, creating a third veth device pair in a service workload pod namespace; and copying the traffic to a target interface after matching the traffic by using a traffic mirroring technology. According to the invention, the engine is deployed on each node of the cloud native environment, the data path of the container is changed, then the serial detection of the working load and Pod in the cloud native environment is realized through veth and tc, and if the flow is threatened, a protection function is adopted.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing and network security technology, and more specifically, to a lightweight cloud native traffic detection and protection engine configuration method. Background Art

[0002] With the rapid development of information technology, the network environment is becoming increasingly complex, and network security threats are constantly evolving. Traditional IDS / IPS devices are mostly based on hardware implementations. When faced with growing network traffic, their processing capabilities gradually become a bottleneck. At the same time, the configuration and policies of traditional network security devices are relatively fixed, making it difficult to adapt to dynamically changing network architectures such as cloud-native environments.

[0003] Cloud-native architectures are characterized by containerization, microservices, continuous delivery, and dynamic orchestration, enabling enterprises to build, deploy, and manage applications more efficiently. Container orchestration platforms such as Kubernetes have become key infrastructure for cloud-native environments, and a large number of workloads are run on cloud platforms in a containerized form. This architecture brings higher resource utilization, faster application deployment, and better scalability, but it also introduces new security challenges. In a cloud-native environment, the communication patterns between workloads are more complex and diverse. The frequent creation, destruction, and migration of containers lead to dynamic changes in network topology, and traffic paths are difficult to predict. In addition, the microservice architecture allows applications to be split into multiple small services, with frequent interactions between services and more dispersed traffic distribution, which increases the difficulty of traffic detection and management. For example, a typical microservice application may contain dozens or even hundreds of microservices, and the communication traffic between each microservice needs to be effectively detected and protected to ensure the security of the entire application.

[0004] The cloud-native environment emphasizes efficient resource utilization and rapid response, so the traffic detection and protection engine needs to be lightweight and able to detect and protect traffic in real time without occupying too many system resources. At the same time, it should have efficient packet processing capabilities to cope with the high concurrency and low latency traffic requirements in the cloud-native environment.

[0005] Therefore, the problems existing in the prior art need to be further improved and developed. Summary of the invention

[0006] (I) Purpose of the invention: In order to solve the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide a lightweight cloud-native traffic detection and protection engine configuration method, which can realize real-time detection and protection of traffic in a cloud-native environment without occupying too many system resources.

[0007] (II) Technical solution: In order to solve the above technical problems, this technical solution provides a lightweight cloud native traffic detection and protection engine configuration method, which specifically includes: Step 1: When the engine starts, create the first veth device pair in the engine's Pod; Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge; Step 3: After the Pod enters protection mode, create a third veth device pair in the business workload pod namespace; Step 4: Use traffic mirroring technology to match the traffic and copy the traffic to the target interface.

[0008] Preferably, the engine in step 1 is deployed in a DaemonSet manner, a Pod exists in each node of the engine, and a first veth device pair is created in the namespace of the pod of the engine: vth and vbr.

[0009] Preferably, a tc qdisc is set in the ingress direction of the vbr, and the tc qdisc is an ingress qdisc, in order to subsequently hang a tc filter to achieve traffic replication.

[0010] Preferably, the step 3 specifically comprises the following steps: Step 301: Change the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, and for the vex- <pid>- Set a temporary MAC address for eth0; Step 302: Create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1, which will be the vex- <pid>-Set the IP and MAC addresses of eth0 to the vin- <pid>-eth1; Step 303: Move the vex and vin to the network namespace of the container where the engine is located, and set the MAC address of the vex to the new eth0 MAC address. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair. Step 304: Set tc qdisc on the vex interface and the vin interface respectively, and allocate two MAC addresses: ucmac and bcmac according to the index of the vex interface.

[0011] Preferably, step 301 and step 302 are used to implement the exchange between the original veth interface and the new veth interface of the container Pod, thereby exporting the traffic of the container Pod to the engine and implementing the isolation of the container Pod.

[0012] Preferably, the tc qdisc set on the vex interface and the vin interface are both ingress qdiscs to achieve traffic replication.

[0013] Preferably, the step 4 specifically includes: Step 401: Execute the first tc filter command to process the inbound traffic of the target container; Step 402: Execute the second tc filter command to process the outbound traffic of the target container; Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the vbr for subsequent detection.

[0014] Preferably, the first tc filter command includes two commands, CMD-1 and CMD-2; after the commands are executed by the CMD-1 and CMD-2, a part of the traffic entering the container is directed to the vbr interface of the engine through unicast, and the rest directly enters the container through vin, and the replication of the traffic is in the form of "replication mirror".

[0015] Preferably, the second tc filter command includes two commands, CMD-3 and CMD-4; the CMD-3 corresponds to CMD-1, which is to add a tc filter on the vin interface to mirror the outgoing traffic of the container to vbr and vex respectively; the difference between the CMD-3 and CMD-1 is that CMD-3 needs to match whether the source MAC address of the data packet is the MAC address of the container, and after matching, the source MAC address of the data packet is modified through pedit to be the ucmac allocated in step 304.

[0016] Preferably, the third tc filter command includes two commands, CMD-5 and CMD-6; the CMD-5 and CMD-6 correspond to the CMD-1 and CMD-3, and the container Pod outbound / inbound traffic mirrored to the vbr is mirrored to vin and vex.

[0017] (III) Beneficial effects: The present invention provides a lightweight cloud native traffic detection and protection engine configuration method. First, the IDS / IPS engine is automatically deployed on each node of the cloud native environment through DaemonSet. When the workload (container) is in protection mode, the data path of the container is changed. Secondly, the workload and IDS / IPS Pod in the cloud native environment are connected in series through veth and tc, and the container is connected in series to the engine "device". The detection engine can capture the traffic of all protected containers on the vth interface. After the engine conducts in-depth analysis of the captured traffic, it performs detection. If it is found to be threatening traffic, it can take blocking measures to achieve protection functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic diagram of the steps of a lightweight cloud native traffic detection and protection engine configuration method of the present invention; Figure 2 It is the network namespace status after the engine is initialized; Figure 3 It is the veth device pair in the initial state of the workload Pod; Figure 4 This is a diagram of renaming the veth interface in the business workload Pod; Figure 5 This is a diagram of creating a new veth pair in the business workload Pod namespace; Figure 6 This is a diagram of moving the newly created veth pair in the container namespace to the engine namespace; Figure 7 This is a diagram of processing the inbound traffic mirroring of the target container; Figure 8 This is a diagram of processing the outbound traffic mirroring of the target container; Fig. 9 This is a schematic diagram to complete the entire process. DETAILED DESCRIPTION

[0019] The present invention is further described in detail below in conjunction with preferred embodiments. More details are elaborated in the following description to facilitate a full understanding of the present invention. However, the present invention can obviously be implemented in a variety of other ways different from the description. Those skilled in the art can make similar generalizations and deductions based on actual application situations without violating the connotation of the present invention. Therefore, the protection scope of the present invention should not be limited by the content of this specific embodiment.

[0020] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that the drawings are only examples and are not drawn to scale, and should not be used to limit the actual protection scope of the present invention.

[0021] A lightweight cloud-native traffic detection and protection engine configuration method, such as Figure 1 As shown, the specific steps include: Step 1: When the engine starts, create the first veth device pair in the engine's Pod.

[0022] Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge.

[0023] Step 3: After the Pod enters protection mode, create a third veth device pair in the business workload pod namespace.

[0024] Step 4: Use traffic mirroring technology to match the traffic and copy the traffic to the target interface.

[0025] More specifically, step 1 is as follows: when the engine starts, a first veth device pair is created in the Pod of the engine: vth and vbr.

[0026] Preferably, the engine in step 1 is deployed in DaemonSet mode, and there is a Pod on each node of the engine, such as Figure 2 As shown, vth and vbr are the first veth device pair created in the namespace of the engine's pod. A tc qdisc is set in the inlet direction of the vbr, and the traffic queuing problem in the namespace of the pod is controlled by the tc qdisc, thereby achieving precise control and management of network traffic.

[0027] The tc qdisc refers to the queuing rules of the TC subsystem. The ingress qdisc is set in the present invention. Its main purpose is to subsequently hang the tc filter to achieve traffic replication and reproduce the traffic of a certain network card to other network devices. When the data packet enters the network interface, the ingress qdisc will process the data packet. Since the ingress qdisc does not involve the queuing and dequeuing process of the data packet, it mainly controls the data packet through classification (classify) and filtering (filter). The ingress qdisc can add multiple filtering rules (filter), and each filter can perform specific operations on matching data packets, such as speed limit, marking, redirection, etc. The Pod is the smallest deployable unit that can be created and managed in the Kubernetes workload. It is a package of a group of containers that share storage and network. In this group of containers, there is a container called Sandbox (or pause) that is used to hold the namespace shared by this group of containers.

[0028] The namespace is a resource isolation mechanism provided by the Linux kernel, which is used to isolate the running environment of a process, including file system mount points, process IDs, networks, UTS names, etc. By using a namespace, a process with an independent running environment can be created, making it invisible to other processes and system resources. The relationship between the namespace and the Pod is a belonging relationship, for example, a Pod belongs to a certain namespace.

[0029] The TC subsystem refers to the Linux Traffic Control (TC) subsystem, which is used to supervise, classify, shape and schedule network traffic, and also processes packet content during the classification process by using filters and operations. The TC subsystem is implemented by using the tc qdisc queuing discipline.

[0030] The veth device pair refers to a virtual Ethernet device. Veth devices are always created in the form of an interconnected pair and are often used to act as tunnels between network namespaces, create bridges to network devices in another namespace, and can also be used as independent network devices.

[0031] More specifically, step 2 is as follows: in the initial state of the Pod, a second veth device pair connecting the business workload pod and the virtual bridge is created in the CNI plug-in: cni0 and eth0.

[0032] Preferably, in step 2, a second veth device pair is created through the CNI plug-in of Kubernetes: cni0 and eth0, such as Figure 3 As shown, the cni0 is a bridge device created by the CNI plug-in on the host, and the eth0 is a network interface in the workload Pod. The second veth device enables the control plane to finely control the protection mode of a workload Pod.

[0033] The control plane can be understood as a management end, which is generally implemented as a Web application. Since the control plane has collected all workload Pods of the monitored cluster, the control plane can communicate with the engine Pod deployed in the cluster to inform the engine of the objects that need to be protected, facilitating accurate traffic control.

[0034] The CNI (Container Network Interface) plug-in is a key component used by Kubernetes to implement container network functions. It defines the standard interface between the container runtime and the network plug-in, allowing different network solutions to be seamlessly integrated with Kubernetes and provide network connection and communication capabilities for containers. In a Kubernetes cluster, the CNI plug-in is responsible for creating and configuring network resources for Pods, including the important operation of creating veth device pairs.

[0035] Preferably, the step 3 is as follows: after the Pod enters the protection mode, a third veth device pair is created in the business workload pod namespace: eth1 and vin; the IP and mac address of the interface eth0 of the second veth device pair are set to the eth1 interface of the third veth device pair, and the traffic is directed to the vbr interface of the first veth device pair of the engine to isolate the Pod.

[0036] More specifically, the step 3 specifically includes the following steps: Step 301: Figure 4 As shown, change the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, abbreviated as vex. And for the vex- <pid>- Set a temporary MAC address for eth0.

[0037] Step 302: Figure 5 As shown, create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1,vin- <pid>-eth1 is abbreviated as vin. <pid>-Set the IP and MAC address of eth0 to the vin- <pid>-eth1.

[0038] The eth1 interface of the third veth device pair remains in the target container Pod namespace, while the original eth0 interface of the target container becomes vex and moves to the engine container. At this time, the target container Pod is isolated from the outside world. Since the detection engine will create a new veth device pair, one end of which is eth1. This new eth1 is placed in the business workload Pod namespace, and the other end remains in the engine namespace, called vin-eth1; the original eth0 of the container is moved to the namespace where the engine is located and becomes vex- <pid>-eth0. In this way, the engine can implement tc's traffic diversion strategy for vin and vex in its own namespace, so that the target container and the external traffic are connected in series on the engine device. That is, if the container is accessed from the outside at this time, the traffic will not be perceived by the application in the container. Similarly, the container cannot access external services.

[0039] More specifically, pid represents the unique identifier assigned by the engine to the container Pod.

[0040] like Figure 6 As shown, through the steps 301 and 302, the original veth interface of the container Pod and the new veth interface can be exchanged, so that the traffic of the container Pod can be exported to the engine, and the isolation of the container Pod can be achieved.

[0041] Step 303: Move the vex and vin to the network namespace of the container where the engine is located, and set the MAC address of the vex to the new eth0 MAC address. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair.

[0042] At this time, the vex- <pid>-The temporary MAC address of eth0 is no longer used.

[0043] Step 304: Set tc qdisc on the vex interface and the vin interface respectively to prepare for the subsequent addition of tcfilter. At the same time, according to the index of the vex interface, allocate two MAC addresses: ucmac and bcmac.

[0044] By adding the tc filter, the traffic of the business workload container Pod can be "connected in series" to the engine's vbr, thereby protecting the engine. The tc qdisc set on the vex interface and the vin interface are both ingress qdiscs, which can achieve traffic replication. When a data packet enters the network interface, the ingress qdisc processes the data packet. The ingress qdisc can add multiple filtering rules (filters), and each filter can perform specific operations on matching data packets, such as speed limiting, marking, redirection, etc.

[0045] The ucmac and bcmac addresses are mainly used to identify the Pod.

[0046] Preferably, the step 4 is as follows: using traffic mirroring technology, after matching the traffic, the traffic is copied to the target interface and circulated again in the Pod. It should be noted that the replication of the traffic is in the form of "copy mirror" rather than "move redirect".

[0047] More specifically, step 4 specifically includes the following steps: Step 401: Execute the first tc filter command to process the inbound traffic of the target container.

[0048] The first tc filter command includes two commands, CMD-1 and CMD-2. The CMD-1 is tc filteradd dev vex … protocol ip u32 match u8 0 1 at -14 match … action pedit … pipe action mirred egress mirror dev vbr. The overall description of the CMD-1 is “copy the unicast traffic with the destination address being the container MAC address to the vbr interface”. The CMD-2 is tc filter add dev vex …protocol all u32 match u8 0 0 action mirred egress mirror dev vbr vin. The “match u8 0 0” in the CMD-2 indicates equality, that is, all other traffic not matched in CMD-1 is copied to vin.

[0049] After the commands are executed by CMD-1 and CMD-2, part of the traffic entering the container is directed to the engine's vbr interface through unicast, and the rest directly enters the container through vin, such as Figure 7 shown.

[0050] The inbound traffic path of the container is the traffic from the host machine to the container. The container refers to the business workload container Pod, that is, the protected object. The host machine is used to carry the container and provide the container operating environment. It may be a virtual machine or a physical machine, and no specific restrictions are made here.

[0051] The CMD-1 and CMD-2 omit many details of the command line through the symbol "...". The two commands CMD-1 and CMD-2 add two filters in the inlet direction of the vex interface. After any data packet enters the tc subsystem of the device, it must be classified. The filter is a classification method used to determine which class the data packet will be placed in. Only the u32 classifier is used in the present invention. The "match u8 0 1 at -14 match" in the CMD-1 means "comparing the least significant bit of the first node of the MAC address with 1 and then with 0 after binary AND". If the result is 0, it indicates unicast traffic; the "match .." in the following "14match" indicates whether the destination MAC address of the matching data packet is the MAC address of the container. After all the above matches are hit, two actions are executed. The first "action pedit" means modifying the packet. The details omitted here indicate "modifying the destination MAC of the packet to the ucmac assigned in step 304", and the second "action mirred" means mirroring the traffic to the vbr interface.

[0052] Step 402: Execute the second tc filter command to process the outbound traffic of the target container.

[0053] The second tc filter command includes two commands, CMD-3 and CMD-4. The CMD-3 is tc filteradd dev vin … u32 match u8 0 1 at -14 match … action pedit … pipe action mirred egress mirror dev vbr. The CMD-3 corresponds to CMD-1, which is to add a tc filter on the vin interface to mirror the outgoing traffic of the container to vbr and vex respectively. The difference between the CMD-3 and CMD-1 is that CMD-3 needs to match whether the source MAC address of the data packet is the MAC address of the container. After matching, the source MAC address of the data packet is modified by pedit to the ucmac assigned in step 304. The CMD-4 is tc filter add dev vin … u32 match u8 0 0action mirred egress mirror dev vbr vex.

[0054] The CMD-3 and CMD-4 add two filters in the inlet direction of the vin interface respectively. Finally, the effects achieved by the CMD-3 and CMD-4 are as follows Figure 8 shown.

[0055] Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the vbr for subsequent detection.

[0056] The third tc filter command includes two commands, CMD-5 and CMD-6. The CMD-5 is tc filter adddev vbr ... u32 match ... action pedit ... pipe action mirred egress mirrordev vin. The CMD-6 is tc filter add dev vbr ... u32 match ... action pedit ...pipe action mirred egress mirror dev vex.

[0057] CMD-5 and CMD-6 correspond to CMD-1 and CMD-3. Their main purpose is to mirror the inbound and outbound traffic of the container Pod mirrored to vbr to vin and vex. The omitted details of "u32 match" indicate "matching whether the MAC address is ucmac", and the omitted details of "action pedit" indicate modifying the source / destination MAC address of the data packet to the MAC address of the container. Finally, the effects achieved by CMD-5 and CMD-6 are as follows: Fig. 9 As shown in the figure, the engine uses the veth device pair and tc traffic mirroring function to cleverly "connect" the Pod's traffic to the engine's vbr-vth device pair, thereby realizing traffic detection and blocking.

[0058] According to the definition of IPv4 protocol, IPv4 addresses are divided into three types: unicast, multicast and broadcast. The unicast traffic refers to the traffic with a unicast destination address in IP. The unicast is a point-to-point connection between the client and the server. The point-to-point means that each client receives a remote stream from the server. The unicast stream is sent only when the client makes a request.

[0059] After step 4, the isolation state of the container Pod in step 3 is released, and the communication of the external access to the business workload Pod can proceed normally.

[0060] It should be noted that in Figure 2-Figure 9 In the figure, double arrows represent the connection of veth devices; long dashed lines represent the data path of traffic or data packets flowing into the network; long and short dashed lines represent the data path of traffic or data packets flowing out of the network.

[0061] The present invention provides a lightweight cloud native traffic detection and protection engine configuration method. First, the IDS / IPS engine is automatically deployed on each node of the cloud native environment through DaemonSet. When the workload (container) is in protection mode, the data path of the container is changed. Secondly, the series connection between the workload and the IDS / IPSPod in the cloud native environment is realized through veth and tc, and the container is connected in series to the engine "device". The detection engine can capture the traffic of all protected containers on the vth interface. After the engine performs in-depth analysis on the captured traffic, it performs detection. If it is found to be threatening traffic, blocking measures can be taken to achieve protection functions.

[0062] The above content is an explanation of the preferred embodiments of the present invention, which can help those skilled in the art to more fully understand the technical solution of the present invention. However, these embodiments are merely illustrative, and it cannot be determined that the specific implementation methods of the present invention are limited to the description of these embodiments. For ordinary technicians in the technical field to which the present invention belongs, without departing from the concept of the present invention, several simple deductions and transformations can be made, which should be regarded as belonging to the protection scope of the present invention.< / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid>

Claims

1. A lightweight cloud native traffic detection and protection engine configuration method, characterized in that: Specifically include: Step 1: When the engine starts, create the first veth device pair in the engine's Pod; Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge; Step 3: After the Pod enters protection mode, create a third veth device pair in the business workload pod namespace; Step 4: Use traffic mirroring technology to match the traffic and copy the traffic to the target interface.

2. According to claim 1, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: The engine in step 1 is deployed in DaemonSet mode. There is a Pod on each node of the engine. The first veth device pair is created in the namespace of the engine pod: vth and vbr.

3. According to claim 2, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: A tc qdisc is set at the ingress direction of the vbr, where the tc qdisc is an ingress qdisc, in order to subsequently mount a tcfilter to implement traffic replication.

4. According to a lightweight cloud native traffic detection and protection engine configuration method according to claim 1, it is characterized in that: The step 3 specifically comprises the following steps: Step 301: Change the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, and for the vex- <pid> - Set a temporary MAC address for eth0;< / pid> < / pid> Step 302: Create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1, the vex- <pid>-Set the IP and MAC address of eth0 to the vin- <pid> -eth1;< / pid> < / pid> < / pid> Step 303: Move the vex and vin to the network namespace of the container where the engine is located, and set the MAC address of the vex to the new eth0 MAC address. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair. Step 304: Set tc qdisc on the vex interface and the vin interface respectively, and allocate two MAC addresses: ucmac and bcmac according to the index of the vex interface.

5. According to claim 4, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: Through step 301 and step 302, the original veth interface and the new veth interface of the container Pod are exchanged, so that the traffic of the container Pod is exported to the engine, and the isolation of the container Pod is achieved.

6. According to claim 4, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: The tc qdisc set on the vex interface and the vin interface are both ingress qdiscs, which implement traffic replication.

7. According to a lightweight cloud native traffic detection and protection engine configuration method according to claim 1, it is characterized in that: The step 4 specifically includes: Step 401: Execute the first tc filter command to process the inbound traffic of the target container; Step 402: Execute the second tc filter command to process the outbound traffic of the target container. Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the vbr for subsequent detection.

8. According to claim 7, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: The first tc filter command includes two commands, CMD-1 and CMD-2. After the commands are executed by CMD-1 and CMD-2, part of the traffic entering the container is directed to the vbr interface of the engine through unicast, and the rest directly enters the container through vin. The replication of the traffic is in the form of "mirror replication".

9. According to claim 7, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: The second tc filter command includes two commands, CMD-3 and CMD-4; CMD-3 corresponds to CMD-1, which is to add a tc filter on the vin interface to mirror the outgoing traffic of the container to vbr and vex respectively; the difference between CMD-3 and CMD-1 is that CMD-3 needs to match whether the source MAC address of the data packet is the MAC address of the container, and after matching, the source MAC address of the data packet is modified through pedit to the ucmac allocated in step 304.

10. A lightweight cloud native traffic detection and protection engine configuration method according to claim 1, characterized in that: The third tc filter command includes two commands, CMD-5 and CMD-6; CMD-5 and CMD-6 correspond to CMD-1 and CMD-3, and the container Pod outbound / inbound traffic mirrored to vbr is mirrored to vin and vex.

Images