Um host de uma filial abre uma conexão com um servidor de outra, e ambas as sedes ficam atrás da mesma VPN MPLS de nível 3 gerenciada. O host conhece apenas seu próprio gateway padrão e nada mais, o que está correto. O importante é que a borda de cliente local entregue o pacote à sua borda de provedor, e que o estado de roteamento VPN do provedor o entregue à filial que possui o prefixo de destino.

Percorrer um pacote pelo caminho é a forma mais rápida de ver qual parte é responsabilidade do cliente e qual parte pertence ao serviço.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Onde termina o trabalho de cada salto

A CE-A precisa de uma rota para a LAN remota apontando para sua conexão local com o provedor, não para o endereço WAN da filial remota. Depois o provedor transporta o pacote pelo próprio núcleo usando o estado de roteamento VPN, e a CE-B o entrega na LAN de destino. Em nenhum momento um host precisa entender rótulos, VRF ou o circuito de internet do outro lado.

O erro que se repete nos chamados é configurar o endereço WAN da filial B como próximo salto na filial A. As duas filiais compraram o mesmo serviço, então parece que deveriam ser vizinhas. Não são: um próximo salto precisa ser alcançável pelo desenho de roteamento que você realmente tem, e a CE remota costuma estar a muitos saltos de distância, atrás de equipamentos que você não administra. Uma rota estática construída sobre essa suposição aparece como ativa e não resolve para nada, o que é pior que uma rota ausente porque na tabela ela parece correta.

A RFC 4364 separa a troca entre a borda de cliente e a de provedor da distribuição de rotas VPN pelo provedor, e essa é exatamente a fronteira deste guia. O trabalho do cliente é dizer à sua borda o que ela pode entregar e aceitar a alcançabilidade que o serviço oferece de volta.

Sobre o que a entrega precisa concordar

Escolha o mecanismo junto com o provedor, não em torno dele. Rotas estáticas, BGP ou um acordo de protocolo de roteamento entre a CE e a PE são todos legítimos, e o OSPF tem um modelo MPLS VPN definido para essa entrega. Nada disso é motivo para construir uma adjacência OSPF entre duas bordas de cliente remotas através de um núcleo de provedor não especificado, pois é um desenho que o provedor não aceitou e não pode suportar.

Antes de colocar uma nova LAN em produção, anote quatro coisas: o prefixo, a rota local seguinte na CE, o anúncio que o provedor aceitará e as rotas que o provedor devolverá. Acrescente qualquer filtragem, limite de prefixos ou restrição entre sedes que o contrato imponha. Uma adjacência saudável é um canal de troca de informações, e não é prova de que um prefixo específico foi aceito; a sessão pode estar ativa enquanto a sua nova sub-rede está dentro de um filtro.

Depois acompanhe a resposta. A filial B precisa de uma rota de volta para a LAN de origem, e o host do lado receptor precisa do próprio gateway e das próprias permissões de serviço. Uma rota que aparece na CE-A estabelece metade do caminho de ida e volta, e metade do caminho é a razão pela qual uma direção de um teste de ping parece saudável enquanto a aplicação continua falhando.

Verifique as duas entregas antes da aprovação

Reúna o estado de roteamento nas duas bordas de cliente, confirme com o provedor que os prefixos de LAN previstos foram aceitos na VPN e então teste uma aplicação permitida em cada direção. Tabelas de rotas sozinhas não provam que a aplicação funciona, e um teste de aplicação sozinho não diz qual plano de controle falhou quando ela não funciona.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Leia as três saídas em conjunto. A primeira diz o que a borda acredita, a segunda diz o que ela aprendeu e de qual par, e a terceira diz o que ela realmente encaminhará. A divergência entre elas costuma ser um problema de política ou de recursão, e não um anúncio ausente, e vale resolvê-la antes de pedir ao provedor que investigue. Leve essas três saídas para a conversa com a operadora, porque respondem à maioria das perguntas que um engenheiro de suporte faria de outra forma.

Saiba o que o serviço não oferece

Isto é acesso roteado de nível 3. Não é um circuito de nível 2 que estende difusões entre escritórios, portanto protocolos de descoberta, aplicações dependentes de difusão e suposições de segmento compartilhado não viajam com ele. Impressão, navegação de nomes e qualquer coisa que dependa de um segmento local precisam do próprio desenho.

A separação de VPN também não é criptografia. A comutação de rótulos mantém os clientes separados dentro da rede do provedor, e não torna a carga confidencial se o contrato exigir confidencialidade. Onde isso importa, a aplicação ou uma camada sobreposta precisa fornecer.

Por fim, mantenha o modelo de serviço escrito ao lado da configuração de roteamento da sede. O próximo engenheiro que adicionar uma sub-rede deve conseguir ler quais prefixos são anunciados, quem os aceita e qual é o caminho de volta esperado: a especificação BGP/MPLS IP VPN é a referência do modelo por trás de tudo isso.

Artigos relacionados