Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Leak Detection Support

Junos EVO chassis has a full liquid‑cooling capability. The Leak Detection Controller (LDC) enables coolant leakage detection through a dedicated LDC daughter board connected to the CPU board. It monitors leakage status using hardware interfaces and low‑speed signals, and provides front‑panel indication through a dedicated leakage LED on liquid‑cooled systems. The LDC software supports leak event notification via Redfish, along with firmware updates through Evo.

The key characteristics of leak detection feature includes:

  • Integrate liquid‑cooling leak detection using the LDC with Redfish APIs and schemas.

  • Support leakage monitoring during both early boot and normal runtime.

  • Enable secure LDC management and firmware updates exclusively through Evo.

LDC Software

The LDC software stack provides system management through a web UI, Redfish API, and SSH. Redfish requests are handled by redfish server, which maps operations to platform services over D‑Bus. These services manage inventory, sensors, power, logging, and firmware updates, and interact with the underlying Linux drivers and hardware. The LDC SoC controls and monitors platform components such as sensors, fans, power supplies, and CPLDs.

Bootup Sequence

When the chassis power is turned on, 48‑V power becomes available and supplies the D2D CPLD and leakage detection circuitry through hardware‑controlled regulators. A comparator continuously monitors leakage and reports status to the D2D CPLD. If a leak is detected, the CPLD updates the leakage status, turns on the red leakage LED, and halts further power sequencing, allowing the user to safely remove the hot‑swappable chassis without turning off chassis power. Leakage detection can be bypassed by pressing the power button for three seconds.

During power‑on, the LDC boots through U‑Boot, loads the Linux kernel, and transitions control to systemd, which initializes services responsible for chassis power‑on and host startup.

LDC Software Stack

  • Secure Access: SSH security with key‑based authentication, firewall protection, and disabled root login
  • Authentication: Account lockout and strong, NIST‑compliant password policy
  • Network Hardening: Continuous monitoring with auto‑recovery of network settings
  • Firmware Resiliency: Dual‑flash with automatic fallback to golden firmware
  • Service Hardening: Disabled nonessential and debug services
  • Redfish Security: TLS‑only communication with mutual certificate authentication
  • Build Security: Compiler hardening enabled for improved protection

Supported Daemons

Following are the supported daemons and their usage:

Table 1: Daemons
Daemon Role & Purpose Importance
systemd Init system and service manager; supervises all LDC processes and dependencies Backbone of service management
systemd-journald Logs system and application events, aiding debugging Essential for event tracing
D-Bus IPC message bus facilitating communication between services Fundamental for API and events
Redfish server RESTful API/web server for Redfish Primary remote user interface

LeakDetection Schema

The LeakDetection schema describes leak detection devices and leak reporting.

  • Resources: Defines resources for leak detection equipment and leak reporting, and enables discovery of detection capabilities to validate customer requirements.

  • Detector Groups:

    • DetectorGroups support multiple detection zones. Each DetectorGroup represents a single detection zone.
    • Each zone consists of one or more LeakDetector instances
    • A zone may also include an optional humidity sensor
    • The criteria for reporting a leak are implementation-defined
    • Leak detection policies are based on manufacturer or configuration settings and are not user-defined
  • Status Object: Status object provides means to report leaks. It defines messages for reporting leaks as Conditions.

Troubleshooting Tools

  • Phosphor Debug Collector: The LDC component collects system logs and status information into diagnostic dumps for troubleshooting. Dumps are managed by system services and can be accessed through D‑Bus interfaces, Redfish APIs, or CLI tools.
  • systemd journalctl: Provides filtered access to system and kernel logs to support debugging and log analysis.

Resiliency

Service Monitoring and Automatic Restart: The LDC software uses the systemd daemon, to manage system services, providing built‑in monitoring and automatic restart on service failures. By default, a crashed service is restarted up to two times within 30 seconds to help minimize downtime.