Resumo
- A variável de publicidade TE da área descrita por RFC 5329 tem padrão falso. A exceção de interface só ganha sentido dentro de uma área habilitada; presença de código e registro não demonstra operação.
- O U-bit preserva a inundação por nós que não reconhecem o LS type. Receber o LSA não prova analisar seus TLVs, identificar o enlace ou alimentar um consumidor de caminhos.
A implantação que não chegou ao fio
Uma auditoria encontra a versão correta no inventário. O binário conhece function code 10. O esquema de gestão expõe os objetos esperados. A conclusão automática é que OSPFv3 TE está ativo.
RFC 5329 descreve outro estado inicial: a publicidade TE por área começa desativada. A variável de desativação por interface tem padrão próprio e só se aplica quando a área está habilitada. Ler apenas a interface ou apenas a capacidade do software não resolve a conjunção.
O recibo de política precisa registrar área, interface, origem da configuração, horário de ativação e processo que a aplicou. Depois vem o recibo de emissão: LSA efetivamente originado com sequência e checksum. Só então é possível observar recepção, interpretação e consumo.
Inundar não significa participar do cálculo
O Intra-Area-TE-LSA tem escopo de área e U-bit ativo. Um roteador que não reconhece o tipo continua obrigado a inundá-lo no escopo. Isso impede que um nó antigo interrompa a distribuição da extensão.
O gráfico de flooding prova que o transporte de estado funcionou. Não prova que o nó criou estado TE. Um receptor que conhece o LSA ainda pode ignorar um TLV desconhecido. Um controlador pode receber a base e não usar aquela versão na decisão.
Separe os recibos: flooding, reconhecimento do LS type, parsing de cada TLV, identidade de enlace, política efetiva e consumidor. O salto entre eles é o que precisa de monitoramento.
Link State ID não é patrimônio de rede
O Link State ID é arbitrário e serve para manter múltiplos TE-LSA. RFC 5329 nega significado topológico ao campo. Usá-lo como chave patrimonial transforma reorganização de anúncios em criação e baixa de circuitos.
A identidade OSPFv3 do link usa o Neighbor ID obrigatório, formado por Neighbor Interface ID e Neighbor Router ID. Em enlaces paralelos, o Router ID se repete e o Interface ID preserva a diferença.
Endereços IPv6 locais e remotos reforçam a correlação, mas são conjuntos mutáveis. O remoto pode faltar ou ser :: em multiacesso. Ausência reduz a evidência; não prova ausência de enlace.
O campo familiar de OSPFv2 deve ser descartado
O Link ID de OSPFv2 não pode conservar a mesma semântica em OSPFv3. O documento manda usar Neighbor ID, recomenda não enviar o antigo sub-TLV e exige ignorá-lo ao receber.
Um coletor deve guardar que o campo chegou e que foi ignorado. Se o apagar, perde pista de interoperabilidade. Se o usar, concede autoridade que a versão nova retirou. Evidência bruta e valor decisório precisam de colunas diferentes.
A primeira instância governa
Neighbor ID aparece exatamente uma vez. Os outros sub-TLVs definidos no RFC não deveriam se repetir; ocorrências depois da primeira são ignoradas. Um mapa com regra de último valor sobrescreve a decisão normativa.
Preserve ordem, contagem, comprimento, padding e resultado do parser. O padding de alinhamento não entra no Length. Sem esses limites, uma divergência pode ser atribuída ao dado quando nasceu no enquadramento.
O duplicado ignorado continua importante. Pode revelar bug, transição ou entrada construída para explorar parsers diferentes. Limpar o registro antes de investigá-lo perde causalidade.
O endereço estável ainda é uma afirmação
Router IPv6 Address TLV anuncia um endereço estável e roteável que deveria ser alcançável quando há conectividade com o roteador. Não admite link-local e aparece em um único TE-LSA do originador compatível.
Esse “deveria” não é resposta de sonda. Presença em LSDB, rota instalada, ICMP, sessão de gestão e transação de aplicação são recibos independentes. Correlacione-os sem transformar intenção protocolar em resultado medido.
Fontes e limite da evidência
- RFC 5329
- RFC 5329 em texto
- Registro RFC Editor
- IETF Datatracker
- Histórico
- Registro legível por máquina
- API documental IETF
- RFC 5340
- RFC 5340 em texto
- RFC 3630
- RFC 3630 em texto
- RFC 5250
- RFC 5250 em texto
- RFC 4203
- RFC 4203 em texto
- RFC 4552
- RFC 8362
- RFC 9350
- Parâmetros OSPFv3 da IANA
- TLVs OSPF TE da IANA
- On Reality Layers
- Running-Code Primacy
- On the Agency Problem
As fontes estabelecem regras, histórico e registros, não implantação atual, produto conforme, configuração, adjacência, base TE, caminho, reserva, encaminhamento ou resultado ao usuário.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
