IPv6 numa VPN MPLS: três decisões, não uma só família de endereços
As rotas da VPN do cliente, a sessão BGP entre os PE e o transporte no núcleo são decisões separadas. Uma sessão pode correr numa família e transportar outra.
Diga «corre um L3VPN IPv6 sobre BGP IPv6» numa revisão de design, e nessa única frase escondem-se três decisões separadas. Que prefixos pertencem à VPN do cliente, que endereços transportam a sessão de encaminhamento entre as extremidades do fornecedor e que núcleo move o pacote etiquetado são escolhas independentes. Podem ser todas IPv6, podem ser misturadas, e a mistura é permitida de propósito. É deslindar as três que transforma um requisito vago em algo contra o que se pode testar uma plataforma.
Separe as três tarefas
A primeira tarefa é a rota do cliente: prefixos IPv6 que pertencem a um contexto de encaminhamento da VPN e têm de ficar fora de qualquer outro contexto. A segunda é a ligação de encaminhamento entre os routers de extremidade do fornecedor que trocam esses prefixos. A terceira é o transporte que leva o pacote etiquetado do cliente pelo núcleo até à extremidade remota. Nomear apenas uma delas ainda não é um design.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Cada tarefa tem a sua própria família de endereços, os seus modos de falha e muitas vezes a sua própria equipa. A tabela é útil precisamente porque uma única frase num documento de design tende a esmagar as três linhas numa só.
A família da rota é VPN-IPv6, não IPv6 unicast
RFC 4659 define a família BGP/MPLS IPv6 VPN, e pertencer-lhe é mais específico do que a palavra IPv6 sugere. Uma rota ali é um distinguidor de rota ligado a um prefixo IPv6, codificado em AFI 2 e SAFI 128. O IPv6 unicast comum é outra família, por isso um anúncio que num looking glass parece um prefixo pode não ser de todo o mesmo objeto. Ler mal a família é a primeira forma de este design correr mal.
A diferença morde na extremidade, onde uma rota tem de aterrar no contexto de VPN correto antes de fazer o que quer que seja. Receber um prefixo prova que a troca aconteceu e nada diz sobre a instalação. Essa lacuna produz o relatório clássico em que a sessão está de pé e o cliente continua às escuras.
A sessão pode correr numa família diferente da VPN
Nada obriga a ligação BGP entre duas extremidades a usar a família própria da VPN. A especificação permite uma sessão IPv4 ou IPv6, e o transporte de IPv6 VPN está ele mesmo definido sobre os dois tipos de núcleo. Uma sessão IPv6 não diz, portanto, nada sobre a família do que transporta, e também não escolhe o plano de dados. Três bits independentes, e o design deveria carregar os três em separado.
Isso liberta e lê-se mal com a mesma facilidade. As rotas de cliente IPv6 podem seguir numa sessão com endereço IPv4, e as rotas IPv4 numa sessão IPv6, desde que a plataforma suporte a combinação e o próximo salto se resolva. O que não pode acontecer é deixar a sessão implicar a carga útil, nem no documento de design nem na monitorização que mais tarde prova o serviço.
O próximo salto num núcleo IPv4 tem a sua própria codificação
Quando o núcleo sob a VPN é IPv4, a rota não aparece com um próximo salto que a extremidade de entrada possa usar diretamente. Chega em forma IPv6 mapeada em IPv4, e é assim que a especificação exprime a extremidade de saída quando o transporte por baixo é IPv4. O router de entrada tem então de converter esse endereço mapeado em algo que consiga realmente alcançar pelo núcleo, e a resolução é o passo que falha em silêncio.
Leia isto como uma dependência de encaminhamento e não como uma cadeia a copiar entre equipamentos. Confirme três coisas na plataforma que realmente opera: o próximo salto anunciado resolve-se num caminho utilizável, a pilha de etiquetas é aceite e o destino aterra no contexto de VPN pretendido. Se qualquer uma falhar, fica uma sessão que parece saudável e não encaminha nada, e por isso a verificação pertence ao ensaio de aceitação e não a um incidente posterior.
Escreva o requisito em quatro linhas
Um requisito que vale a pena testar nomeia quatro coisas: a família da VPN, o transporte da sessão, a codificação do próximo salto e a disposição do núcleo. Depois nomeia um prefixo de cliente a seguir de ponta a ponta: pela troca, instalação, resolução de etiquetas e caminho de regresso. «Suporta BGP IPv6» não cobre nenhuma das quatro e esconde onde vive realmente o desencontro.
Uma sessão saudável sem a troca VPN-IPv6 está incompleta, e uma rota VPN recebida sem encaminhamento a funcionar está igualmente incompleta. Manter essas como linhas de aceitação separadas torna curta a próxima conversa de diagnóstico, porque a linha que falha já está escrita.