Entrega do L3VPN: rotas privadas, uma predefinida ou uma tabela completa?

O circuito está ativo, a VRF está configurada e o fornecedor faz uma pergunta curta que decide o resto do projeto: o que o customer edge deve receber? Três respostas são comuns e nenhuma decorre do facto de existir uma pilha de etiquetas. São decisões de serviço sobre onde o tráfego sai da filial.

Percorrer a entrega por ordem é a forma mais barata de fazer isto bem. Começa-se pelo que acontece ao tráfego que não corresponde a nada, depois anotam-se os prefixos privados e o seu comportamento em falha, e só então se discute quão grande é o feed que está disposto a transportar.

Comece pelo tráfego para o qual ninguém planificou

Faça uma pergunta antes de aparecer qualquer lista de prefixos: quando um pacote não corresponde a nenhuma rota privada, para onde deve ir? Uma filial com circuito de internet próprio mantém normalmente uma predefinida local, pelo que o tráfego web comum sai pela firewall local e nunca toca no fornecedor. Nesse desenho a VPN transporta apenas os sites privados remotos, e são os prefixos mais específicos que fazem a seleção.

Uma filial que se destina a usar uma saída central é o caso oposto. Aí a predefinida aponta para dentro do serviço, e o fornecedor ou o site central é dono do encaminhamento, do routing de retorno e de qualquer tradução. Dizer "predefinida para a VPN" sem esse dono produz uma filial que resolve nomes e não chega a nada.

Os dois desenhos diferem na forma como uma falha de routing se manifesta, e é por isso que adivinhar sai caro. Com uma predefinida local, uma rota privada perdida envia esse tráfego para a internet, onde a firewall o descarta ou, pior, algo que não pretendia responde. Com uma predefinida central, a mesma perda retira totalmente o acesso à internet e o ticket chega como "a filial inteira está em baixo". Nenhuma das falhas é errada em si, mas só uma corresponde ao serviço que vendeu, e uma configuração de BGP sozinha não lhe diz qual construiu.

Anote os prefixos privados com o respetivo caso de falha

Liste os prefixos que a filial tem de alcançar e note quais estão resumidos. Um agregado um bit demasiado largo arrasta destinos desconhecidos para a VPN, e isso só está certo se o lado remoto os possuir realmente e os encaminhar.

Descreva depois o comportamento pretendido quando o serviço privado falha. Uma rota de descarte retida mantém o tráfego fora de um caminho não autorizado e produz uma interrupção limpa e esperada. Uma predefinida flutuante pode preservar a disponibilidade passando para um caminho de reserva, mas apenas se esse caminho estiver autorizado a transportar esse tráfego.

Mantenha a disponibilidade e o recurso de reserva permitido como dois requisitos separados no documento de entrega. As equipas que os fundem acabam a discutir se a filial devia ter falhado, em vez de verificarem se a política acordada foi implementada.

Verifique o que o CE realmente instalou

A intenção da configuração e o estado de encaminhamento divergem com frequência suficiente para que a verificação pertença à entrega e não à revisão do incidente. Num customer edge IOS-XE, os três comandos abaixo respondem a três perguntas diferentes: o que foi oferecido, o que foi aceite e o que está realmente a ser usado.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Execute os três no dia da entrega e não um mês depois, enquanto alguém ainda se lembra do que foi acordado. A primeira saída depende de soft-reconfiguration inbound ou de um route refresh guardado; sem um ou outro, o CE não lhe pode mostrar o que rejeitou. A segunda mostra as rotas aceites e melhores após a política. A terceira diz para onde a predefinida vai realmente, e é a linha mais útil de toda a entrega.

Execute as mesmas verificações num segundo CE se o site tiver dois acessos. A aceitação assimétrica entre dois edges é uma causa comum de "funciona a partir de um servidor e não do outro", e é invisível num diff de configuração que parece simétrico.

Qualifique um feed maior em vez de o assumir

Por vezes o cliente precisa mesmo de informação de rotas de internet dentro da VRF, para policy routing ou para uma saída central que encaminhe por prefixo. É um requisito a declarar, delimitar e orçamentar, não uma predefinida escondida. Traz memória para a RIB e a FIB, CPU para atualizações, manutenção de filtros e um dono para a tabela resultante.

Os argumentos de capacidade falham nas duas direções. Uma tabela completa não é proibida dentro de uma VRF, e também não é gratuita. Do mesmo modo, não se pode inferir o custo de hoje a partir de uma contagem antiga de rotas, e uma atribuição de etiquetas mais pequena não elimina o custo de armazenar rotas.

A especificação BGP/MPLS IP VPN discute vários arranjos de acesso à internet ao lado do próprio serviço VPN e não declara uma tabela completa nem uma predefinida obrigatórias para todos os clientes, e é essa a secção a apontar quando surge uma afirmação sobre "prática padrão": RFC 4364.

Encerre a entrega registando o conjunto anunciado, o conjunto recebido e o conjunto selecionado ao lado da política de saída acordada, e testando um destino privado, um destino público pretendido e um caso de perda de rota. Um registo assinado desses três testes resolve mais discussões do que qualquer afirmação sobre o que a maioria das redes faz.