Comprendre la fuite de route multicast pour les instances VRF et de routeur virtuel
Les fournisseurs de services utilisent des VPN de couche 3 pour séparer et préserver le trafic de plusieurs clients. Pour séparer les routes d’un VPN des routes de l’Internet public ou d’autres VPN, les équipements du fournisseur gèrent des tables de routage distinctes (appelées tables VRF) pour chaque VPN qui se connecte à un équipement de périphérie client. Les appareils prenant en charge les clients ou les sites appartenant au VPN peuvent accéder uniquement aux routes des tables VRF de ce VPN.
Toutefois, les fournisseurs peuvent avoir besoin de partager des services avec plusieurs clients ou sites tout en préservant la confidentialité des services généraux entre leurs clients. Les fournisseurs peuvent y parvenir en mettant à disposition certaines routes dans les tables de routage pour des instances VRF ou de routeur virtuel particulières des clients. Cette pratique est appelée fuite de route, qui permet à un équipement de partager des informations de route d’une instance de routage VRF ou routeur virtuel configurée à une autre à l’aide de stratégies internes d’exportation et d’importation de routes.
Les fournisseurs peuvent également utiliser la fuite de route pour les services de multidiffusion tels que l’IPTV et d’autres services de médias en streaming.
Implémentation des fuites de route VRF multicast statiques sur les commutateurs
Sur les commutateurs Junos OS, l’implémentation de fuite de route VRF multicast vous permet de partager statiquement des routes multicast à partir d’une instance de routage VPN de couche 3 exécutant un protocole multicast tel que Protocol Independent Multicast (PIM) avec le routeur virtuel client ou des instances VRF. Vous ne pouvez divulguer que des routes multicast statiques dont la longueur du préfixe est /32. Par conséquent, les routes sont partagées pour les groupes IGMP (Internet Group Management Protocol) et non pour une source spécifique. La version 3 d’IGMP doit être activée sur toutes les interfaces de couche 2 et de couche 3. Aucune autre version d’IGMP n’est prise en charge.
En outre, vous devez configurer une interface IRB (Integrated Routing and Bridging) pour chaque interface de couche 3. Pour vous assurer que les routes statiques multicast sont présentes dans l’instance de routage qui exécute multicast, utilisez IGMP pour ajouter les routes à chaque interface IRB configurée dans l’instance de routage. Incluez les group multicast-group-address source ip-address instructions au niveau de la [edit protocols igmp interface irb-interface-name statichiérarchie ].
Pour que la fuite de route multicast fonctionne correctement, vous devez également configurer le multicast indépendant du protocole (PIM) sur chaque interface IRB incluse dans le routeur virtuel ou l’instance VRF.
Par exemple, pour ajouter l’interface IRB,
irb.1023, à une instance de routage nomméecust-11et activer PIM sur l’interface IRB :user@switch# set routing-instances cust-11 interface irb.1023 user@switch# set routing-instances cust-11 protocols pim interface irb.1023
Cette implémentation nécessite également que vous activiez la surveillance IGMP sur toutes les interfaces client recevant du trafic multicast. Utilisez l’instruction multicast-router-interface pour configurer chaque interface client afin qu’elle fasse face à l’instance de routage multicast. Vous devez également ajouter chaque groupe multicast à chaque interface client en incluant l’instruction group multicast-group-address au niveau de la [edit protocols igmp-snooping vlan vlan-id interface interface-name] hiérarchie. Il n’est pas nécessaire de configurer un protocole multicast tel que PIM pour les instances VRF ou routeur virtuel du client.
Pour activer la fuite de route multicast, configurez des routes multicast statiques dans une instance VRF client ou de routeur virtuel pour chaque groupe multicast configuré et pointez chaque route vers la table de routage de l’instance de routage multicast. Pour configurer, incluez le static route destination-prefix/32 next-table instance-name.inet.0 groupe d’instructions au niveau de la [edit routing-instances routing-instance-name routing-options] hiérarchie.
Par exemple, pour faire fuiter la route multicast 233.252.0.0/32 vers une instance de routage client nommée cust-11:
user@switch# set routing-instances cust-11 routing-options route 233.252.0.0/32 next table HQ.inet.0
Dans cet exemple, la route multicast statique est configurée sur l’instance de routage client et pointe vers la table de routage de l’instance de routage multicast, HQ. Cette configuration garantit que le trafic multicast est transféré.