Das Problem

Im November haben wir mit einem unserer Juniper MX204-R Core-Router Probleme festgestellt. Alles begann mit einem Absturz des Systems, den wir in der Form bisher noch nicht erlebt habe. Knapp 2 Wochen später kamen dann mehrere spontane Reboots am selben Tag dazu. Die Meldungen die wir auf der Konsole gesehen haben waren etwas beunruhigend.

Nov 30 12:42:05 jlaunchd 23012 - - Registered PID 23388(replication-server-service): new process
MCAHANDLER
WaitForApCheckIn - Timeout
WaitForApCheckIn - Counter: 6
t 3: MceRestart
[...]
Booting from Flash A

FPGA Reset Reason = 0x8

Dazu kamen dann noch Speicherfehler.

{1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 {1}[Hardware Error]: It has been corrected by h/w and requires no further action
{1}[Hardware Error]: event severity: corrected
{1}[Hardware Error]: Error 0, type: corrected
{1}[Hardware Error]: section_type: memory error
{1}[Hardware Error]: error_status: 0x0000000000000400
{1}[Hardware Error]: node: 0 perf: interrupt took too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
{2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 {2}[Hardware Error]: It has been corrected by h/w and requires no further action
{2}[Hardware Error]: event severity: corrected
{2}[Hardware Error]: Error 0, type: corrected
{2}[Hardware Error]: section_type: memory error
{2}[Hardware Error]: error_status: 0x0000000000000400
{2}[Hardware Error]: node: 0 perf: interrupt took too long (3152 > 3148), lowering kernel.perf_event_max_sample_rate to 63000
{3}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 {3}[Hardware Error]: event severity: fatal
{3}[Hardware Error]: Error 0, type: fatal
{3}[Hardware Error]: section_type: memory error
{3}[Hardware Error]: error_status: 0x0000000000000400
{3}[Hardware Error]: node: 0 Kernel panic - not syncing: Fatal hardware error!

Das sah erstmal nicht so gut aus.

Austausch des Speichers

Recherchen haben ergeben, dass das Gerät zwei DIMM-Speicherriegel mit jeweils 16GB und insgesamt vier DIMM-Slots haben sollte. Schauen wir doch mal nach, was das System sagt.

chris@router> start shell
% su -
Password:
root@router:~ # vhclient -s
Last login: [...]
root@router-node:~# dmidecode -t memory | egrep -e 'Size|Part Number' | egrep -ve 'Unknown|No Module Installed'
	Size: 16384 MB
	Part Number: M4R0-AGS1BCRG-B553
	Size: 16384 MB
	Part Number: M4R0-AGS1BCRG-B553

Das sind also 16GB DDR4 RDIMMs mit 2133 MT/s. Davon hatte jemand von uns noch ein paar Module rumliegen und daraufhin haben wir mal ausprobiert, die Module auszutauschen. Bis wir am Speicher angekommen sind, waren am Chassis insgesamt 40 Schrauben zu lösen. Wir haben den alten Speicher ausgebaut und in einem anderen System einem Speichertest unterzogen. Es wurden etliche Fehler gemeldet, so dass wir mit unserer Vermutung richtig gelegen haben, dass der Speicher die Ursache für die Abstürze ist.

Speichertest mit memtest86+

Speicherupgrade?

Wo wir das Gerät schon einmal offen haben, können wir natürlich mal ausprobieren, ob ein Upgrade von 32GB auf 64GB RAM möglich ist. Gerade im Umfeld des Community-IX, wo wir sehr viele Routen von vielen Sponsoren erhalten, wäre es gut, mehr Speicher für potenzielle Routen zu haben. Also haben wir direkt mal vier Module mit jeweils 16GB eingebaut.

Blick auf das Mainboard mit den 4 RAM-Slots

Nach dem Reboot werden tatsächlich 64GB RAM erkannt

Booting from Flash A

FPGA Reset Reason = 0x83

Primary BIOS version CBEP_P_SUM1_00.15.01

Total Memory Size = 64GB

In der JunOS-VM werden allerdings weiterhin nur 24GB RAM genutzt.

chris@router> show system memory | match Total
       Total memory: 25110932 Kbytes (100%)

Das ist übrigens mehr, als man eigentlich zur Verfügung hat. Standardmäßig sind die 32GB RAM so aufgeteilt, dass der VM-Host und die JunOS-VM jeweils 16GB zur Verfügung haben. Diese Verteilung kann man jedoch anpassen, so dass der VM-Host dann nur noch 8GB und die JunOS-VM 24GB zur Verfügung hat. Dies muss jedoch als Benutzer “root” erfolgen. Ein regulärer Benutzer reicht nicht aus, selbst wenn dieser alle Rechte hat.

request vmhost exec "set_vjunos_memory high"

Nach einem Reboot stehen dann 24GB RAM in der JunOS-VM zur Verfügung. Wie können wir jetzt den zusätzlich eingebauten Speicher nutzen? Wir haben uns ein wenig auf dem VM-Host umgesehen und herausgefunden, dass /etc/vehostd/rainier-junos.xml die entscheidende Datei ist, aus der beim Systemstart das XML für die JunOS-VM erstellt wird.

chris@router> start shell
% su -
Password:
root@router:~ # vhclient -s
Last login: ...
root@router-node:~# grep -i "memory unit" /etc/vehostd/rainier-junos.xml
  <memory unit='GiB'>24</memory>
  <currentMemory unit='GiB'>24</currentMemory>

Da die Zeichenkette >24< nur in den beiden Zeilen vorkommt, können wir sie einfach ersetzen.

root@router-node:~# sed -i 's/>24</>48</' /etc/vehostd/rainier-junos.xml
root@router-node:~# grep -i "memory unit" /etc/vehostd/rainier-junos.xml
  <memory unit='GiB'>48</memory>
  <currentMemory unit='GiB'>48</currentMemory>

Nach einem Reboot stehen dann tatsächlich 48GB RAM in der JunOS-VM zur Verfügung.

chris@router> show system memory | match Total
        Total memory: 50274348 Kbytes (100%)

Ergebnis

Ob wir den zusätzlichen Speicher wirklich sinnvoll nutzen können und ob das System auch wirklich stabil mit mehr Routen läuft, bleibt noch abzuwarten. Uns ist auch bewusst, dass diese Änderung nicht updatefest ist. Jedes JunOS-Update wird die Änderung wieder überschreiben. Da sie allerdings mit einer sed-Zeile wiederhergestellt werden kann, hält sich der Aufwand in Grenzen. Allerdings muss das System dann nach dem Update zweimal neu gestartet werden. Wichtig zu wissen ist auch, dass diese Konfiguration vom Hersteller nicht unterstützt wird und wir keine Verantwortung für Schäden übernehmen, die entstehen, weil das jemand mit seiner Hardware ausprobieren möchte. Für uns war das eigentlich nur etwas Spielerei im Zusammenhang mit dem Austausch des defekten Speichers.

Der Router läuft jetzt seit einem Monat stabil mit dem neuen Speicher und der Austausch hat uns vor einer teuren Investition bewahrt.