Interligando dois Virtual Systems (VS) na plataforma Huawei NE (Interligando 2 roteadores virtuais no Huawei NE) – Made4it
Roteadores Virtuais (VS / Virtual-System) no Huawei NE
fevereiro 18, 2020
Dashboard Personalizada e Gráficos de CDN por tempo – Novidades Made4Flow 24/02/2020
fevereiro 24, 2020

Interligando dois Virtual Systems (VS) na plataforma Huawei NE (Interligando 2 roteadores virtuais no Huawei NE)

A linha NE40 da Huawei, principalmente nos modelos M2K e M2K-B, vem se tornando o novo “queridinho” dos ISPs no Brasil, permitindo diversos cenários com um custo benefício muito legal, tanto na camada de Core de rede ( BGP, Roteadores de agregação e afins) quanto na camada de Acesso ( BNGs IPoE, PPPoE… ).

Recentemente na Made4IT, tivemos um caso em que um cliente com um NE40E-M2K-B necessitava de uma virtualização a nível de Chassis, de modo que um parceiro pudesse aproveitar também dos recursos da caixa porém com um certo nível de segregação.

Com nosso conhecimento e expertise com o vendor, sugerimos e concebemos um Virtual System na caixa para essa finalidade, e, seguindo a recomendação do vendor, informamos ao cliente que a comunicação entre os “virtual-systems” deveria se dar por portas de rede dedicadas, onde teríamos um “loop físico” para entregar dados ao “virtual-system” do parceiro. Aqui dentro da empresa, acabamos por chamar esse recurso carinhosamente de “alça de caixão” (risos).

 

Com isto, a primeira forma de interligar dois VS é simplesmente conectar um cabo entre duas portas no mesmo roteador, alocando cada porta para um único VS.

Se quer saber mais sobre virtualização de roteadores Huawei, consulte o post Roteadores Virtuais (VS / Virtual-System) no Huawei NE

Neste mesmo cenário, um tempo atrás fizemos uma implementação em que a necessidade dele era simples, sendo basicamente:

“Minha operadora está me abordando em 2 equipamentos diferentes na minha rede sendo o BGP e um Switch MPLS que tenho a 40km daqui. A operadora quer usar MPLS comigo. Preciso rotar MPLS no meu NE40 onde a operadora vai me entregar os circuitos em algumas VPWS’es.”

Nesse caso a implantação se deu tranquilamente, usando o recurso “Virtual Ethernet”  onde o lado “layer2” e o lado “layer3” tem interfaces distintas para trabalhar a VPWS e fazer a conectividade IP respectivamente.


Se você não conhece sobre MPLS nos roteadores NE, ou se o conceito de “lado layer2” ou “lado layer3” não fez sentido, consulte o post Interfaces L3 em túneis L2 MPLS no Roteador Huawei NE (Como configurar MPLS com IP no Huawei) 

A outra forma de interligar…

Em nossas trocas de experiência entre as equipes de N2 e N3 que são constantes e diárias, um de nossos consultores teve um insight em um momento de devaneio (geralmente no chuveiro, no banheiro, ao abrir a geladeira, caminhando, etc):

“Sabemos que uma virtual-ethernet tem seu lado layer2 e seu lado layer3.
E sabemos que podemos colocar um desses lados em um virtual-system diferente do admin pois, virtual-ethernets só podem ser criadas na vs admin. Agora imagina, se fizéssemos 2 ve-groups diferentes e usássemos um circuit-cross-connection (CCC) do MPLS para juntar esses 2 lados layer2, seria possível fazer os virtual-systems se conversarem em layer3 sem precisar da alça de caixão ?

Apenas para citar, o CCC é a forma mais básica, sem sinalização, de conectar dois serviços através de um VPWS.

Então partimos aos testes de interligar dois VS locais através de um CCC MPLS.

Interligando dois VS via VPN VPWS CCC

Cenário:

Para nossos testes vamos utilizar dois VE-GROUPs, interligar o L2 dos VE-GROUPs via CCC VPWS, e manter um lado L3 no Admin-VS enquanto que o outro lado L3 colocaremos no VS1.

Configurações:

Primeiramente, vamos criar as interfaces que farão parte do L2:

# Admin-VS
 
! Lado L2 Admin-VS
 
interface Virtual-Ethernet0/2/100
 ve-group 100 l2-terminate
 
interface Virtual-Ethernet0/2/100.100
 vlan-type dot1q 100
 
! Lado L2 VS1
 
interface Virtual-Ethernet0/2/200
 ve-group 200 l2-terminate
 
interface Virtual-Ethernet0/2/200.100
 vlan-type dot1q 100

Após isto, vamos interligar a VLAN 100 via VPN VPWS CCC:

! Interligação MPLS CCC VPWS
ccc teste interface Virtual-Ethernet0/2/100.100 tagged out-interface Virtual-Ethernet0/2/200.100 tagged

Com o layer2 configurado, podemos seguir na ativação dos serviços L3:

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

Por fim, vamos inserir somente a subinterface L3 para o VS1.

# Admin-VS
admin
 virtual-system vs1 pvmb slot 3
  port-mode port
  assign interface Virtual-Ethernet0/2/201.100
 
 
# VS1
 
! Lado L3 VS1
interface Virtual-Ethernet0/2/201.100
 vlan-type dot1q 100
 ip address 10.1.1.2 255.255.255.252

Considerações sobre o cenário

Algumas considerações do cenário:

  • Só foi possível adicionar uma subinterface vlan no virtual-system, não permitiu o virtual-ethernet inteiro
  • Foi necessário trocar o mac-address do Virtual-Ethernet em um dos lados, pois o VS herda o mac do chassis

Validações

CCC entre virtual-ethernets up:

<HUAWEI>display vll ccc
total  ccc vc : 1
local  ccc vc : 1,  1 up
remote ccc vc : 0,  0 up
 
name: teste, type: local, state: up,
intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false
 
intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false
 
VC last up time : 2020/02/17 14:40:58
VC total up time: 0 days, 0 hours, 16 minutes, 37 seconds

Ping entre os dois VS:

Admin-VS:
<HUAWEI>ping 10.1.1.2
  PING 10.1.1.2: 56  data bytes, press CTRL_C to break
    Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
    Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms
 
  --- 10.1.1.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/1 ms
 
 
VS1:
<HUAWEI-vs1>ping 10.1.1.1
  PING 10.1.1.1: 56  data bytes, press CTRL_C to break
    Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms
    Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms
    Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms
    Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=1 ms
    Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms
 
  --- 10.1.1.1 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2
  PING 10.1.1.2: 56  data bytes, press CTRL_C to break
    Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
    Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms
    Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms
 
  --- 10.1.1.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/1 ms

Teste com uma sessão BGP e adjacencia OSPFv2 e OSPFv3:

<HUAWEI>displ bgp peer
 
 BGP local router ID : 192.168.88.100
 Local AS number : 11111
 Total number of peers : 1                 Peers in established state : 1
 
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv
  10.1.1.2        4       22222       25       25     0 00:19:38 Established        0

<HUAWEI>displ ospf peer  brief
 
(M) Indicates MADJ neighbor
 
 
          OSPF Process 1 with Router ID 10.0.0.1
                   Peer Statistic Information
Total number of peer(s): 1
 Peer(s) in full state: 1
-----------------------------------------------------------------------------
 Area Id         Interface                  Neighbor id          State
 0.0.0.0         VE0/2/101.100              10.0.0.2             Full

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

Por fim é isto pessoal, não sabemos a performance ou impacto na caixa, porém os serviços básicos funcionaram normalmente.

 

Caso venha a testar com tráfego, nos deixe saber! Compartilhe conosco seus resultados.

 

Abraços,

 

Rafael Ganascim, Gabriel Henrique e Kevin Walters

IT Consulting Team – Made4it

Deixe uma resposta

1
Olá! Fale conosco via WhatsApp!
Powered by