Exemple : configuration du routage multitopologique pour le transfert basé sur les classes du trafic vocal, vidéo et de données

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer l’équipement CE1 :

1. Configurez les interfaces.

   À des fins de démonstration, l’exemple place une interface Ethernet en mode bouclage et configure plusieurs adresses sur cette interface de bouclage. Les adresses sont ensuite annoncées au réseau.

2. Configurez la connexion BGP externe (EBGP) à l’équipement PE1.

3. Configurez la stratégie de routage qui annonce les adresses configurées sur l’interface fe-0/1/0.

4. Configurez la stratégie de routage qui étiquette les routes vocales avec l’attribut de la communauté vidéo et les routes vidéo avec l’attribut de la communauté vocale.

5. Appliquez la stratégie d’exportation set_community afin que les routes directes soient exportées de la table de routage vers BGP.

   Appliquez la stratégie d’exportation inject_directs pour annoncer les adresses configurées sur l’interface fe-0/1/0.

6. Configurez le numéro du système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show policy-optionset les show routing-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer l’équipement PE1 :

1. Configurez les interfaces.

   Le plan de transfert utilise un filtre de pare-feu pour indiquer la topologie de table de transfert que le trafic de table doit utiliser. Dans ce cas, vous devez configurer un filtre de pare-feu sur toutes les interfaces liées aux topologies de routage. En général, toutes les interfaces OSPF multitopologiques du cœur où les topologies sont configurées ont des filtres de pare-feu d’entrée. En outre, les interfaces entrantes, où le trafic d’un équipement CE pénètre dans un équipement PE vers le cœur, ont des filtres de pare-feu configurés. Cette configuration sur l’équipement PE1 affiche un filtre de pare-feu appliqué à l’interface entrante (connectée à l’équipement CE) et aux deux interfaces centrales (connectées à l’équipement P1 et à l’équipement P3).

2. Configurez le numéro du système autonome (AS).

3. Configurez BGP.

4. Configurez une stratégie d’auto-routage pour vous assurer que les équipements IBGP utilisent l’adresse de bouclage sur l’équipement PE1 comme adresse de saut suivant sur toutes les annonces de routage IBGP.

   Ainsi, l’équipement PE1 sert de routeur de passerelle pour les routes EBGP.

5. Appliquez la stratégie d’auto-saut suivant aux sessions IBGP.

6. Configurez les topologies voix et vidéo, qui vous permettent d’utiliser ces topologies avec OSPF et BGP.

   Les noms voix et vidéo sont locaux au routeur. Les noms ne sont pas propagés au-delà de ce routeur. Toutefois, à des fins de gestion, il est pratique d’adopter un schéma de nommage cohérent entre les routeurs dans un environnement multitopologique.

7. Appliquez les balises de communauté pour identifier les topologies voix et vidéo en configurant un nom de topologie de routage et une valeur pour la communauté BGP.

   Dans Junos OS, la prise en charge multitopologique de BGP est basée sur la valeur communautaire d’un routage BGP. Cette configuration détermine l’association entre une topologie et une ou plusieurs valeurs de communauté et remplit les tables de routage topologiques. Les mises à jour BGP qui ont une valeur de communauté correspondante sont répliquées dans la table de routage topologique associée. Vous décidez quelles valeurs de la communauté BGP sont associées à une topologie donnée.

   Cette configuration entraîne l’ajout des mises à jour BGP reçues avec la valeur de la communauté Target:40:40 à la table de routage topologique :voice.inet.0 (en plus de la table de routage par défaut inet.0). Les mises à jour reçues avec la valeur de la communauté target:50:50 sont ajoutées à la table de routage topologique :video.inet.0 (en plus de la table de routage par défaut inet.0).

8. Activez et désactivez OSPF multitopologique sur des interfaces particulières.

   Activez les désignations OSPF multitopologiques uniquement sur les interfaces souhaitées, comme illustré en figure 1. Sur l’interface fe-1/2/1.6 face à l’équipement P1, activez la topologie vocale et désactivez la topologie vidéo. Sur l’interface fe-1/2/2.9 face à l’équipement P3, activez la topologie vidéo et désactivez la topologie vocale.

   Lorsqu’un ID de topologie est configuré sous OSPF, la topologie est automatiquement activée sur toutes les interfaces sous OSPF. Pour désactiver une topologie ou ajouter une métrique, vous devez ajouter une configuration explicite.

   À des fins de lisibilité, chaque topologie est configurée sous chaque interface OSPF souhaitée, même si ce comportement par défaut se produit lorsque l’ID de topologie est configuré. Configurez des valeurs métriques supérieures sur un lien pour rendre la liaison moins préférée qu’une autre liaison disponible.

