Mapear uma porta de acesso sem etiqueta para o VNI EVPN correto
Uma trama de anfitrião sem etiqueta é classificada pela porta de acesso e depois transportada pelo VTEP como VNI. Verifique entrada, saída e modelo de serviço separadamente.
Um anfitrião Ethernet comum envia tramas sem etiqueta, e a malha EVPN ainda tem de as transportar no serviço de inquilino correto. A porta de acesso classifica a trama num segmento local, o VTEP mapeia esse segmento para um VNI, e o ponto de conexão remoto apresenta a trama como o seu anfitrião espera. O VLAN e o VNI identificam partes diferentes desse caminho e não precisam de partilhar um número. Siga o runbook abaixo por ordem, porque um erro em qualquer passo produz o mesmo sintoma: um anfitrião que transmite e não recebe nada.
Seguir uma trama através da malha
Para um serviço simples baseado em VLAN, um caminho ilustrativo é assim:
Host A: untagged frame
to access port: local VLAN 110
to VTEP A: L2VNI 50110
to VTEP B: corresponding local service
to access port: untagged frame to Host BOs números de VLAN e VNI são exemplos, não uma regra. O VLAN local é uma classificação de entrada que existe num único comutador; o L2VNI é o identificador de serviço de overlay que ambos os VTEP compreendem. A especificação de overlay RFC 8365 mantém o identificador de serviço separado da forma como um anfitrião está ligado, e nomeia três formas: baseada em VLAN, agrupada e sensível ao VLAN.
Configurar a classificação de entrada
O anfitrião tem um endereço e não alcança nada, enquanto a própria porta aparece. Decida em que modo de ligação a porta está realmente — uma porta de acesso que transporta tramas sem etiqueta ou um trunk com um VLAN nativo — e configure esse modo explicitamente. Uma trama sem etiqueta continua a sair da porta dentro de um segmento local com nome, e esse segmento é uma decisão e não um efeito secundário da plataforma. Abra a configuração em execução da porta e leia a classificação que ela realmente tem, em vez de confiar num valor predefinido do fabricante que nunca definiu.
Num comutador típico a sequência é uma mudança de modo e uma atribuição de VLAN de acesso, seguida de uma verificação de que a porta está realmente up e nesse estado. Se a porta for um trunk, é o VLAN nativo que trata as tramas sem etiqueta, e essa é uma configuração diferente com modos de falha diferentes. Registe tanto o modo como o VLAN antes de avançar.
show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan briefConfigurar o VTEP e o mapeamento de VNI
O VTEP acrescenta o encapsulamento VXLAN e o VNI. O anfitrião não gera esse cabeçalho e não precisa de saber que o serviço existe.
Mapeie o VLAN local para o L2VNI com a forma de comando suportada pela plataforma e mantenha esse mapeamento coerente nas duas extremidades do serviço. Um L2VNI de inquilino e o L3VNI usado para o encaminhamento entre sub-redes são objetos diferentes, e misturar os seus números quebra o encaminhamento sem tocar no caminho L2; e lembre-se de que uma rota de underlay funcional até ao VTEP remoto pertence a mais uma camada da montagem.
Se o mapeamento estiver errado, a trama entra na mesma na malha e simplesmente aterra no serviço errado. É por isso que a verificação é uma verificação de serviço e não uma verificação de ligação.
Configurar a apresentação de saída
Na extremidade remota o serviço recebido tem de voltar a ser aquilo que o anfitrião espera: Ethernet nu numa porta de acesso, uma etiqueta específica num trunk que controla, e um tratamento da etiqueta interna que corresponda ao modelo de serviço escolhido. Verifique a lista de VLAN permitidas no trunk antes de culpar o overlay, porque uma etiqueta que o trunk de saída não permite é descartada depois de o overlay já ter feito o seu trabalho. Confirme que o anfitrião remoto espera a apresentação que recebe e não a que o seu diagrama assumiu.
Se uma etiqueta interna sobrevive é uma propriedade do modelo de serviço que escolheu, por isso nenhum artigo pode prometer em geral removê-la ou conservá-la. Um desenho que assume um comportamento e uma plataforma que implementa o outro passam num teste de ligação e falham na aplicação.
Leia em conjunto a aprendizagem MAC local, a rota de serviço EVPN e o mapeamento do ponto de conexão remoto, e conduza a descoberta de vizinhos de que a aplicação precisa em vez de apenas um ping. Um endereço MAC aprendido noutro domínio de bridge pode ser perfeitamente válido ali e ainda assim apontar para o serviço errado.
Verificar com um único par de anfitriões
Levante um par de anfitriões e prove o caminho completo antes de acrescentar um segundo par. Depois leia o estado nos dois VTEP e confirme que o mesmo identificador de serviço aparece nas duas extremidades.
show mac address-table vlan 110
show bgp l2vpn evpn
show nve peersPara cada extremidade anote quatro valores: apresentação da porta, segmento local, L2VNI e a apresentação inversa na saída. Esse registo permite ao próximo engenheiro perceber por que o anfitrião tem uma ligação simples sem etiqueta enquanto a malha transporta um serviço de inquilino. Se uma alteração falhar, reponha a porta no VLAN anterior e volte a testar o mesmo par, para que o retrocesso seja um estado conhecido e não um palpite.