A adjacência está ausente, e o router no meio parece o suspeito óbvio. Ele pode ser inocente. Encaminhar os pacotes externos do túnel e participar no protocolo de encaminhamento overlay são dois trabalhos diferentes, e um equipamento pode fazer o primeiro sem fazer o segundo. Percorra as cinco verificações abaixo por ordem e pare na primeira que falhar.

Passo 1: desenhe os dois papéis

Desenhe a adjacência EIGRP pretendida como uma ligação lógica entre dois routers e, depois, desenhe os routers underlay que transportam os seus pacotes de túnel. O mesmo equipamento não tem de aparecer nas duas listas, e confundir as listas é a razão mais comum para um router de trânsito saudável ser acusado de quebrar a adjacência.

Um router de trânsito encaminha os pacotes externos com o seu encaminhamento IP e a sua política habituais. Não precisa de executar o protocolo transportado dentro do túnel protegido nem precisa de um processo EIGRP para fazer passar esses pacotes.

Passo 2: verifique o que o equipamento do meio termina

Se o router do meio termina o túnel e deve formar adjacências EIGRP com os spoke, a resposta muda por completo. Esse equipamento precisa do comportamento de encaminhamento overlay suportado, e chamá-lo trânsito não faz desaparecer o requisito de vizinho. Leia a configuração do túnel antes da configuração do encaminhamento. Essa resposta decide todas as verificações seguintes.

Portanto, a primeira pergunta real não é que protocolo ajustar. É se a caixa é um hub, um spoke, um simples salto underlay ou um serviço Layer 2 que transporta tramas entre extremos.

Passo 3: verifique o plano de controlo do vizinho

Em cada equipamento que deva ser vizinho, confirme quatro coisas: a instância EIGRP e o número de sistema autónomo, os parâmetros de autenticação, a interface que participa no processo e a instrução de rede que cobre essa interface. Uma divergência em qualquer uma delas mantém a adjacência em baixo enquanto a interface continua ativa e o ping continua a funcionar.

O RFC 7868 descreve o EIGRP como um protocolo IP com uma troca de controlo multicast, e é por isso que uma relação de vizinhança não é algo que um router intermédio possa substituir encaminhando pacotes para um destino. Ou a troca de controlo chega ao par, ou a adjacência não se forma.

Passo 4: verifique que o transporte entrega a troca de controlo

A seguir, verifique se o overlay transporta realmente o tráfego de controlo entre os extremos previstos. Inspecione o mapeamento NHRP do par e a rota externa que chega até ele, e depois confirme que a interface do túnel está ativa e deixa passar tráfego. Um ping underlay bem-sucedido prova que o caminho externo existe; não prova que a troca de controlo do overlay foi entregue.

Um serviço Layer 2 transparente, um túnel ponto a ponto e uma nuvem DMVPN multiponto entregam o multicast de formas diferentes. Siga o modelo de interface, NHRP e multicast suportado para o que está realmente implementado em vez de assumir que os três se comportam da mesma forma.

Passo 5: redesenhe a fronteira se não puder participar

Se um equipamento overlay necessário não puder executar o protocolo, altere o desenho de forma explícita. Use um protocolo ou modelo de troca suportado nessa fronteira, ou prepare um túnel de ponta a ponta adequado para que os vizinhos sejam os extremos que realmente falam entre si. Não assuma que uma rota estática transforma um não participante num relé para cada pacote de controlo.

Registe o papel de cada equipamento no diagrama e guarde-o com a configuração. O RFC 7868 define a troca de protocolo, e essa definição é a referência para perceber por que a relação de vizinhança não pode ser simulada por encaminhamento de trânsito.

Quando a adjacência continua a falhar depois das cinco verificações, os suspeitos restantes são funcionalidades de plataforma como o tratamento de multicast na interface do túnel e políticas que filtram o protocolo 88. São causas concretas e testáveis, e valem mais do que mais uma ronda de culpar o router do meio.

Artigos relacionados