Resumo

  • Route Target Constraints transforma o interesse de importação dos PEs em estado de divulgação por par: membership NLRI segue rumo às fontes, e a alcançabilidade VPN compatível retorna pelo grafo inverso.
  • Uma mudança só está provada com AFI 1/SAFI 132 negociado, membership exato, sincronização limitada, diferenças de Adj-RIB-Out, política de segurança independente e evidência de VRF, rótulo, FIB e pacotes.

O PE de origem tem a rota. O novo VRF do destino importa o Route Target correto. Todas as sessões no caminho estão Established e o RR não registra pressão de recursos. Mesmo assim, a tabela VPN do receptor não mostra o prefixo.

O impulso natural é procurar um anúncio perdido no sentido fonte-destino. Mas a primeira ausência pode estar no sentido oposto. Sem o RT Membership NLRI do receptor, o RR não tem base para incluir aquela rota no filtro de saída daquele par. Ele não perdeu a rota: nunca recebeu a declaração de interesse necessária para revelá-la.

Esse é o mecanismo de RFC 4684, conhecido como RTC ou RT-Constrain. Em uma distribuição densa, todos os PEs podem receber muitas rotas VPN e descartar localmente as que nenhum VRF importa. Com RTC, cada receptor anuncia seu interesse, o RR deriva um filtro por vizinho e devolve somente os NLRI VPN que combinam.

O ganho é maior quando os interesses são esparsos. Reduz estado, processamento e atualizações. Ao mesmo tempo, cria um plano operacional próprio: a existência de uma rota na fonte não prova que ela fazia parte do perímetro de divulgação do receptor.

O Route Target abre uma possibilidade, não conclui o serviço

RFC 4364 separa Route Distinguisher e Route Target. O RD diferencia prefixos VPN potencialmente sobrepostos. O RT é uma comunidade estendida usada nas políticas de exportação e importação dos VRFs.

Se um RT da rota coincide com um RT de importação do VRF, a rota se torna elegível. Ela ainda pode perder na seleção BGP, ser rejeitada por política, falhar na recursão de próximo salto ou rótulo e não chegar à FIB. Mesmo uma FIB correta não encerra a prova de pacotes.

RTC não altera essa semântica. O membership informa demanda de distribuição, não identidade de cliente. Não cria VRF, não autentica quem nomeia um RT, não valida o NLRI VPN e não demonstra entrega.

Por isso, uma rota ausente pode nascer em fronteiras diferentes: origem, recepção no RR, interesse RTC, reflexão de membership, filtro derivado, VPN Adj-RIB-Out, importação no PE, seleção, rótulo, FIB ou dados. O diagnóstico deve encontrar a primeira fronteira sem o estado esperado.

A demanda sobe; a rota desce

O grafo de RFC 4684 é inverso. O receptor anuncia um NLRI que representa {AS de origem, Route Target} na direção dos sistemas que mantêm ou distribuem as rotas. Os anúncios VPN correspondentes percorrem depois o caminho contrário.

Membership é estado BGP, não uma ordem remota. Ele passa por seleção, política e route reflection. É transportado em MP_REACH_NLRI e MP_UNREACH_NLRI, definidos em RFC 4760, com AFI 1 e SAFI 132. Fora a rota padrão, a chave contém quatro octetos de origin AS e oito de Route Target, em prefixos de 32 a 96 bits.

O prefixo de comprimento zero é o default RT membership. Ele diz que o par aceita receber todo o conjunto VPN relevante dessa relação. Não é uma rota IP default, não identifica um cliente universal e não manda instalar todas as rotas.

Há funções de RR e fases de migração em que distribuição densa é deliberada. Ainda assim, o default membership deve ser tratado como exceção mensurável: ele diminui o benefício de filtragem, eleva o custo de convergência e amplia a informação exposta.

Negociar a família não comprova o anúncio

Os dois lados precisam negociar AFI 1/SAFI 132 no OPEN para trocar RTC. Essa capacidade comprova apenas que o canal existe. Não comprova que determinado membership foi originado, recebido ou selecionado, nem que o filtro esperado alterou o Adj-RIB-Out VPN.

Configuração também não basta. A prova mínima inclui as duas visões de capability, UPDATE exato, RIB RTC recebida, caminhos de membership relevantes, política aplicada e filtro de saída por par.

A nota da Cisco sobre Route Target Constraint mostra, em sua família de produtos, import RTs de VRF produzindo atualizações rtfilter e filtros recebidos no RR. A referência da Juniper para family route-target apresenta o PE informando interesse e o RR enviando somente as rotas compatíveis.

