Network Management Systems monitoring MX304 routers running Junos 24.2R1-S1 may receive spurious Power Entry Module (PEM) alarms via SNMP traps when routing engine mastership toggles between RE0 and RE1. The NMS displays alarms reporting a critical power supply state and abnormally low temperature readings (below 5°C) on both PEM 0 and PEM 1, accompanied by high CPU utilization alerts. These alarms typically clear automatically within 1 minute, are not service-affecting, and do not reflect actual hardware issues on the MX304 device.

When routing engine mastership changes occur on an MX304, the Network Management System may display the following alarms received via SNMP traps:

Resolved in 1m 0s: Juniper MX: Sensor [PEM 1]: Power supply is in critical state
Problem: Juniper MX: Sensor [PEM 0]: Temperature is too low: <5
Problem: Juniper MX: Sensor [PEM 0]: Power supply is in critical state
Problem: Juniper MX: System [Routing Engine 0]: High CPU utilization (over 90% for 5m)
Problem: Juniper MX: Sensor [PEM 1]: Temperature is too low: <5

Observable behavior:

1. NMS receives SNMP trap alarms during or immediately after routing mastership toggle
2. NMS displays both PEM 0 and PEM 1 in critical power supply state
3. NMS shows temperature sensor readings below 5°C
4. NMS reports RE0 CPU utilization spike above 90%
5. All NMS alarms auto-clear within approximately 1 minute
6. No actual service impact or traffic disruption occurs
7. Physical inspection and CLI commands on the MX304 show PEMs operating normally

To verify on MX304:

show chassis environment
show chassis alarms
show system alarms

These commands will show normal PEM operation with no corresponding alarms on the device itself.

To reproduce:

1. Monitor SNMP traps on the NMS for MX304 with dual routing engines
2. Execute "request chassis routing-engine master switch" on the MX304
3. Observe PEM alarms appearing on NMS briefly during the transition
4. Verify no alarms are present on the MX304 device using the CLI commands above

These NMS alarms are false positives caused by transient SNMP polling issues during routing engine mastership transitions. The PEM hardware is functioning correctly, and the temperature/power readings reported to the NMS are inaccurate.

Root Cause: During routing engine mastership switchover, there is a brief period where SNMP OID polling may return invalid or stale sensor data.

The NMS interprets these transient invalid readings as critical hardware failures, even though the MX304 device itself shows no alarms and the PEMs are operating normally.

Resolution:

1. Verify no actual service impact - Check that traffic is flowing normally and no customer complaints exist
2. Confirm physical PEM status on device - SSH to the MX304 and run:

show chassis environment
show chassis alarms

1. Verify actual PEM temperatures and power states are within normal operating ranges, and no alarms are present on the device
2. Review SNMP trap configuration on NMS - Consider adjusting SNMP trap thresholds, implementing alarm correlation rules, or filtering transient alarms that resolve within 1-2 minutes
3. Monitor for pattern - If NMS alarms only occur during mastership changes and auto-clear within 1-2 minutes while the device shows no issues, they can be safely ignored or suppressed