- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-02-2016 02:30 PM - edited 11-04-2016 02:31 AM
Hi Guys,
Interesting one. Devices are in HA pair of the PA-500. Suddenly we are no longer able to access the active device through the
GUl, but able to ping mgmt interface and SSH to it. When SSHing getting the screen below:
A firewall in not producing any command output and doesn't see itself as in HA pair, no (active).
The passive device still accessible and seeing this box as active:
The clients currently connected to the box are not experiencing any system outage, so my guess active is working fine.
Another CLI output from the passive box (uptime is quite cool 713 days):
Anyone who had this before or any ideas? Thinking about to give a reboot to the box but not sure if the interfaces are in the correct state on the passive box. Why are they all down apart on the HA links?:
Thx,
Myky
11-04-2016 03:48 AM
Hi @TranceforLife,
auto — Causes the link status to reflect physical connectivity, but discards all packets received. This option allows the link state of the interface to stay up until a failover occurs, decreasing the amount of time it takes for the passive device to take over.
This option is supported in Layer 2, Layer 3, and Virtual Wire mode. The auto option is desirable, if it is feasible for your network.
shutdown — Forces the interface link to the down state. This is the default option, which ensures that loops are not created in the network.
The CLI command you mention doesn't work because it relies on the management server process to be executed.
Yes, if you still have SSH access to the device, then support can root into your device. Once rooted into the device they can restart the management server as root.
Cheers,
-Kim.
11-04-2016 03:03 AM
Hi,
Passive link state is probably configured as 'shutdown'. This forces the interface link to the down state on your passive device :
Looks like the management server might have an issue ... as long as your DP has no issues then traffic might pass the device normally.
Restarting the mgmt-server usually fixes this issue but obviously you cannot do this currently in the operational mode. You can of course reboot the device, alternatively you could reach out to support who could root your device and restart the mgmt-server process as root to try and fix it.
Cheers,
-Kim.
11-04-2016 03:30 AM
Hi Wiki,
Thanks for your feed back. Didn't know about passive link states. But what is the purpose/difference of having "auto" or "shutdown" configured?
That's an issue. I did try to use command:
> debug software restart management-server but nothing is working at the moment.
Do you think support still will be able to access box as root?
Thx,
Myky
11-04-2016 03:48 AM
Hi @TranceforLife,
auto — Causes the link status to reflect physical connectivity, but discards all packets received. This option allows the link state of the interface to stay up until a failover occurs, decreasing the amount of time it takes for the passive device to take over.
This option is supported in Layer 2, Layer 3, and Virtual Wire mode. The auto option is desirable, if it is feasible for your network.
shutdown — Forces the interface link to the down state. This is the default option, which ensures that loops are not created in the network.
The CLI command you mention doesn't work because it relies on the management server process to be executed.
Yes, if you still have SSH access to the device, then support can root into your device. Once rooted into the device they can restart the management server as root.
Cheers,
-Kim.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!