O EVPN está ativo, mas o serviço não: quatro pontos de verificação

Alcançar o endereço do VTEP remoto prova que a rede subjacente transporta pacotes, e é tudo o que prova. O serviço do inquilino precisa de uma sessão BGP EVPN com a família de endereços correta, um VNI local ligado e operacional, uma rota originada e uma importação na extremidade remota. São quatro pontos de verificação separados, cada um com uma reparação diferente. Tratar uma rede subjacente verde como preparação do serviço é a forma mais comum de uma implantação de EVPN encravar.

Leia-os por ordem e pare no primeiro que não seja o que o desenho espera. Os pontos de verificação posteriores não podem compensar uma falha anterior.

Ponto de verificação 1: transporte até ao VTEP

Comece pela acessibilidade entre os endereços de loopback usados como origens do VTEP. A rota tem de existir na rede subjacente, o caminho tem de estar permitido, incluindo qualquer requisito de encapsulamento, e o caminho de volta tem de funcionar. Uma rota que existe mas é filtrada numa direção produz uma falha assimétrica que parece intermitente. Confirme ambas as direções antes de continuar.

Registe os endereços de origem e de destino que verificou. Um passo posterior que resolve um próximo salto através de outro endereço é um teste diferente, e tratá-los como um só é a forma como um próximo salto resolvido é culpado por uma falha de transporte.

Ponto de verificação 2: a família EVPN, não o número de sessões

Uma sessão BGP estabelecida não significa que a família de endereços EVPN foi negociada. Veja o estado específico da família para o vizinho: se a família está ativada, se foi negociada com o par e se a sessão a transporta de todo. Uma sessão ativa para IPv4 unicast que nunca negociou EVPN não mostra nada de errado num resumo geral de vizinhos, e a especificação de sobreposição EVPN trata os procedimentos de serviço e controlo como assuntos separados do transporte.

Verifique também o endereço de origem da sessão. Um emparelhamento construído sobre um endereço que não é a origem do VTEP é uma discrepância de desenho que espera explicar uma falha de encaminhamento.

Ponto de verificação 3: o serviço local está ligado

O VNI local tem de estar ligado à bridge ou ao VRF que representa o inquilino, e a plataforma tem de o reportar como operacional. O estado de pertença usado pelo modelo de replicação pode ser importante antes de qualquer MAC de host ser aprendido, por isso uma tabela de pontos finais vazia não é prova de que o serviço esteja em baixo.

Depois confirme o que o dispositivo origina realmente: a rota local para esse VNI com os route targets que o desenho especifica. Um VNI ligado mas não anunciado produz um serviço que existe localmente e em nenhum outro lugar.

Ponto de verificação 4: importação no recetor

No dispositivo recetor, compare os route targets exportados e importados em vez dos VNI numéricos. Um número de VNI coincidente não prova que a instância recetora importa o anúncio, e um route target desalinhado é invisível numa listagem de VNI. Resolva o próximo salto anunciado através da rede subjacente antes de confiar na entrada de encaminhamento. Depois leia o estado de encaminhamento da sobreposição para o serviço e não para o dispositivo como um todo.

Uma tabela de pares também pode refletir dados de plano de dados ou aprendizagem de pertença específicos da implementação. Leia a sua origem e o contexto do serviço juntamente com a rota EVPN em vez de tratar o número de linhas como prova.

Um registo que percorre o caminho

Mantenha um registo por serviço: estado local do VNI, o vizinho EVPN e a família, a rota originada e o resultado recebido e importado. Percorra esse registo desde a origem até à instalação. Quando algo falha, o registo diz qual dos quatro pontos de verificação reparar em vez de qual comando tentar.

Acrescente marcas temporais enquanto o faz. Uma importação que aparece minutos depois do anúncio é uma questão de política ou de convergência, enquanto uma que nunca aparece é uma questão de configuração, e essa diferença só é visível se anotou quando olhou.

Quando o VXLAN estático é a resposta certa

Um caminho de dados VXLAN configurado estaticamente pode funcionar com pares fornecidos manualmente enquanto a tabela EVPN permanece vazia. Não é uma implantação de EVPN avariada, é um modelo de controlo diferente. Decida qual o desenho pretende antes de diagnosticar uma tabela vazia como falha.

Um vizinho IGP na rede subjacente fornece transporte e nada mais. O estado do serviço da sobreposição é uma coisa separada para construir e uma coisa separada para verificar.