Bonjour,
 
J'aimerais avoir votre avis sur un cas de routage OSPF un peu particulier.
 
Si on a un réseau OSPF avec deux area 1 et 2 et le backbone area 0.
L'area 1 contient plusieurs ABR (disons 2).
Un router interne à l'area 1 reçoit du traffic qu'il envoie vers l'area 2.
 
Si l'on est dans une configuration telle que le shortest path sur l'ensemble du domaine OSPF passe par l'ABR qui est le plus loin du router de l'area 1, quel est le chemin choisi ?
 
En d'autres termes, le router 1 et les deux ABR se trouvent dans l'area 1. Le router 1 calcule avec Dijkstra le shortest path vers les deux ABR, il sait donc comment sortir au plus vite de son area.
Cependant, en choisissant l'ABR le plus proche, le chemin à travers le backbone sera alors beaucoup plus long qu'il ne l'est avec l'autre ABR.
Le router 1 a-t-il une connaissance du coût des chemins (ABR1 - area 2) et (ABR2 - area2), et va-t-il choisir l'ABR en fonction du coût global du chemin jusqu'à sa destination, ou bien simplement choisir l'ABR le plus proche.
 
S'il y a des experts OSPF dans le coin...
 
Merci,
 
Bonne journée

le calcul des coûts cumulatifs se fait au global dans tout le réseau OSPF, le découpage en aires n'a aucune influence, tu le verras via ton show ip route

ok d'accord merci beaucoup. J'ai cherché la réponse un certain temps dans les RFC et des cours cisco et je ne trouvais pas la réponse car ce cas n'est jamais vraiment abordé.
Je vais tester avec Cisco packet tracer pour vérifier, ça sera en effet plus simple.

Cela étant, je me pose la même question pour IS-IS qui n'est par contre pas supporté par Cisco packet tracer, donc je ne pourrai pas vérifier expérimentalement.
Est-ce que le routage IS-IS dans un cas similaire est le même que OSPF, ie shortest path en tenant compte de la topologie globale du réseau ?

merci !

je réponds à ma propre question s'il y en a que ça intéresse: la réponse est non pour IS-IS. IS-IS cherche le Shortest path de la source au backbone, puis du backbone à l'area de destination.
 
Une extension a été prévue avec le RFC 2966 pour remédier au cas de suboptimal routing qu'un tel routage implique.

Plop, je suis tombé sur ce topic.
 
Concernant ISIS, mintoo tu as raison.
 
Dans ISIS, il y a 2 types d'aires:
- L2: équivalent à l'aire backbone OSPF
- L1: aire non backbone
- routeur L1L2: équivalent d'un ABR OSPF, connecté à l'aire L2 et L1, faisant la transition entre L1 et L2, donc connaissant les routes L1 et L2
 
Par défaut, une aire L1 ISIS se comporte comme une aire stub OSPF c'est à dire qu'il n'y a pas de route en dehors de l'aire L1: une (ou plusieurs) route par défaut est nécessaire pour sortir de l'aire L1. Donc un routeur L1 ne prendra en considération que la meilleure route par défaut vers un routeur L1L2. Ce routeur L1 n'a pas la vision complète des métriques ISIS, ce qui ne donne pas un routage optimal.
 
Si ce routeur L1 veut un routage optimale, il faut faire ce qu'on appelle du route leaking c'est à dire configurer les routes L2 qui sont autorisées à être injectées dans l'aire L1.
- Ainsi, si on a plusieurs routeurs L1L2 qui font du route leaking pour les mêmes routes, les routeurs L1 auront un routage optimisé vers la destination car ils la connaitront en spécifique via les différents routeurs L1L2 et non via la route par défaut
- On peut aussi configurer un seul routeur L1L2 pour faire du route leaking et laisser les autres routeurs L1L2 annoncer une route par défaut. Ainsi, les destinations correspondantes aux "routes leakées" passeront par le premier routeur L1L2, et si ce dernier tombe, la route par défaut annoncée par les autres routeurs L1L2 assurent la connectivité. Faire du route leaking sur un routeur permet de dire que ce routeur L1L2 est porte de sortie pour les destinations en question (c'est du traffic engineering)
- On peut aussi combiner différents routeurs L1L2, chacun annoncant des routes leakées différentes et forcer le chemin de sortie pour telle ou telle destination