La línea NE40 de Huawei, principalmente los modelos M2K y M2K-B, se está convirtiendo en la nueva «niña mimada» de los ISPs en Brasil, permitiendo diversos escenarios con un muy buen costo-beneficio, tanto en la capa de Core Network (BGP, Aggregation Routers y similares) como en la capa de Acceso (BNGs IPoE, PPPoE…).

Recientemente, en Made4IT, tuvimos un caso en el que un cliente con un NE40E-M2K-B necesitaba una virtualización a nivel de chasis, para que un socio también pudiera aprovechar los recursos de la caja pero con un cierto nivel de segregación.

Con nuestro conocimiento y experiencia con el proveedor, sugerimos y diseñamos un Sistema Virtual en la caja para este propósito, y, siguiendo la recomendación del proveedor, informamos al cliente que la comunicación entre los «sistemas virtuales» debería ser a través de puertos de red dedicados, donde tendríamos un «bucle físico» para entregar datos al «sistema virtual» del socio. En la empresa acabamos llamando cariñosamente a esta característica «correa de ataúd» (risas).

 

Con esto, el primer camino para interconectar dos VS es simplemente conectar un cable entre dos puertos del mismo router, asignando cada puerto a un único VS.

Si quieres saber más sobre la virtualización de los routers Huawei, consulta el post  Virtual Routers(VS / Virtual-System) on Huawei NE

En este mismo escenario, hace un tiempo hicimos una implementación donde su necesidad era simple, siendo básicamente:

«Mi operador me está planteando 2 equipos diferentes en mi red siendo BGP y un Switch MPLS que tengo a 40km. El operador quiere utilizar MPLS conmigo. Necesito enrutar MPLS en mi NE40 donde el operador me entregará los circuitos en algunos VPWS’es».

En este caso el despliegue se realizó sin problemas, utilizando el recurso «Virtual Ethernet » donde el lado «capa2» y el lado «capa3» tienen interfaces distintas para hacer funcionar el VPWS y realizar la conectividad IP respectivamente.


Si usted no sabe acerca de MPLS en los routers NE, o si el concepto de «lado layer2» o «lado layer3» no tiene sentido, consulte el post L3 interfaces en L2 MPLS túneles en Huawei NE Router (Cómo configurar MPLS con IP en Huawei) 

La otra forma de conectar…

En nuestros constantes y diarios intercambios entre los equipos de N2 y N3, uno de nuestros asesores tuvo una idea en un momento de ensoñación (normalmente en la ducha, en el baño, abriendo la nevera, paseando, etc.):

«Sabemos que una virtual-ethernet tiene su lado layer2 y su lado layer3.
Y sabemos que podemos poner uno de estos lados en un sistema virtual que no sea admin porque, las redes virtuales sólo se pueden crear en vs admin. Ahora imaginemos que creamos dos grupos virtuales diferentes y utilizamos un circuito de conexión cruzada (CCC ) de MPLS para unir los dos lados de la capa 2. ¿Sería posible hacer que los sistemas virtuales se comunicaran entre sí en la capa 3 sin necesidad de la correa del ataúd?«.

Sólo para citar, la CCC es la forma más básica, sin señalización, de conectar dos servicios a través de un VPWS.

A continuación, nos lanzamos a las pruebas de interconexión de dos VS locales a través de un MPLS CCC.

Interconexión de dos VS mediante VPN VPWS CCC

Escenario:

Para nuestras pruebas utilizaremos dos VE-GROUPs, interconectaremos los L2 de los VE-GROUPs a través de CCC VPWS, y mantendremos un lado L3 en Admin-VS mientras que el otro lado L3 lo pondremos en VS1.

Ajustes:

En primer lugar, crearemos las interfaces que formarán parte de L2:

# Admin-VS
 
¡! Lado L2 Admin-VS
 
interfaz Virtual-Ethernet0/2/100
  ve-grupo 100 l2-terminar
 
interfaz Virtual-Ethernet0/2/100.100
  vlan-type dot1q 100
 
¡! Lado L2 VS1
 
interfaz Virtual-Ethernet0/2/200
  ve-grupo 200 l2-terminar
 
interfaz Virtual-Ethernet0/2/200.100
  vlan-type dot1q 100

A continuación, interconectaremos la VLAN 100 a través de la VPN VPWS CCC:

¡! Interconexión MPLS CCC VPWS
ccc test interface Virtual-Ethernet0/2/100.100 tagged out-interface Virtual-Ethernet0/2/200.100 tagged

Con la capa 2 configurada, podemos pasar a activar los servicios L3:

# Admin-VS
 
¡! Lado L3 Admin-VS
 
interfaz Virtual-Ethernet0/2/101
  dirección-mac c4b8-b434-ab45
  ve-group 100 l3-access
 
interfaz Virtual-Ethernet0/2/101.100
  vlan-type dot1q 100
  dirección ip 10.1.1.1 255.255.255.252
 
 
