Acerca de los flujos de tráfico
En esta página, se describe cómo los registros de flujo de VPC informan los registros de flujo para casos de uso comunes. Consulta las siguientes secciones para ver ejemplos de flujos de tráfico de muestra por medio de registros de flujo de VPC.
Flujos de VM
En las siguientes secciones, se incluyen ejemplos de cómo los registros de flujo de VPC toman muestras del tráfico que envían y reciben las instancias de máquinas virtuales (VM). Para obtener información sobre cómo los registros de flujo de VPC informan los registros de flujo de los Pods de Google Kubernetes Engine (GKE), consulta Flujos de GKE.
Flujos de VM a VM en la misma red de VPC
En los flujos de VM a VM en la misma red de VPC, los registros de flujo se informan
desde la VM que envía la solicitud y la VM que responde, siempre y cuando ambas VM estén en subredes que tengan
habilitados los registros de flujo de VPC. En este ejemplo, la VM 10.10.0.2 envía una solicitud con
1,224 bytes a la VM 10.50.0.2, que también se encuentra en una subred con el registro
habilitado. A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5,342 bytes. La solicitud y la respuesta se registran desde
ambas VM.
| Informe de la VM de solicitud (10.10.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| respuesta | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| Informe de la VM de respuesta (10.50.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes | Anotaciones |
| solicitud | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| respuesta | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
Flujos de VM a dirección IP externa
Para los flujos que pasan Internet entre una VM que está en una red de VPC y un extremo con una dirección IP externa, los registros de flujos se informan solo desde la VM que está en la red de VPC:
- Para los flujos de salida, los registros se informan desde la VM de la red de VPC que es el origen del tráfico.
- Para los flujos de entrada, los registros se informan desde la VM de la red de VPC que es el destino del tráfico.
En este ejemplo, la VM 10.10.0.2 intercambia paquetes por Internet con un
extremo que tiene la dirección IP externa 203.0.113.5. El tráfico de salida de 1,224 bytes que se envía de 10.10.0.2 a 203.0.113.5 se registra desde la VM de origen, 10.10.0.2. El tráfico de entrada de 5,342 bytes que se envía de 203.0.113.5 a 10.10.0.2 se registra desde el destino del tráfico, la VM 10.10.0.2.
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| solicitud | 10.10.0.2 | 203.0.113.5 | 1,224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| respuesta | 203.0.113.5 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* src_location.* |
Flujos de VM a VM para una VPC compartida
En los flujos de VM a VM en una VPC compartida, puedes habilitar los registros de flujo de VPC en la subred del proyecto host. Por ejemplo, la subred 10.10.0.0/20 pertenece a una red de VPC compartida que se define en un proyecto host. Puedes ver los registros de flujo de las VM que pertenecen a esta subred, incluidas las que se crean para proyectos de servicio. En este ejemplo, los proyectos de servicio se llaman “webserver” (servidor web), “recommendation” (recomendación), “database” (base de datos).
En los flujos de VM a VM, cuando ambas VM se encuentran en el mismo proyecto (o en el caso de una red compartida, en el mismo proyecto host) se le proporciona, al otro extremo de la conexión, las anotaciones para el ID del proyecto y datos similares. Si la otra VM se encuentra en un proyecto diferente, no se proporcionan las anotaciones para la otra VM.
En la siguiente tabla, se muestra un flujo que registra 10.10.0.10 o 10.10.0.20.
src_vpc.project_idydest_vpc.project_idson para el proyecto host porque la subred de VPC pertenece a él.src_instance.project_idydest_instance.project_idson para los proyectos de servicio porque las instancias pertenecen a ellos.
|
connection .src_ip |
src_instance .project_id |
src_vpc .project_id |
connection .dest_ip |
dest_instance .project_id |
dest_vpc .project_id |
|---|---|---|---|---|---|
| 10.10.0.10 | servidor web | host_project | 10.10.0.20 | recomendación | host_project |
Los proyectos de servicio no son propietarios de la red de VPC compartida ni tienen acceso a los registros de flujo de la red de VPC compartida.
Flujos de VM a VM para el intercambio de tráfico entre redes de VPC
A menos que ambas VM se encuentren en el mismo proyecto de Google Cloud, los flujos de VM para las redes de intercambio de tráfico se informan de la misma manera que en los extremos externos: la información del proyecto y otras anotaciones no se proporcionan a la otra VM. Si ambas VM se encuentran en el mismo proyecto, incluso en redes diferentes, sí se proporciona a la otra VM la información del proyecto y otras anotaciones.
En este ejemplo, las subredes de la VM 10.10.0.2 del proyecto analytics-prod y de la VM 10.50.0.2 del proyecto webserver-test se conectan a través del intercambio de tráfico de redes de VPC.
Si los registros de flujo de VPC están habilitados en el proyecto analytics-prod, el tráfico (1,224 bytes) que se envía de 10.10.0.2 a 10.50.0.2 se registra desde la VM 10.10.0.2, que es el origen del flujo. El tráfico (5,342 bytes) que se envía de 10.50.0.2 a 10.10.0.2 también se registra desde la VM 10.10.0.2, que es el destino del flujo.
En este ejemplo, los registros de flujo de VPC no se encuentran habilitados en el proyecto webserver-test, por lo que la VM 10.50.0.2 no realiza registros.
| reporter | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| fuente | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* src_vpc.* |
| destino | 10.50.0.2 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* |
Flujos de VM con Cloud Load Balancing
En el caso de los flujos a través de Cloud Load Balancing, los registros de flujo de VPC anotan el tráfico enviado a través de un balanceador de cargas de red de transferencia, un balanceador de cargas de red de proxy o un balanceador de cargas de aplicaciones. En los siguientes ejemplos, se supone que estos balanceadores de cargas están configurados como balanceadores de cargas internos.
Flujos de VM a VM a través de un balanceador de cargas de red de transferencia interno
Cuando agregas una VM al servicio de backend para un balanceador de cargas de red de transferencia interno, Google Cloud agrega la dirección IP del balanceador de cargas a la tabla de enrutamiento local de la VM. Esto permite que la VM acepte paquetes de solicitud con destinos establecidos en la dirección IP del balanceador de cargas. Cuando la VM responde, envía su respuesta de forma directa; sin embargo, la dirección IP de origen de los paquetes de respuesta está configurada en la dirección IP del balanceador de cargas, y no en la VM del balanceo de cargas.
Los flujos de VM a VM que se envían a través de un balanceador de cargas de red de transferencia interno se informan desde el origen y el destino.
| Según lo informado por la VM del cliente (192.168.1.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.* |
| respuesta | 10.240.0.200 | 192.168.1.2 | 5,342 |
dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.* |
| Según lo informado por la VM de backend (10.240.0.3) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes | Anotaciones |
| solicitud | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (todos los campos excepto url_map_name) |
| respuesta | 10.240.0.200 | 192.168.1.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (todos los campos excepto url_map_name) |
En la solicitud que el balanceador de cargas distribuye a la VM de backend, la dirección IP de origen se establece en la dirección IP de la VM del cliente. Esto significa que la VM de backend puede proporcionar información de src_instance y dest_instance sobre la VM del cliente. Sin embargo, a diferencia de la VM de backend, la VM cliente no puede agregar información src_instance ni dest_instance sobre la VM de backend a su informe porque envía la solicitud a la dirección IP del balanceador de cargas y recibe la respuesta de esta, no de la VM de backend.
Flujos de VM a balanceador de cargas de red de proxy interno y de VM a balanceador de cargas de aplicaciones interno
Las VMs cliente informan el tráfico que pasa a través de un balanceador de cargas de red de proxy interno o un balanceador de cargas de aplicaciones interno, siempre que la VM cliente esté en una subred que tenga habilitados los registros de flujo de VPC. Por ejemplo, una VM cliente con la dirección IP 10.10.0.2 envía una solicitud con 1,224 bytes al extremo del balanceador de cargas, 10.10.0.3. Luego, la solicitud llega a un backend. A su vez, el backend responde a la solicitud con una respuesta que contiene 5,342 bytes.
Tanto la solicitud como la respuesta se registran en la VM del cliente. Los registros de la VM cliente están disponibles en el proyecto de Google Cloud al que pertenece la VM.
| Informe de la VM cliente (10.10.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.10.0.2 | 10.10.0.3 | 1,224 |
src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.* |
| respuesta | 10.10.0.3 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (for Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.* |
Flujos de VM a VM a través de Private Service Connect
Para el tráfico de VM a VM a través de Private Service Connect, los registros de flujo de VPC toman muestras de flujos entre los consumidores de Private Service Connect y los servicios publicados.
Extremo de Private Service Connect a un servicio publicado
Los flujos de tráfico a los servicios publicados de Private Service Connect se informan desde las VMs del consumidor y del productor, siempre y cuando ambas VMs estén en subredes que tengan habilitados los registros de flujo de VPC. En este ejemplo, la VM de consumidor, 10.10.0.2, envía una solicitud con 1,224 bytes al extremo de Private Service Connect, 10.10.0.3. En la VPC del productor, la dirección IP de origen de la solicitud se traduce a una dirección IP en la subred de adjunto de servicio, que, en este ejemplo, es 10.40.0.2. La dirección IP de destino de la solicitud se traduce a la dirección IP del balanceador de cargas de red de transferencia interno, 10.50.0.3. Luego, la solicitud llega a la VM del backend, 10.50.0.2, que también se encuentra en una subred con el registro habilitado.
A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5,342 bytes. La solicitud y la respuesta se registran desde ambas VMs. Los registros de la VM de consumidor están disponibles en el proyecto de consumidor, y los registros de la VM de productor están disponibles en el proyecto de productor.
| Informe de la VM de consumidor (10.10.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.10.0.2 | 10.10.0.3 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| respuesta | 10.10.0.3 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| Informe de la VM de productor (10.50.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.40.0.2 | 10.50.0.3 | 1,224 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.* |
| respuesta | 10.50.0.3 | 10.40.0.2 | 5,342 |
src_instance.* src_vpc.* psc.reporter psc.psc_attachment.* |
Flujos de VM a API de Google
En el caso del tráfico de VM a las APIs de Google a través de la dirección IP externa de la VM, el Acceso privado a Google o un extremo de Private Service Connect, los registros de flujo de VPC anotan los registros de registro con información de la API de Google. En la siguiente sección, se proporciona un ejemplo de cómo los registros de flujo de VPC anotan registros de registro de una VM que accede a una API de Google global a través de un extremo de Private Service Connect.
De VM a API de Google global a través de Private Service Connect
Las VMs de consumidor informan los flujos de tráfico a una API de Google, siempre y cuando la VM esté en una subred que tenga habilitados los registros de flujo de VPC. En este ejemplo, la VM de consumidor, 10.10.0.2, envía una solicitud con 1,224 bytes al extremo de Private Service Connect, 10.10.110.10. La solicitud se reenvía al servicio de Google adecuado, por ejemplo, Cloud Storage. A su vez, Cloud Storage responde a la solicitud con una respuesta que contiene 5,342 bytes. La solicitud y la respuesta se registran desde la VM solicitante.
| Informe de la VM de consumidor (10.10.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.10.0.2 | 10.10.110.10 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.* |
| respuesta | 10.10.110.10 | 10.10.0.2 | 5,342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
Flujos de GKE
En las siguientes secciones, se incluyen ejemplos de cómo los registros de flujo de VPC toman muestras del tráfico de GKE desde y hacia los Pods.
Flujo de Pod a ClusterIP
En este ejemplo, el tráfico se envía desde el Pod cliente (10.4.0.2) a cluster-service (10.0.32.2:80). El destino se resuelve en la dirección IP del Pod del servidor si seleccionas (10.4.0.3) en el puerto de destino (8080).
En los bordes del nodo, el flujo se muestra dos veces con la dirección IP y el puerto traducidos. Para ambos puntos de muestreo, identificaremos que el Pod de destino respalda el servicio cluster-service en el puerto 8080 y anotamos el registro con los detalles del Service y los detalles del Pod. En caso de que el tráfico se enrute a un Pod en el mismo nodo, el tráfico no sale del nodo y no se muestrea en absoluto.
En este ejemplo, se encuentran los siguientes registros.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| SRC | 10.4.0.2 | 10.4.0.3 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.4.0.2 | 10.4.0.3 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
Flujos LoadBalancer externos de GKE
El tráfico de una dirección IP externa a un servicio de GKE (35.35.35.35) se enruta a un nodo en el clúster, 10.0.12.2 en este ejemplo, para el enrutamiento. De forma predeterminada, los balanceadores de cargas de red de transferencia externos distribuyen el tráfico entre todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta
Herramientas de redes fuera del
clúster.
El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2). Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. En caso de que el tráfico se enrute a un Pod en el mismo nodo, 10.4.0.3 en este ejemplo, el segundo salto no se registrará porque no sale del nodo.
El segundo salto se registra en los puntos de muestreo de ambos nodos. Para el primer salto, identificamos el Service según la IP del balanceador de cargas y el puerto del Service (80). Para el segundo salto, identificamos que el Pod de destino respalda el Service en el puerto de destino (8080).
En este ejemplo, se encuentran los siguientes registros.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| DEST | 203.0.113.1 | 35.35.35.35 | 1,224 |
src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.* |
| SRC | 10.0.12.2 | 10.4.0.2 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.0.12.2 | 10.4.0.2 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
Flujos de Ingress de GKE
Una conexión de una dirección IP externa a un destino de Ingress finaliza en el servicio de Cloud Load Balancing. La conexión se mapea a un Service NodePort, según la URL. Para entregar la solicitud, el balanceador de cargas (130.211.0.1) se conecta a uno de los nodos del clúster (10.0.12.2) para el enrutamiento a través del NodePort del Service. De forma predeterminada, cuando se crea un objeto Ingress, el controlador de Ingress de GKE configura un balanceador de cargas de HTTP(S) que distribuye el tráfico en todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta
Herramientas de redes fuera del clúster.
El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2).
Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. Para el primer salto, se identifica el Service según su NodePort (60000). Para el segundo salto, se comprueba que el Pod de destino respalde el Service en el puerto de destino (8080). El segundo salto se registra en los puntos de muestreo de ambos nodos.
Sin embargo, en un caso en el que el tráfico se enruta a un Pod en el mismo nodo (10.4.0.3), el segundo salto no se registra porque el tráfico no abandonó el nodo.
En este ejemplo, se encuentran los siguientes registros.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| DEST | 130.211.0.1 | 10.0.12.2 | 1,224 |
dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.* |
| SRC | 10.0.12.2 | 10.4.0.2 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.0.12.2 | 10.4.0.2 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
Flujos de Ingress de GKE mediante el balanceo de cargas nativo del contenedor
Las solicitudes de una dirección IP externa a un destino de Ingress que usa el balanceo de cargas nativo del contenedor finalizan en el balanceador de cargas. En este tipo de Ingress, los Pods son objetos principales para el balanceo de cargas.
Luego, se envía una solicitud desde el balanceador de cargas (130.211.0.1) de forma directa a un Pod seleccionado (10.4.0.2). Identificamos que el Pod de destino respalda al Service en el puerto de destino (8080).
En este ejemplo, se encuentra el siguiente registro.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| DEST | 130.211.0.1 | 10.4.0.2 | 1,224 |
dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
Pod al flujo externo
El tráfico de un Pod (10.4.0.3) a una IP externa (203.0.113.1) se modifica con el enmascaramiento de IP para que los paquetes se envíen desde la IP del nodo (10.0.12.2) en lugar de la dirección IP del Pod. De forma predeterminada, el clúster de GKE está configurado para enmascarar el tráfico a destinos externos. Para obtener más información, consulta
Agente de enmascaramiento de IP.
Si quieres ver las anotaciones de Pod de este tráfico, puedes configurar el agente de enmascaramiento para que no enmascare las direcciones IP de los Pods. En ese caso, para permitir el tráfico a Internet, puedes configurar Cloud NAT, que procesa las direcciones IP del Pod. Para obtener más información acerca de Cloud NAT con GKE, consulta la interacción de GKE.
En este ejemplo, se encuentra el siguiente registro.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Anotaciones |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |
Flujos de conectividad híbrida
En el caso del tráfico entre Google Cloud y redes locales, los registros de flujo de VPC anotan los flujos entre instancias de VM, incluidas las instancias que se usan como nodos de GKE, y los extremos locales, entre las APIs de Google y los extremos locales, y el tráfico de tránsito entre los extremos locales. En el siguiente ejemplo, se describe cómo los registros de flujo de VPC anotan los flujos entre instancias de VM en una red de VPC y un extremo local.
Para flujos entre una VM que está en una red de VPC y un extremo local con una dirección IP interna, los registros de flujo se informan solo desde Google Cloud. Los siguientes recursos informan registros de flujo:
- La VM Genera informes de registros de flujo si la subred a la que está conectada la VM tiene habilitados los registros de flujo de VPC.
- La puerta de enlace que conecta la red de VPC al extremo local Genera informes de registros de flujo si la puerta de enlace tiene habilitados los registros de flujo de VPC.
En el diagrama anterior, el extremo local 10.30.0.2 envía una solicitud con 1,224 bytes a la VM 10.0.0.2 en la red de VPC a través de Cloud Interconnect. A su vez, la VM 10.0.0.2 responde a la solicitud con una respuesta que contiene 5,243 bytes. La solicitud y la respuesta se registran desde el adjunto de VLAN para Cloud Interconnect y la VM.
| Según lo informado por el adjunto de VLAN | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.30.0.2 | 10.10.0.2 | 1,224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| respuesta | 10.10.0.2 | 10.30.0.2 | 5,342 |
reporter src_instance.* src_vpc.* dest_gateway.* |
| Informe de la VM de solicitud (10.10.0.2) | ||||
|---|---|---|---|---|
| solicitud/respuesta | connection.src_ip | connection.dest_ip | bytes_sent | Anotaciones |
| solicitud | 10.30.0.2 | 10.10.0.2 | 1,224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| respuesta | 10.10.0.2 | 10.30.0.2 | 5,342 |
reporter src_instance.* src_vpc.* dest_gateway.* |