Usando latência para calcular métricas OSPF

É possível configurar o OSPF para usar a latência nos cálculos de custo / métrica do link. A idéia é permitir o roteamento baseado no desempenho, através do qual os links mais rápidos e menos congestionados da rede serão escolhidos dinamicamente, em vez de depender do comportamento padrão do OSPF, o que resulta em links de 100 Mbps com o mesmo custo que os links de 1 Gbps.

É possível configurar o OSPF para usar a latência nos cálculos de custo / métrica do link. A idéia é permitir o roteamento baseado no desempenho, através do qual os links mais rápidos e menos congestionados da rede serão escolhidos dinamicamente, em vez de depender do comportamento padrão do OSPF, o que resulta em links de 100 Mbps com o mesmo custo que os links de 1 Gbps.

Resposta curta: Não, não apenas com OSPF

Resposta longa:

A única maneira de o OSPF calcular dinamicamente os caminhos com base na latência / congestionamento é usar o MPLS Traffic Engineering com otimizações offline dos custos do MPLS TE com base em seus critérios ; O MPLS TE usa LSAs OSPF para transportar informações sobre os caminhos comutados da etiqueta. No entanto, a MPLS Traffic Engineering é um martelo pesado e muitas operações de rede não podem lidar com o fluxo de trabalho adicional introduzido no provisionamento ou solução de problemas do MPLS TE.

Outra resposta sugere que você não deve ajustar os custos do link com base na largura de banda e usar a função de um nó para os custos. Não posso falar por sua rede, mas essa orientação é desnecessária em muitos casos, pois o caminho de custo mais baixo em uma topologia bem projetada segue automaticamente o núcleo da rede. Eu não tentaria ajustar uma topologia ineficiente com custos de link ... apenas faça o tráfego fluir naturalmente pelo núcleo e garanta que o OSPF veja um 1GE como um caminho melhor do que um link FastEthernet. Isso naturalmente acontecerá se você definir bem a topologia e usar a largura de banda de referência de custo automático no processo OSPF. Certifique-se de usar isso em todos os roteadores OSPF para que eles entendam os custos do link da mesma maneira.

Você não deve confiar nas métricas / custos padrão, não no IGP ou no STP. Minha única pergunta sobre se a LAN foi projetada é perguntar qual link está bloqueando; se o engenheiro não pode responder sem olhar, é uma forte indicação de que a rede não foi projetada.

Você deve projetar como deseja que o tráfego flua em operação normal e em cenários de falha e, em seguida, projetar o padrão métrico que atenda a esses requisitos. Prefiro fazer isso com caneta e papel e adicionar café, se assim for.

Eu prefiro muito o padrão de métrica baseado em função , onde PP, P-PE, PE-PE, etc, cada um tem o mesmo valor de métrica, independentemente da largura de banda ou latência. Ou seja, eu sei para onde quero que meu tráfego vá; para mim, não importa qual é a latência ou qual a capacidade, se eu não tiver capacidade suficiente para onde o tráfego flua, atualizarei o links.

A função baseada em funções certamente não é a única maneira de fazê-lo. Se você deseja basear seu padrão de métrica na velocidade do link ou na latência medida, vá em frente.

Independentemente de como você projeta seu padrão de métrica, ele será totalmente estático e desconhecerá as condições reais do link, como perda de pacotes, latência, jitter, capacidade etc. ) para alterar as condições da rede, é necessário analisar o RSVP ou mesmo o SDN.

Outra opção, se usar roteadores PfR ou OER, use sondas ativas ou dados de fluxo de rede para selecionar um caminho dinamicamente. Ou, é claro, a opção muito simples é codificar os valores de custo do OSPF.

A outra consideração é que você está tentando codificar uma métrica estática ou deseja um comportamento dinâmico (a latência muda com a carga do tráfego).

Por fim, como mencionado acima, você tem certeza de que deseja a complexidade; se você observar o EIGRP, ele possui uma métrica de carga, mas ninguém nunca usa porque adiciona complexidade operacional e pode obter oscilação do tráfego.