Bond ativo-reserva do Linux em EVPN all-active: o que quebra

Coloque um bond ativo-reserva no servidor e um segmento Ethernet all-active na fabric, e metade do tráfego de retorno pode desaparecer sem que um único contador de erros se mova. Nenhuma das duas configurações está errada por si só. O problema está na entrega entre elas, onde um lado escolhe uma única porta e o outro assume que cada folha ligada consegue entregar. Siga uma trama em cada direção e a divergência torna-se óbvia.

O que o ativo-reserva faz a uma trama de entrada

O modo de bonding 1 mantém exatamente um slave no caminho de transmissão e só o troca quando o atual falha. Essa parte é bem conhecida. O que importa aqui é o lado da receção: o kernel só entrega uma trama à pilha se ela chegar pelo slave ativo, e descarta as tramas que aparecem em qualquer outro slave. Esta all_slaves_active definição existe precisamente para relaxar essa regra, e por omissão está desligada. ip -d link show bond0 imprime o valor atual ao lado do modo.

/proc/net/bonding/bond0 nomeia o slave ativo e reporta o estado da ligação de cada slave. Esse ficheiro é a única fonte honesta de qual porta está atualmente a transportar tráfego.

Um host neste modo tem apenas um caminho de receção utilizável de cada vez, escolhido localmente sem conhecimento da fabric. Se uma trama para esse host chegar pelo outro cabo, a porta do comutador conta-a como recebida, a pilha do host nunca a vê, e todos os contadores exceto o contador de descartes do próprio host parecem perfeitamente saudáveis.

O que o multihoming all-active faz a um próximo salto remoto

O multihoming EVPN descreve um conjunto de folhas que partilham um segmento Ethernet, identificado por um ESI, e anuncia esse segmento ao resto da fabric. No modelo all-active, os pares remotos instalam mais do que um próximo salto para os endereços do segmento. O unicast para o servidor pode então chegar a qualquer folha, e a fabric é livre de escolher por fluxo. É todo o sentido do desenho, e é também o pressuposto que o bond do servidor tem de cumprir.

O tráfego inundado segue outra regra. As folhas elegem um forwarder designado por segmento, pelo que broadcast, unicast desconhecido e multicast entram normalmente por um deles. Assim, unicast e inundação tomam duas decisões separadas, e só uma delas aparece no estado do bond do host.

Onde as duas eleições divergem

O kernel escolhe o seu slave ativo a partir do estado da ligação e da sua própria política. A fabric escolhe os próximos saltos a partir das rotas EVPN, e um forwarder designado a partir de uma eleição entre as folhas. Nenhum dos processos consulta o outro. Quando escolhem folhas diferentes, a falha depende da direção: o que o servidor envia sai normalmente, e as respostas desaparecem.

Existem duas saídas suportadas, e não são intermutáveis. Dê ao host um bond que a fabric possa tratar como uma única ligação lógica, o que na prática significa um bond LACP negociado com as folhas, e ambas as ligações estão realmente ativas em conjunto. Ou aceite também entrega single-active a partir da fabric, para que o segmento siga o mesmo modelo de uma porta de cada vez que o bond. O que não funciona é um segmento all-active à frente de um bond que só escuta numa porta, a menos que ative deliberadamente a receção nos slaves inativos e aceite a entrega duplicada que se segue.

Porque o cabo de reserva continua a parecer saudável

Um cabo que não transporta tráfego continua a reportar ligação ativa, e um slave de reserva num bond foi desenhado para parecer pronto. Os operadores leem isso como redundância e deixam de fazer perguntas.

Pergunte antes qual porta física a trama de retorno usou. No host, conte os pacotes recebidos por slave em vez de por bond, porque o contador do bond esconde a assimetria. Na folha, olhe para as entradas de encaminhamento da bridge para o MAC do servidor e para o conjunto de próximos saltos que a rota EVPN transporta. Se a entrada apontar para a folha cuja ligação ao host é a de reserva, o desenho está a entregar numa porta que o host ignora. Isto é uma divergência de configuração e não uma avaria de hardware, e nenhuma quantidade de monitorização do estado da ligação a revelará.

Teste a entrega nos dois sentidos, não o estado da ligação

Construa uma matriz com uma linha por falha e uma coluna por direção, e preencha com tráfego entregue em vez do estado da interface. A linha um é o funcionamento normal, e é exatamente aí que a divergência se esconde, porque o sintoma parece um problema da aplicação.

Depois retire a ligação ativa do host, retire uma folha, retire os uplinks dessa folha e reponha cada uma por vez. Após cada passo, registe o slave ativo, o estado do segmento EVPN, a entrada de encaminhamento remota e o débito observado nos dois sentidos. Uma folha que perde o caminho para a fabric enquanto a sua ligação ao host permanece ativa é o caso interessante, porque a ligação continua anunciada e pode tornar-se silenciosamente num beco sem saída. Teste com fluxos unicast novos e com o tráfego inundado de que a aplicação depende, porque os dois usam decisões de encaminhamento diferentes.

Aceite o desenho apenas quando a matriz mostrar entrega bidirecional pelo caminho pretendido. Dois cabos com ligação ativa não são esse resultado.