Users may see the Next-Generation Routing Engine (NGRE) alarm "Note: Please check compute node with network boot interface MAC address aa:bb:cc:dd:ee:ff for connectivity and DHCP configuration" when they perform a check on vmhost status by using the show vmhost status command. They may also be unable to log in to the vmhost vhclient shell.
show vmhost status
The alarm may be seen after a series of Junos OS upgrade procedures are processed on the vmhost-based Routing Engine as per PR1368059 .
This article explains what must be done to work around the issue.
The following alarm is observed when checking vmhost status.
{master:member0-re1} labroot@router-re1> show vmhost status invoke-on all-routing-engines Mar 11 11:04:08 member0-re0: -------------------------------------------------------------------------- Compute cluster: rainier-re-cc Compute Node: rainier-re-cn, Online member0-re1: Juniper Business Use Only -------------------------------------------------------------------------- Compute cluster: rainier-re-cc Compute Node: rainier-re-cn, Online member1-re0: -------------------------------------------------------------------------- Compute cluster: rainier-re-cc Compute Node: rainier-re-cn, Online member1-re1: -------------------------------------------------------------------------- Compute cluster: rainier-re-cc Compute Node: rainier-re-cn, Offline <<<<<vmhost is offline. </span> Note: Please check compute node with network boot interface MAC address aa:bb:cc:dd:ee:ff for connectivity and DHCP configuration <<<<
Further, a disk alarm similar to the following is also reported:
2021-03-11 10:41:34 SGT Minor VMHost RE 1 Disk 1 Usage is above threshold 2021-03-10 16:49:45 SGT Minor VMHost RE 1 Disk 2 File System Errors 2021-03-10 16:49:45 SGT Minor VMHost RE 1 Disk 1 File System Errors
When users encounter the file leak problem on a vmhost-based RE as described in PR1368059 , the NG-RE must be rebooted first before implementing the workaround for the file leak issue.
Because vmhost is offline as shown in the above output, you cannot log in to the vmhost shell ( vhclient -s ). You need to reboot vmhost first, and then fix the file leak after vmhost reboots.
vhclient -s
Perform the following steps:
Reboot the NG-RE vmhost.
Note: Use request vmhost reboot via the console or re-seat the NG-RE physically.
request vmhost reboot
Check and implement the workaround for the file leak issue.
Note: The following steps require root privilege as you need to log in using Junos/FreeBSD Unix shell mode.
>start shell user root
Check whether the vmhost has user " postfix ."
postfix
root@re0:/root # vhclient "grep postfix /etc/passwd" postfix:x:101:998::/var/spool/postfix:/bin/false
If no postfix user is found, the Routing Engine is not affected by this software issue. If you still see vmhost offline and encounter the alarm "Note: Please check compute node with network boot interface MAC address aa:bb:cc:dd:ee:ff for connectivity and DHCP configuration," contact Support for troubleshooting further. If the vmhost has the postfix user, proceed with the following steps:
If no postfix user is found, the Routing Engine is not affected by this software issue. If you still see vmhost offline and encounter the alarm "Note: Please check compute node with network boot interface MAC address aa:bb:cc:dd:ee:ff for connectivity and DHCP configuration," contact Support for troubleshooting further.
If the vmhost has the postfix user, proceed with the following steps:
Check whether the daemon postfix is running under vmhost.
root@re0:/root # vhclient "service postfix status"
Based on the command output, various actions are required:
The postfix mail system is not running.
If the daemon postfix is NOT running and vmhost has user postfix , the system is affected by this software issue.
If you see "postfix: unrecognized service":
The daemon postfix is not installed. The system is NOT affected by this software issue. No action is required.
Execute the following command to remove the postfix user account under vmhost to stop the system file leak issue. This command does not introduce any system impact.
root@re0:/root # vhclient "userdel postfix" userdel: group postfix is the primary group of another user and is not removed. < Ignore this message.
Use the following command to verify if the user account postfix is removed properly. The command should return an empty output.
root@re0:/root # vhclient "grep postfix /etc/passwd"
Delete the following files under /var/spool/postfix/maildrop/ to clean up the system. It is recommended to perform this during a Maintenance Window because system performance might be affected during the operation. It would be safer to take a backup of the Routing Engine before deleting the files.
/var/spool/postfix/maildrop/
root@re0:/root # vhclient "find /var/spool/postfix/maildrop/ -name '*' -print|xargs rm" rm: cannot remove '/var/spool/postfix/maildrop/': Is a directory rm: cannot remove '/var/spool/postfix/maildrop/B97561E811': No such file or directory rm: cannot remove '/var/spool/postfix/maildrop/A19EC1E7EB': No such file or directory rm: cannot remove '/var/spool/postfix/maildrop/996E71E7DC': No such file or directory rm: cannot remove '/var/spool/postfix/maildrop/B1D4D1E803': No such file or directory rm: cannot remove '/var/spool/postfix/maildrop/B6B4B1E80A': No such file or directory rm: cannot remove '/var/spool/postfix/maildrop/A3BD71E7F0': No such file or directory
Note: Ignore the "No such file or directory" return messages.