Rota nula no NX-OS EVPN: manter o descarte dentro de um único tenant

O pedido chega como uma alteração de uma linha: bloquear um endereço. Adiciona uma rota de host para Null0 dentro do contexto do tenant, o prefixo desaparece da tabela local como esperado, e então começam as perguntas. A rota saiu do equipamento? Os VTEP remotos descartaram, ou simplesmente perderam a acessibilidade? Há agora um segundo tenant afetado?

Uma rota estática local correta responde apenas à primeira dessas perguntas, e é por isso que uma alteração de blackhole é, na realidade, três resultados revistos e não um único comando.

O que a alteração tem de produzir realmente

Começa por escrever os três resultados. O tenant previsto tem de descartar o destino localmente. Só a rota autorizada pode ser exportada, sem mais nada a viajar com ela. Cada VTEP recetor tem de selecionar a ação de descarte prevista e não um caminho diferente.

Cada resultado tem as suas próprias provas e nenhum implica os outros. Uma rota Null0 local produz descarte local e, sem redistribuição, não exporta absolutamente nada. Uma rota redistribuída sem a community acordada chega como um prefixo comum e é reencaminhada. Uma community sem a política de receção pode ser ignorada por completo.

Escrever primeiro os resultados também te protege de uma falha comum: uma alteração que parece funcionar porque o destino já estava inacessível por um motivo não relacionado. Se não consegues descrever como distinguirias os dois casos, o teste de aceitação ainda não está desenhado.

A instrução local só faz a primeira parte

Em NX-OS da linha 10.4(x), a rota nula fica dentro do contexto VRF do tenant e não num único comando que nomeie a VRF. O fragmento é curto e não é, de modo algum, uma configuração EVPN completa.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

O endereço é um prefixo de documentação, não um alvo. Repara na diferença de sintaxe em relação ao IOS, onde o nome da VRF aparece dentro do próprio comando de rota, e confirma a forma suportada para a versão que realmente executas antes de colar seja o que for.

Por si só, esta linha descarta o tráfego para esse host dentro de TENANT_A e não faz mais nada. Não marca a rota, não a seleciona para BGP e não define uma community. São decisões de configuração separadas, e cada uma é um ponto onde a alteração pode ser demasiado estreita para funcionar ou demasiado ampla para ser segura.

O descarte local também afeta o tráfego legítimo para o mesmo destino. Se a intenção é parar uma fonte abusiva enquanto os utilizadores reais ainda precisam do endereço, uma rota nula é a ferramenta errada e vais aprendê-lo na primeira chamada de suporte.

Exportação e importação são acordos separados

A redistribuição é onde o âmbito é decidido. Restringe os prefixos elegíveis à mitigação aprovada, mantém-na dentro do tenant e limita os peers de origem aos que constam do desenho. Redistribuir todas as rotas estáticas porque uma rota de host marcada precisa de viajar é a forma como uma alteração de manutenção se torna um incidente de encaminhamento.

A community BLACKHOLE é um acordo sobre um valor bem conhecido, não uma autorização para qualquer vizinho descartar qualquer endereço. O RFC 7999 descreve-a nesses termos, e a fronteira de confiança sobre quem a pode anunciar faz parte do desenho e não é um detalhe de implementação.

O lado recetor precisa da sua própria configuração. Em NX-OS, as rotas nulas de tipo 5 exigem tratamento com route-map no VTEP para selecionar o comportamento de descarte, o que está documentado juntamente com os passos de exportação. Um dispositivo emissor que marca corretamente e um recetor que ignora a marca produzem uma alteração que parece aplicada e que reencaminha o tráfego mesmo assim.

Revê o route-map quanto a efeitos secundários enquanto estás lá. Uma política nova e restritiva pode suprimir acessibilidade legítima de prefixos não relacionados, e esse dano aparece mais tarde do que o blackhole e é mais difícil de lhe atribuir.

Escreve a retirada antes da inserção

Regista o proprietário do destino, o motivo, o aprovador e uma validade antes de configurar seja o que for. Um descarte sem validade torna-se uma entrada permanente cuja origem ninguém recorda, e a pessoa seguinte que depurar o endereço tratá-la-á como uma parte normal da rede.

Mantém um caminho de gestão independente que não dependa da rota que estás a alterar. Se a mitigação cobrir um endereço que usas para chegar ao equipamento, criaste um bloqueio com passos extra.

Nomeia o controlo exato que remove a mitigação e testa essa remoção num laboratório ou numa janela que possas permitir-te. Uma retirada que ninguém ensaiou é um plano e não um procedimento.

Aceita com provas, não com a saída do comando

Verifica o estado de encaminhamento selecionado e o estado de reencaminhamento nos VTEP previstos, e verifica um destino vizinho que deve permanecer intacto. Confirma que nenhum outro tenant importou o prefixo, porque a fuga entre tenants é o modo de falha que transforma uma ação de manutenção num incidente.

Depois retira e verifica que a rota normal e o serviço regressam. O guia de rotas nulas do NX-OS EVPN para a versão 10.4(x) documenta a marcação, a redistribuição e a política de receção aqui descritas, e é a referência com que deves comparar a tua própria versão.