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 multicast d’envoyer du trafic à plusieurs destinataires sur des interfaces. Le routage asymétrique est la situation dans laquelle les paquets passent de l’hôte source à l’hôte de destination mais 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 :
Comprendre le 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 multicast, tels que PIM (Protocol Independent Multicast) versions 1 et 2, IGMP (Internet Group Management Protocol), SAP (Session Announcement Protocol) et DVMRP (Distance Vector Multicast RoutingProtocol), d’envoyer du trafic sur les interfaces du cluster. Notez toutefois que les protocoles multicast ne doivent pas être activés sur l’interface de gestion du châssis (fxp0) ou sur les interfaces de structure (fab0 et fab1). Les sessions de multicast sont synchronisées sur l’ensemble du cluster et maintenues lors de 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 en amont (vers la source) et en aval (vers les abonnés) dans les flux de trafic. Les périphériques répliquent (fanout) un seul paquet multicast sur plusieurs réseaux contenant des abonnés. Dans l’environnement de cluster de châssis, des fanouts de paquets multicast peuvent être actifs sur l’un ou l’autre des nœuds.
Si l’interface entrante est active sur le noeud courant et sauvegardée sur le noeud pair, la session est active sur le noeud courant et la sauvegarde est sauvegardée sur le noeud pair.
La configuration multicast sur un cluster de châssis est identique à la configuration multicast sur un périphérique autonome. Pour plus d’informations, reportez-vous au Guide de l’utilisateur des protocoles multicast .
Comprendre le transfert de données PIM
Le PIM (Protocol Independent Multicast) est utilisé entre les périphériques pour suivre les paquets multicast à se transmettre.
Une session PIM encapsule des données multicast dans un paquet unicast PIM. 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 est utilisée pour 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.
Comprendre 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 les sessions n’ont pas besoin d’être reconfigurées 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 en 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 non le paquet ou le transmet à l’autre nœud sur la liaison de structure. 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 la liaison de fabric au nœud où la session est ancrée.
Le nœud d’ancrage de la session peut changer s’il y a des changements dans le routage au cours de la session.
Dans ce scénario, deux connexions Internet sont utilisées, l’une d’entre elles étant préférée. La connexion à la zone de confiance se fait à l’aide d’une interface Ethernet redondante afin d’assurer la redondance LAN des appareils dans 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 non fiable).
- Comprendre les défaillances de l’interface Ethernet redondante de zone de confiance
- Comprendre les défaillances dans les interfaces de la zone non approuvée
Comprendre les défaillances de l’interface Ethernet redondante de zone de confiance
Dans des conditions normales d’exploitation, le trafic circule de l’interface de zone de confiance ge-0/0/1, appartenant à reth0.0, vers Internet. Étant donné que la connexion Internet principale se trouve sur le nœud 0, les sessions sont créées dans 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 à 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, analyse antispam, analyse antivirus et 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 de la structure pour le traitement de sortie et la transmission éventuelle hors du nœud 1 via l’interface ge-7/0/1.
Comprendre les défaillances dans les interfaces de la zone non approuvée
Dans ce cas, les sessions sont migrées d’un nœud à l’autre. Dans des conditions normales d’exploitation, le trafic est traité uniquement par le nœud 0. Une défaillance de l’interface ge-0/0/0 sur le noeud 0 entraîne une modification de la table de routage, de sorte qu’elle pointe désormais vers l’interface ge-7/0/0 dans le noeud 1. Après la défaillance, les sessions du nœud 0 deviennent inactives et les sessions passives du nœud 1 deviennent actives. Le trafic arrivant 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 en cas de défaillance de l’interface ge-0/0/1 ou ge-7/0/1, mais pas en cas de défaillance des interfaces connectées à Internet. 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 d’un routage asymétrique pour un cluster de châssis permet de traiter de manière transparente le trafic reçu sur l’un ou l’autre des équipements.
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 la liaison de structure, connectez une interface Gigabit Ethernet sur un équipement à une autre interface Gigabit Ethernet sur l’autre équipement.
-
Pour créer le lien 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 appareil à 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 assure un routage asymétrique. Comme l’illustre la figure 2, deux connexions Internet sont utilisées, l’une d’entre elles étant préférée. La connexion à la zone de confiance est assurée par une interface Ethernet redondante afin d’assurer la redondance LAN des appareils dans la zone de confiance.
Dans cet exemple, vous configurez les informations du groupe (en appliquant la configuration à l’aide de la apply-groups commande) et du cluster de châssis. Ensuite, configurez les zones de sécurité et les politiques de sécurité. Voir les tableaux 1 à 4.
| Caractéristique |
Nom |
Paramètres de configuration |
|---|---|---|
| Groupe |
noeud0 |
|
| noeud 1 |
|
| Caractéristique |
Nom |
Paramètres de configuration |
|---|---|---|
| Liens de fabric |
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. |
| défiance |
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-confiance. |
QUELCONQUE |
|
Configuration
Procédure
Configuration rapide de la CLI
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 commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en 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étrique :
-
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/7 -
Configurez le nombre d’interfaces Ethernet redondantes.
{primary:node0}[edit] user@host# set chassis cluster reth-count 1 -
Configurez 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 255 -
Configurez 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/24 -
Configurez les routes statiques (une vers chaque FAI, avec une 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 100 -
Configurez 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.0 -
Configurez les politiques 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, la sortie de cette show 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, passez commit en 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 de cluster 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 du cluster de châssis
- Dépannage à l’aide de journaux
Vérification de l’état du cluster de châssis
But
Vérifiez l’état du cluster de châssis, l’état de basculement et les informations sur le groupe de redondance.
Action
À partir du mode opérationnel, entrez 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 de cluster de châssis
But
Vérifiez les informations sur les interfaces du cluster de châssis.
Action
À partir du mode opérationnel, entrez 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 relatives aux statistiques des différents objets en cours de synchronisation, aux hellos de l’interface de fabric et de contrôle, ainsi qu’à l’état des interfaces surveillées dans le cluster.
Action
À partir du mode opérationnel, entrez 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 relatives aux statistiques du plan de contrôle du cluster de châssis (pulsations envoyées et reçues) et aux statistiques des liaisons de structure (sondes envoyées et reçues).
Action
À partir du mode opérationnel, entrez 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 de RTO envoyés et reçus pour les services.
Action
À partir du mode opérationnel, entrez 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 du cluster de châssis
But
Vérifiez l’état et la priorité des deux nœuds d’un cluster, ainsi que des informations pour savoir si le nœud principal a été préempté ou s’il y a eu un basculement manuel.
Action
À partir du mode opérationnel, entrez 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 à l’aide de journaux
But
Utilisez ces journaux pour identifier les problèmes de cluster de châssis. Vous devez exécuter ces journaux sur les deux nœuds.
Action
À partir du 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