Sintaxe e defaults não são portáveis. O comando Cisco bgp default route-target filter e os controles Juniper Route Target Filtering documentam decisões locais. A presença deles não prova negociação ou recepção real de membership RFC 4684.

Um único melhor caminho pode apagar receptores

Vários PEs do mesmo AS podem originar o mesmo prefixo {origin AS, RT}. Se o RR considerasse só o melhor caminho iBGP comum, a direção de demanda de outros clientes poderia desaparecer, embora todos precisassem das rotas correspondentes.

RFC 4684 exige que todos os caminhos iBGP disponíveis daquele prefixo RT participem da construção do filtro e modifica a divulgação do membership local. O procedimento depende de uma topologia de reflexão coerente, como a de RFC 4456, mas vai além da seleção comum de alcançabilidade.

Não é ADD-PATH de VPN. O objetivo não é entregar múltiplas alternativas de uma rota; é preservar todas as direções de interesse. “O RT está na tabela” não responde quais PEs pediram, quais caminhos o RR reteve nem qual conjunto VPN foi liberado a cada vizinho.

Join e leave alteram um grafo vivo

Ao receber anúncio ou retirada de membership, o emissor deve reavaliar os VPN RIB-OUTs e produzir o mínimo de anúncios e retiradas para chegar ao novo estado. Commit de VRF não fecha join; remoção de configuração não fecha leave.

No join, provar intenção aprovada, origem de membership, recepção e reflexão, expansão do filtro, entrada em Adj-RIB-Out, recepção no PE, importação no VRF, resolução de rótulo e next hop, FIB e pacotes. No leave, verificar antes que nenhum outro VRF ainda precise do RT e que apenas rotas sem outra combinação ativa sejam retiradas.

Uma rota pode carregar vários RTs, e um VRF pode importar vários. Um total inalterado pode esconder a troca de uma rota correta por uma indevida. A reconciliação deve comparar identidades e atributos exatos, inclusive durante migrações entre RRs.

EoR encerra a espera inicial

RFC 4684 recomenda um End-of-RIB para RTC mesmo sem Graceful Restart. Um RR pode aguardar esse sinal antes de liberar os anúncios VPN iniciais, evitando tomar um conjunto parcial como final.

A espera precisa ter limite; o default especificado é 60 segundos. Não é um objetivo universal, mas impede que a otimização cause ausência indefinida. Registrar timer efetivo, horário do EoR e comportamento após expiração é parte da evidência.

RTC UPDATE não é Route Refresh. Um altera interesse atual; o outro solicita nova divulgação do estado de exportação. RFC 5291 define ORF como entradas tipadas levadas por ROUTE-REFRESH. RFC 7543 mostra Covering Prefix ORF provocando membership RTC para buscar rotas faltantes, uma composição posterior e não uma exigência do RTC comum.

Seletividade não concede confiança

RFC 4684 declara que filtros de saída derivados de RT membership não se destinam à segurança. Em fronteiras administrativas, filtros independentes de NLRI de entrada e saída continuam necessários, assim como política sobre o próprio membership.

O anúncio expressa interesse de um peer. Não autentica cliente, contrato ou direito de nomear qualquer RT. Não valida a rota VPN e não limita sozinho o plano de dados. Se o peer amplia interesse e o emissor o trata como autorização, amplia também a divulgação.

O controle independente deve cobrir namespaces RT aprovados, papéis dos pares, traduções em bordas, membership de entrada, VPN NLRI de saída, limites de estado, registro e rollback. RTC opera dentro dessa autorização; não a substitui.

Evidência completa atravessa os dois sentidos

O modelo Adj-RIB-In, Loc-RIB e Adj-RIB-Out de RFC 4271 ajuda a não transformar uma tela em prova total. Para RTC, ele deve abranger as famílias de membership e VPN.

Começar no receptor: intenção VRF e import RTs aprovados, capability RTC, UPDATE de membership, política e todos os caminhos iBGP relevantes. No RR, preservar RIB RTC e filtro por vizinho. Depois seguir a rota VPN da fonte pelo Loc-RIB e Adj-RIB-Out até a RIB VPN do PE.

Concluir com importação, seleção, rótulo, próximo salto, FIB e canários positivos e negativos. Repetir na retirada, migração de RR e upgrade. Só assim a reversão prova que a antiga autoridade de divulgação terminou.

Fontes