Appendix G. Differences from RFC 2178

F. Plusieurs interfaces vers le même réseau/sous-réseau (Multiple interfaces to the same network/subnet)

Il existe au moins deux façons de prendre en charge plusieurs interfaces physiques vers le même sous-réseau IP. Les deux méthodes interopéreront avec les implémentations de la RFC 1583 (et bien sûr de ce mémo). Les deux méthodes sont esquissées brièvement ci-dessous. On suppose que chaque interface s'est vu attribuer une adresse IP distincte (sinon, la prise en charge de plusieurs interfaces relève davantage d'un problème de niveau lien ou ARP qu'un problème OSPF).

Méthode 1 :
    Exécuter l'ensemble des fonctionnalités OSPF sur les deux interfaces, en envoyant et en recevant des hellos, en inondant, en prenant en charge des machines à états (FSM) d'interface et de voisin séparées pour chaque interface, etc. En faisant cela, tous les autres routeurs sur le sous-réseau traiteront les deux interfaces comme des voisins séparés, puisque les voisins sont identifiés (sur les réseaux broadcast et NBMA) par leur adresse IP.

    La méthode 1 présente les inconvénients suivants :

    (1) Vous augmentez le nombre total de voisins et d'adjacences.

    (2) Vous perdez le test de bidirectionnalité sur les deux interfaces, puisque la bidirectionnalité est basée sur le Router ID.

    (3) Vous devez considérer les deux interfaces ensemble lors de l'élection du Designated Router, puisque si vous déclarez les deux comme DR simultanément, vous pouvez confondre le briseur d'égalité (qui est le Router ID).

Méthode 2 :
    Exécuter OSPF sur une seule interface (appelez-la l'interface principale), mais inclure à la fois l'interface principale et l'interface secondaire dans votre Router-LSA.

    La méthode 2 présente les inconvénients suivants :

    (1) Vous perdez le test de bidirectionnalité sur l'interface secondaire.

    (2) Lorsque l'interface principale échoue, vous devez promouvoir l'interface secondaire au statut principal.

G. Différences avec la RFC 2178 (Differences from RFC 2178)

Cette section documente les différences entre ce mémo et la RFC 2178. Toutes les différences sont rétrocompatibles. Les implémentations de ce mémo et des RFC 2178, 1583 et 1247 interopéreront.

G.1 Modifications de l'inondation (Flooding modifications)

    Trois changements ont été apportés à la procédure d'inondation de la section 13.

    Le premier changement concerne l'étape 4 de la section 13. Désormais, les LSA MaxAge sont acquittés puis ignorés uniquement lorsque a) il n'y a pas de copie de la LSA dans la base de données et b) aucun des voisins du routeur n'est dans l'état Exchange ou Loading. Dans tous les autres cas, le LSA MaxAge est traité comme tout autre LSA, en installant la LSA dans la base de données et en l'inondant sur les interfaces appropriées lorsque la LSA est plus récente que la copie de la base de données (étape 5 de la section 13). Ce changement affecte également le contenu de la Table 19.

    Le deuxième changement concerne l'étape 5a de la section 13. La vérification MinLSArrival est destinée uniquement aux LSA reçues pendant l'inondation, et ne doit pas être effectuée sur les LSA que le routeur émet lui-même.

    Le troisième changement concerne l'étape 8 de la section 13. La confusion entre les routeurs quant à quelle instance de LSA est la plus récente peut provoquer une quantité désastreuse d'inondation dans un protocole link-state (voir [Ref26]). OSPF se protège contre ce problème de deux manières : a) le champ LS age est utilisé comme un champ TTL pendant l'inondation, pour finalement supprimer les LSA en boucle du réseau (voir la section 13.3), et b) les routeurs refusent d'accepter des mises à jour de LSA plus fréquemment qu'une fois tous les MinLSArrival secondes (voir la section 13). Cependant, il reste un cas dans la RFC 2178 où des désaccords sur le LSA le plus récent peuvent provoquer beaucoup de trafic d'inondation : répondre à d'anciens LSA en réinondant la copie de la base de données. Pour cette raison, l'étape 8 de la section 13 a été modifiée pour ne répondre avec la copie de la base de données que lorsque cette copie n'a pas été envoyée dans un Link State Update au cours des dernières MinLSArrival secondes.