Mon blog

Le protocole de routage OSPF fonctionne en distribuant de l'information sur les interfaces du routeur, informations qui sont transmises par inondation à tous les routeurs de la zone. Cette information est structurée en LSA (Link State Advertisement) et ces LSA appartiennent à différents types, les premiers ayant été décrits dans le RFC 2328. Comme tous les routeurs de la même zone (area) doivent comprendre tous ces types, ajouter un nouveau type de LSA n'est pas facile. D'où l'idée, qui avait fait l'objet du RFC 2370, de créer un type « opaque » qui pourrait stocker de l'information spécifique à une application, sans que les routeurs aient besoin de connaitre autre chose que le fait qu'il soit opaque. C'est l'objet de notre RFC, qui remplace le 2370.

Ainsi, il sera plus facile d'étendre OSPF, comme l'avaient fait les RFC 3623 ou RFC 3630. Il suffit désormais d'enregistrer un « type de LSA opaque » auprès de l'IANA. Les routeurs qui ne connaissent pas ce type passeront les LSA sans les comprendre et sans être affectés. Le RFC 5250 ne spécifie d'ailleurs pas comment utiliser les LSA opaques, cela dépend complètement de l'application envisagée (section 2).

La section 3 décrit en détail ces nouveaux LSA. Il en existe de trois types :

• Le type OSPF 9 est réservé aux LSA opaques locaux à un segment de réseau et ne sont pas transmis aux routeurs qui sont sur d'autres segments,
• Le type OSPF 10 sert aux LSA opaques locaux à une zone OSPF,
• Et le type 11 est pour les LSA opaques diffusés dans tout un AS (à l'exception des zones « terminales » par exemple les NSSA du RFC 3101).

Le LSA opaque est composé d'un en-tête LSA normal (section 12.1 du RFC 2328) suivi de 32 bits d'information qui sont divisés en un sous-type de 8 bits (le registre IANA les nomme opaque LSA option types) et 24 bits pour les informations spécifiques à l'application. Ainsi, le sous-type 1 désigne l'application traffic engineering du RFC 3630, alors que le 4 est la router information du RFC 4970. Le reste du LSA contient les données (de longueur variable, voir l'annexe A.2).

La section 3.1 gouverne la diffusion de ces LSA opaques, par inondation (section 13 du RFC 2328). Un routeur sait que son voisin OSPF est capable de gérer des LSA opaques en regardant le bit O (comme Opaque, valeur 0x40) lu dans les paquets Database Description que les deux routeurs s'échangent.

Justement, la section 4 décrit les changements dans les structures de données du protocole. En raison de l'option O citée plus haut, la description d'un voisin OSPF doit avoir un champ de plus pour stocker cette information sur les capacités du voisin.

La section 5 est la grosse nouveauté par rapport au RFC 2370, qui avait normalisé le protocole à l'origine. Elle décrit la diffusion des LSA opaques entre différentes zones OSPF. Enfin, la section 7 décrit les questions de compatibilité avec les vieux routeurs qui ne mettent pas en œuvre les LSA opaques (ils les ignorent, et ne peuvent donc pas les transmettre à leurs voisins).

La plupart des mises en œuvre d'OSPF supportent ces LSA opaques. Avec Quagga, il faut s'assurer que le logiciel a été configuré avant la compilation avec --enable-opaque-lsa. Il suffit ensuite de mettre ospf opaque-lsa dans le fichier de configuration OSPF. IOS et JunOS disposent également de ces LSA opaques.