Autres configurations MC-LAG
Configuration du pontage actif-actif et du VRRP sur IRB dans l’agrégation de liens multichâssis sur les routeurs MX Series
Les sections suivantes décrivent la configuration du pontage actif-actif et du VRRP sur IRB dans une agrégation de liens multichâssis (MC-LAG) :
- Configuration de MC-LAG
- Configuration de la liaison de protection entre châssis
- Configuration de plusieurs châssis
- Configuration de l’ID de service
- Configuration de la surveillance IGMP pour MC-LAG actif-actif
Configuration de MC-LAG
Un MC-LAG est composé de groupes d’agrégation de liens logiques (LAG) et est configuré sous la hiérarchie [edit interfaces aeX], comme suit :
[edit]
interfaces {
ae0 {
encapsulation ethernet-bridge;
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0;
}
}
aggregated-ether-options {
mc-ae {
mode active-active; # see note below
}
}
}
}
L’instruction mode active-active n’est valide que si l’encapsulation est un pont Ethernet ou un pont VLAN étendu.
Utilisez l’instruction mode pour spécifier si un MC-LAG est actif-veille ou actif-actif. Si la connexion ICCP est active et que la liste ICL est activée, le routeur configuré en veille affiche les interfaces Ethernet agrégées multichâssis partagées avec l’homologue.
L’utilisation de la protection multichâssis au niveau de l’interface physique permet de réduire la configuration au niveau de l’interface logique.
S’il y a n+1 interfaces logiques sous ae0, de ae0.0 à ae0.n, il y a également n+1 interfaces logiques sous ge-0/0/0, de ge-0/0/0.0 à ge-0/0/0.n, chaque interface logique ge-0/0/0 est un lien de protection pour l’interface logique ae0.
Un domaine de pont ne peut pas avoir d’interfaces logiques Ethernet agrégées multichâssis appartenant à différents groupes de redondance.
Configuration de la liaison de protection entre châssis
La liaison de protection de liaison entre châssis (ICL-PL) fournit la redondance lorsqu’une défaillance de liaison (par exemple, une défaillance de jonction MC-LAG) se produit sur l’une des liaisons actives. L’ICL-PL est une interface Ethernet agrégée. Vous ne pouvez configurer qu’un seul ICL-PL entre les deux homologues, bien que vous puissiez configurer plusieurs MC-LAG entre eux.
L’ICL-PL suppose que l’interface ge-0/0/0.0 est utilisée pour protéger l’interface ae0.0 de MC-LAG-1 :
[edit]
interfaces {
ae0 {
....
unit 0 {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0.0;
}
....
}
...
}
}
}
L’interface de protection peut être une interface de type Ethernet telle que ge ou xe, ou une interface Ethernet agrégée (ae).
Configuration de plusieurs châssis
Une hiérarchie de niveau supérieur permet de spécifier une configuration relative à plusieurs châssis, comme suit :
[edit]
multi-chassis {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0;
}
}
}
Cet exemple spécifie l’interface ge-0/0/0 comme interface de protection multichâssis pour toutes les interfaces Ethernet agrégées multichâssis qui font également partie de l’homologue. Vous pouvez ainsi le remplacer en spécifiant la protection au niveau de l’interface physique et au niveau de l’interface logique.
Configuration de l’ID de service
Vous devez configurer la même configuration unique à l’échelle du réseau pour un service dans l’ensemble des routeurs PE fournissant le service. Vous pouvez configurer les ID de service au niveau des hiérarchies indiquées dans les exemples suivants :
Configuration globale (système logique par défaut)
switch-options {
service-id 10;
}
bridge-domains {
bd0 {
service-id 2;
}
}
routing-instances {
r1 {
switch-options {
service-id 10;
}
bridge-domains {
bd0 {
service-id 2;
}
}
}
}
Systèmes logiques
ls1 {
switch-options {
service-id 10;
}
routing-instances {
r1 {
switch-options {
service-id 10;
}
}
}
}
L’utilisation d’un nom de service par domaine de pont n’est pas prise en charge.
L’ID de service de niveau pont est requis pour lier les domaines de pont associés entre les homologues et doit être configuré avec la même valeur. Les valeurs service-id partagent l’espace de noms entre toutes les instances de pontage et de routage, ainsi qu’entre les pairs. Par conséquent, les valeurs dupliquées pour les ID de service ne sont pas autorisées dans ces entités.
L’ID de service au niveau du domaine de pont est obligatoire pour les domaines de pont de type non VLAN unique. L’ID de service est facultatif pour les domaines de pont avec un identifiant VLAN (VID) défini. Si aucun ID de service n’est défini dans ce dernier cas, il est récupéré à partir de la configuration de l’ID de service de cette instance de routage.
Lorsque cette instance de routage par défaut (ou toute autre instance de routage) qui contient un domaine de pont contenant une interface Ethernet agrégée multichâssis est configurée, vous devez configurer un service-id numberswitch-options au niveau global , indépendamment du fait que des ID de service spécifiques soient configurés ou non pour les domaines de pont contenus.
Dans l’exemple d’illustration illustré à la Figure 1, les instances de routage réseau N1 et N2, toutes deux pour le même ID de service, sont configurées avec le même ID de service dans N1 et N2. L’utilisation d’une chaîne de nom au lieu d’un nombre n’est pas prise en charge.
de service
Les restrictions de configuration suivantes s’appliquent :
L’ID de service doit être configuré lorsque l’interface Ethernet agrégée multichâssis est configurée et qu’une interface logique Ethernet agrégée multichâssis fait partie d’un domaine de pont. Cette exigence est appliquée.
Un seul domaine de pont ne peut pas correspondre à deux ID de groupe de redondance.
La Figure 2 montre qu’il est possible de configurer un domaine de pont constitué d’interfaces logiques à partir de deux interfaces Ethernet agrégées multichâssis et de les mapper à un ID de groupe de redondance distinct, ce qui n’est pas pris en charge. Un service doit être mappé un à un avec le groupe de redondance qui fournit le service. Cette exigence est appliquée.
Figure 2 : domaine de pont avec interfaces logiques à partir de deux interfaces
Ethernet agrégées multichâssis
Pour afficher la configuration Ethernet agrégée multichâssis, utilisez la commande show interfaces mc-ae . Pour plus d’informations, reportez-vous à l’Explorateur CLI.
Configuration de la surveillance IGMP pour MC-LAG actif-actif
Pour que la solution multicast fonctionne, les conditions suivantes doivent être configurées :
La liaison de protection multichâssis doit être configurée en tant qu’interface côté routeur.
[edit bridge-domain bd-name] protocols { igmp-snooping { interface ge-0/0/0.0 { multicast-router-interface; } } }Dans cet exemple, ge-0/0/0.0 est une interface ICL.
Les
multichassis-lag-replicate-stateoptions d’instruction doivent être configurées sous l’instructionmulticast-snooping-optionsde ce domaine de pont.
La surveillance avec MC-LAG actif-actif n’est prise en charge qu’en mode non-proxy.
Configuration de la surveillance IGMP en mode actif-actif MC-LAG
Vous pouvez utiliser l'option de service-id lbridge-domain'instruction pour spécifier la configuration Ethernet agrégée multichâssis sur les routeurs MX240, MX480, MX960 et les commutateurs QFX Series.
L’instruction
service-idest obligatoire pour les domaines de pont de type VLAN non unique (none, all ou vlan-id-tags :dual).L’instruction est facultative pour les domaines de pont avec un VID défini.
Le niveau
service-iddu pont est requis pour lier les domaines de pont connexes entre les homologues et doit être configuré avec la même valeur.Les
service-idvaleurs partagent l’espace de noms dans toutes les instances de pontage et de routage, ainsi que dans les pairs. Par conséquent, les valeurs dupliquéesservice-idne sont pas autorisées sur ces entités.Une modification de l’ID de service de pont est considérée comme catastrophique et le domaine de pont est modifié.
Cette procédure vous permet d’activer ou de désactiver la fonctionnalité de réplication.
Pour configurer la surveillance IGMP en mode actif-actif MC-LAG :
Configuration du basculement de liaison manuel et automatique pour les interfaces MC-LAG sur les routeurs MX Series
Dans une topologie d’agrégation de liens multichâssis (MC-LAG) avec mode de veille actif, un basculement de liaison ne se produit qu’en cas de panne du nœud actif. Vous pouvez remplacer ce comportement par défaut en configurant une interface MC-LAG en mode veille-active pour qu’elle revienne automatiquement à un nœud préféré. Avec cette configuration, vous pouvez déclencher un basculement de liaison vers un noeud préféré, même lorsque le noeud actif est disponible. Prenons l’exemple de deux nœuds, PE1 et PE2. PE1 est configuré en mode actif, ce qui en fait un nœud préféré, et PE2 est configuré en mode veille-actif. En cas de défaillance au niveau de PE1, PE2 devient le nœud actif. Cependant, dès que PE1 est à nouveau disponible, un basculement automatique de liaison est déclenché et la commande est rebasculée sur PE1 même si PE2 est actif.
Vous pouvez configurer le basculement de liaison en deux modes : révertif et non révertif. En mode réversible, le basculement de liaison est déclenché automatiquement à l’aide de la commande de request interface mc-ae switchover mode opérationnel. En mode non réversible, le basculement de liaison doit être déclenché manuellement par l’utilisateur. Vous pouvez également configurer une heure de retour qui déclenche un basculement automatique ou manuel à l’expiration du minuteur spécifié.
Si deux périphériques MC-LAG configurés dans une configuration de veille active utilisant le protocole ICCP (Inter-Chassis Control Protocol) et le mode de couverture de commutateur non réversible sont configurés sur les interfaces Ethernet agrégées des deux MC-LAG et lorsque les deux interfaces mc-ae sont reliées entre elles par une configuration de commutation locale de circuit de couche 2, nous vous recommandons d’effectuer le basculement en entrant le
request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)mode opérationnel sur une seule des interfaces Ethernet agrégées d’un équipement MC-LAG. Cette commande ne peut être émise que sur les périphériques MC-LAG configurés en tant que nœuds actifs (à l’aide de l’instructionstatus-control activeau niveau de la[edit interfaces aeX aggregated-ether-options mc-ae]hiérarchie).En mode de basculement non réversible, lorsqu’une interface MC-LAG passe à l’état de veille en raison de la défaillance d’une liaison de membre MC-LAG et qu’une autre interface MC-LAG passe à l’état actif, le MC-LAG en état de veille reste dans cet état jusqu’à ce que le MC-LAG à l’état actif rencontre une défaillance et revienne à l’état actif.
Si vous effectuez un basculement sur les deux interfaces Ethernet agrégées du MC-LAG, en raison de la configuration de commutation locale du circuit de couche 2, un basculement sur une interface Ethernet agrégée déclenche un basculement sur l’autre interface Ethernet agrégée. Dans un tel scénario, les deux interfaces Ethernet agrégées passent à l’état veille, puis reviennent à l’état actif. Par conséquent, vous ne devez pas effectuer de basculement sur les deux interfaces Ethernet agrégées d’un MC-LAG en même temps.
La configuration de circuit de couche 2 et les fonctionnalités VPLS ne sont pas prises en charge si vous configurez une interface MC-LAG pour qu’elle soit en mode de basculement inversé. Vous ne pouvez configurer la fonctionnalité de basculement réversible ou non réversible que si deux périphériques MC-LAG sont configurés dans une configuration de veille active (un périphérique défini en tant que nœud actif à l’aide de l’instruction
status-control standbyet l’autre périphérique défini en tant que nœud de secours à l’aide de l’instructionstatus-control activeau niveau de la[edit interfaces aeX aggregated-ether-options mc-ae]hiérarchie). Vous pouvez effectuer un basculement en entrant la commande derequest interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)mode opérationnel uniquement sur les périphériques MC-LAG configurés en tant que nœuds actifs.
Pour configurer le mécanisme de basculement de liaison sur une interface MC-LAG :
Vous pouvez utiliser la show interfaces mc-ae revertive-info commande pour afficher les informations de configuration du basculement.
Activation forcée de liaisons ou d’interfaces MC-LAG avec une capacité LACP limitée
Dans un réseau MC-LAG, une liaison client MC-LAG sans configuration LACP (Link Access Control Protocol) reste inactive et les commutateurs MC-LAG ne peuvent plus y accéder.
Pour vous assurer que l’appareil client avec une capacité LACP limitée est opérationnel et accessible sur le réseau MC-LAG, configurez l’une des liaisons ou interfaces Ethernet agrégées sur un commutateur MC-LAG pour qu’elle soit active à l’aide de l’instruction force-up au niveau hiérarchique approprié sur votre équipement :
[edit interfaces interface-name aggregated-ether-options lacp]
Vous pouvez configurer la fonction de remontée forcée sur les commutateurs MC-LAG en mode actif ou en mode veille. Toutefois, afin d’éviter le trafic dupliqué et les pertes de paquets, vous configurez la fonction de démarrage forcé sur une seule liaison Ethernet agrégée des commutateurs MC-LAG. Si plusieurs liaisons Ethernet agrégées sont actives sur les commutateurs MC-LAG avec la fonction de force up configurée, l’équipement sélectionne la liaison en fonction de l’ID de port LACP et de la priorité du port. La préférence est donnée au port ayant la priorité la plus basse. Dans le cas de deux ports ayant la même priorité, celui avec l’ID de port le plus bas est privilégié.
Cette force-up option n’est pas prise en charge sur les commutateurs QFX10002.
Sur le commutateur QFX5100, vous pouvez configurer la fonction de refoulement dans le protocole LACP (Link Aggregation Control Protocol) sur les commutateurs MC-LAG à partir de Junos OS version 14.1X53-D10.
Si LACP apparaît partiellement dans le réseau MC-LAG, c’est-à-dire qu’il apparaît sur l’un des commutateurs MC-LAG et n’apparaît pas sur les autres commutateurs MC-LAG, la fonction de force est désactivée.
Augmentation du nombre d’entrées ARP et Network Discovery Protocol pour les topologies MC-LAG et VXLAN de couche 3 améliorées
- Comprendre la nécessité d’augmenter le nombre d’entrées ARP et NDP (Network Discovery Protocol)
- Augmentation du nombre d’entrées de protocole ARP et Network Discovery pour le MC-LAG amélioré à l’aide du transport IPv4
- Augmentation des entrées de protocole ARP et Network Discovery pour le MC-LAG amélioré à l’aide du transport IPv6
- Augmentation de l’ARP pour la passerelle EVPN-VXLAN pour border-leaf dans Edge Routed Bridge (ERB) ou Spine dans Centrally Routed Bridge (CRB) pour le trafic des locataires IPv4
- Augmentation des entrées de protocole ARP et Network Discovery pour la passerelle EVPN-VXLAN pour border-leaf dans Edge Routed Bridge (ERB) ou Spine dans Centrally Route Bridge (CRB) pour le trafic des locataires IPv6
Comprendre la nécessité d’augmenter le nombre d’entrées ARP et NDP (Network Discovery Protocol)
Le nombre d’entrées ARP et NDP est passé à 256 000 afin d’améliorer les scénarios MC-LAG et VXLAN de couche 3.
Voici quelques scénarios MC-LAG et VXLAN de couche 3 améliorés dans lesquels une augmentation des entrées ARP et NDP est nécessaire :
Topologie MC-LAG améliorée avec un grand nombre d’interfaces MC-AE contenant un grand nombre de membres par châssis.
Topologie spine-leaf non réduite, dans laquelle les équipements Leaf fonctionnent comme des passerelles de couche 2 et gèrent le trafic au sein du VXLAN, tandis que les équipements Spine fonctionnent comme des passerelles de couche 3 et gèrent le trafic entre les VXLAN à l’aide d’interfaces IRB.
Dans ce scénario, l’augmentation des entrées ARP et NDP est nécessaire au niveau du cœur de réseau.
Équipements de branche qui fonctionnent à la fois comme passerelles de couche 2 et de couche 3.
Dans ce scénario, les équipements de cœur de réseau de transit fonctionnent uniquement en routage de couche 3, et le nombre accru d’entrées ARP et NDP n’est nécessaire qu’au niveau de la branche.
Augmentation du nombre d’entrées de protocole ARP et Network Discovery pour le MC-LAG amélioré à l’aide du transport IPv4
Pour augmenter le nombre d’entrées ARP et NDP à l’aide du transport IPv4, procédez comme suit. Nous vous recommandons d’utiliser les valeurs fournies dans cette procédure pour des performances optimales :
Augmentation des entrées de protocole ARP et Network Discovery pour le MC-LAG amélioré à l’aide du transport IPv6
Augmenter le nombre d’entrées ARP et Network Discovery Protocol à l’aide du transport IPv6. Nous vous recommandons d’utiliser les valeurs fournies dans cette procédure pour des performances optimales :
Augmentation de l’ARP pour la passerelle EVPN-VXLAN pour border-leaf dans Edge Routed Bridge (ERB) ou Spine dans Centrally Routed Bridge (CRB) pour le trafic des locataires IPv4
Pour augmenter le nombre d’entrées ARP à l’aide du trafic de locataire IPv4, procédez comme suit. Nous vous recommandons d’utiliser les valeurs fournies dans cette procédure pour des performances optimales :
Augmentation des entrées de protocole ARP et Network Discovery pour la passerelle EVPN-VXLAN pour border-leaf dans Edge Routed Bridge (ERB) ou Spine dans Centrally Route Bridge (CRB) pour le trafic des locataires IPv6
Pour augmenter le nombre d’entrées ARP et Network Discovery Protocol à l’aide du trafic des locataires IPv4 et IPv6, procédez comme suit. Nous vous recommandons d’utiliser les valeurs fournies dans cette procédure pour des performances optimales :
Synchronisation et validation des configurations
Pour propager, synchroniser et valider les modifications de configuration d’un périphérique (Junos Fusion Provider Edge, Junos Fusion Enterprise, commutateurs EX Series et routeurs MX Series) vers un autre, effectuez les tâches suivantes :
- Configurer les équipements pour la synchronisation de la configuration
- Créer un groupe de configuration global
- Créer un groupe de configuration local
- Créer un groupe de configuration à distance
- Créer des groupes d’application pour les configurations locales, distantes et globales
- Synchronisation et validation des configurations
- Dépannage des connexions d’appareils distants
Configurer les équipements pour la synchronisation de la configuration
Configurez les noms d’hôte ou les adresses IP des périphériques qui synchroniseront leurs configurations, ainsi que les noms d’utilisateur et les détails d’authentification des utilisateurs qui administreront la synchronisation de la configuration. Activez également une connexion NETCONF afin que les appareils puissent synchroniser leurs configurations. Le protocole SCP (Secure Copy Protocol) copie les configurations en toute sécurité entre les périphériques.
Par exemple, si vous disposez d’un périphérique local nommé Commutateur A et que vous souhaitez synchroniser une configuration avec des périphériques distants nommés Commutateur B, Commutateur C et Commutateur D, vous devez configurer les détails du commutateur B, du commutateur C et du commutateur D sur le commutateur A.
Pour spécifier les détails de la configuration :
Créer un groupe de configuration global
Créez un groupe de configuration global regroupant les équipements locaux et distants.
Pour créer un groupe de configuration global :
Le résultat de la configuration est le suivant :
groups {
global {
when {
peers [ Switch A Switch B Switch C Switch D ];
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/8;
}
}
}
ge-0/0/1 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/2 {
ether-options {
802.3ad ae1;
}
}
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members v1;
}
}
}
}
ae1 {
aggregated-ether-options {
lacp {
active;
system-id 00:01:02:03:04:05;
admin-key 3;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
mode active-active;
}
}
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members v1;
}
}
}
}
}
switch-options {
service-id 1;
}
vlans {
v1 {
vlan-id 100;
l3-interface irb.100;
}
}
}
}
Créer un groupe de configuration local
Créez un groupe de configuration local pour l’équipement local.
Pour créer un groupe de configuration local :
Le résultat de la configuration est le suivant :
groups {
local {
when {
peers Switch A;
}
interfaces {
ae1 {
aggregated-ether-options {
mc-ae {
chassis-id 0;
status-control active;
events {
iccp-peer-down {
prefer-status-control-active;
}
}
}
}
}
irb {
unit 100 {
family inet {
address 10.10.10.3/8 {
arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00;
}
}
}
}
}
multi-chassis {
multi-chassis-protection 10.1.1.1 {
interface ae0;
}
}
}
}
Créer un groupe de configuration à distance
Créez un groupe de configuration à distance pour les appareils à distance.
Pour créer un groupe de configuration distante :
Le résultat de la configuration est le suivant :
groups {
remote {
when {
peers Switch B Switch C Switch D
}
interfaces {
ae1 {
aggregated-ether-options {
mc-ae {
chassis-id 1;
status-control standby;
events {
iccp-peer-down {
prefer-status-control-active;
}
}
}
}
}
irb {
unit 100 {
family inet {
address 10.10.10.3/8 {
arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00;
}
}
}
}
}
multi-chassis {
multi-chassis-protection 10.1.1.1 {
interface ae0;
}
}
}
}
Créer des groupes d’application pour les configurations locales, distantes et globales
Créez des groupes d’application afin que les modifications apportées à la configuration soient héritées par les groupes de configuration locaux, distants et globaux. Répertoriez les groupes de configuration par ordre d’héritage, où les données de configuration du premier groupe de configuration sont prioritaires sur les données des groupes de configuration suivants.
Lorsque vous appliquez les groupes de configuration et que vous exécutez la commit peers-synchronize commande, les modifications sont validées sur les périphériques locaux et distants. En cas d’erreur sur l’un des périphériques, un message d’erreur est émis et la validation est terminée.
Pour appliquer les groupes de configuration, procédez comme suit :
[edit] user@switch# set apply-groups [<name of global configuration group> <name of local configuration group> <name of remote configuration group>]
Par exemple:
[edit] user@switch# set apply-groups [ global local remote ]
Le résultat de la configuration est le suivant :
apply-groups [ global local remote ];Synchronisation et validation des configurations
La commit at <"string"> commande n’est pas prise en charge lors de la synchronisation de la configuration.
Vous pouvez activer l’instruction peers-synchronize sur l’appareil local (ou demandeur) pour copier et charger sa configuration sur l’appareil distant (ou répondant) par défaut. Vous pouvez également exécuter la commit peers-synchronize commande.
Configurez la
commitcommande sur le local (ou la demande) pour effectuer automatiquement unepeers-synchronizeaction entre les périphériques.[edit] user@switch# set system commit peers-synchronize
Le résultat de la configuration est le suivant :
system { commit { peers-synchronize; } }Exécutez la
commit peers-synchronizecommande sur l’appareil local (ou demandeur).[edit] user@switch# commit peers-synchronize
Dépannage des connexions d’appareils distants
Problème
Description
Lorsque vous exécutez la commit commande, le système émet le message d’erreur suivant :
root@Switch A# commit
error: netconf: could not read hello error: did not receive hello packet from server error: Setting up sessions for peer: 'Switch B' failed warning: Cannot connect to remote peers, ignoring it
Le message d’erreur indique qu’il existe un problème de connexion NETCONF entre l’équipement local et l’équipement distant.
Résolution
Résolution
Vérifiez que la connexion SSH à l’équipement distant (commutateur B) fonctionne.
root@Switch A# ssh root@Switch B
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:1 ECDSA host key for Switch A has changed and you have requested strict checking. Host key verification failed.Le message d’erreur indique que la connexion SSH ne fonctionne pas.
Supprimez l’entrée de clé dans le répertoire /root/.ssh/known_hosts :1 et essayez à nouveau de vous connecter au commutateur B.
root@Switch A# ssh root@Switch B
The authenticity of host 'Switch B (10.92.76.235)' can't be established. ECDSA key fingerprint is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Switch A,10.92.76.235' (ECDSA) to the list of known hosts. Password: Last login: Wed Apr 13 15:29:58 2016 from 192.168.61.129 - JUNOS 15.1I20160412_0929_dc-builder Kernel 64-bit FLEX JNPR-10.1-20160217.114153_fbsd-builder_stable_10 At least one package installed on this device has limited support. Run 'file show /etc/notices/unsupported.txt' for details.La connexion au commutateur B a réussi.
Déconnectez-vous du commutateur B.
root@Switch B# exit
logout Connection to Switch B closed.Vérifiez que NETCONF sur SSH fonctionne.
root@Switch A# ssh root@Switch B -s netconf
logout Connection to st-72q-01 closed.Password:<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>Le message du journal indique que la NETCONF sur SSH a réussi.
Si le message d’erreur indiquait que NETCONF over SSH n’a pas réussi, activez NETCONF over SSH en exécutant la
set system services netconf sshcommande.Créez des groupes de configuration à synchroniser si vous ne l’avez pas déjà fait.
Vous pouvez exécuter la
show | comparecommande pour voir si des groupes de configuration ont été créés.root@Switch A# show | compare
Lancez la
commitcommande.root@Switch A# commit
[edit chassis] configuration check succeeds commit complete {master:0}[edit]Le message du journal indique que la validation a réussi.