Você está na página 1de 17

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Função Virtual de Rede Lightweight 4over6 vMX White Paper White Paper Função virtual de rede vMX

White Paper

Função virtual de rede vMX Lightweight

4over6

Juniper e Snabb em um container Docker

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Índice

Resumo executivo

3

Introdução

3

O problema da transição para IPv6

3

Docker Container lwAFTR vMX

4

Plano de controle virtual vMX

5

Plano de encaminhamento virtual vMX

5

Snabbvmx

5

Aplicação Juniper Extension Toolkit (JET)

5

Configuração

5

Redundância e escalabilidade horizontal

8

Escalabilidade vertical da interface vMX

9

Escalabilidade horizontal das instâncias vMX múltiplas

9

Design opcional de interface dual em pilha única

10

Diagrama YANG Softwire IETF

11

Como funciona o Snabbvmx

14

Conclusão

14

Sobre o Snabb

15

Sobre a Juniper Networks

15

Lista de figuras

Figura 1: O problema da transição IPv4 para IPv6

3

Figura 2: Contêiner Docker lwAFTR vMX

4

Figura 3: Configuração de exemplo com uma interface de pilha dupla

6

Figura 4: Escalabilidade vertical da interface vMX

9

Figura 5: Escalabilidade horizontal das instâncias vMX múltiplas

9

Figura 6: Exemplo de design de interface duplal em pilha única

10

Figura 7: Como funciona internamente o Snabbvmx

14

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Resumo executivo

O roteador virtual vMX da Juniper Networks ® , projetado com mecanismo de comutação de pacotes baseado em software de código aberto Snabb em um container Docker, apresenta uma função virtual de rede (VNF) de alta escalabilidade e desempenho para fechar milhões de túneis IPv4- em-IPv6 como Roteadores de Transição de Famílias de Endereços (AFTRs), definidos pela RFC 7596.

Introdução

Conforme os provedores de serviço aceleram a migração das suas principais redes para IPv6, eles precisam assegurar acesso ininterrupto e continuidade dos serviços para todos os usuários IPv4 existentes. Esse documento descreve os desafios da transição IPv6 que os provedores de serviço estão enfrentando e como o Lightweight 4over6, como apresentado na RFC 7596 da IETF (Força-Tarefa de Engenharia da Internet), pode ajudar. Além disso, este documento oferece uma explicação detalhada dos elementos principais que levam a uma VNF de alto desempenho e escalável, o que é exigido do lado do provedor de serviço.

Incluído e executado dentro de um contêiner Docker, o roteador virtual vMX da Juniper Networks integra e gerencia totalmente um aplicativo de processamento de pacotes de terceiros e de código aberto (Snabb) para entregar um AFTR de alto desempenho e escalável, e conectar as interfaces de 10GbE chipset Intel 82599 com as interfaces de rede virtual vMX. O modelo de dados IEFT YANG para softwire IPv4-em-IPv6 é integrado com o vMX para configurar e gerenciar o Snabb.

Da perspectiva de integração de rede, a VNF Lightweight 4over6 vMX é uma solução de roteamento virtual totalmente funcional, ampliada de maneira transparente por uma “microVNF” de terceiros com funções específicas no tráfego de dados. Além do AFTR, a vMX também dá suporte a múltiplas funções de protocolo de rede, incluindo o Protocolo de Resolução de Endereço (ARP), Protocolo para Descoberta de Vizinhos IPv6 (NDP), Menor Rota Aberta Primeiro (OSPF), Detecção Bidirecional de Transmissão (BFD), Protocolo de Roteamento de Borda (BGP), Protocolo Simples de Gerenciamento de Rede (SNMP), autenticação no sistema, Protocolo de Configuração de Rede (NETCONF) e outros, para uma solução virtual verdadeiramente confiável.

Cada interface 10GbE é capaz de fechar milhões de túneis. A natureza stateless da função de terminação do túnel AFTR permite que uma única VNF não apenas escale verticalmente para interfaces 10GbE múltiplas, mas também escale horizontalmente compartilhando tráfego de rede através de várias VNFs.

O problema da transição ao IPv6

