Comprendre comment le trafic multicast routé de couche 2 et de couche 3 sont gérés avec OVSDB
L’implémentation par Juniper Networks Junos OS du protocole de gestion OVSDB (Open vSwitch Database) permet aux contrôleurs SDN et aux équipements Juniper Networks qui prennent en charge OVSDB de communiquer.
Cette rubrique explique comment un équipement Juniper Networks doté de fonctionnalités VXLAN (Virtual Extensible LAN) et de protocole de gestion OVSDB gère les types de trafic suivants :
(Ce scénario s’applique à tous les équipements Juniper Networks qui prennent en charge VXLAN et OVSDB.) Trafic de diffusion de couche 2, unicast inconnu et multicast (BUM) qui provient d’un VXLAN géré par OVSDB et est transféré vers des interfaces au sein du même VXLAN.
Note:Vous devez configurer explicitement la réplication du trafic unicast inconnu dans un environnement Contrail.
(Ce scénario s’applique uniquement aux équipements Juniper Networks pouvant fonctionner comme une passerelle VXLAN de couche 3 dans un environnement OVSDB-VXLAN.) Trafic multicast de couche 3 reçu par une interface de routage et de pontage intégré (IRB) dans un VXLAN géré par OVSDB et transféré aux interfaces d’un autre VXLAN géré par OVSDB.
Par défaut, le trafic BUM de couche 2 qui provient d’un VXLAN géré par OVSDB est géré par un ou plusieurs points de terminaison de tunnel virtuel logiciel (VTEP), des nœuds de service ou des nœuds de service haut de baie (TSN) dans le même VXLAN. (Dans cette rubrique, les VTEP logiciels, les nœuds de service et les TSN sont collectivement appelés réplicateurs.) Le tableau des adresses MAC (Remote Multicast Media Access Control) du schéma OVSDB pour les équipements physiques ne contient qu’une seule entrée avec le mot clé unknown-dst comme chaîne MAC et une liste de réplicateurs.
Compte tenu de l’entrée de table précédemment décrite, le trafic BUM de couche 2 reçu sur une interface du VXLAN géré par OVSDB est transféré à l’un des réplicateurs. Le réplicateur vers lequel un paquet BUM est transféré est déterminé par l’équipement Juniper Networks sur lequel le VXLAN géré par OVSDB est configuré. Une fois le paquet BUM reçu, l’entité réplique le paquet et transfère les répliques vers toutes les interfaces du VXLAN.
Au lieu d’utiliser des réplicateurs, vous pouvez éventuellement activer la réplication de nœud entrant pour gérer le trafic BUM de couche 2 sur les équipements Juniper Networks qui prennent en charge OVSDB.
La réplication des nœuds entrants est prise en charge sur tous les équipements Juniper Networks qui prennent en charge OVSDB, à l’exception des commutateurs QFX Series.
Une fois la réplication de nœud entrante activée, après avoir reçu un paquet BUM de couche 2 sur une interface dans un VXLAN géré par OVSDB, l’équipement Juniper Networks réplique le paquet, puis transfère les répliques à tous les VTEP logiciels inclus dans la table distante MPC unicast du schéma OVSDB. Les VTEP logiciels transfèrent ensuite les répliques vers toutes les machines virtuelles (VM), à l’exception des VM de service, ou des nœuds, sur le même hôte.
Lorsque les équipements Juniper Networks répliquent des paquets BUM de couche 2 vers un grand nombre de VTEP logiciels distants, les performances des équipements Juniper Networks peuvent être impactées.
Sur les interfaces IRB qui transfèrent le trafic multicast de couche 3 d’un VXLAN géré par OVSDB à un autre, la réplication des nœuds entrants est automatiquement mise en œuvre. Avec la réplication de nœud entrant, l’équipement Juniper Networks réplique un paquet multicast de couche 3, puis l’interface IRB transfère les répliques vers tous les VTEP matériels et logiciels, mais pas vers les nœuds de service, dans l’autre VXLAN géré par OVSDB. Pour le routage du trafic multicast de couche 3 d’un VXLAN géré par OVSDB à un autre, la réplication de nœud entrant est la seule option et n’a pas besoin d’être configurée.