Resumo

  • A RFC 5185 cria um caminho intra-área adicional sobre um enlace físico já usado por outra área. A mudança pode atrair tráfego que antes seguia caminhos internos mais lentos.
  • O ganho de rota precisa ser acompanhado por LSDB, SPF, FIB e tráfego antes/depois, além de uma identidade física que conte capacidade e risco apenas uma vez.

O enlace de backbone tinha folga e baixa latência. Depois que a adjacência multiárea ficou FULL, o tráfego da Área 1 abandonou os enlaces internos mais lentos e passou a usar o caminho rápido. O projeto declarou sucesso.

Na falha seguinte, uma única interrupção no circuito afetou o backbone e a Área 1 ao mesmo tempo. A mudança melhorara o caminho normal e ampliara o raio de impacto. A segunda consequência não aparecia no recibo.

A preferência que motivou a extensão

Publicada em maio de 2008 como Standards Track, a RFC 5185 descreve dois ABRs unidos por um enlace rápido no backbone. Outra área contém um caminho interno mais lento. Como OSPF prefere caminho intra-área a interárea, o tráfego pode ignorar o enlace rápido.

A extensão estabelece outra adjacência, daquela área, sobre a interface comum. O enlace passa a ser uma opção intra-área sem deixar o backbone. Virtual link não resolve o exemplo sem alterar a pertença do enlace. Endereços secundários consomem espaço, não atendem interfaces sem numeração e podem aumentar rotas. Colocar a mesma sub-rede em áreas diferentes contradiz o modelo de área.

O mecanismo muda a projeção topológica. A decisão sobre concentração, manutenção e rollback continua local.

FULL não é comprovante de circuito novo

Cada adjacência adicional recebe estrutura de interface OSPF sempre ponto a ponto, mesmo sobre outro network type. A interface FSM segue esse modelo e a neighbor FSM permanece normal. A adjacência primária continua segundo a RFC 2328.

Em meio que não seja ponto a ponto, o endereço vizinho é configurado ou descoberto fora do OSPF, e os pacotes são enviados em unicast. O Area ID separa as adjacências recebidas.

Ao chegar a FULL, a adjacência entra na Router-LSA da área como link tipo 1. Link ID é o Router ID remoto; Link Data é o IP vizinho ou o IfIndex no caso sem numeração. Não há link tipo 3 para a adjacência multiárea.

Esse estado é real e influencia SPF. Porém continua apoiado no mesmo porto, placa, fibra e contrato. Três estados FULL podem desaparecer com uma única manutenção.

A capacidade pertence ao pai físico

A RFC 3630 anuncia métrica TE, bandwidth máximo e reservável, bandwidth não reservado e grupo administrativo. Esses atributos descrevem o recurso do enlace. Copiá-los para três arestas lógicas não triplica o que o enlace entrega.

O inventário precisa de um ID físico para interface, placa, membro de LAG, circuito, provedor e shared-risk group. Adjacência primária e adicionais apontam para ele. A capacidade é deduplicada no pai; consumidores por área são listados separadamente.

Nas camadas de realidade de Heng Lu, Router-LSA e SPF formam uma representação executável. Contadores, óptica, circuito e encaminhamento formam a restrição em operação. A representação orienta a decisão, mas não pode criar matéria.

Medir a concentração faz parte do aceite

O recibo deve comparar LSDB, SPF, RIB e FIB, tráfego por destino, utilização, perda, filas e capacidade dos caminhos alternativos. Assim fica claro quanto tráfego migrou e quanto voltaria numa falha.

RFC 6987 permite anunciar métrica máxima durante manutenção ou sobrecarga; RFC 9355 permite influenciar o cálculo no sentido inverso. Esses controles ajudam a drenar, mas não provam que o tráfego saiu. A verificação final ocorre nos contadores e no caminho observado.

Se o novo caminho concentrar tráfego além do limite, o operador precisa de rollback definido antes da mudança. O sucesso não é apenas adjacency up: é o resultado de forwarding dentro da capacidade e do risco aceitos.

Compatibilidade pode produzir inventários diferentes

O extremo remoto só precisa modelar a adjacência como ponto a ponto. Configuração idêntica nos dois lados não é requisito, embora a RFC recomende simetria para facilitar representação e troubleshooting.

Isso favorece adoção voluntária, mas o registro deve guardar a diferença. Router IDs, funções ABR, interface, origem do endereço vizinho, Area ID, visão de cada ponta e circuito comum permitem reconciliar alarmes mesmo quando os nomes divergem.

Ambiguidade deve falhar na configuração

O Area ID normalmente identifica a adjacência. Um pacote de backbone pode coincidir com virtual link ou multi-area adjacency; a coincidência simultânea é erro de configuração a ser tratado antes da operação.

O mesmo princípio vale para planejamento. Se duas arestas não podem ser ligadas ou separadas com evidência física, o sistema não deve decidir pela ordem de importação. Risco desconhecido não equivale a caminhos independentes.

OSPFv3 evidencia a separação

No OSPFv3, links de Router-LSA não dependem de semântica de endereço. A RFC 5185 não anuncia prefixos da adjacência na intra-area-prefix-LSA e diz que link-LSA não deve ser anunciada. O endereço link-local pode ser aprendido no cabeçalho Hello.

Uma aresta topológica pode, portanto, existir sem novo prefixo. Inventários de topologia, endereçamento e circuito devem permanecer separados e ligados por evidência, em vez de fabricar um objeto ausente.

O recibo que mede benefício e custo

Registrar ID da mudança e snapshot; Router IDs, versões e papéis ABR; interface e origem do vizinho; circuito, placa, provedor e risco; adjacência primária e adicionais; Area IDs; network type e modelo ponto a ponto; FSMs; Link ID, Link Data, métrica e ausência de tipo 3; comportamento OSPFv3; LSDB, SPF, RIB, FIB e tráfego; capacidade única; assimetria; teste de virtual link; drain, rollback e resultado final.

A RFC 5185 oferece uma pequena coordenação comum para decisões futuras localizadas. Usá-la bem significa conservar dois fatos ao mesmo tempo: o novo caminho pode ser melhor, e o suporte físico continua sendo um só.

Fontes

  1. RFC 5185 — HTML
  2. RFC 5185 — texto
  3. Informações RFC Editor
  4. IETF Datatracker
  5. Histórico
  6. Referências
  7. Errata RFC 5185
  8. RFC 2328 — OSPFv2
  9. Informações RFC 2328
  10. RFC 5340 — OSPFv3
  11. Informações RFC 5340
  12. RFC 3630 — engenharia de tráfego
  13. RFC 6987 — stub router
  14. RFC 7770 — capacidades opcionais
  15. RFC 8665 — Segment Routing
  16. RFC 9355 — reverse metric
  17. RFC 3137 — stub router
  18. Heng Lu — camadas da realidade
  19. Heng Lu — especificação mínima e adoção voluntária
  20. Heng Lu — primazia do código em execução