Utilisation de la latence pour calculer les métriques OSPF

Est-il possible de configurer OSPF pour utiliser la latence dans ses calculs de coût / métrique de liaison. L'idée étant de permettre un routage basé sur les performances, les liaisons les plus rapides et les moins encombrées du réseau étant choisies dynamiquement, plutôt que de s'appuyer sur le comportement par défaut d'OSPF, ce qui fait que les liaisons 100 Mbps ont le même coût que les liaisons 1 Gbit / s.

Est-il possible de configurer OSPF pour utiliser la latence dans ses calculs de coût / métrique de liaison. L'idée étant de permettre un routage basé sur les performances, les liaisons les plus rapides et les moins encombrées du réseau étant choisies dynamiquement, plutôt que de s'appuyer sur le comportement par défaut d'OSPF, ce qui fait que les liaisons 100 Mbps ont le même coût que les liaisons 1 Gbit / s.

Réponse courte: Non, pas avec OSPF seul

Longue réponse:

La seule façon pour OSPF de calculer dynamiquement les trajets en fonction de la latence / de l'encombrement consiste à utiliser MPLS Traffic Engineering avec des optimisations hors ligne des coûts MPLS TE en fonction de vos critères ; MPLS TE utilise des LSA OSPF pour transporter des informations sur les chemins commutés d'étiquette. Cependant, MPLS Traffic Engineering est un gros marteau et de nombreuses opérations réseau ne peuvent pas gérer le flux de travail supplémentaire introduit dans l'approvisionnement ou le dépannage de MPLS TE.

Une autre réponse suggère que vous ne devez pas ajuster les coûts de liaison en fonction de la bande passante et utiliser le rôle d'un nœud pour les coûts. Je ne peux pas parler pour son réseau, mais ces conseils sont inutiles dans de nombreux cas, car le chemin le plus économique dans une topologie bien conçue suit automatiquement le cœur du réseau. Je n'essaierais pas d'ajuster une topologie inefficace avec les coûts de liaison ... faites simplement circuler le trafic à travers le cœur naturellement et assurez-vous qu'OSPF considère un 1GE comme un meilleur chemin qu'un lien FastEthernet. Cela se produira naturellement si vous disposez correctement la topologie et utilisez la bande passante de référence à coût automatique dans le cadre du processus OSPF. Assurez-vous de l'utiliser sur tous les routeurs OSPF afin qu'ils comprennent les coûts de liaison de la même manière.

Vous ne devez pas vous fier aux métriques / coûts par défaut, pas dans IGP ou STP. Ma seule question si le LAN a été conçu est de demander quel lien bloque, si l'ingénieur ne peut pas répondre sans regarder, c'est une forte indication que le réseau n'a pas été conçu.

Vous devez concevoir la façon dont vous souhaitez que le trafic circule dans des conditions de fonctionnement normal et dans des scénarios de panne, puis concevoir une norme métrique qui satisfait à ces exigences. Je préfère le faire avec du stylo et du papier, ajouter du café si cela est incliné.

Je préfère largement la norme métrique basée sur les rôles , où PP, P-PE, PE-PE, etc. ont chacun la même valeur métrique, quelle que soit la bande passante ou la latence. Autrement dit, je sais où je veux que mon trafic aille, pour moi, peu importe la latence ou la capacité, si je n'ai pas assez de capacité là où je veux que le trafic circule, je mettrai à niveau le liens.

Le rôle n'est certainement pas le seul moyen de le faire, si vous souhaitez baser votre norme métrique sur la vitesse de la liaison ou la latence mesurée, allez-y.

Quelle que soit la façon dont vous concevez votre norme métrique, elle sera entièrement statique et ignorera les conditions de liaison réelles telles que la perte de paquets, la latence, la gigue, la capacité, etc. ) pour changer les conditions du réseau, vous devez examiner RSVP ou même SDN.

Une autre option consiste à utiliser PfR ou OER, c'est-à-dire que les routeurs utilisent des sondes actives ou des données netflow pour sélectionner dynamiquement un chemin. Ou bien sûr, l'option très simple consiste à coder en dur les valeurs de coût OSPF.

L'autre considération est que vous essayez de coder une métrique statique ou voulez-vous un comportement dynamique (changements de latence avec la charge de trafic).

Enfin, comme cela a été mentionné ci-dessus, êtes-vous sûr de vouloir la complexité, si vous regardez l'EIGRP, il a une métrique de charge mais personne ne l'utilise jamais car il ajoute de la complexité opérationnelle et vous pouvez obtenir une oscillation du trafic.