O esgotamento 1 de endereços públicos IPv4 está forçando os provedores de serviço não apenas a acelerar a adoção do IPv6, mas também a compartilhar endereços IPv4 públicos entre seus registrados. Uma abordagem simples de pilha dupla, como mostrada na figura 1, consome um endereço público IPv4 por registro residencial. A solução mais comum hoje usa um Carrier Grade NAT (CGNAT) (mostrado do lado direito da figura 1), também conhecido como Tradução de Endereço de Rede (NAT) em larga escala, que fica entre o equipamento nas dependências do cliente (CPE) e a rede principal. A Juniper oferece hoje uma solução baseada na Série MX 3D de Roteadores de Borda Universais(veja o guia Dia um: Instalando o CGNAT na Série MX para mais detalhes). O roteador CGNAT fornece uma Tradução de Porta de Endereço de Rede (NAPT) com estado para todos os dispositivos CPE para uma pequena faixa de endereços públicos IPv4. O CGNAT requer o uso de endereços IPv4 privados atribuídos para dispositivos CPE individuais, tornando essa abordagem incrivelmente complexa por oferecer serviços de entrada sobre IPv4, sem mencionar os muitos outros desafios relacionados à resiliência, escalabilidade e custos.

Pilha dupla sem salvar IPv4 IPv6 e IPv4 IPv6 Público IPv4 Público, $$$
Pilha dupla sem
salvar IPv4
IPv6 e IPv4
IPv6 Público
IPv4 Público, $$$
Limite statefull NAT em grande escala, $$$ IPv6
Limite statefull NAT em
grande escala, $$$
IPv6

IPv6 Público

IPv4 Privado

Lw4o6 RFC 7596 túneis stateless

IPv6 Público IPv4 Privado Lw4o6 RFC 7596 túneis stateless Porta IPv6 IPv4 público compartilhado de porta

Porta IPv6 IPv4 público compartilhado de porta restrita

Figura 1: O problema da transição IPv4 para IPv6

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

O Lightweight 4over6, definido na RFC 7596 e mostrado no meio da figura 1, delega o endereço de rede statefull e funcionalidade de tradução de

porta para o CPE enquanto transporta o tráfego IPv4 dentro de um túnel IPv6 stateless. O mecanismo de transporte deriva do Dual-Stack Lite (DS-

Lite) como definido na IETF RFC 6333. Isso remove a necessidade de qualquer tradução de endereço e encerramento do túnel statefull do lado do provedor. Para delegar a função NAPT e tornar o compartilhamento de endereço IPv4 possível, endereços IPv4 com porta restrita são alocados para os CPEs.

Um único endereço IPv4 público pode ser compartilhado por múltiplos registrados, sendo atribuída a cada um uma faixa de porta única das 1024 portas TCP/UDP. A faixa de porta de 0 a 1023 está reservada para serviços de entrada como SSH ou HTTP e pode ser mapeada e opcionalmente carregada para selecionar registrados.

A tabela 1 ilustra uma tabela típica de vinculação.

Tabela 1: Tabela de exemplo de vinculação

IPv6 público registrado

IPv4 público compartilhado

Faixa de porta UDP/TCP

2001:db8:1:1::1

193.5.1.1

1024 - 2047

2001:db8:1:1::2

193.5.1.1

2048 - 3071

2001:db8:1:1::3

193.5.1.1

3072 - 4095

.

.

.

.

.

.

.

.

.

2001:db8:1:1::63

193.5.1.1

64512 - 65535

2001:db8:1:1::64

193.5.1.2

1024 - 2047

Contêiner Docker vMX lwAFTR

O roteador virtual vMX é lançado dentro de um Docker e conectado às interfaces físicas de 10GbE através de drivers de placa de rede em modo

usuário baseado em Snabb. Todas as aplicações necessárias, drivers de interface, bibliotecas e daemons necessários para executar o plano de encaminhamento virtual vMX (VFP) e plano de controle virtual (VCP), incluindo Qemu e KVM, estão incluídos na imagem do contêiner Docker. A própria imagem vMX não é distribuída dentro da imagem do contêiner; ela é adicionada no início, junto à configuração e arquivos de licença.

fxp0

xe-0/0/0

xe-0/0/1

xe-0/0/2

xe-0/0/n

fxp0 KVM vMX VCP em1 JET App int Snabbvmx 0/0/0 Snabbvmx 0/0/1 vMX VFP Snabbvmx
fxp0
KVM
vMX VCP
em1
JET App
int
Snabbvmx
0/0/0
Snabbvmx
0/0/1
vMX VFP
Snabbvmx
0/0/2
KVM
Snabbvmx
0/0/n

