AUF DIESER SEITE
Andere MC-LAG-Konfigurationen
Konfiguration von Aktiv-Aktiv-Bridging und VRRP über IRB in der Multichassis-Link-Aggregation auf Routern der MX-Serie
In den folgenden Abschnitten wird die Konfiguration von Aktiv-Aktiv-Bridging und VRRP über IRB in einer Multichassis-Link-Aggregation (MC-LAG) beschrieben:
- Konfigurieren von MC-LAG
- Konfigurieren der Interchassis-Verbindungsschutzverbindung
- Konfiguration mehrerer Chassis
- Konfigurieren der Dienst-ID
- Konfigurieren von IGMP-Snooping für Aktiv-Aktiv-MC-LAG
Konfigurieren von MC-LAG
Eine MC-LAG besteht aus logischen Link-Aggregation-Gruppen (LAGs) und wird gemäß der Hierarchie [edit interfaces aeX] wie folgt konfiguriert:
[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
}
}
}
}
Die Aktiv-Aktiv-Anweisung mode ist nur gültig, wenn es sich bei der Kapselung um eine Ethernet-Bridge oder eine Extended-VLAN-Bridge handelt.
Verwenden Sie die mode-Anweisung, um anzugeben, ob eine MC-LAG aktiv-standby oder aktiv-aktiv ist. Wenn die ICCP-Verbindung aktiviert ist und ICL hochgefahren wird, ruft der als Standby konfigurierte Router die aggregierten Multichassis-Ethernet-Schnittstellen auf, die mit dem Peer geteilt werden.
Die Verwendung von Multi-Chassis-Schutz auf der Ebene der physischen Schnittstelle ist eine Möglichkeit, die Konfiguration auf der Ebene der logischen Schnittstelle zu reduzieren.
Wenn es n+1 logische Schnittstellen unter ae0 gibt, von ae0.0 bis ae0.n, gibt es auch n+1 logische Schnittstellen unter ge-0/0/0, von ge-0/0/0.0 bis ge-0/0/0.n ist jede logische ge-0/0/0-Schnittstelle eine Schutzverbindung für die logische ae0-Schnittstelle.
Eine Bridge-Domäne darf keine aggregierten Ethernet-Schnittstellen mit mehreren Chassis aufweisen, die zu unterschiedlichen Redundanzgruppen gehören.
Konfigurieren der Interchassis-Verbindungsschutzverbindung
Die Interchassis-Verbindungsschutzverbindung (ICL-PL) bietet Redundanz, wenn auf einer der aktiven Verbindungen ein Verbindungsausfall (z. B. EIN MC-LAG-Trunk-Fehler) auftritt. Die ICL-PL ist eine aggregierte Ethernet-Schnittstelle. Sie können nur eine ICL-PL zwischen den beiden Peers konfigurieren, obwohl Sie mehrere MC-LAGs zwischen ihnen konfigurieren können.
Die ICL-PL geht davon aus, dass die Schnittstelle ge-0/0/0.0 verwendet wird, um die Schnittstelle ae0.0 von MC-LAG-1 zu schützen:
[edit]
interfaces {
ae0 {
....
unit 0 {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0.0;
}
....
}
...
}
}
}
Bei der Schutzschnittstelle kann es sich um eine Ethernet-Schnittstelle, z. B. ge oder xe, oder um eine aggregierte Ethernet-Schnittstelle (ae) handeln.
Konfiguration mehrerer Chassis
Eine Hierarchie der obersten Ebene wird verwendet, um eine Multichassis-bezogene Konfiguration wie folgt anzugeben:
[edit]
multi-chassis {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0;
}
}
}
In diesem Beispiel wird die Schnittstelle ge-0/0/0 als Multichassis-Schutzschnittstelle für alle aggregierten Multichassis-Ethernet-Schnittstellen angegeben, die auch Teil des Peers sind. Dies kann durch die Angabe des Schutzes auf der Ebene der physischen Schnittstelle und der Ebene der logischen Schnittstelle außer Kraft gesetzt werden.
Konfigurieren der Dienst-ID
Sie müssen dieselbe eindeutige netzwerkweite Konfiguration für einen Dienst in der Gruppe von PE-Routern konfigurieren, die den Dienst bereitstellen. Sie können die Service-IDs unter der Ebene der Hierarchien konfigurieren, die in den folgenden Beispielen gezeigt werden:
Globale Konfiguration (logisches Standardsystem)
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;
}
}
}
}
Logische Systeme
ls1 {
switch-options {
service-id 10;
}
routing-instances {
r1 {
switch-options {
service-id 10;
}
}
}
}
Die Verwendung eines Dienstnamens pro Bridgedomäne wird nicht unterstützt.
Die Service-ID auf Bridge-Ebene ist erforderlich, um verwandte Bridge-Domänen peerübergreifend zu verknüpfen, und sollte mit demselben Wert konfiguriert werden. Die service-id-Werte teilen den gemeinsamen Namensraum für alle Bridging- und Routinginstanzen sowie über Peers hinweg. Daher sind doppelte Werte für Dienst-IDs in diesen Entitäten nicht zulässig.
Die Service-ID auf der Ebene der Bridge-Domäne ist für Bridge-Domänen vom Typ "kein einzelnes VLAN" obligatorisch. Die Service-ID ist optional für Bridge-Domänen, für die eine VLAN-Kennung (VID) definiert ist. Wenn im letzteren Fall keine Dienst-ID definiert ist, wird sie aus der Dienst-ID-Konfiguration für diese Routing-Instanz übernommen.
Wenn diese Standard-Routing-Instanz (oder eine andere Routing-Instanz), die eine Bridge-Domäne mit einer aggregierten Multichassis-Ethernet-Schnittstelle enthält, konfiguriert wird, müssen Sie eine Service-ID numberfür switch-options auf globaler Ebene konfigurieren, unabhängig davon, ob für die enthaltenen Bridge-Domänen bestimmte Service-IDs konfiguriert sind.
In der Beispielabbildung in Abbildung 1 sind die Netzwerkroutinginstanzen N1 und N2, beide für dieselbe Dienst-ID, sowohl in N1 als auch in N2 mit derselben Dienst-ID konfiguriert. Die Verwendung einer Namenszeichenfolge anstelle einer Zahl wird nicht unterstützt.
Es gelten die folgenden Konfigurationseinschränkungen:
Die Service-ID muss konfiguriert werden, wenn die aggregierte Multichassis-Ethernet-Schnittstelle konfiguriert ist und eine aggregierte Ethernet-Schnittstelle Teil einer Bridge-Domäne ist. Diese Anforderung wird erzwungen.
Eine einzelne Bridge-Domäne kann nicht zwei Redundanzgruppen-IDs entsprechen.
In Abbildung 2 ist es möglich, eine Bridge-Domäne zu konfigurieren, die aus logischen Schnittstellen von zwei aggregierten Multichassis-Ethernet-Schnittstellen besteht, und diese einer separaten Redundanzgruppen-ID zuzuordnen, die nicht unterstützt wird. Ein Dienst muss eins zu eins mit der Redundanzgruppe zugeordnet werden, die den Dienst bereitstellt. Diese Anforderung wird erzwungen.
Abbildung 2: Bridge-Domäne mit logischen Schnittstellen von zwei aggregierten Multichassis-Ethernet-Schnittstellen
Um die aggregierte Multichassis-Ethernet-Konfiguration anzuzeigen, verwenden Sie den Befehl show interfaces mc-ae . Weitere Informationen finden Sie im CLI-Explorer.
Konfigurieren von IGMP-Snooping für Aktiv-Aktiv-MC-LAG
Damit die Multicastlösung funktioniert, muss Folgendes konfiguriert werden:
Die Multichassis-Schutzverbindung muss als Schnittstelle für den Router konfiguriert sein.
[edit bridge-domain bd-name] protocols { igmp-snooping { interface ge-0/0/0.0 { multicast-router-interface; } } }In diesem Beispiel ist ge-0/0/0.0 eine ICL-Schnittstelle.
Die
multichassis-lag-replicate-stateAnweisungsoptionen müssen unter dermulticast-snooping-optionsAnweisung für diese Bridge-Domäne konfiguriert werden.
Das Snooping mit Aktiv-Aktiv-MC-LAG wird nur im Nicht-Proxy-Modus unterstützt.
Konfigurieren von IGMP-Snooping im MC-LAG-Aktiv-Aktiv-Modus
Sie können die Option der bridge-domain Anweisung service-id verwenden, um die aggregierte Multichassis-Ethernet-Konfiguration auf MX240-Routern, MX480-Routern, MX960-Routern und Switches der QFX-Serie anzugeben.
Die
service-idAnweisung ist obligatorisch für Bridge-Domänen, die nicht mit einem einzelnen VLAN bestehen (none, all oder vlan-id-tags:dual).Die Anweisung ist für Bridge-Domänen mit definierter VID optional.
Die Bridge-Ebene
service-idist erforderlich, um verwandte Bridge-Domänen peerübergreifend zu verknüpfen, und sollte mit demselben Wert konfiguriert werden.Die
service-idWerte teilen sich den gemeinsamen Namensraum für alle Bridging- und Routinginstanzen sowie über Peers hinweg. Daher sind doppelteservice-idWerte für diese Entitäten nicht zulässig.Eine Änderung der Bridge-Service-ID wird als katastrophal angesehen, und die Bridge-Domäne wird geändert.
Mit diesem Verfahren können Sie die Replikationsfunktion aktivieren oder deaktivieren.
So konfigurieren Sie IGMP-Snooping im MC-LAG-Aktiv-Aktiv-Modus:
Konfiguration der manuellen und automatischen Verbindungsumschaltung für MC-LAG-Schnittstellen auf Routern der MX-Serie
In einer Multichassis-Link-Aggregation-Topologie (MC-LAG) mit Aktiv-Standby-Modus erfolgt ein Link-Switchover nur, wenn der aktive Knoten ausfällt. Sie können dieses Standardverhalten außer Kraft setzen, indem Sie eine MC-LAG-Schnittstelle im Aktiv-Standby-Modus so konfigurieren, dass sie automatisch zu einem bevorzugten Knoten zurückkehrt. Mit dieser Konfiguration können Sie einen Verbindungs-Switchover zu einem bevorzugten Knoten auslösen, auch wenn der aktive Knoten verfügbar ist. Betrachten Sie z. B. zwei Knoten, PE1 und PE2. PE1 ist im aktiven Modus konfiguriert, was ihn zu einem bevorzugten Knoten macht, und PE2 ist im Aktiv-Standby-Modus konfiguriert. Im Falle eines Ausfalls bei PE1 wird PE2 zum aktiven Knoten. Sobald jedoch PE1 wieder verfügbar ist, wird eine automatische Verbindungsumschaltung ausgelöst und die Steuerung wieder auf PE1 geschaltet, obwohl PE2 aktiv ist.
Sie können den Link-Switchover in zwei Modi konfigurieren: revertiv und nicht revertiv. Im Umkehrmodus wird die Verbindungsumschaltung automatisch über den request interface mc-ae switchover Befehl Betriebsmodus ausgelöst. Im nicht-revertiven Modus muss die Linkumschaltung manuell vom Benutzer angestoßen werden. Sie können auch eine Wiederherstellungszeit konfigurieren, die eine automatische oder manuelle Umschaltung auslöst, wenn der angegebene Timer abläuft.
Wenn auf den aggregierten Ethernet-Schnittstellen der MC-LAGs zwei MC-LAG-Geräte konfiguriert sind, die in einem Aktiv-Standby-Setup mit Inter-Chassis Control Protocol (ICCP) und nicht-revertivem Switchcover-Modus konfiguriert sind, und wenn beide MC-AE-Schnittstellen mit einer lokalen Layer-2-Circuit-Switching-Konfiguration verbunden sind, empfehlen wir, dass Sie den Switchover durchführen, indem Sie die
request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)Betriebsmodusbefehl auf nur einer der aggregierten Ethernet-Schnittstellen eines MC-LAG-Geräts. Dieser Befehl kann nur auf MC-LAG-Geräten ausgegeben werden, die als aktive Knoten konfiguriert sind (mithilfe derstatus-control activeAnweisung auf Hierarchieebene[edit interfaces aeX aggregated-ether-options mc-ae]).Wenn im nicht umkehrbaren Umschaltmodus eine MC-LAG-Schnittstelle aufgrund eines Ausfalls einer MC-LAG-Mitgliedsverbindung in den Standby-Zustand wechselt und eine andere MC-LAG-Schnittstelle in den aktiven Zustand wechselt, verbleibt die MC-LAG im Standby-Zustand in diesem Zustand, bis die MC-LAG im aktiven Zustand einen Fehler erkennt und in den aktiven Zustand zurückkehrt.
Wenn Sie aufgrund der lokalen Switching-Konfiguration der Layer-2-Verbindung einen Switchover auf beiden aggregierten Ethernet-Schnittstellen in der MC-LAG durchführen, löst ein Switchover auf der einen aggregierten Ethernet-Schnittstelle einen Switchover auf der anderen aggregierten Ethernet-Schnittstelle aus. In einem solchen Szenario wechseln beide aggregierten Ethernet-Schnittstellen in den Standby-Zustand und gehen dann wieder in den aktiven Zustand über. Daher dürfen Sie den Switchover nicht auf beiden aggregierten Ethernet-Schnittstellen in einer MC-LAG gleichzeitig durchführen.
Layer-2-Leitungskonfiguration und VPLS-Funktionen werden nicht unterstützt, wenn Sie eine MC-LAG-Schnittstelle für den Umkehr-Switchover-Modus konfigurieren. Sie können die Funktion zum revertiven oder nicht wiederherstellbaren Umschalten nur konfigurieren, wenn zwei MC-LAG-Geräte in einem Aktiv-Standby-Setup konfiguriert sind (ein Gerät wird mithilfe der
status-control standbyAnweisung als aktiver Knoten und das andere Gerät mithilfe derstatus-control activeAnweisung auf Hierarchieebene[edit interfaces aeX aggregated-ether-options mc-ae]als Standbyknoten festgelegt). Sie können einen Switchover durchführen, indem Sie denrequest interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)Befehl Betriebsmodus nur auf MC-LAG-Geräten eingeben, die als aktive Knoten konfiguriert sind.
So konfigurieren Sie den Link-Switchover-Mechanismus auf einer MC-LAG-Schnittstelle:
Sie können den show interfaces mc-ae revertive-info Befehl verwenden, um die Konfigurationsinformationen für den Switchover anzuzeigen.
Erzwingen der Verfügbarkeit von MC-LAG-Verbindungen oder -Schnittstellen mit begrenzter LACP-Kapazität
In einem MC-LAG-Netzwerk bleibt eine MC-LAG-Clientverbindung ohne LACP-Konfiguration (Link Access Control Protocol) unterbrochen und kann von den MC-LAG-Switches nicht aufgerufen werden.
Um sicherzustellen, dass das Clientgerät mit eingeschränkten LACP-Funktionen im MC-LAG-Netzwerk verfügbar und zugänglich ist, konfigurieren Sie einen der aggregierten Ethernet-Links oder -Schnittstellen auf einem MC-LAG-Switch so, dass er verfügbar ist, indem Sie die force-up Anweisung auf der entsprechenden Hierarchieebene auf Ihrem Gerät verwenden:
[edit interfaces interface-name aggregated-ether-options lacp]
Sie können die Force-up-Funktion auf den MC-LAG-Switches entweder im aktiven Modus oder im Standby-Modus konfigurieren. Um jedoch doppelten Datenverkehr und Paketverluste zu vermeiden, konfigurieren Sie die Force-up-Funktion nur auf einer aggregierten Ethernet-Verbindung der MC-LAG-Switches. Wenn mehrere aggregierte Ethernet-Verbindungen auf den MC-LAG-Switches mit konfigurierter Force-up-Funktion vorhanden sind, wählt das Gerät die Verbindung basierend auf der LACP-Port-ID und der Portpriorität aus. Der Port mit der niedrigsten Priorität erhält Vorrang. Bei zwei Ports mit gleicher Priorität wird derjenige mit der niedrigsten Port-ID bevorzugt.
Die force-up Option wird auf QFX10002-Switches nicht unterstützt.
Auf dem QFX5100-Switch können Sie die Force-up-Funktion im Link Aggregation Control Protocol (LACP) auf den MC-LAG-Switches ab Junos OS Version 14.1X53-D10 konfigurieren.
Wenn LACP teilweise im MC-LAG-Netzwerk auftaucht, d. h., wenn es auf einem der MC-LAG-Switches und nicht auf anderen MC-LAG-Switches auftaucht, ist die Force-Up-Funktion deaktiviert.
Erhöhung der ARP- und Network Discovery-Protokolleinträge für verbesserte MC-LAG- und Layer-3-VXLAN-Topologien
- Erkennen der Notwendigkeit einer Erhöhung der ARP- und Network Discovery Protocol (NDP)-Einträge
- Erhöhung der ARP- und Network Discovery-Protokolleinträge für erweiterte MC-LAG mithilfe von IPv4-Transport
- Erhöhung der ARP- und Network Discovery-Protokolleinträge für erweiterte MC-LAG mit IPv6-Transport
- Erhöhung des ARP für EVPN-VXLAN-Gateway für Border-Leaf in der Edge Routed Bridge (ERB) oder Spine in der Centrally Routed Bridge (CRB) für IPv4-Mandantendatenverkehr
- Erhöhung der ARP- und Netzwerkerkennungsprotokolleinträge für EVPN-VXLAN-Gateway für Border-Leaf in der Edge Routed Bridge (ERB) oder Spine in der zentral gerouteten Bridge (CRB) für IPv6-Mandantendatenverkehr
Erkennen der Notwendigkeit einer Erhöhung der ARP- und Network Discovery Protocol (NDP)-Einträge
Die Anzahl der ARP- und NDP-Einträge wurde auf 256.000 erhöht, um erweiterte MC-LAG- und Layer 3-VXLAN-Szenarien zu verbessern.
Im Folgenden finden Sie einige erweiterte MC-LAG- und Layer 3-VXLAN-Szenarien, in denen eine Erhöhung der ARP- und NDP-Einträge erforderlich ist:
Verbesserte MC-LAG-Topologie mit einer großen Anzahl von MC-AE-Schnittstellen, die eine große Anzahl von Mitgliedern pro Gehäuse enthalten.
Nicht reduzierte Spine-Leaf-Topologie, bei der die Leaf-Geräte als Layer-2-Gateways fungieren und den Datenverkehr innerhalb des VXLAN verarbeiten, während die Spine-Geräte als Layer-3-Gateways fungieren und den Datenverkehr zwischen den VXLANs über IRB-Schnittstellen verarbeiten.
In diesem Szenario ist die Erhöhung der ARP- und NDP-Einträge auf Spine-Ebene erforderlich.
Leaf-Geräte, die sowohl als Layer-2- als auch als Layer-3-Gateways fungieren.
In diesem Szenario bieten die Transit-Spine-Geräte nur Layer-3-Routing-Funktionen, und die erhöhte Anzahl von ARP- und NDP-Einträgen wird nur auf Leaf-Ebene benötigt.
Erhöhung der ARP- und Network Discovery-Protokolleinträge für erweiterte MC-LAG mithilfe von IPv4-Transport
Gehen Sie folgendermaßen vor, um die Anzahl der ARP- und NDP-Einträge mithilfe des IPv4-Transports zu erhöhen. Es wird empfohlen, die in diesem Verfahren angegebenen Werte zu verwenden, um eine optimale Leistung zu erzielen:
Erhöhung der ARP- und Network Discovery-Protokolleinträge für erweiterte MC-LAG mit IPv6-Transport
Erhöhen Sie die Anzahl der ARP- und Network Discovery Protocol-Einträge mithilfe des IPv6-Transports. Es wird empfohlen, die in diesem Verfahren angegebenen Werte zu verwenden, um eine optimale Leistung zu erzielen:
Erhöhung des ARP für EVPN-VXLAN-Gateway für Border-Leaf in der Edge Routed Bridge (ERB) oder Spine in der Centrally Routed Bridge (CRB) für IPv4-Mandantendatenverkehr
Gehen Sie folgendermaßen vor, um die Anzahl der ARP-Einträge mit IPv4-Mandantendatenverkehr zu erhöhen. Es wird empfohlen, die in diesem Verfahren angegebenen Werte zu verwenden, um eine optimale Leistung zu erzielen:
Erhöhung der ARP- und Netzwerkerkennungsprotokolleinträge für EVPN-VXLAN-Gateway für Border-Leaf in der Edge Routed Bridge (ERB) oder Spine in der zentral gerouteten Bridge (CRB) für IPv6-Mandantendatenverkehr
Gehen Sie folgendermaßen vor, um die Anzahl der ARP- und Network Discovery Protocol-Einträge mit IPv4- und IPv6-Mandantendatenverkehr zu erhöhen. Es wird empfohlen, die in diesem Verfahren angegebenen Werte zu verwenden, um eine optimale Leistung zu erzielen:
Synchronisieren und Bestätigen von Konfigurationen
Führen Sie die folgenden Aufgaben aus, um Konfigurationsänderungen von einem Gerät (Junos Fusion Provider Edge, Junos Fusion Enterprise, Switches der EX-Serie und Router der MX-Serie) an ein anderes Gerät weiterzugeben, zu synchronisieren und zu bestätigen:
- Konfigurieren von Geräten für die Konfigurationssynchronisierung
- Erstellen einer globalen Konfigurationsgruppe
- Erstellen einer lokalen Konfigurationsgruppe
- Erstellen einer Remotekonfigurationsgruppe
- Erstellen von Anwendungsgruppen für die lokale, Remote- und globale Konfiguration
- Synchronisieren und Bestätigen von Konfigurationen
- Fehlerbehebung bei Remote-Geräteverbindungen
Konfigurieren von Geräten für die Konfigurationssynchronisierung
Konfigurieren Sie die Hostnamen oder IP-Adressen für die Geräte, die ihre Konfigurationen synchronisieren sollen, sowie die Benutzernamen und Authentifizierungsdetails für die Benutzer, die die Konfigurationssynchronisierung verwalten. Aktivieren Sie außerdem eine NETCONF-Verbindung, damit die Geräte ihre Konfigurationen synchronisieren können. Das Secure Copy Protocol (SCP) kopiert die Konfigurationen sicher zwischen den Geräten.
Wenn Sie beispielsweise ein lokales Gerät mit dem Namen "Switch A" haben und eine Konfiguration mit Remote-Geräten namens "Switch B", "Switch C" und "Switch D" synchronisieren möchten, müssen Sie die Details für "Switch B", "Switch C" und "Switch D" auf "Switch A" konfigurieren.
So legen Sie die Konfigurationsdetails fest:
Erstellen einer globalen Konfigurationsgruppe
Erstellen Sie eine globale Konfigurationsgruppe, die lokalen und Remote-Geräte.
So erstellen Sie eine globale Konfigurationsgruppe:
Die Ausgabe für die Konfiguration lautet wie folgt:
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;
}
}
}
}
Erstellen einer lokalen Konfigurationsgruppe
Erstellen Sie eine lokale Konfigurationsgruppe für das lokale Gerät.
So erstellen Sie eine lokale Konfigurationsgruppe:
Die Ausgabe für die Konfiguration lautet wie folgt:
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;
}
}
}
}
Erstellen einer Remotekonfigurationsgruppe
Erstellen Sie eine Remotekonfigurationsgruppe für Remotegeräte.
So erstellen Sie eine Remotekonfigurationsgruppe:
Die Ausgabe für die Konfiguration lautet wie folgt:
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;
}
}
}
}
Erstellen von Anwendungsgruppen für die lokale, Remote- und globale Konfiguration
Erstellen Sie Anwendungsgruppen, damit Änderungen in der Konfiguration an lokale, Remote- und globale Konfigurationsgruppen vererbt werden. Listet die Konfigurationsgruppen in der Reihenfolge der Vererbung auf, wobei die Konfigurationsdaten in der ersten Konfigurationsgruppe Vorrang vor den Daten in nachfolgenden Konfigurationsgruppen haben.
Wenn Sie die Konfigurationsgruppen anwenden und den commit peers-synchronize Befehl ausgeben, werden die Änderungen sowohl auf dem lokalen als auch auf dem Remotegerät übernommen. Wenn auf einem der Geräte ein Fehler auftritt, wird eine Fehlermeldung ausgegeben und der Commit wird beendet.
So wenden Sie die Konfigurationsgruppen an:
[edit] user@switch# set apply-groups [<name of global configuration group> <name of local configuration group> <name of remote configuration group>]
Zum Beispiel:
[edit] user@switch# set apply-groups [ global local remote ]
Die Ausgabe für die Konfiguration lautet wie folgt:
apply-groups [ global local remote ];Synchronisieren und Bestätigen von Konfigurationen
Der commit at <"string"> Befehl wird beim Ausführen der Konfigurationssynchronisierung nicht unterstützt.
Sie können die peers-synchronize Anweisung auf dem lokalen (oder anfordernden) Gerät aktivieren, um ihre Konfiguration standardmäßig auf das entfernte (oder antwortende) Gerät zu kopieren und zu laden. Alternativ können Sie den commit peers-synchronize Befehl auch ausführen.
Konfigurieren Sie den
commitBefehl auf dem lokalen (oder anfordernden) Befehl, um automatisch einepeers-synchronizeAktion zwischen Geräten auszuführen.[edit] user@switch# set system commit peers-synchronize
Die Ausgabe für die Konfiguration lautet wie folgt:
system { commit { peers-synchronize; } }Geben Sie den
commit peers-synchronizeBefehl auf dem lokalen (oder anfordernden) Gerät aus.[edit] user@switch# commit peers-synchronize
Fehlerbehebung bei Remote-Geräteverbindungen
Problem
Beschreibung
Wenn Sie den commit Befehl absetzen, gibt das System die folgende Fehlermeldung aus:
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
Die Fehlermeldung zeigt an, dass ein NETCONF-Verbindungsproblem zwischen dem lokalen Gerät und dem Remotegerät vorliegt.
Auflösung
Auflösung
Stellen Sie sicher, dass die SSH-Verbindung zum Remote-Gerät (Switch B) funktioniert.
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.Die Fehlermeldung zeigt an, dass die SSH-Verbindung nicht funktioniert.
Löschen Sie den Schlüsseleintrag im Verzeichnis /root/.ssh/known_hosts:1 und versuchen Sie erneut, eine Verbindung zu Switch B herzustellen.
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.Die Verbindung zu Switch B war erfolgreich.
Melden Sie sich von Switch B ab.
root@Switch B# exit
logout Connection to Switch B closed.Stellen Sie sicher, dass NETCONF über SSH funktioniert.
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>Die Protokollmeldung zeigt, dass die NETCONF über SSH erfolgreich war.
Wenn die Fehlermeldung zeigte, dass NETCONF über SSH nicht erfolgreich war, aktivieren Sie NETCONF über SSH, indem Sie den
set system services netconf sshBefehl eingeben.Erstellen Sie Konfigurationsgruppen für die Synchronisierung, falls Sie dies noch nicht getan haben.
Sie können den
show | compareBefehl ausgeben, um zu sehen, ob Konfigurationsgruppen erstellt wurden.root@Switch A# show | compare
Geben Sie den
commitBefehl ein.root@Switch A# commit
[edit chassis] configuration check succeeds commit complete {master:0}[edit]Die Protokollmeldung zeigt an, dass der Commit erfolgreich war.