9. Configurez le filtre de pare-feu.

   Une fois les topologies de routage configurées, le trafic doit passer par un filtre de pare-feu pour utiliser les tables de transfert de topologie de routage. Pour les topologies de routage de base, lorsque le trafic pénètre pour la première fois dans le réseau central, appliquez un filtre de pare-feu d’entrée à l’interface entrante. En outre, ajoutez des filtres de pare-feu aux interfaces où OSPF multitopologique est configuré. Tous les routeurs doivent utiliser le même filtre de pare-feu pour associer les paquets à une topologie afin d’assurer un transfert cohérent et d’éviter les boucles de routage ou les pertes de paquets.

   Le plan de transfert gère le trafic à mesure qu’il pénètre dans le routeur et sort d’une interface particulière. Pour inspecter le trafic et utiliser une table de transfert topologique spécifiée pour effectuer des recherches au saut suivant, configurez un filtre de pare-feu d’entrée sur chaque interface où la prise en charge de la topologie de routage est souhaitée. Utilisez un filtre de pare-feu régulier pour identifier les caractéristiques des paquets.

   En général, pour se différencier au niveau de l’application, il est pratique d’utiliser des points de code DiffServ (DSP). Lorsqu’un filtre de pare-feu correspond, le pare-feu demande à la recherche de route d’utiliser une table de transfert topologique particulière. Les attributs de paquets sont identifiés dans la clause from , suivie d’une clause indiquant la table de transfert topologique à utiliser dans les recherches de sauts suivants. Cette configuration informe le routeur quel trafic utilise une table de transfert de topologie de routage et quel trafic utilise la table de transfert par défaut. Le dernier terme, nommé par défaut, spécifie l’utilisation de la table de transfert par défaut.

   Ces configurations de pare-feu affichent les adresses source et les DSP utilisés pour trier la voix, la vidéo et le trafic par défaut. Les DSP sont pratiques parce que vous pouvez les définir au niveau ou à proximité d’un équipement CE et parce que les informations sont intactes sur le réseau. Par exemple, ici, la classe de service (CoS) est configurée pour accélérer le trafic. Les DSP sont également pratiques lorsque la même adresse IP est utilisée pour différentes applications.

10. Activez le CoS sur les interfaces.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show policy-options, show routing-options, show firewallet show class-of-service les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

But

Vérifiez que les interfaces OSPF sont configurées pour appartenir à une ou plusieurs topologies.

Action

Depuis le mode opérationnel, saisissez la show (ospf | ospf3) interface interface-name detail commande.

Sens

Cette sortie montre que la topologie vocale a été ajoutée à l’interface fe-1/2/1.6 sur l’équipement PE1. Le nom de la topologie est voix et mt-ID 126. La topologie vidéo est désactivée sur cette interface. Le coût de l’interface est de 10.

Le routeur-LSA créé et inondé par le routeur comprend toutes les informations topologiques pertinentes pour des interfaces spécifiques, telles que MT-ID et métrique. Si le MTR n’est pas configuré sur une interface OSPF, le routeur-LSA n’inclut aucune information sur la topologie de cette interface. Les voisins OSPF peuvent ou non prendre en charge OSPF multitopologique. Autrement dit, une liaison particulière n’est pas utilisée pour calculer les routes OSPF pour une topologie, sauf si les routeurs des deux extrémités de la liaison annoncent cette liaison dans le cadre de la topologie. Si osPF multitopologique n’est pas pris en charge dans les routeurs OSPF voisins ou n’est pas configuré pour le faire, les informations de topologie dans les LSA reçues par le voisin sont ignorées.

But

Assurez-vous que les routes sont dans les tables de routage attendues et que les communautés attendues sont rattachées aux routes.

Action

À partir du mode opérationnel, saisissez la show route detail commande sur l’équipement PE1.

Sens

Ce résultat affiche le routage BGP 11.19.130.0/24 avec la valeur de la communauté target:40:40. Comme le routage correspond aux critères de la topologie vocale, il est ajouté aux tables de routage par défaut et voix (inet.0 et :voice.inet.0). L’équipement PE1 apprend le routage de l’équipement CE1 à EBGP, puis l’injecte dans IBGP.

But

Vérifiez le protocole saut suivant et le saut suivant de transfert.

Action

À partir du mode opérationnel, saisissez la show route detail commande sur l’équipement PE2.

Sens

