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

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 esgotamento1 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 Limite statefull NAT em

Lw4o6 RFC 7596
salvar IPv4 grande escala, $$$
túneis stateless

IPv6
IPv6 e IPv4

IPv6 Público
IPv4 Privado
IPv6 Público Porta IPv6 IPv4 público
IPv4 Público, $$$ compartilhado de porta restrita

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

1 https://en.wikipedia.org/wiki/IPv4_address_exhaustion
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 fxp0
KVM vMX VCP
em1
JET App
int
xe-0/0/0 Snabbvmx 0/0/0

xe-0/0/1 Snabbvmx 0/0/1

xe-0/0/2 vMX VFP

Snabbvmx 0/0/2
KVM

xe-0/0/n 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 dados2 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 .. 0/0/n estão conectadas via driver de rede virtio_net para_virtualized no Qemu no modo VhostUser, dando suporte
à transferência rápida de pacote sem cópia entre a placa de interface física e a máquina virtual convidada—nesse caso, a VFP vMX. Isso requer
uma quantidade suficiente de Hugepages no nó do computador.

Snabbvmx
O Snabbvmx é parte da pilha de rede virtualizada Ethernet de código aberto Snabb3 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 VhostUser4 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 Snabb5

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)
2 https://tools.ietf.org/html/draft-ietf-softwire-yang-00
3 https://github.com/snabbco/snabb
4 http://www.virtualopensystems.com/en/solutions/guides/snabbswitch-qemu/
5 https://github.com/Igalia/snabb/tree/lwaftr/src/program/snabbvmx
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

KVM vMX VCP

em1
Internet
JET App
int
xe-0/0/0
Snabbvmx 0/0/0
0000:81:00.0
Acesso Snabbvmx 0/0/1
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 vMX—nesse 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

KVM vMX VCP

em1
JET App
int
Internet
Snabbvmx 0/0/0

Snabbvmx 0/0/1
vMX VFP
Snabbvmx 0/0/2
Acesso KVM
IPv6 Snabbvmx
Snabbvmx 0/0/3

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
Snabbvmx 0/0/2
KVM

Snabbvmx 0/0/3

fxp0 vMX VCP

KVM

JET App
Internet

12 x 10 GbE Snabbvmx 0/0/0

100 GbE
Snabbvmx 0/0/1
vMX VFP

100 GbE Snabbvmx KVM 0/0/2

Snabbvmx 0/0/3
Acesso
IPv6

fxp0 vMX VCP

KVM

JET App

Snabbvmx 0/0/0

Snabbvmx 0/0/1
vMX VFP
Snabbvmx KVM 0/0/2

Snabbvmx 0/0/3
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
aqui.

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;
}
}

Não há dependências de liberação do SO Junos além de precisar de uma versão mínima que suporte YANG personalizado, que é a 16.1.
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 nh_fwd6 vMX VCP
a KVM
Reconstrutor6
nhame
nto
vMX VFP
Intel
Divisão Divisão Usuário
10GbE LwAfr v4v6 hospe-
v4v6
deiro

Reconstrutor4 KVM
nh_fwd4
Fragmentador4

Snabb
vmx
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
https://github.com/snabbco/snabb/tree/master/src/program/lwaftr/doc.

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. Caribe e América Latina

1133 Innovation Way Entre em contato com nosso representante de vendas:
Sunnyvale, CA 94089 USA IPAM-CALA@juniper.net
Telefone: 888.JUNIPER (888.586.4737)
ou +1.408.745.2000
Fax: +1.408.745.2100 Saiba mais sobre a Juniper:
www.juniper.net www.junipernetworks.com.br