¡! Lado L3 VS1
 
interfaz Virtual-Ethernet0/2/201
  ve-group 200 l3-access
 
interfaz Virtual-Ethernet0/2/201.100
  vlan-type dot1q 100

Por último, insertaremos sólo la subinterfaz L3 para VS1.

# Admin-VS
admin
  sistema virtual vs1 pvmb ranura 3
  puerto-modo puerto
  asignar interfaz Virtual-Ethernet0/2/201.100
 
 
# VS1
 
¡! Lado L3 VS1
interfaz Virtual-Ethernet0/2/201.100
  vlan-type dot1q 100
  dirección ip 10.1.1.2 255.255.255.252

Consideraciones sobre el escenario

Algunas consideraciones sobre el escenario:

  • Sólo era posible añadir una subinterfaz vlan en el sistema virtual, no permitía que toda la virtual-ethernet
  • Era necesario cambiar la dirección mac de la Ethernet virtual en un lado, porque la VS hereda la mac del chasis.

Validaciones

CCC entre redes virtuales:

<HUAWEI>pantalla vll ccc
total ccc vc : 1
local ccc vc : 1, 1 arriba
remoto ccc vc : 0, 0 arriba
 
nombre: test, tipo: local, estado: up,
intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false
 
intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false
 
VC última vez : 2020/02/17 14:40:58
Tiempo total de funcionamiento de la CV: 0 días, 0 horas, 16 minutos, 37 segundos

Ping entre los dos VS:

Admin-VS:
<HUAWEI>ping 10.1.1.2
  PING 10.1.1.2: 56 bytes de datos, pulse CTRL_C para interrumpir
  Respuesta de 10.1.1.2: bytes=56 Secuencia=1 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Secuencia=2 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
  Respuesta de 10.1.1.2: bytes=56 Secuencia=4 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms
 
  --- 10.1.1.2 estadísticas ping ---
  5 paquete(s) transmitido(s)
  5 paquete(s) recibido(s)
  0,00% de pérdida de paquetes
  ida y vuelta min/avg/max = 1/1/1 ms
 
 
VS1:
<HUAWEI-vs1>ping 10.1.1.1
  PING 10.1.1.1: 56 bytes de datos, pulse CTRL_C para interrumpir
  Respuesta de 10.1.1.1: bytes=56 Secuencia=1 ttl=255 tiempo=1 ms
  Respuesta desde 10.1.1.1: bytes=56 Secuencia=2 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.1: bytes=56 Secuencia=3 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.1: bytes=56 Secuencia=4 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.1: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms
 
  --- 10.1.1.1 estadísticas ping ---
  5 paquete(s) transmitido(s)
  5 paquete(s) recibido(s)
  0,00% de pérdida de paquetes
  ida y vuelta min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2
  PING 10.1.1.2: 56 bytes de datos, pulse CTRL_C para interrumpir
  Respuesta de 10.1.1.2: bytes=56 Secuencia=1 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Secuencia=2 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
  Respuesta de 10.1.1.2: bytes=56 Secuencia=4 ttl=255 tiempo=1 ms
  Respuesta de 10.1.1.2: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms
 
  --- 10.1.1.2 estadísticas ping ---
  5 paquete(s) transmitido(s)
  5 paquete(s) recibido(s)
  0,00% de pérdida de paquetes
  ida y vuelta min/avg/max = 1/1/1 ms

Prueba con una sesión BGP y adyacencias OSPFv2 y OSPFv3:

<HUAWEI>displ bgp peer
 
  ID del enrutador local BGP : 192.168.88.100
  Número AS local : 11111
  Número total de peers : 1 Peers en estado establecido : 1
 
  Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
  10.1.1.2 4 22222 25 25 0 00:19:38 Establecido 0

<HUAWEI>displ ospf peer brief
 
(M) Indica vecino MADJ
 
 
  Proceso OSPF 1 con ID de router 10.0.0.1
  Información estadística paritaria
Número total de pares: 1
  Pares en pleno estado: 1
-----------------------------------------------------------------------------
  Id de área Interfaz Id de vecino Estado
  0.0.0.0 VE0/2/101.100 10.0.0.2 Completo

<HUAWEI> displ ospfv3 peer
  Proceso OSPFv3 (1)
  Área OSPFv3 (0.0.0.0)
  Neighbor ID Pri State Dead Time Interface Instance ID
  10.0.0.1 1 Completo/DR 00:00:38 VE0/2/201.100 0

Finalmente esto es todo amigos, no sabemos el rendimiento o impacto en la caja, sin embargo los servicios básicos funcionaron con normalidad.

 

Si lo pruebas con tráfico, ¡háznoslo saber! Comparta sus resultados con nosotros.

 

Abrazos,

 

Rafael Ganascim, Gabriel Henrique y Kevin Walters

Equipo de consultoría TI – Made4it