Un cœur IBGP typique a des routes BGP avec des sauts suivants de protocole qui sont résolus à l’aide des routes IGP sous-jacentes. Les routes IBGP d’une table de routage topologique ont des adresses IP de protocole au saut suivant. Par défaut, la même table de routage topologique est utilisée pour rechercher et résoudre l’adresse IP du protocole à un saut suivant de transfert. Cette sortie de l’équipement PE2 affiche le même routage BGP que dans l’exemple précédent : 11.19.130.0/24. Le routage est présenté sous un angle différent, c’est-à-dire de l’équipement PE2 en tant que route IBGP. De même, ce routage IBGP est ajouté à la fois à inet.0 et :voice.inet.0 sur l’équipement PE2. Cependant, alors que chaque route a le même protocole saut suivant, chaque route a un saut suivant de transfert différent (ge-0/0/3.0 au lieu de ge-0/1/4.0). La raison de cette différence est que lorsque l’adresse IP du protocole 10.255.165.93 est résolu, il utilise la table de routage correspondante (inet.0 ou :voice.inet.0) pour rechercher le saut suivant du protocole.

But

Vérifiez le protocole saut suivant et le saut suivant de transfert.

Action

À partir du mode opérationnel, saisissez la show route commande sur l’équipement PE2.

Sens

Cette sortie de l’équipement PE2 affiche le protocole 11.19.130.0/24, qui est l’adresse IP 10.255.165.93, démontrant ainsi comment IBGP route 11.19.130.0/24 résout son protocole prochain saut. Les sauts suivants de transfert de 10.255.165.93 correspondent aux sauts suivants de transfert IBGP de la route 11.19.130/24, comme illustré dans l’exemple précédent. Observez ici que l’adresse IP 10.255.165.93 est également dans la table de routage :video.inet.0. Cette adresse est l’adresse de bouclage de l’équipement PE1 et réside donc dans les trois tables de routage. Cet exemple montre également comment le trafic entrant dans l’équipement PE2 destiné à 11.19.130.0/24 sort de différentes interfaces selon la topologie associée. Le trafic réel est marqué de telle sorte qu’un filtre de pare-feu peut diriger le trafic vers une table de routage topologique particulière.

But

Assurez-vous que les topologies attendues sont activées sur le voisin OSPF.

Action

À partir du mode opérationnel, saisissez la show ospf neighbor 10.0.0.21 extensive commande sur l’équipement P2.

Sens

Cette sortie P2 de l’équipement affiche le pe2 voisin OSPF (10.0.0.21), où la multitopologie OSPF par défaut et la vidéo sont des participants OSPF multitopologiques. L’indicateur bidirectionnel indique que le voisin est configuré à l’aide du même ID OSPF multitopologique.

But

Vérifiez les liens où les topologies vidéo et vocale sont activées.

Action

À partir du mode opérationnel, saisissez la show ospf database lsa-id 10.255.165.203 extensive commande sur l’équipement P2.

Sens

Cette sortie P2 de l’équipement affiche le routeur-LSA à l’origine de l’équipement PE2. Le LSA affiche des liaisons où les topologies vidéo et vocale sont activées (en plus de la topologie par défaut).

But

Assurez-vous que les chemins attendus sont utilisés.

Action

À partir du mode opérationnel, saisissez la traceroute commande sur l’équipement CE1.

Le premier exemple de sortie montre un traceroute sur la topologie vocale va de l’équipement CE1 à l’équipement CE2 où les DSP sont définis. Les routes sont résolues sur :voice.inet.0. Ce chemin traceroute suit le chemin vocal CE1-PE1-P1-P2-PE2-CE2

Cette sortie affiche un chemin trace de l’équipement CE1 à l’équipement CE2 pour la voix où aucun DSP n’est défini. Les routes sont résolues sur inet.0, et le chemin qui en résulte est différent du cas précédent où les DSP sont définis. Ce chemin traceroute suit le chemin par défaut CE1-PE1-P4-PE2-CE2.

Cette sortie affiche un chemin de trace de l’équipement CE1 à l’équipement CE2 pour le trafic vidéo où le filtre de pare-feu est basé sur l’adresse de destination. Les routes sont résolues sur :video.inet.0 . Ce traceroute suit le chemin vidéo CE1-PE1-P3-P4-PE2-CE2.

Cette sortie affiche un chemin de trace de l’équipement CE1 à l’équipement CE2 pour la vidéo où les DSP sont définis. Les bits DSCP ordonnent à l’équipement PE1 d’utiliser la table topologique :voice.inet.0. Comme il n’y a pas d’entrée dans la table de routage vocal pour les routes vidéo, le trafic est interrompu.