Encadenamiento de servicios de Contrail con CSRX
El encadenamiento de servicios es el concepto de reenviar el tráfico a través de varias entidades de red en un orden determinado y cada entidad de red realiza funciones específicas, como firewall, IPS, TDR, LB, etc. La manera heredada de realizar el encadenamiento de servicios sería utilizar dispositivos de HW independientes, pero esto hace que el encadenamiento de servicios sea inflexible, costoso y prolongado los tiempos de establecimiento. En las funciones de red de encadenamiento de servicios dinámicos se implementan como una VM o un contenedor y se pueden encadenar automáticamente de forma lógica. Por ejemplo, en la Figure 1 se utiliza contrail para encadenar servicios entre dos pods en dos redes distintas mediante un – servidor de seguridad cSRX de nivel 4 contenedor para proteger el tráfico entre ellos.
Aquí se utilizan redes a la izquierda y a la’derecha para simplificar la simplicidad, para seguir el flujo de izquierda a derecha, pero puede utilizar sus propios nombres de Course. Asegúrese de configurar la red antes de conectar una caja Pod o de lo contrario no se creará el conjunto Pod.
Cómo reunir los pods de cliente y CSRX
Supongamos que’s crear dos redes virtuales usando este archivo YAML:
Verify using Kubectl:
Es’una buena costumbre confirmar que estas dos redes se encuentran ahora en contrail antes de continuar. En la Contrail UI, seleccione configurar redes > redes > > de dominio predeterminado en la Figure 2que se centra en la red de la izquierda.
Si usa el espacio de nombres predeterminado en el archivo YAML de una red, lo creará en el dominio predeterminado del dominio y el proyecto K8S-default.
Crear pods de cliente
Ahora,’permita que s cree dos pods de Ubuntu, uno en cada red con el siguiente objeto de anotación:
#left-ubuntu-sc.yaml apiVersion: v1 kind: Pod metadata: name: left-ubuntu-sc labels: app: webapp-sc annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "vn-left" }]' spec: containers: - name: ubuntu-left-pod-sc image: contrailk8sdayone/ubuntu securityContext: privileged: true capabilities: add: - NET_ADMIN #right-ubuntu-sc.yaml apiVersion: v1 kind: Pod metadata: name: right-ubuntu-sc labels: app: webapp-sc annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "vn-right" }]' spec: containers: - name: ubuntu-right-pod-sc image: contrailk8sdayone/ubuntu securityContext: privileged: true capabilities: add: - NET_ADMIN # kubectl create -f right-ubuntu-sc.yaml # kubectl create -f left- ubuntu-sc.yaml # kubectl get pod NAME READY STATUS RESTARTS AGE left-ubuntu-sc 1/1 Running 0 25h right-ubuntu-sc 1/1 Running 0 25h # kubectl describe pod Name: left-ubuntu-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 03:40:20 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.10.10.1", "mac": "02:7d:b1:09:00:8d", "name": "vn-left" }, { "ips": "10.47.255.249", "mac": "02:7d:99:ff:62:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-left" }] Status: Running IP: 10.47.255.249 Containers: ubuntu-left-pod-sc: Container ID: docker://2f9a22568d844c68a1c4a45de4a81478958233052e 08d4473742827482b244cd Image: contrailk8sdayone/ubuntu Image ID: docker-pullable://contrailk8sdayone/ubuntu@sha256:fa2930cb8f4b766e5b335dfa42de510ecd30af6433ceada14cdaae8de9065d2a ...<snipped>... Name: right-ubuntu-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 04:09:18 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.20.20.1", "mac": "02:89:cc:86:48:8d", "name": "vn-right" }, { "ips": "10.47.255.252", "mac": "02:89:b0:8e:98:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-right" }] Status: Running IP: 10.47.255.252 Containers: ubuntu-right-pod-sc: Container ID: docker://4e0b6fa085905be984517a11c3774517d01f481fa 43aadd76a633ef15c58cbfe Image: contrailk8sdayone/ubuntu Image ID: docker-pullable://contrailk8sdayone/ubuntu@sha256:fa2930cb8f4b766e5b335dfa42de510ecd30af6433ceada14cdaae8de9065d2a ...<snipped>...
Crear cSRX Pod
Ahora cree un Juniper cSRX contenedor que tenga una interfaz en la red de la izquierda y otra en la red correcta, con este archivo YAML:
Confirme que la ubicación de la interfaz está en la red correcta:
# kubectl describe pod csrx1-sc Name: csrx1-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 03:40:31 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.10.10.2", "mac": "02:84:71:f4:f2:8d", "name": "vn-left" }, { "ips": "10.20.20.2", "mac": "02:84:8b:4c:18:8d", "name": "vn-right" }, { "ips": "10.47.255.248", "mac": "02:84:59:7e:54:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-left" }, { "name": "vn-right" } ] Status: Running IP: 10.47.255.248 Containers: csrx1-sc: Container ID: docker://82b7605172d937895269d76850d083b6dc6e278e41cb45b4cb8cee21283e4f17 Image: contrailk8sdayone/csrx Image ID: docker://sha256:329e805012bdf081f4a15322f994e5e3116b31c90f108a19123cf52710c7617e ...<snipped>...
Cada contenedor cuenta con una interfaz que pertenece a una red predeterminada para todo el clúster, independientemente de la utilización del objeto Annotations porque el objeto Annotations anterior crea y coloca una interfaz adicional en una red específica.
Comprobar PodIP
Para verificar el podIP, inicie sesión en el encajador izquierdo, pord y el cSRX para confirmar las direcciones IP/MAC:
# kubectl exec -it left-ubuntu-sc bash root@left-ubuntu-sc:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 13: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:7d:99:ff:62:8d brd ff:ff:ff:ff:ff:ff inet 10.47.255.249/12 scope global eth0 valid_lft forever preferred_lft forever 15: eth1@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:7d:b1:09:00:8d brd ff:ff:ff:ff:ff:ff inet 10.10.10.1/24 scope global eth1 valid_lft forever preferred_lft forever # kubectl exec -it right-ubuntu-sc bash root@right-ubuntu-sc:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:89:b0:8e:98:8d brd ff:ff:ff:ff:ff:ff inet 10.47.255.252/12 scope global eth0 valid_lft forever preferred_lft forever 25: eth1@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:89:cc:86:48:8d brd ff:ff:ff:ff:ff:ff inet 10.20.20.1/24 scope global eth1 valid_lft forever preferred_lft forever # kubectl exec - it csrx1-sc cli root@csrx1-sc> root@csrx1-sc> show interfaces Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 100 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:71:f4:f2:8d, Hardware address: 02:84:71:f4:f2:8d Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 200 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:8b:4c:18:8d, Hardware address: 02:84:8b:4c:18:8d
A diferencia de otros pods, el’cSRX no adquirió IP con DHCP, y comienza con la configuración predeterminada de fábrica, por lo que es necesario configurarlo.
De forma predeterminada, cSRX eth0 solo es visible desde el Shell y se utiliza para la administración. Al conectar redes, la primera red conectada se asigna a eth1, que es GE-0/0/1, y la segunda adjunta se asigna a eth2, que es GE-0/0/0.
Configurar IP cSRX
Configure esta configuración básica en el cSRX. Para asignar la dirección IP correcta, utilice la asignación dirección MAC/IP de la kubectl describir la salida del comando Pod, así como para configurar la Directiva de seguridad predeterminada con el fin de permitir todo esto por ahora:
set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/24 set interfaces ge-0/0/0 unit 0 family inet address 10.20.20.2/24
set security zones security-zone trust interfaces ge-0/0/0 set security zones security-zone untrust interfaces ge-0/0/1 set security policies default-policy permit-all commit
Compruebe la dirección IP asignada en el cSRX:
root@csrx1-sc> show interfaces Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 100 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:71:f4:f2:8d, Hardware address: 02:84:71:f4:f2:8d
Logical interface ge- 0/0/1.0 (Index 100) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.10.10.0/24, Local: 10.10.10.2
Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 200 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:8b:4c:18:8d, Hardware address: 02:84:8b:4c:18:8d
Logical interface ge- 0/0/0.0 (Index 200) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.20.20.0/24, Local: 10.20.20.2
Una prueba de ping en el conjunto Pod izquierdo fallaría debido a que no hay ruta:
Agregue una ruta estática a los pods izquierdo y derecho y, a continuación, intente hacer ping de nuevo:
El ping sigue fallando, ya que’no creamos el encadenamiento de servicios, que también se ocupará de la ruta. Veamos’qué ha ocurrido con nuestros paquetes:
No’hay ninguna sesión en el cSRX. Para solucionar el problema de ping, inicie sesión en el nodo de cálculo cent22 que hospeda este contenedor para volcar el tráfico mediante TShark y Compruebe la ruta. Para obtener la interfaz que vincula los contenedores:
[root@cent22 ~]# vif -l Vrouter Interface Table Flags: P=Policy, X=Cross Connect, S=Service Chain, Mr=Receive Mirror Mt=Transmit Mirror, Tc=Transmit Checksum Offload, L3=Layer 3, L2=Layer 2 D=DHCP, Vp=Vhost Physical, Pr=Promiscuous, Vnt=Native Vlan Tagged Mnp=No MAC Proxy, Dpdk=DPDK PMD Interface, Rfl=Receive Filtering Offload, Mon=Interface is Monitored Uuf=Unknown Unicast Flood, Vof=VLAN insert/strip offload, Df=Drop New Flows, L=MAC Learning Enabled Proxy=MAC Requests Proxied Always, Er=Etree Root, Mn=Mirror without Vlan Tag, Ig=Igmp Trap Enabled ...<snipped>... vif0/3 OS: tapeth0-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.252 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10760 bytes:452800 errors:0 TX packets:14239 bytes:598366 errors:0 Drops:10744 vif0/4 OS: tapeth1-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.1 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13002 bytes:867603 errors:0 TX packets:16435 bytes:1046981 errors:0 Drops:10805 vif0/5 OS: tapeth0-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.249 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10933 bytes:459186 errors:0 TX packets: 14536 bytes:610512 errors:0 Drops:10933 vif0/6 OS: tapeth1-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.1 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:12625 bytes:1102433 errors:0 TX packets:15651 bytes:810689 errors:0 Drops:10957 vif0/7 OS: tapeth0-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.248 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:20996 bytes:1230688 errors:0 TX packets:27205 bytes:1142610 errors:0 Drops:21226 vif0/8 OS: tapeth1-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.2 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13908 bytes:742243 errors:0 TX packets:29023 bytes:1790589 errors:0 Drops:10514 vif0/9 OS: tapeth2-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.2 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:16590 bytes:1053659 errors:0 TX packets:31321 bytes:1635153 errors:0 Drops:10421 ...<snipped>...
Tenga en cuenta que vif0/3 y vif0/4 están enlazados con el POD derecho y ambos vinculados con tapeth0-89a4e2 y tapeth1-89a4e2 respectivamente. Lo mismo se dirige al conjunto Pod izquierdo para Vif0/5 y Vif0/6 mientras que Vif0/7, VIF 0/8 y Vif0/9 se enlazan con cSRX1. También puedes ver el número de paquetes o bytes que se han encontrado en la interfaz, así como el VRF. VRF 3 es para la red de clústeres predeterminada, mientras VRF 6 es para la red izquierda y VRF 5 es para la red correcta. En la ilustración 10,3, puede ver la asignación de interfaz desde todas las perspectivas (contenedor, Linux, VR-Agent).
’Intente hacer ping de nuevo al conjunto Pod derecho desde la caja de la caja de la izquierda y utilice TShark en la interfaz de TAP del encajador adecuado para realizar una inspección más detallada:
Parece que ping’no me llega al encajado adecuado, deje que’visite la cSRX’en la interfaz de red izquierda:
Podemos ver el paquete pero no hay nada en el cSRX posibilidad de seguridad de quitar este paquete
Para comprobar la tabla de enrutamiento de la red VRF a la izquierda, inicie sesión en el contenedor vrouter_vrouter-agent_1 del nodo de cálculo:
[root@cent22 ~]# docker ps | grep vrouter 9a737df53abe ci-repo.englab.juniper.net:5000/contrail-vrouter-agent:master-latest "/entrypoint.sh /usr…" 2 weeks ago Up 47 hou rs vrouter_vrouter-agent_1 e25f1467403d ci-repo.englab.juniper.net:5000/contrail-nodemgr:master-latest "/entrypoint.sh /bin…" 2 weeks ago Up 47 hou rs vrouter_nodemgr_1 [root@cent22 ~]# docker exec -it vrouter_vrouter-agent_1 bash (vrouter-agent)[root@cent22 /]$ (vrouter-agent)[root@cent22 /]$ rt --dump 6 | grep 10.20.20. (vrouter- agent)[root@cent22 /]$
Tenga en cuenta que 6 es el cuadro de enrutamiento VRF de la red de la izquierda; lo mismo en la tabla de enrutamiento adecuado de la red, pero falta una ruta:
Por lo tanto, incluso si todos los pods están hospedados en los mismos nodos de computación, éstos no se pueden’comunicar entre sí. Y si estos pods se alojan en distintos nodos computacionales, usted tiene un problema mayor. El encadenamiento’de servicios no es suficiente para ajustar las rutas en los contenedores, sino también para intercambiar rutas entre el vRouter entre los nodos de cálculo, independientemente de la ubicación del conjunto Pod (así como el ajuste automático si la caja Pod se movió a otro nodo de cálculo). Antes de que labbing encadenamiento’de servicios permita abordar una preocupación importante para los administradores de red que no son aficionados a este tipo de… solución de problemas de CLI, puede hacer lo mismo con la solución de problemas de la interfaz gráfica de usuario del controlador contrail.
Desde la interfaz de usuario del controlador de Contrail, seleccione supervisar enrutadores virtuales > > de infraestructura y, a continuación, seleccione el nodo que aloja la caja Pod, en nuestro caso cent22. local, como se muestra en la siguiente captura de pantalla, en la Figure 4.
La Figure 4 muestra la ficha interfaz, que equivale a ejecutar el comando VIF-l en el contenedor vrouter_vrouter-Agent-1, pero muestra incluso más información. Observe la asignación entre el identificador de instancia y la denominación de la interfaz de punteo, donde los seis primeros caracteres del identificador de instancia siempre se reflejan en nombre de interfaz de punteo.
Somos Cowboys de GUI. ’Seleccione las tablas de enrutamiento de cada VRF desplazándose a la ficha rutas y seleccione el VRF que desea ver, como en la Figure 5.
Seleccione la red de la izquierda. El nombre es más largo porque incluye el dominio (y Project). Puede confirmar que no hay un prefijo 10.20.20.0/24 de la red correcta. También puede comprobar el dirección MAC aprendidos en la red de la izquierda seleccionando L2, la interfaz gráfica de usuario equivalente al comando de puente de la familia RT--dump 6.
Encadenamiento de servicios
Ahora vamos’a s a utilizar el encSRX al encadenamiento de servicios mediante la interfaz gráfica de usuario de comandos de contrail. El encadenamiento de servicios consta de cuatro pasos que deben llevarse a cabo en orden:
- Crear una plantilla de servicio;
- Cree una instancia de servicio basada en la plantilla de servicio que se acaba de completar;
- Cree una directiva de red y seleccione la instancia de servicio que creó anteriormente;
- Aplicar esta directiva de red en la red.
Dado que Contrail interfaz gráfica de usuario es la mejor solución para proporcionar un único punto de administración para todos los entornos, lo utilizaremos para desarrollar el cambio de servicio. Todavía puede usar la GUI del controlador de Contrail normal para crear encadenamiento de servicios.
Primero deje’que inicie sesión en contrail interfaz de usuario de comando (en nuestro https://10.85.188.16:9091/de instalación) tal como se muestra en la Figure 7y, a continuación, seleccione Service > Catalog > Create, como se muestra en la Figure 8.
Inserte un nombre de una plantilla de servicios, aquí myweb-cSRX-CS, luego elija la versión 2 y la máquina virtual para los modos de servicio. Elija en la red y en el cortafuegos como tipos de servicio, como se muestra en la Figure 9.
A continuación, seleccione Administración, a la izquierda y a la derecha, y haga clic en crear.
A continuación, seleccione implementación y haga clic en el botón crear para crear las instancias de servicio, tal y como se muestra en la Figure 11.
Asigne un nombre a esta instancia de servicio y, a continuación, seleccione en el menú desplegable el nombre de la plantilla que creó antes de elegir la correcta de la red de la cSRX sea la instancia (contenedor en ese caso) que realizará el encadenamiento de servicio. Haga clic en las tuplas de puerto para expandirlas como se muestra en la Figure 12. A continuación, para cada una de las tres interfaces, enlace una interfaz de la cSRX y, a continuación, haga clic en crear.
El nombre de la interfaz’de máquina virtual no se muestra en el menú desplegable,’sino el ID de instancia. Puede identificarlo a partir del nombre de interfaz de TAP, como mencionamos anteriormente. En otras palabras, todo lo que hay que saber son los seis primeros caracteres de cualquier interfaz que pertenezca a ese contenedor. Todas las interfaces de una instancia determinada (VM o contenedor) comparten los mismos primeros caracteres.
Antes de continuar, asegúrese de que los Estados de las tres interfaces estén en funcionamiento y muestren la dirección IP correcta de la instancia de cSRX, como se muestra en la Figure 13.
Para crear la Directiva de red, vaya a superposición > directivas de red > crear como en la Figure 14.
Asigne un nombre a la Directiva de red y, a continuación, en la primera regla agregue la red a la izquierda como la red de origen y la red correcta como destino con la acción de Pass.
Seleccione la opción avanzada y adjunte la instancia de servicio a la que creó anteriormente y, a continuación, haga clic en el botón crear.
Para adjuntar esta directiva de red a la red, haga clic en red virtual en la columna situada más a la izquierda, seleccione la red de la izquierda y edite.
En directivas de red, seleccione la Directiva de red que acaba de crear en la lista del menú desplegable y, a continuación, haga clic en guardar. Haga lo mismo para la red correcta.
Comprobar encadenamiento de servicio
’Ahora, compruebe que el efecto de este servicio cambia en la ruta. En el nodo del control de módulo del controlador de Contrail (http://10.85.188.16:8143), seleccione supervisar > infraestructura > enrutador virtual y, a continuación, seleccione el nodo que alberga la caja Pod, en nuestro caso Cent22. local, seleccione la ficha rutas y seleccione el VRF izquierdo.
Puede ver que las rutas de host de red adecuadas se han perdido a la red de la izquierda (10.20.20.1/32, 10.20.20.2/32 en este caso).
Ahora deje’que s haga ping al encajador derecho desde el conjunto Pod izquierdo para ver la sesión creada en el cSRX:
Políticas de seguridad
Cree una política de seguridad en el cSRX para permitir solo HTTP y HTTPS:
El comando ping falla porque la Directiva del cSRX lo interrumpe:
root@csrx1-sc> show log syslog | last 20 Jun 14 23:04:01 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.1/8- >10.20.20.1/575 0x0 icmp 1(8) deny-ping trust untrust UNKNOWN UNKNOWN N/A(N/A) ge-0/0/1.0 No policy reject 5394 N/A N/A -1 Jun 14 23:04:02 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.1/9- >10.20.20.1/575 0x0 icmp 1(8) deny-ping trust untrust UNKNOWN UNKNOWN N/A(N/A) ge-0/0/1.0 No policy reject 5395 N/A N/A -1 Try to send http traffic from the left to the right POD and verify the session status on the CSRX root@left-ubuntu-sc:/# wget 10.20.20.1 --2019-06-14 23:07:34-- http://10.20.20.1/ Connecting to 10.20.20.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 11510 (11K) [text/html] Saving to: 'index.html.4' 100%[============================= =========>] 11,510 --.-K/s in 0s 2019-06-14 23:07:34 (278 MB/s) - 'index.html.4' saved [11510/11510]
Y, en el cSRX podemos ver la sesión crear:
root@csrx1-sc> show log syslog | last 20 Jun 14 23:07:31 csrx1-sc flowd-0x2[374]: csrx_l3_add_new_resolved_unicast_ nexthop: Adding resolved unicast NH. dest: 10.20.20.1, proto v4 (peer initiated) Jun 14 23:07:31 csrx1-sc flowd-0x2[374]: csrx_l3_add_new_resolved_unicast_ nexthop: Sending resolve request for stale ARP entry (b). NH: 5507 dest: 10.20.20.1 Jun 14 23:07:34 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_CREATE: session created 10.10.10.1/47190->10.20.20.1/80 0x0 junos- http 10.10.10.1/47190->10.20.20.1/80 0x0 N/A N/A N/A N/A 6 only-http-s trust untrust 5434 N/A(N/A) ge- 0/0/1.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 Jun 14 23:07:35 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN: 10.10.10.1/47190- >10.20.20.1/80 0x0 junos-http 10.10.10.1/47190->10.20.20.1/80 0x0 N/A N/A N/A N/A 6 only- http-s trust untrust 5434 14(940) 12(12452) 2 UNKNOWN UNKNOWN N/A(N/A) ge- 0/0/1.0 UNKNOWN N/A N/A -1