Routage multicast et routage asymétrique sur cluster de châssis
La prise en charge du routage multicast dans un cluster de châssis permet à différents protocoles de multidiffusion d’envoyer le trafic à travers les interfaces à plusieurs destinataires. Le routage asymétrique est la situation dans laquelle les paquets de l’hôte source à l’hôte de destination suivent un chemin différent de celui des paquets de l’hôte de destination à l’hôte source. Pour plus d’informations, consultez les rubriques suivantes :
Présentation du routage multicast sur un cluster de châssis
La prise en charge du routage multicast entre les nœuds d’un cluster de châssis permet aux protocoles de multidiffusion, tels que PIM (Protocol Independent Multicast) versions 1 et 2, IGMP (Internet Group Management Protocol), SAP (Session Announcement Protocol) et DVMRP (Distance Vector Multicast Routing Protocol), d’envoyer le trafic entre les interfaces du cluster. Notez toutefois que les protocoles de multidiffusion ne doivent pas être activés sur l’interface de gestion du châssis () ni sur les interfaces de fabric (fxp0fab0 et fab1). Les sessions de multidiffusion sont synchronisées sur l’ensemble du cluster et gérées pendant les basculements de groupe redondants. Pendant le basculement, comme pour d’autres types de trafic, il peut y avoir une perte de paquets multicast.
Le transfert de données multicast dans un cluster de châssis utilise l’interface entrante pour déterminer si la session reste active ou non. Les paquets sont transférés au nœud homologue si l’interface sortante d’une session leaf se trouve sur l’homologue plutôt que sur le nœud de l’interface entrante. Le routage multicast sur un cluster de châssis prend en charge les tunnels pour les interfaces entrantes et sortantes.
Le trafic multicast a une direction ascendante (vers la source) et aval (vers les abonnés) dans les flux de trafic. Les appareils répliquent (fanout) un paquet multicast unique sur plusieurs réseaux contenant des abonnés. Dans l’environnement de cluster de châssis, les distributions de paquets multicast peuvent être actives sur l’un ou l’autre nœud.
Si l’interface entrante est active sur le nœud actuel et sauvegarde sur le nœud homologue, la session est active sur le nœud actuel et sauvegarde sur le nœud homologue.
La configuration multicast sur un cluster de châssis est identique à la configuration multicast sur un équipement autonome. Consultez le Guide de l’utilisateur des protocoles de multidiffusion pour plus d’informations .
- Comprendre le transfert de données PIM
- Présentation de la synchronisation de sessions multicast et PIM
Comprendre le transfert de données PIM
Le multicast indépendant du protocole (PIM) est utilisé entre les appareils pour suivre les paquets de multidiffusion à transférer les uns aux autres.
Une session PIM encapsule des données multicast dans un paquet PIM unicast. Une session PIM crée les sessions suivantes :
Session de contrôle
Session de données
La session de données enregistre l’ID de session de contrôle. La session de contrôle et la session de données sont fermées indépendamment. L’interface entrante permet de déterminer si la session PIM est active ou non. Si l’interface sortante est active sur le nœud homologue, les paquets sont transférés vers le nœud homologue pour être transmis.
Présentation de la synchronisation de sessions multicast et PIM
La synchronisation des sessions multicast et PIM permet d’éviter les pertes de paquets dues au basculement, car il n’est pas nécessaire de configurer à nouveau les sessions en cas de basculement.
Dans les sessions PIM, la session de contrôle est synchronisée avec le nœud de sauvegarde, puis la session de données est synchronisée.
Dans les sessions multicast, la session modèle est synchronisée avec le nœud homologue, puis toutes les sessions leaf sont synchronisées, et enfin la session modèle est synchronisée à nouveau.
Voir aussi
Comprendre le routage asymétrique sur un cluster de châssis
Vous pouvez utiliser les pare-feu SRX Series dans des scénarios de routage asymétrique de clusters de châssis (voir Figure 1). Le trafic reçu par un nœud est comparé à la table de session de ce nœud. Le résultat de cette recherche détermine si le nœud traite ou transmet le paquet à l’autre nœud via la liaison de fabric. Les sessions sont ancrées sur le nœud de sortie du premier paquet qui a créé la session. Si le trafic est reçu sur le nœud dans lequel la session n’est pas ancrée, ces paquets sont transférés via le lien de la structure vers le nœud où la session est ancrée.
Le nœud d’ancrage de la session peut changer si le routage est modifié au cours de la session.
Dans ce scénario, deux connexions Internet sont utilisées, l’une étant préférée. La connexion à la zone de confiance s’effectue à l’aide d’une interface Ethernet redondante pour fournir une redondance LAN aux périphériques de la zone de confiance. Ce scénario décrit deux cas de basculement dans lesquels les sessions proviennent de la zone de confiance avec une destination Internet (zone de non-approbation).
- Comprendre les défaillances dans la zone de confiance Interface Ethernet redondante
- Comprendre les défaillances dans les interfaces de zone de confiance
Comprendre les défaillances dans la zone de confiance Interface Ethernet redondante
Dans des conditions normales de fonctionnement, le trafic circule de l’interface de la zone de confiance ge-0/0/1, appartenant à reth0.0, vers Internet. La connexion Internet principale se trouvant sur le nœud 0, les sessions sont créées sur le nœud 0 et synchronisées avec le nœud 1. Toutefois, les sessions ne sont actives que sur le nœud 0.
Une défaillance de l’interface ge-0/0/1 déclenche un basculement du groupe de redondance, ce qui entraîne l’activation de l’interface ge-7/0/1 dans le nœud 1. Après le basculement, le trafic arrive au nœud 1. Après la recherche de session, le trafic est envoyé au nœud 0 car la session est active sur ce nœud. Le nœud 0 traite ensuite le trafic et le transmet vers Internet. Le trafic de retour suit un processus similaire. Le trafic arrive au nœud 0 et est traité à des fins de sécurité (par exemple, l’analyse antispam, l’analyse antivirus et l’application de stratégies de sécurité) sur le nœud 0, car la session est ancrée au nœud 0. Le paquet est ensuite envoyé au nœud 1 via l’interface fabric pour traitement sortant et transmission éventuelle hors du nœud 1 via l’interface ge-7/0/1.
Comprendre les défaillances dans les interfaces de zone de confiance
Dans ce cas, les sessions sont migrées d’un nœud à l’autre. Dans des conditions de fonctionnement normales, le trafic n’est traité que par le nœud 0. Une défaillance de l’interface ge-0/0/0 sur le nœud 0 provoque une modification de la table de routage, de sorte qu’elle pointe maintenant vers l’interface ge-7/0/0 dans le nœud 1. Après l’échec, les sessions du nœud 0 deviennent inactives et les sessions passives du nœud 1 deviennent actives. Le trafic provenant de la zone de confiance est toujours reçu sur l’interface ge-0/0/1, mais est transféré au nœud 1 pour traitement. Une fois le trafic traité dans le nœud 1, il est transféré vers Internet via l’interface ge-7/0/0.
Dans cette configuration de cluster de châssis, le groupe de redondance 1 est utilisé pour contrôler l’interface Ethernet redondante connectée à la zone de confiance. Comme configuré dans ce scénario, le groupe de redondance 1 bascule uniquement si l’interface ge-0/0/1 ou ge-7/0/1 échoue, mais pas si les interfaces connectées à Internet échouent. En option, la configuration peut être modifiée pour permettre au groupe de redondance 1 de surveiller toutes les interfaces connectées à Internet et de basculer en cas de défaillance d’une liaison Internet. Ainsi, par exemple, la configuration peut permettre au groupe de redondance 1 de surveiller ge-0/0/0 et de rendre ge-7/0/1 actif pour reth0 si la liaison Internet ge-0/0/0 échoue. (Cette option n’est pas décrite dans les exemples de configuration suivants.)
Voir aussi
Exemple : configuration d’une paire de clusters de châssis asymétriques
Cet exemple montre comment configurer un cluster de châssis pour autoriser le routage asymétrique. La configuration du routage asymétrique pour un cluster de châssis permet de traiter le trafic reçu sur l’un ou l’autre équipement de manière transparente.
Exigences
Avant de commencer :
-
Connectez physiquement une paire d’appareils ensemble, en vous assurant qu’il s’agit des mêmes modèles. Cet exemple utilise une paire de périphériques SRX1500 ou SRX1600.
-
Pour créer le lien de structure, connectez une interface Gigabit Ethernet sur un périphérique à une autre interface Gigabit Ethernet sur l’autre périphérique.
-
Pour créer la liaison de contrôle, connectez le port de contrôle des deux périphériques SRX1500.
-
-
Connectez-vous à l’un des périphériques à l’aide du port console. (Il s’agit du nœud qui forme le cluster.)
-
Définissez l’ID de cluster et le numéro de nœud.
user@host> set chassis cluster cluster-id 1 node 0 reboot
-
-
Connectez-vous à l’autre périphérique à l’aide du port console.
-
Définissez l’ID de cluster et le numéro de nœud.
user@host> set chassis cluster cluster-id 1 node 1 reboot
-
Aperçu
Dans cet exemple, un cluster de châssis fournit un routage asymétrique. Comme l’illustre la figure 2, deux connexions Internet sont utilisées, l’une étant privilégiée. La connexion à la zone de confiance est assurée par une interface Ethernet redondante afin de fournir une redondance LAN aux périphériques de la zone de confiance.
Dans cet exemple, vous configurez les informations de groupe (en appliquant la configuration avec la apply-groups commande) et de cluster de châssis. Ensuite, vous configurez les zones de sécurité et les stratégies de sécurité. Voir les tableaux 1 à 4.
Fonction |
Nom |
Paramètres de configuration |
|---|---|---|
Groupes |
nœud0 |
|
|
nœud1 |
|
Fonction |
Nom |
Paramètres de configuration |
|---|---|---|
Liens vers la structure |
fab0 |
Interface : ge-0 / 0 / 7 |
|
FAB1 |
Interface : ge-7/0/7 |
Intervalle de pulsation |
– |
1000 |
Seuil de pulsation |
– |
3 |
Groupe de redondance |
1 |
|
|
|
Surveillance des interfaces
|
Nombre d’interfaces Ethernet redondantes |
– |
1 |
Interfaces |
GE-0/0/1 |
|
|
GE-7/0/1 |
|
|
GE-0/0/3 |
Parent redondant : reth0 |
|
GE-7/0/3 |
Parent redondant : reth0 |
|
reth0 |
|
Nom |
Paramètres de configuration |
|---|---|
Confiance |
L’interface reth0.0 est liée à cette zone. |
Untrust |
Les interfaces ge-0/0/1 et ge-7/0/1 sont liées à cette zone. |
But |
Nom |
Paramètres de configuration |
|---|---|---|
Cette stratégie de sécurité autorise le trafic de la zone de confiance vers la zone de non-approbation. |
TOUT |
|
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit du mode de configuration.
{primary:node0}[edit]
set groups node0 system host-name srxseries-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.50/24
set groups node1 system host-name srxseries-2
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.100.51/24
set apply-groups “${node}”
set interfaces fab0 fabric-options member-interfaces ge-0/0/7
set interfaces fab1 fabric-options member-interfaces ge-7/0/7
set chassis cluster reth-count 1
set chassis cluster heartbeat-interval 1000
set chassis cluster heartbeat-threshold 3
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255
set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-7/0/1 unit 0 family inet address 10.2.1.233/24
set interfaces ge-7/0/3 gigether-options redundant-parent reth0
set interfaces reth0 unit 0 family inet address 10.16.8.1/24
set routing-options static route 0.0.0.0/0 qualified-next-hop 10.4.0.1 metric 10
set routing-options static route 0.0.0.0/0 qualified-next-hop 10.2.1.1 metric 100
set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone untrust interfaces ge-7/0/1.0
set security zones security-zone trust interfaces reth0.0
set security policies from-zone trust to-zone untrust policy ANY match source-address any
set security policies from-zone trust to-zone untrust policy ANY match destination-address any
set security policies from-zone trust to-zone untrust policy ANY match application any
set security policies from-zone trust to-zone untrust policy ANY then permit
Procédure étape par étape
Pour configurer une paire de clusters de châssis asymétriques :
Configurez l’interface de gestion.
{primary:node0}[edit] user@host# set groups node0 system host-name srxseries-1 user@host# set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.50/24 user@host# set groups node1 system host-name srxseries-2 user@host#set groups node1 interfaces fxp0 unit 0 family inet address 192.168.100.51/24 user@host# set apply-groups “${node}”Configurez l’interface de la structure.
{primary:node0}[edit] user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/7 user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/7Configurez le nombre d’interfaces Ethernet redondantes.
{primary:node0}[edit] user@host# set chassis cluster reth-count 1Configurez les groupes de redondance.
{primary:node0}[edit] user@host# set chassis cluster heartbeat-interval 1000 user@host# set chassis cluster heartbeat-threshold 3 user@host# set chassis cluster node 0 user@host# set chassis cluster node 1 user@host# set chassis cluster redundancy-group 1 node 0 priority 100 user@host# set chassis cluster redundancy-group 1 node 1 priority 1 user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255 user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255Configurez les interfaces Ethernet redondantes.
{primary:node0}[edit] user@host# set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24 user@host# set interfaces ge-0/0/3 gigether-options redundant-parent reth0 user@host# set interfaces ge-7/0/1 unit 0 family inet address 10.2.1.233/24 user@host# set interfaces ge-7/0/3 gigether-options redundant-parent reth0 user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24Configurez les routes statiques (une vers chaque FAI, avec la route préférée via ge-0/0/1).
{primary:node0}[edit] user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.4.0.1 metric 10 user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.2.1.1 metric 100Configurez les zones de sécurité.
{primary:node0}[edit] user@host# set security zones security-zone untrust interfaces ge-0/0/1.0 user@host# set security zones security-zone untrust interfaces ge-7/0/1.0 user@host# set security zones security-zone trust interfaces reth0.0Configurez les stratégies de sécurité.
{primary:node0}[edit] user@host# set security policies from-zone trust to-zone untrust policy ANY match source-address any user@host# set security policies from-zone trust to-zone untrust policy ANY match destination-address any user@host# set security policies from-zone trust to-zone untrust policy ANY match application any user@host# set security policies from-zone trust to-zone untrust policy ANY then permit
Résultats
Depuis le mode opérationnel, confirmez votre configuration en entrant la show configuration commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
Par souci de concision, cette show sortie de commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
user@host> show configuration
version x.xx.x;
groups {
node0 {
system {
host-name srxseries-1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.50/24;
}
}
}
}
}
node1 {
system {
host-name srxseries-2;
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.51/24;
}
}
}
}
}
}
apply-groups "${node}";
chassis {
cluster {
reth-count 1;
heartbeat-interval 1000;
heartbeat-threshold 3;
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
interface-monitor {
ge-0/0/3 weight 255;
ge-7/0/3 weight 255;
}
}
}
}
interfaces {
ge-0/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge-7/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge–0/0/1 {
unit 0 {
family inet {
address 10.4.0.202/24;
}
}
}
ge–7/0/1 {
unit 0 {
family inet {
address 10.2.1.233/24;
}
}
}
fab0 {
fabric–options {
member–interfaces {
ge–0/0/7;
}
}
}
fab1 {
fabric–options {
member–interfaces {
ge–7/0/7;
}
}
}
reth0 {
gigether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.16.8.1/24;
}
}
}
}
...
routing-options {
static {
route 0.0.0.0/0 {
next-hop 10.4.0.1;
metric 10;
}
}
}
routing-options {
static {
route 0.0.0.0/0 {
next-hop 10.2.1.1;
metric 100;
}
}
}
security {
zones {
security–zone untrust {
interfaces {
ge-0/0/1.0;
ge-7/0/1.0;
}
}
security–zone trust {
interfaces {
reth0.0;
}
}
}
policies {
from-zone trust to-zone untrust {
policy ANY {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
}
Si vous avez terminé de configurer l’appareil, entrez commit à partir du mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’état du cluster de châssis
- Vérification des interfaces des clusters de châssis
- Vérification des statistiques du cluster de châssis
- Vérification des statistiques du plan de contrôle du cluster de châssis
- Vérification des statistiques du plan de données du cluster de châssis
- Vérification de l’état du groupe de redondance des clusters de châssis
- Dépannage des journaux
Vérification de l’état du cluster de châssis
But
Vérifiez l’état du cluster de châssis, l’état du basculement et les informations du groupe de redondance.
Action
En mode opérationnel, saisissez la show chassis cluster status commande.
{primary:node0}
user@host> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 1 , Failover count: 1
node0 100 primary no no
node1 1 secondary no no
Vérification des interfaces des clusters de châssis
But
Vérifiez les informations sur les interfaces des clusters de châssis.
Action
En mode opérationnel, saisissez la show chassis cluster interfaces commande.
{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/3 255 Up 1
ge-7/0/3 255 Up 1
Vérification des statistiques du cluster de châssis
But
Vérifiez les informations sur les statistiques des différents objets en cours de synchronisation, les bonjours de la structure et de l’interface de contrôle et l’état des interfaces surveillées dans le cluster.
Action
En mode opérationnel, saisissez la show chassis cluster statistics commande.
{primary:node0}
user@host> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 228
Heartbeat packets received: 2370
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 2272
Probes received: 597
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0
Vérification des statistiques du plan de contrôle du cluster de châssis
But
Vérifiez les informations sur les statistiques du plan de contrôle du cluster de châssis (pulsations envoyées et reçues) et les statistiques des liens de la structure (sondes envoyées et reçues).
Action
En mode opérationnel, saisissez la show chassis cluster control-plane statistics commande.
{primary:node0}
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Vérification des statistiques du plan de données du cluster de châssis
But
Vérifiez les informations sur le nombre d’ORT envoyés et reçus pour des services.
Action
En mode opérationnel, saisissez la show chassis cluster data-plane statistics commande.
{primary:node0}
user@host> show chassis cluster data-plane statistics
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0
Vérification de l’état du groupe de redondance des clusters de châssis
But
Vérifiez l’état et la priorité des deux nœuds d’un cluster et indiquez si le nœud principal a été préempté ou s’il y a eu un basculement manuel.
Action
En mode opérationnel, saisissez la chassis cluster status redundancy-group commande.
{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy-Group: 1, Failover count: 1
node0 100 primary no no
node1 1 secondary no no
Dépannage des journaux
But
Utilisez ces journaux pour identifier les éventuels problèmes liés aux clusters de châssis. Vous devez exécuter ces journaux sur les deux nœuds.
Action
En mode opérationnel, entrez ces show commandes.
user@host> show log jsrpd user@host> show log chassisd user@host> show log messages user@host> show log dcd user@host> show traceoptions