Figura 2:Docker Container vMX lwAFTR

O nó do computador hospeda o SO com as dependências mínimas de versão de software:

Placa Ethernet 10GbE chipset Intel 82599

Kernel Linux versão 3.10 ou mais recente com módulo kernel KVM carregado (necessário para executar o contêiner Docker lwAFTR vMX no nó do computador)

Motor Docker

Hugepages

Como o contêiner já contém Qemu, KVM e um driver da placa Ethernet, não há necessidade de tais elementos no nó do computador, nem há conflito se a mesma versão ou diferentes estiverem presentes.

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Plano de controle virtual vMX

A VCP vMX executa o sistema operacional Junos ® da Juniper Networks com a configuração Lightweight 4over6 e a extensão de operação

carregada baseada na versão ampliada do modelo de dados 2 IETF YANG. A funcionalidade AFTR Lightweight 4over6, assim como os recursos do SO

Junos vMX são configuráveis via linha de comando e NETCONF. O console serial do SO Junos pode ser acessado diretamente anexando-o a um

contêiner Docker em execução (“docker attach <name>").

A porta de gerenciamento (fxp0) da VCP vMX está conectada em tempo de execução pelo docker à ponte Linux docker0. A porta interna (em1) da

VCP vMX está conectada a uma ponte interna dentro do contêiner em execução e isolada de outros contêineres e do computador hospedeiro

através de isolamento da rede por namespace. Isso permite que múltiplos contêineres sejam executados no mesmo nó do computador

simultaneamente.

Plano de encaminhamento virtual vMX

A

VFP vMX executa o software de plano de encaminhamento virtual Trio e trabalha com encaminhamento de pacotes e resolução do próximo salto.

O

fechamento do túnel 4over6, no entanto, é delegado para o Snabbvmx.

A

interface interna (int) da VFP está conectada à mesma ponte interna dentro do contêiner em execução que em1 do VCP.

As interfaces de rede 0/0/0

à transferência rápida de pacote sem cópia entre a placa de interface física e a máquina virtual convidadanesse caso, a VFP vMX. Isso requer

uma quantidade suficiente de Hugepages no nó do computador.

0/0/n estão conectadas via driver de rede virtio_net para_virtualized no Qemu no modo VhostUser, dando suporte

Snabbvmx

O Snabbvmx é parte da pilha de rede virtualizada Ethernet de código aberto Snabb 3 e tem duas funções principais:

1. Guiar diretamente a porta de interface física e guiar de forma transparente os pacotes de transporte para a VFP vMX

2. Realizar o fechamento do túnel AFTR Lightweight 4over6

Essa dupla funcionalidade é melhor explicada comparando o Snabbvmx com uma “colisão nos fios.” O tráfego encapsulado IPv4-em-IPv6 é desencapsulado; então, todo tráfego IPv4 não local é encapsulado de acordo com a tabela de vinculação fornecida. Todo o tráfego restante, incluindo ARP, IPv6, NDP, BGD, Protocolo de Descoberta de Camada de Link (LLDP), OSPF, BGP, Protocolo de Mensagem de Controle de Internet (ICMP) Ping, etc.,passa de maneira transparente entre a porta física e as interfaces de dados virtuais VFP vMX (0/0/n).

As portas de interface física são referenciadas pelos endereços (ex: 0000:05:00.0) de Interconexão de Componentes Periféricos (PCI) no modo de execução. A ordem dos endereços dada para o contêiner na inicialização define o mapeamento para as interfaces virtuais 0/0/0 através de 0/0 na vMX. Cada porta física é consumida por um daemon Snabbvmx e conectada através de uma interface de alto desempenho VhostUser 4 com a VFP vMX via Qemu ou KVM.

Se a interface de rede não tiver uma configuração Lightweight 4over6 no SO, todo tráfego passará de maneira transparente entre a porta física e a interface de dados virtuais no roteador virtual vMX. O Snabbvmx é totalmente transparente nesse caso, permitindo que todas as configurações de interface vMX suportadas, incluindo VLANe MPLS.

O Snabbvmx contribui para o projeto Snabb 5

Aplicação Juniper Extension Toolkit

A aplicação Juniper Extension Toolkit (JET) controla a funcionalidade de todas as aplicações do driver da interface Snabbvmx dentro do contêiner baseado na configuração ampliada do SO Junos para Lightweight 4over6. Ela também fornece acesso operacional e estatístico ao plano de

controle do SO Junos. Informações adicionais sobre o JET podem ser encontradas aqui.

Configuração

A configuração da interface e Lightweight 4over6 é conduzida através da configuração do SO Junos. O mapeamento das portas de interface física

com as interfaces do SO Junos é feito através da lista ordenada de endereços de porta de interface PCI fornecidas para o contêiner na inicialização.

Abaixo está um exemplo de inicialização com as portas de interface 10GbE disponíveis no nó do computador:

$ lspci |grep 10- 81:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network

Connection (rev 01)

81:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network

Connection (rev 01)

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

83:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 83:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

$ cat run1.sh #!/bin/bash

NAME=”lwaftr1”

CFG=”lwaftr1.txt”

VMX=”vmx-bundle-16.1R1.7.tgz”

CONTAINER=”vmxlwaftr:v0.10”

IDENTITY=”lab,lab123”

INTERFACES=”0000:81:00.0 0000:81:00.1 0000:83:00.0 0000:83:00.1” LICENSE=”license-eval.txt” docker run --name $NAME -ti --privileged -v $PWD:/u:ro $CONTAINER -i $IDENTITY -l $LICENSE -c $CFG $VMX $INTERFACES

Isso resulta no seguinte mapeamento de interface:

Tabela 2: Porta para interface e mapeamento de ID

Endereço PCI

Junos OS IFD

Snabbvmx id

lwaftr-instance id

0000:81:00.0

xe-0/0/0

xe0

0

0000:81:00.1

xe-0/0/1

xe1

1

0000:83:00.0

xe-0/0/2

xe2

2

0000:83:00.1

xe-0/0/3

xe3

3

Por padrão, o vMX usa a nomenclatura de interface ge-0/0/x. Isso pode ser alterado para xe com a seguinte configuração:

chassis { fpc 0 { pic 0 { interface-type xe;

}

}

}

fxp0 fxp0 vMX VCP KVM em1 Internet JET App int xe-0/0/0 Snabbvmx 0/0/0 0000:81:00.0 Snabbvmx
fxp0
fxp0
vMX VCP
KVM
em1
Internet
JET App
int
xe-0/0/0
Snabbvmx
0/0/0
0000:81:00.0
Snabbvmx
0/0/1
Acesso
IPv6
vMX VFP
Snabbvmx
0/0/2
KVM
Snabbvmx
0/0/n

Figura 3: Configuração de exemplo com uma interface de pilha dupla

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Uma única porta física está conectada a um roteador com uma configuração de pilha dupla para IPv4 e IPv6. O vMX age como o próximo salto, respondendo às consultas de protocolo do NDP IPv6 e ARP, e pontos de terminação IGP e BGP. Opcionalmente, o BFD também pode ser habilitado; entretanto, isso precisa da seguinte configuração padrão do SO Junos em 0/0/0:

interfaces { xe-0/0/0 { mtu 9000; unit 0 { description “xe0”; family inet { address 172.20.0.16/24;

}

family inet6 { address 2004:400::1/64;

}

}

}

}

O diagrama YANG IETF é usado para configurar o driver da porta física Snabbvmx com informação VLAN, informação IPv4 e IPv6, além da configuração AFTR Lightweight e tabela de vinculação. Cada interface de rede tem um objeto instanciado lwaftr correspondente. A configuração de exemplo mostra cinco entradas de vinculação:

ietf-softwire:softwire-config { binding { br {

br-instances { br-instance 0 { tunnel-payload-mtu 9000; tunnel-path-mru 9100; binding-table { binding-entry 2004:400:400::1 { binding-ipv4-addr 4.4.4.1; port-set { psid-offset 0; psid 1; psid-len 6;

}

brr-ipv6-addr 2004:400::1;

}

binding-entry 2004:400:400::2 { binding-ipv4-addr 4.4.4.1; port-set { psid-offset 0; psid 2; psid-len 6;

}

br-ipv6-addr 2004:400::1;

}

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

binding-entry 2004:400:400::3 { binding-ipv4-addr 4.4.4.1; port-set { psid-offset 0; psid 3; psid-len 6;

}

br-ipv6-addr 2004:400::1;

}

binding-entry 2004:400:400::4 { binding-ipv4-addr 4.4.4.1; port-set { psid-offset 0; psid 4; psid-len 6;

}

br-ipv6-addr 2004:400::1;

}

binding-entry 2004:400:400::5 { binding-ipv4-addr 4.4.4.1; port-set { psid-offset 0; psid 5; psid-len 6;

}

br-ipv6-addr 2004:400::1;

}

}

jnx-aug-softwire:ipv4_address 172.20.0.16; jnx-aug-softwire:cache_refresh_interval 1;

}

}

}

}

}

O

endereço IPv4 no objeto instanciado lwaftr aumentado é usado para detectar tráfego local que deve atravessar encapsulamento do túnel e que

deve ser passado na interface de rede vMXnesse exemplo, xe-0/0/0.

O cache_refresh_interval, medido em segundos (se configurado), irá enviar periodicamente uma cópia do pacote processado para a resolução

de próximo salto do vMX, armazenar em cache o próximo salto (um por família IPv4 e IPv6 cada), e usar para todos os pacotes. Se o cache_

refresh_interval não for configurado, todos os pacotes serão enviados para vMX no padrão xe-0/0/0 para roteamento e serão transmitidos para a porta física assim que recebidos de volta.

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Redundância e escalabilidade horizontal

A natureza stateless do Lightweight 4over6 do lado do provedor de serviço permite o balanceamento de tráfegopara muitas interfaces sem a necessidade de um caminho de encapsulamento e desencapsulamento que passe pela mesma interface e instância. O único requisito é que

cada instância tenha a tabela de vinculação completa carregada.

O vMX anuncia os pontos finais do túnel sobre cada interface através do BGP, mas com um próximo salto diferente (IP diferente por

interface). O roteador de peering recebe quatro próximos saltos por família de protocolo se todas as quatro instâncias estiverem operacionais e puderem equilibrar a carga de tráfego para as interfaces usando múltiplos caminhos de custo igual (ECMP). Se uma instância

finaliza, a rota não é mais anunciada e o próximo salto é removido.

Escalabilidade vertical da interface vMX

fxp0 fxp0 vMX VCP KVM em1 JET App int Internet Snabbvmx 0/0/0 Snabbvmx 0/0/1 vMX
fxp0
fxp0
vMX VCP
KVM
em1
JET App
int
Internet
Snabbvmx
0/0/0
Snabbvmx
0/0/1
vMX VFP
Snabbvmx
0/0/2
KVM
Acesso
IPv6
Snabbvmx

Figura 4: Escalabilidade vertical da interface vMX

Quatro interfaces em um único vMX não são o limite real. O limite real apenas é atingido quando todos os núcleos nos mesmos nós de acesso de

memória não uniforme (NUMA) estiverem em uso. O tráfego nunca percorre uma interface para outra porque cada interface tem a tabela de

vinculação completa e, portanto, pode formar túneis de encapsulamento e desencapsulamento bidirecionalmente.

Escalabilidade horizontal das instâncias vMX múltiplas

O conceito de escalabilidade vertical não está limitado a um único vMX. Ele funciona bem até o limite de ECMP do roteador de peering, que

geralmente é 64.

Figura 5: Escalabilidade horizontal das instâncias vMX múltiplas

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

fxp0 vMX VCP KVM JET App Snabbvmx 0/0/0 Snabbvmx 0/0/1 vMX VFP 0/0/2 Snabbvmx KVM
fxp0
vMX VCP
KVM
JET App
Snabbvmx
0/0/0
Snabbvmx
0/0/1
vMX VFP
0/0/2
Snabbvmx
KVM
Snabbvmx
0/0/3
12 x 10 GbE
12 x 10 GbE
fxp0 vMX VCP KVM JET App Snabbvmx 0/0/0 Snabbvmx 0/0/1 vMX VFP Snabbvmx 0/0/2 KVM
fxp0
vMX VCP
KVM
JET App
Snabbvmx
0/0/0
Snabbvmx
0/0/1
vMX VFP
Snabbvmx
0/0/2
KVM
Snabbvmx
0/0/3
Internet
Internet
100 GbE 100 GbE Acesso IPv6
100 GbE
100 GbE
Acesso
IPv6
fxp0 vMX VCP KVM JET App Snabbvmx 0/0/0 Snabbvmx 0/0/1 vMX VFP Snabbvmx 0/0/2 KVM
fxp0
vMX VCP
KVM
JET App
Snabbvmx
0/0/0
Snabbvmx
0/0/1
vMX VFP
Snabbvmx
0/0/2
KVM
Snabbvmx
0/0/3

A figura 5 mostra um exemplo de três contêineres Docker vMX, cada um servindo a 4x10GbE, o que resulta em uma capacidade bidirecional de 120 Gbps para milhões de conexões.

Design opcional de pilha única da interface dupla

Há redes que requerem que o vMX use interfaces físicas separadas por família de protocolo. O encapsulamento e desencapsulamento do protocolo ainda é feito no ingresso, mas o cachê do próximo salto não pode ser usado porque o pacote deve ser enviado para o vMX para roteamento baseado na família IP dos pacotes.

A figura 6 mostra um design usando duas interfaces físicas separadas, uma para o tráfego IPv4 e outra para o tráfego IPv6. O encapsulamento e desencapsulamento do túnel sempre ocorrem na entrada, nunca na saída; portanto, a mesma tabela de vinculação deve ser compartilhada por ambas as instâncias lwaftr. Isso pode ser obtido armazenando a tabela de vinculação em um arquivo e usando-a como referência para uso por todas as interfaces:

Figura 6: Exemplo de design de pilha única de interface dupla

ietf-softwire:softwire-config { binding { br {

br-instances { br-instance 0 {

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

tunnel-payload-mtu 9000; tunnel-path-mru 9100; ipv4_address 172.16.2.35;

}

br-instance 3 { tunnel-payload-mtu 9000; tunnel-path-mru 9100; ipv4_address 172.16.2.35;

}

}

binding-table-file binding_table_4m.txt;

}

}

}

As interfaces xe-0/0/0 e xe-0/0/1 ainda devem ser configuradas como pilhas duplas, porque elas têm duas tarefas principais para realizar:

1. Responder ao BFD, ICMP e peer através dos protocolos OSPF e BGP.

2. Aceitar e rotear pacotes IPv4 desencapsulados ou pacotes IPv6 encapsulados

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Diagrama YANG Softwire IETF

O SO Junos versão 16.1 dá suporte a um diagrama YANG personalizado a ser adicionado no modo de execução para estender o armazenamento da configuração, operação via linha de comando e acesso através do NETCONF e gRPC.

O contêiner Docker lwAFTR vMX incorpora o último desenho do diagrama YANG softwire IETF. Informações adicionais podem ser encontradas

O SO Junos também dá suporte à ampliação do diagrama YANG e desvios para adicionar contêineres e folhas YANG de solução específica. Para o

lwAFTR vMX, várias folhas adicionais foram adicionadas e publicadas em um arquivo de ampliação separado:

module jnx-softwire { namespace “http://yang.juniper.net/software/aug”; prefix “jnx-swire”;

import ietf-inet-types {prefix inet; } import ietf-softwire {prefix sw; }

organization “Juniper Networks, Inc.”;

revision 2016-07-19 { description “Juniper software augments. “;

}

augment “/sw:softwire-config/sw:binding/sw:br” { leaf binding-table-file { type string; description “Complete path of the binding table file”;

}

}

augment “/sw:softwire-config/sw:binding/sw:br/sw:br-instances/sw:br-instance” { leaf ipv6_address { type inet:ipv6-address;

}

leaf ipv4_address { type inet:ipv4-address;

}

leaf ipv6_vlan { type uint16 {

range 0

}

4094;

}

leaf ipv4_vlan { type uint16 {

range 0

}

4094;

}

leaf hairpinning { type boolean;

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

default false;

}

leaf fragmentation { type boolean; default false;

}

leaf cache_refresh_interval {

type uint32;

units seconds;

default 1;

}

leaf icmpv6_rate_limiter_n_packets {

type uint32;

}

leaf icmpv6_rate_limiter_n_seconds {

type uint32;

default 1;

}

leaf policy_icmpv6_incoming {

type enumeration {

enum allow;

enum drop;

}

}

leaf policy_icmpv6_outgoing {

type enumeration {

enum allow;

enum drop;

}

}

leaf policy_icmpv4_incoming {

type enumeration {

enum allow;

enum drop;

}

}

leaf policy_icmpv4_outgoing {

type enumeration {

enum allow;

enum drop;

}

}

leaf ipv6_ingress_filter

{ type string;

description

“IPv6 ingress filter in libpcap format”;

}

leaf ipv6_egress_filter

{ type string;

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

description “IPv6 egress filter in libpcap format”;

}

leaf ipv4_ingress_filter { type string; description “IPv4 ingress filter in libpcap format”;

}

leaf ipv4_egress_filter { type string; description “IPv4 egress filter in libpcap format”;

}

}

}

No caso de que algumas dessas folhas sejam adicionadas ao RFC IETF final, elas podem simplesmente ser removidas do arquivo de ampliação e um novo contêiner Docker pode ser construído.

Os modelos YANG draft-ietf-softwire têm contêineres para recursos não suportados pela implementação Lightweight 4over6 baseada em vMX, principalmente ce (lado do cliente) e algoritmo (para MAP-T, MAP-E). Esses estão sinalizados como “não suportado” por um arquivo de desvio:

module jnx-softwire-dev { namespace “http://yang.juniper.net/software/aug”; prefix “jnx-swire”;

import ietf-softwire {prefix sw; }

organization “Juniper Networks, Inc.”;

revision 2016-07-19 { description “Juniper software deviation (lwaftr) BR only functionality “;

}

deviation /sw:softwire-config/sw:binding/sw:ce { deviate not-supported;

}

deviation /sw:softwire-config/sw:algorithm { deviate not-supported;

}

}

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Como funciona o Snabbvmx

A figura 7 mostra um diagrama de bloco de todos os componentes Snabb necessários. Os pacotes IPv4 e IPv6 vêm a partir da porta física 10GbE e

ou são passados de maneira transparente para uma interface virtual vMX correspondente (por ex., xe-0/0/0) ou são detectados como um pacote que precisa de encapsulamento ou desencapsulamento Lightweight 4over6. A configuração pendente, fragmentação e reconstrução podem ocorrer na entrada e saída. O Snabbvmx age como um daemon driver da interface de rede que não apenas passa pacotes de maneira transparente entre uma interface 10GbE física dedicada e uma interface virtual no vMX (executando no Qemu), mas também trabalha com pacotes IPv4 e IPv6

e pacotes IPv4 não locais, passando-os pela aplicação LwAFTR. Enquanto o diagrama apenas mostra uma instância do Snabbvmx e um par de

interfaces físicas e virtuais, a solução do Snabbvmx escala horizontalmente executando instâncias múltiplas, cada uma conectando a um par

separado de interfaces virtuais e físicas.

mirror tap xeX Fragmentador6 Acomp vMX VCP nh_fwd6 KVM a Reconstrutor6 nhame vMX VFP Intel
mirror
tap xeX
Fragmentador6
Acomp
vMX VCP
nh_fwd6
KVM
a Reconstrutor6
nhame
vMX VFP
Intel
Divisão
Divisão
Usuário
10GbE
LwAfr
v4v6
hospe-
v4v6
deiro
Reconstrutor4
KVM
nh_fwd4
Fragmentador4
Snabb

Figura 7: Como funciona internamente o Snabbvmx

O Snabbvmx do daemon Snabb carrega a aplicação Intel10g para acionar uma porta física 10GbE baseada em chipset Intel 82599. A aplicação

LwAFTR é o “burro de carga”, trabalhando com o encapsulamento e desencapsulamento do túnel. O FragmenterX e ReassemblerX estão no

caminho de dados para trabalhar a fragmentação e reconstrução do IPv4 para IPv6. A aplicação Split v4v6 divide os pacotes IPv4 de IPv6 e envia-os

a partir da aplicação Intel10g para a aplicação de reconstrução específica do protocolo. Os pacotes recebidos do vMX através da aplicação

VhostUser também são divididos baseados em IPv4 ou IPv6 e enviados para a função de triagem nh_fwd4/nh_fwd6 específica de protocolo. Essa

função nh_fwd toma uma decisão de encaminhamento baseada em controle de acesso de mídia(MAC) de destino unicast ou broadcast, que seja

compatível ao destino IPv4 local ou IPv4-em-IPv6.

A divisão v4v6, em combinação com o acompanhamento da aplicação, permite o monitoramento de pacotes indo e saindo da porta física baseado

em endereços IPv4 compatíveis, seja como origem, destino ou dentro de um pacote IPv4-em-IPv6. A configuração de tais filtros é feita via

localização de memória compartilhada no sistema do arquivo e pode ser acessada através do monitor snabbvmx Snabb <ipv4- address>.

Ao contrário do daemon Snabb do sistema de suporte de operações (OSS) para LwAFTR, Snabbvmx, ARP, descoberta de vizinho IPv6 e qualquer

outro protocolo como BFD ou IS-IS, o vMX trabalha com o BGP e passa-o transparentemente através do Snabbvmx. Isso simplifica e fortalece a

solução para o Lightweight 4over6.

O daemon Snabbvmx é controlado através de arquivos de configuração que são gerados pelo VCP vMX. Ele atualiza as entradas da tabela de

vinculação alertando o daemon Snabbvmx em execução da presença de uma nova tabela de vinculação pré-compilada. Múltiplos daemons

Snabbvmx conectados ao mesmo vMX compartilham a mesma tabela de vinculação.

O arquivo de configuração para LwAFTR, fragmentação, reconstrução e tabela de vinculação usados internamente são documentados aqui. Eles

são gerados automaticamente a cada vez que a configuração do SO Junos vMX é atualizada.

Conclusão

A VNF do AFTR Lightweight 4over6 baseada em vMX e Snabb oferece uma funcionalidade de fechamento de túnel confiável, escalável e de alto

desempenho, além de fácil de instalar. Ela escala para milhões de conexões e dúzias de interfaces 10GbE, limitada apenas pelo número de saltos

ECMP simultâneos que um roteador de gateway de datacenter suporta para IPv4 e IPv6.

A solução de roteamento virtual Juniper Networks vMX fornece uma funcionalidade de gerenciamento de plano de controle confiável, incluindo

BGP para IPv4 e IPv6, BFD e YAN personalizado para provisionamento de acordo com o diagrama softwire IEFT publicado. Enquanto isso, o Snabb

fornece um encapsulamento e desencapsulamento Lightweight 4over6 de alto desempenho com fragmentação opcional e reconstrução para

milhões de conexões. A combinação de vMX e Snabb fornece aos provedores de serviço a flexibilidade de migrar para redes IPv6 enquanto

garantem a continuidade dos serviços para usuários IPv4.

Função Virtual de Rede Lightweight 4over6 vMX

White Paper

Sobre o Snabb

O Snabb (anteriormente “Snabb Switch”) é um kit de ferramentas de rede de pacotes rápido e simples, disponível publicamente através da licença 2.0 Apache em https://github.com/snabbco/snabb.

O

Snabb foi programado usando essas principais técnicas:

Lua, uma linguagem de programação de alto nível que é fácil de aprender

LuaJIT, um compilador de tradução dinâmica que compete com C

E/S Ethernet sem sobrecarga de kernel (modo “kernel bypass”)

O

Snabb compila em um executável independente chamado de snabb. Esse binário único inclui aplicações múltiplas e executadas em qualquer

distribuição Linux/x86-64 moderna.

O Snabb lwAFTR implementa o componente AFTR do Lightweight 4-over-6 (lw4o6) que faz ponte com a Internet e também pode ser executado

independente, sem NETCONF/YANG e sem plano de controle de roteamento dinâmico. Para mais informações, visite

O Snabbvmx atualmente contribui para o projeto Snabb. Veja https://github.com/Igalia/snabb/pull/391 para o status atual.

Sobre a Juniper Networks

A Juniper Networks desafia o status quo com produtos, soluções e serviços que transformam a economia de redes. Nossa equipe co-inova com

clientes e parceiros para entregar redes automatizadas, escaláveis e seguras com agilidade, desempenho e valor. Informações adicionais podem ser

encontradas em Juniper Networks ou entre em contato com a Juniper no Twitter e Facebook.

Sede e vendas Juniper Networks, Inc.

1133 Innovation Way

Sunnyvale, CA 94089 USA Telefone: 888.JUNIPER (888.586.4737)

ou +1.408.745.2000

Fax: +1.408.745.2100

www.juniper.net

Caribe e América Latina

Entre em contato com nosso representante de vendas:

IPAM-CALA@juniper.net

Saiba mais sobre a Juniper:

www.junipernetworks.com.br

em contato com nosso representante de vendas: IPAM-CALA@juniper.net Saiba mais sobre a Juniper: www.junipernetworks.com.br