Konfigurieren der Routing-Engine-Redundanz
Führen Sie die folgenden Schritte und Beispiele aus, um die Routing-Engine-Redundanz zu konfigurieren.
Um die Aufgaben in den folgenden Abschnitten ausführen zu können, müssen die Konfigurationsgruppen re0 und re1 definiert werden. Weitere Informationen zu Konfigurationsgruppen finden Sie im Junos OS CLI-Benutzerhandbuch.
Ändern der primären Standardrolle der Routing-Engine
Bei Routern mit zwei Routing-Engines können Sie konfigurieren, welche Routing-Engine die primäre und welche die Sicherung ist. Standardmäßig ist die Routing-Engine in Steckplatz 0 die primäre (re0) und die in Steckplatz 1 die Sicherung (re1).
In Systemen mit zwei Routing-Engines können nicht beide Routing-Engines gleichzeitig als primär konfiguriert werden. Diese Konfiguration führt dazu, dass die Commit-Prüfung fehlschlägt.
Um die Standardkonfiguration zu ändern, fügen Sie die routing-engine Anweisung auf der [edit chassis redundancy] Hierarchieebene ein:
[edit chassis redundancy] routing-engine slot-number (master | backup | disabled);
slot-number kann 0 oder 1 sein. Um die Routing-Engine als primäre Instanz zu konfigurieren, geben Sie die master-Option an. Um es als Backup zu konfigurieren, geben Sie die Backup-Option an. Um eine Routing-Engine zu deaktivieren, geben Sie die Option disabled an.
Informationen zum Wechseln zwischen der primären und der Backup-Routing-Engine finden Sie unter Manuelles Wechseln der primären Rolle der Routing-Engine.
Konfigurieren des automatischen Failovers auf die Backup-Routing-Engine
In den folgenden Abschnitten wird beschrieben, wie Sie das automatische Failover auf die Sicherungs-Routing-Engine konfigurieren, wenn bestimmte Fehler auf der primären Routing-Engine auftreten.
- Ohne Unterbrechung der Paketweiterleitung
- Bei Erkennung eines Festplattenfehlers auf der primären Routing-Engine
- Bei Erkennung einer unterbrochenen LCMD-Konnektivität zwischen der VM und der RE
- Bei Erkennung eines Verlusts des Keepalive-Signals von der primären Routing-Engine
- bei Erkennung des em0-Schnittstellenfehlers auf der primären Routing-Engine
- Wenn ein Softwareprozess fehlschlägt
Ohne Unterbrechung der Paketweiterleitung
Für Router mit zwei Routingmodulen können Sie Graceful Routing-Engine Switchover (GRES) konfigurieren. Wenn Graceful-Switchover konfiguriert ist, erfolgt die Wiederherstellung der Socketverbindung nahtlos und ohne Unterbrechung der Paketweiterleitung. Informationen zum Konfigurieren des Graceful Routing-Engine-Switchovers finden Sie unter Konfigurieren des Graceful Routing-Engine-Switchovers.
Bei Erkennung eines Festplattenfehlers auf der primären Routing-Engine
Nachdem Sie eine Backup-Routing-Engine konfiguriert haben, können Sie sie anweisen, automatisch die primäre Rolle zu übernehmen, wenn sie einen Festplattenfehler von der primären Routing-Engine erkennt. Um diese Funktion zu aktivieren, schließen Sie die on-disk-failure Anweisung auf der [edit chassis redundancy failover] Hierarchieebene ein.
[edit chassis redundancy failover] on-disk-failure;
Die on-disk-failure Anweisung auf der Hierarchieebene wird auf PTX-Plattformen, auf denen [edit chassis redundancy] Junos weiterentwickelt ausgeführt wird, nicht unterstützt. Diese Plattformen verwenden standardmäßig einen Switchover, wenn ein Festplattenfehler erkannt wird.
Bei Erkennung einer unterbrochenen LCMD-Konnektivität zwischen der VM und der RE
Legen Sie die folgende Konfiguration fest, die zu einem automatischen RE-Switchover führt, wenn die LCMD-Konnektivität zwischen VM und RE unterbrochen wird. Um diese Funktion zu aktivieren, schließen Sie die on-loss-of-vm-host-connection Anweisung auf der [edit chassis redundancy failover] Hierarchieebene ein.
[edit chassis redundancy failover] on-loss-of-vm-host-connection;
Wenn der LCMD-Prozess auf dem primären Server abstürzt, schaltet das System nach einer Minute um, vorausgesetzt, die Backup-RE-LCMD-Verbindung ist stabil. Das System schaltet unter den folgenden Bedingungen nicht um: wenn die Backup-RE-LCMD-Verbindung instabil ist oder wenn der aktuelle primäre Server gerade die primäre Rolle übernommen hat. Wenn der primäre Server gerade die primäre Rolle übernommen hat, erfolgt der Wechsel erst nach vier Minuten.
Bei Erkennung eines Verlusts des Keepalive-Signals von der primären Routing-Engine
Nachdem Sie eine Backup-Routing-Engine konfiguriert haben, können Sie sie anweisen, automatisch die primäre Rolle zu übernehmen, wenn sie einen Verlust des Keepalive-Signals von der primären Routing-Engine erkennt.
Um das Failover beim Empfang eines Keepalive-Verlustsignals zu aktivieren, fügen Sie die on-loss-of-keepalives Anweisung auf der [edit chassis redundancy failover] Hierarchieebene ein:
[edit chassis redundancy failover] on-loss-of-keepalives;
Die on-loss-of-keepalives Anweisung in der Hierarchie wird auf PTX-Plattformen, auf denen [edit chassis redundancy] Junos weiterentwickelt wird, nicht unterstützt. Diese Plattformen verwenden standardmäßig einen Switchover, wenn Keepalive-Nachrichten nicht erkannt werden.
Wenn kein Graceful Routing-Engine-Switchover konfiguriert ist, erfolgt das Failover standardmäßig nach 300 Sekunden (5 Minuten). Sie können ein kürzeres oder längeres Zeitintervall konfigurieren.
Der Keepalive-Zeitraum wird auf 360 Sekunden zurückgesetzt, wenn die primäre Routing-Engine manuell neu gestartet oder angehalten wurde.
Um den Keepalive-Zeitraum zu ändern, fügen Sie die keepalive-time Anweisung auf der [edit chassis redundancy] Hierarchieebene ein:
[edit chassis redundancy] keepalive-time seconds;
Der Bereich für die Keepalive-Zeit beträgt 2 bis 10.000 Sekunden.
Im folgenden Beispiel wird die Abfolge von Ereignissen beschrieben, wenn Sie die Backup-Routing-Engine so konfigurieren, dass ein Verlust des Keepalive-Signals in der primären Routing-Engine erkannt wird:
-
Konfigurieren Sie manuell eine Keepalive-Zeit von 25 Sekunden.
-
Nachdem die Verbindung der Packet Forwarding Engine zur primären Routing-Engine unterbrochen wurde und der Keepalive-Timer abläuft, wird die Paketweiterleitung unterbrochen.
-
Nach 25 Sekunden Keepalive-Verlust wird eine Meldung protokolliert, und die Backup-Routing-Engine versucht, die primäre Rolle zu übernehmen. Wenn die Backup-Routing-Engine aktiv wird, wird ein Alarm generiert und die Anzeige mit dem aktuellen Status der Routing-Engine aktualisiert.
-
Nachdem die Backup-Routing-Engine die primäre Rolle übernommen hat, fungiert sie weiterhin als primär.
Wenn Graceful Routing-Engine Switchover konfiguriert ist, wird das Keepalive-Signal automatisch aktiviert, und die Failoverzeit wird auf 2 Sekunden festgelegt. Sie können die Keepalive-Zeit nicht manuell zurücksetzen.
Wenn Sie die primäre Routing-Engine anhalten oder neu starten, setzt Junos OS die Keepalive-Zeit auf 360 Sekunden zurück, und die Backup-Routing-Engine übernimmt die primäre Rolle erst, wenn der Keepalive-Zeitraum von 360 Sekunden abgelaufen ist.
Eine ehemalige primäre Routing-Engine wird zu einer Backup-Routing-Engine, wenn sie nach einem Failover auf die Backup-Routing-Engine wieder in Betrieb genommen wird. Um den primären Status der früheren primären Routing-Engine wiederherzustellen, können Sie den Befehl request chassis routing-engine master switch operational mode verwenden.
Wenn zu irgendeinem Zeitpunkt eine der Routing-Engines nicht vorhanden ist, wird die verbleibende Routing-Engine automatisch zur primären , unabhängig davon, wie die Redundanz konfiguriert ist.
bei Erkennung des em0-Schnittstellenfehlers auf der primären Routing-Engine
Nachdem Sie eine Backup-Routing-Engine konfiguriert haben, weisen Sie sie an, automatisch die primäre Rolle zu übernehmen, wenn die em0-Schnittstelle auf der primären Routing-Engine ausfällt. Um diese Funktion zu aktivieren, schließen Sie die on-re-to-fpc-stale Anweisung auf der [edit chassis redundancy failover] Hierarchieebene ein.
[edit chassis redundancy failover] on-re-to-fpc-stale;
Wenn ein Softwareprozess fehlschlägt
Um die automatische Umschaltung auf die Backup-Routing-Engine zu konfigurieren, wenn ein Softwareprozess fehlschlägt, fügen Sie die failover other-routing-engine Anweisung auf der [edit system processes process-name] Hierarchieebene ein:
[edit system processes process-name] failover other-routing-engine;
process-name ist einer der gültigen Prozessnamen. Wenn diese Anweisung für einen Prozess konfiguriert ist und dieser Prozess innerhalb von 30 Sekunden viermal fehlschlägt, wird der Router von der anderen Routing-Engine neu gestartet. Eine weitere Anweisung, die auf der [edit system processes] Hierarchieebene verfügbar ist, ist failover alternate-media. Weitere Informationen zur Option "Alternative Medien" finden Sie in der Junos OS Administration Library for Routing Devices.
Manuelles Wechseln der Routing-Engine Primäre Rolle
Verwenden Sie einen der folgenden Befehle, um die primäre Rolle der Routing-Engine manuell zu wechseln:
-
Fordern Sie auf der Sicherungs-Routing-Engine an, dass die Sicherungs-Routing-Engine die primäre Rolle übernimmt, indem Sie den
request chassis routing-engine master acquireBefehl ausgeben. -
Fordern Sie auf der primären Routing-Engine an, dass die Backup-Routing-Engine die primäre Rolle übernimmt, indem Sie den
request chassis routing-engine master releaseBefehl verwenden. -
Wechseln Sie auf einer der beiden Routing-Engines die primäre Rolle, indem Sie den
request chassis routing-engine master switchBefehl eingeben.
Überprüfen des Redundanzstatus der Routing-Engine
Eine separate Protokolldatei wird für die Redundanzprotokollierung unter /var/log/mastership bereitgestellt. Verwenden Sie den file show /var/log/mastership Befehl, um das Protokoll anzuzeigen. In Tabelle 1 sind die Ereigniscodes und Beschreibungen des primären Rollenprotokolls aufgeführt.
| Ereigniscode |
Beschreibung |
|---|---|
| E_NULL = 0 |
Das Ereignis ist ein NULL-Ereignis. |
| E_CFG_M |
Die Routing-Engine ist als primär konfiguriert. |
| E_CFG_B |
Die Routing-Engine ist als Backup konfiguriert. |
| E_CFG_D |
Die Routing-Engine ist als deaktiviert konfiguriert. |
| E_MAXTRY |
Die maximale Anzahl von Versuchen, die primäre Rolle zu erwerben oder freizugeben, wurde überschritten. |
| E_REQ_C |
Es wurde eine Anforderung für die primäre Rolle des Anspruchs gesendet. |
| E_ACK_C |
Es wurde eine Bestätigung der primären Rolle des Anspruchs empfangen. |
| E_NAK_C |
Eine Anforderung an die primäre Rolle eines Anspruchs wurde nicht bestätigt. |
| E_REQ_Y |
Die Bestätigung der primären Rolle wird angefordert. |
| E_ACK_Y |
Primäre Rolle anerkannt wird. |
| E_NAK_Y |
Primäre Rolle wird nicht anerkannt. |
| E_REQ_G |
Eine Anforderung für die primäre Releaserolle wurde von einer Routing-Engine gesendet. |
| E_ACK_G |
Die Routing-Engine bestätigte die Freigabe der primären Rolle. |
| E_CMD_A |
Die Befehlsanforderung chassis routing-engine master acquire wurde von der Backup-Routing-Engine ausgegeben. |
| E_CMD_F |
Die Befehlsanforderung chassis routing-engine master acquire force wurde von der Backup-Routing-Engine ausgegeben. |
| E_CMD_R |
Die Masterversion der Chassis-Routing-Engine für die Befehlsanforderung wurde von der primären Routing-Engine ausgegeben. |
| E_CMD_S |
Der Chassis-Routing-Engine-Master-Switch für die Befehlsanforderung wurde von einer Routing-Engine ausgegeben. |
| E_NO_ORE |
Es wird keine andere Routing-Engine erkannt. |
| E_TMOUT |
Eine Zeitüberschreitung bei einer Anforderung. |
| E_NO_IPC |
Die Routing-Engine-Verbindung wurde unterbrochen. |
| E_ORE_M |
Der Status "Andere Routing-Engine" wurde in "Primär" geändert. |
| E_ORE_B |
Der Status der anderen Routing-Engine wurde in eine Sicherung geändert. |
| E_ORE_D |
Der Status der anderen Routing-Engine wurde in "Deaktiviert" geändert. |
Überprüfen Sie die CPU- und Speicherauslastung insgesamt.
Zweck
Sie können umfassende Informationen zu Systemprozessen über Softwareprozesse anzeigen, die auf dem Router ausgeführt werden und über steuernde Terminals verfügen. Dieser Befehl entspricht dem UNIX-Befehl top. Der UNIX-Befehl top zeigt jedoch die Speicherauslastung in Echtzeit an, wobei sich die Speicherwerte ständig ändern, während der Befehl show system processes extensive eine Momentaufnahme der Speicherauslastung zu einem bestimmten Zeitpunkt liefert.
Aktion
Um die gesamte CPU- und Speicherauslastung zu überprüfen, geben Sie den folgenden Junos OS-Befehl für die Befehlszeilenschnittstelle (CLI) ein:
user@host> show system processes extensive
Beispielausgabe
user@R1> show system processes extensive
last pid: 5251; load averages: 0.00, 0.00, 0.00 up 4+20:22:16 10:44:41
58 processes: 1 running, 57 sleeping
Mem: 57M Active, 54M Inact, 17M Wired, 184K Cache, 35M Buf, 118M Free
Swap: 512M Total, 512M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
4480 root 2 0 3728K 1908K select 231:17 2.34% 2.34% chassisd
4500 root 2 0 1896K 952K select 0:36 0.00% 0.00% fud
4505 root 2 0 1380K 736K select 0:35 0.00% 0.00% irsd
4481 root 2 0 1864K 872K select 0:32 0.00% 0.00% alarmd
4488 root 2 0 8464K 4600K kqread 0:28 0.00% 0.00% rpd
4501 root 2 -15 1560K 968K select 0:21 0.00% 0.00% ppmd
4510 root 2 0 1372K 812K select 0:13 0.00% 0.00% bfdd
5 root 18 0 0K 0K syncer 0:09 0.00% 0.00% syncer
4485 root 2 0 3056K 1776K select 0:07 0.00% 0.00% snmpd
4499 root 2 0 3688K 1676K select 0:05 0.00% 0.00% kmd
4486 root 2 0 3760K 1748K select 0:05 0.00% 0.00% mib2d
4493 root 2 0 1872K 928K select 0:03 0.00% 0.00% pfed
4507 root 2 0 1984K 1052K select 0:02 0.00% 0.00% fsad
4518 root 2 0 3780K 2400K select 0:02 0.00% 0.00% dcd
8 root -18 0 0K 0K psleep 0:02 0.00% 0.00% vmuncachedaemo
4 root -18 0 0K 0K psleep 0:02 0.00% 0.00% bufdaemon
4690 root 2 0 0K 0K peer_s 0:01 0.00% 0.00% peer proxy
4504 root 2 0 1836K 968K select 0:01 0.00% 0.00% dfwd
4477 root 2 0 992K 320K select 0:01 0.00% 0.00% watchdog
4354 root 2 0 1116K 604K select 0:01 0.00% 0.00% syslogd
4492 root 10 0 1004K 400K nanslp 0:01 0.00% 0.00% tnp.sntpd
4446 root 10 0 1108K 616K nanslp 0:01 0.00% 0.00% cron
4484 root 2 0 15716K 7468K select 0:01 0.00% 0.00% mgd
4494 root 2 15 2936K 2036K select 0:01 0.00% 0.00% sampled
5245 remote 2 0 8340K 3472K select 0:01 0.00% 0.00% cli
2 root -18 0 0K 0K psleep 0:00 0.00% 0.00% pagedaemon
4512 root 2 0 2840K 1400K select 0:00 0.00% 0.00% l2tpd
1 root 10 0 852K 580K wait 0:00 0.00% 0.00% init
5244 root 2 0 1376K 784K select 0:00 0.00% 0.00% telnetd
4509 root 10 0 1060K 528K nanslp 0:00 0.00% 0.00% eccd
4508 root 2 0 2264K 1108K select 0:00 0.00% 0.00% spd
2339 root 10 0 514M 17260K mfsidl 0:00 0.00% 0.00% newfs
4497 root 2 0 2432K 1152K select 0:00 0.00% 0.00% cosd
4490 root 2 -15 2356K 1020K select 0:00 0.00% 0.00% apsd
4496 root 2 0 2428K 1108K select 0:00 0.00% 0.00% rmopd
4491 root 2 0 2436K 1104K select 0:00 0.00% 0.00% vrrpd
4487 root 2 0 15756K 7648K sbwait 0:00 0.00% 0.00% mgd
5246 root 2 0 15776K 8336K select 0:00 0.00% 0.00% mgd
0 root -18 0 0K 0K sched 0:00 0.00% 0.00% swapper
5251 root 30 0 21732K 840K RUN 0:00 0.00% 0.00% top
4511 root 2 0 1964K 908K select 0:00 0.00% 0.00% pgmd
4502 root 2 0 1960K 956K select 0:00 0.00% 0.00% lmpd
4495 root 2 0 1884K 876K select 0:00 0.00% 0.00% ilmid
4482 root 2 0 1772K 776K select 0:00 0.00% 0.00% craftd
4503 root 10 0 1040K 492K nanslp 0:00 0.00% 0.00% smartd
6 root 28 0 0K 0K sleep 0:00 0.00% 0.00% netdaemon
4498 root 2 0 1736K 932K select 0:00 0.00% 0.00% nasd
4506 root 2 0 1348K 672K select 0:00 0.00% 0.00% rtspd
4489 root 2 0 1160K 668K select 0:00 0.00% 0.00% inetd
4478 root 2 0 1108K 608K select 0:00 0.00% 0.00% tnetd
4483 root 2 0 1296K 540K select 0:00 0.00% 0.00% ntpd
4514 root 3 0 1080K 540K ttyin 0:00 0.00% 0.00% getty
4331 root 2 0 416K 232K select 0:00 0.00% 0.00% pccardd
7 root 2 0 0K 0K pfeacc 0:00 0.00% 0.00% if_pfe_listen
11 root 2 0 0K 0K picacc 0:00 0.00% 0.00% if_pic_listen
3 root 18 0 0K 0K psleep 0:00 0.00% 0.00% vmdaemon
9 root 2 0 0K 0K scs_ho 0:00 0.00% 0.00% scs_housekeepi
10 root 2 0 0K 0K cb-pol 0:00 0.00% 0.00% cb_poll
Bedeutung
Die Beispielausgabe zeigt die Menge an virtuellem Arbeitsspeicher, die von der Routing-Engine und Softwareprozessen verwendet wird. Beispielsweise sind 118 MB physischer Speicher und 512 MB der Auslagerungsdatei frei, was darauf hinweist, dass der Arbeitsspeicher des Routers nicht knapp ist. Das Feld "Prozesse" zeigt, dass sich die meisten der 58 Prozesse im Ruhezustand befinden, wobei sich 1 im Ausführungszustand befindet. Der ausgeführte Prozess oder Befehl ist der oberste Befehl.
In der Spalte "Befehle" werden die Prozesse aufgelistet, die derzeit ausgeführt werden. Der Chassis-Prozess (Chassisd) hat beispielsweise eine Prozesskennung (PID) von 4480 mit einer aktuellen Priorität (PRI) von 2. Eine niedrigere Prioritätszahl gibt eine höhere Priorität an.
Die Prozesse werden nach Aktivitätsgrad aufgelistet, wobei der aktivste Prozess ganz oben in der Ausgabe steht. Beispielsweise verbraucht der Chassis-Prozess (Chassisd) mit 2,34 Prozent die größte Menge an CPU-Ressourcen.
Das Speicherfeld (Mem) zeigt den virtuellen Speicher an, der von der Routing-Engine verwaltet und von Prozessen verwendet wird. Der Wert im Speicherfeld wird in KB und MB angegeben und ist wie folgt aufgeteilt:
-
Aktiv: Speicher, der zugewiesen wird und von Programmen verwendet wird.
-
Inact: Speicher, der entweder zugewiesen, aber nicht zuletzt verwendet wurde, oder Speicher, der von Programmen freigegeben wurde. Inaktiver Speicher wird weiterhin im Adressraum eines oder mehrerer Prozesse abgebildet und wird daher auf die residente Mengengröße dieser Prozesse angerechnet.
-
Kabelgebunden – Speicher, der nicht ausgetauscht werden kann und in der Regel für Routing-Engine-Speicherstrukturen oder Speicher verwendet wird, der physisch durch einen Prozess gesperrt ist.
-
Cache: Speicher, der keinem Programm zugeordnet ist und nicht ausgetauscht werden muss, bevor er wiederverwendet werden kann.
-
Buf: Die Größe des Speicherpuffers, der zum Speichern von Daten verwendet wird, die kürzlich von der Festplatte aufgerufen wurden.
-
Frei – Speicher, der keinem Programm zugeordnet ist. Arbeitsspeicher, der von einem Prozess freigegeben wird, kann inaktiv, zwischengespeichert oder frei werden, je nachdem, welche Methode der Prozess zum Freigeben des Speichers verwendet.
Wenn das System nicht genügend Arbeitsspeicher hat, verwendet der Auslagerungsprozess den Speicher der freien, zwischengespeicherten, inaktiven und, falls erforderlich, aktiven Seiten wieder.
Das Feld "Auslagerung" zeigt den gesamten verfügbaren Auslagerungsspeicher an und wie viel davon nicht verwendet wurde. Im Beispiel zeigt die Ausgabe 512 MB Gesamtauslagerungsspeicher und 512 MB freien Auslagerungsspeicher an.
Abschließend wird die Speicherauslastung der einzelnen Prozesse aufgelistet. Das Feld SIZE gibt die Größe des virtuellen Adressraums an, und das RES-Feld gibt die Größe des Programms im physischen Speicher an, die auch als RSS oder Resident Set Size bezeichnet wird. In der Beispielausgabe verfügt der Chassisprozess (Chassisd) über 3728 KB virtuellen Adressraum und 1908 KB physischen Speicher.
Beispiel für die Konfiguration der Routing-Engine
Sie können Konfigurationsgruppen verwenden, um sicherzustellen, dass die richtigen IP-Adressen für jedes Routing-Modul verwendet werden, und um eine einzige Konfigurationsdatei für beide Routingmodule zu verwalten.
Im folgenden Beispiel werden die Konfigurationsgruppen re0 und re1 mit separaten IP-Adressen definiert. Diese bekannten Konfigurationsgruppennamen werden nur auf der entsprechenden Routing-Engine wirksam.
groups {
re0 {
system {
host-name my-re0;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.40/24;
}
}
}
}
}
re1 {
system {
host-name my-re1;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.41/24;
}
}
}
}
}
}
Sie können der Management-Ethernet-Schnittstelle (in diesem Beispiel fxp0 ) auf beiden Routing-Engines eine zusätzliche IP-Adresse zuweisen. Die zugewiesene Adresse verwendet das Schlüsselwort master-only und ist für beide Routing-Engines identisch, wodurch sichergestellt wird, dass jederzeit auf die IP-Adresse der primären Routing-Engine zugegriffen werden kann. Die Adresse ist nur auf der Management-Ethernet-Schnittstelle der primären Routing-Engine aktiv. Während eines Routing-Engine-Switchovers wird die Adresse auf die neue primäre Routing-Engine übertragen.
Auf re0 lautet die Konfiguration beispielsweise:
[edit groups re0 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.132/25;
}
}
Auf re1 sieht die Konfiguration wie folgt aus:
[edit groups re1 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.133/25;
}
}
Weitere Informationen zur Erstkonfiguration von dualen Routing-Engines finden Sie im Junos OS Software-Installations- und Upgrade-Handbuch. Weitere Informationen zum Zuweisen einer zusätzlichen IP-Adresse zur Management-Ethernet-Schnittstelle mit dem Schlüsselwort master-only auf beiden Routing-Engines finden Sie im Junos OS CLI-Benutzerhandbuch.
Kopieren einer Konfigurationsdatei von einer Routing-Engine auf die andere
Sie können entweder den Konsolenport oder den Management-Ethernet-Port verwenden, um die Verbindung zwischen den beiden Routing-Engines herzustellen. Sie können dann die Konfiguration kopieren oder FTP verwenden, um sie von der primären in die Sicherung zu übertragen, die Datei zu laden und wie gewohnt zu bestätigen.
Geben Sie den folgenden Befehl ein, um über den Management-Ethernet-Port eine Verbindung mit der anderen Routing-Engine herzustellen:
user@host> request routing-engine login (other-routing-engine | re0 | re1)
Geben Sie auf einem TX Matrix-Router den folgenden Befehl ein, um über den Ethernet-Management-Port Verbindungen mit der anderen Routing-Engine herzustellen:
user@host> request routing-engine login (backup | lcc number | master | other-routing-engine | re0 | re1)
Weitere Informationen zu diesem request routing-engine login Befehl finden Sie im CLI-Explorer.
Um eine Konfigurationsdatei von einer Routing-Engine in die andere zu kopieren, geben Sie den file copy folgenden Befehl ein:
user@host> file copy source destination
In diesem Fall source ist der Name der Konfigurationsdatei. Diese Dateien werden im Verzeichnis /config gespeichert. Die aktive Konfiguration ist /config/juniper.conf, ältere Konfigurationen befinden sich in /config/juniper.conf {1...9}. Das destination ist eine Datei auf der anderen Routing-Engine.
Im folgenden Beispiel wird eine Konfigurationsdatei von Routing-Engine 0 in Routing-Engine 1 kopiert:
user@host> file copy /config/juniper.conf re1:/var/tmp/copied-juniper.conf
Im folgenden Beispiel wird eine Konfigurationsdatei von Routing-Engine 0 auf Routing-Engine 1 auf einem TX Matrix-Router kopiert:
user@host> file copy /config/juniper.conf scc-re1:/var/tmp/copied-juniper.conf
Um die Konfigurationsdatei zu laden, geben Sie den load replace Befehl auf der [edit] Hierarchieebene ein:
user@host> load replace /var/tmp/copied-juniper.conf
Stellen Sie sicher, dass Sie alle IP-Adressen, die in der Konfiguration der Ethernet-Verwaltungsschnittstelle auf Routing-Engine 0 angegeben sind, in Adressen ändern, die für Routing-Engine 1 geeignet sind.
Laden eines Softwarepakets von der anderen Routing-Engine
Sie können ein Paket von der anderen Routing-Engine auf die lokale Routing-Engine laden, indem Sie den vorhandenen request system software add package-name Befehl verwenden:
user@host> request system software add re(0|1):/filename
Geben Sie im re-Teil der URL die Nummer der anderen Routing-Engine an. Geben Sie in dem filename Teil der URL den Pfad zum Paket an. Pakete befinden sich typischerweise im Verzeichnis /var/sw/pkg.