An administrator is seeing one of the firewalls in a HA active/passive pair moved to "suspended" state due to Non-functional loop.
Which three actions will help the administrator resolve this issue? (Choose three.)
An administrator is seeing one of the firewalls in a HA active/passive pair moved to "suspended" state due to Non-functional loop.
Which three actions will help the administrator resolve this issue? (Choose three.)
To resolve an HA active/passive pair moved to a 'suspended' state due to a non-functional loop, check the HA link monitoring interface cables to ensure they are connected properly, as faults in the cables can cause the suspension. Check the High Availability link and path monitoring settings, which are responsible for monitoring the status and ensuring there are no issues. Lastly, use the CLI command 'show high-availability flap-statistics' to identify if the firewalls have switched roles frequently, which can help diagnose the root cause of the non-functional loop.
Guys, I've checked all the answers. If we see quickly, we identify 4 coorect answers: ABCE. If we pay more attention, we'll fond that B is false. In fact, the link High Availability > Active/Passive Settings > Passive Link State doesn't exist on PAN. The correct link is High Availability > General > Active/Passive Settings > Passive Link State "B" is the trap on this question.
High Availability > Active/Passive Settings > Passive Link State does exist. Technically its Device > High Availability > Active/Passive Settings > Passive Link State. Device is left off all these answers so I imagine it's supposed to be assumed.
It´s right that High Availability > Active/Passive Settings > Passive Link State does exist. The correct path is Device > High Availability > GENERAL> Active/Passive Settings > Passive Link State. So B is wrong.
ACE, based on shared KBs from other members here a-. Check the HA Link Monitoring interface cables c-. Check the High Availability > Link and Path Monitoring setting e-. As per KB, it mention flaps, Command found is correct (Not in KB) show high-availability flap-statistics b- not correct, this is correct path: Device> High Availability> General> Active/Passive Settings> Passive Link State> >> Flood Protection / SYN-Actions d- N/A for active/active FWs setup - Device > High Availability > Active/Active Config
B: just set Passive node data link with "Shutdown" or "Auto" D: only for A/A (HA3) configure NOTE: E: Is a real command content...
ACE is correct. Please refer to the link below: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgVCAS
It's BCE. A - NO. There is no such thing as "HA Link monitoring cables". These are data interfaces we are talking about. B - YES. If passive link state is "shutdown" then it brings link down when the firewall becomes passive, which makes the path monitoring fail because the link is down. That is one reason why it's better to set the passive link state to "auto" instead of "shutdown". C - YES. Link and path monitoring settings are where you tell the fw to monitor the ink state of the port, and also specify a destination IP to ping. D - NO. These settings would be for an active/active config, to use HA3. E - YES. This command shows you how many times the fw has flapped. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgVCAS
This is the right answer. A bunch of people here confusing link (data interface) monitoring with HA interfaces :/
I'm going with ABC. A and C are explicitly mentioned in the link below: https://knowledgebase.paloaltonetworks.com/articles/en_US/Knowledge/HA-Link-Monitoring-Interface-T-60615 D doesnt apply to this. As for B, If the passive link state is set to shutdown, I can imagine the link would be down and so the link and path monitoring would fail, thus causing this issue. This is mentioned as a cause of a preemption loop, which is slightly different (https://knowledgebase.paloaltonetworks.com/articles/en_US/Knowledge/When-does-an-HA-node-go-into-S-67706). This is not mentioned as a cause of our issue, though. E would help identify that flapping has occurred, but it wont help with recovery. Also, it's already obvious that it's occurring because the HA pair is saying it's in a suspended state due to Non-functional loop.
Correction: it's ACE. This issue is caused by Link and Path Monitoring settings monitoring interfaces that are down, which only happens on the active unit. Active comes up, links are down, it moves to passive... new active comes up, links are also down for that unit, it moves to passive. Eventually this flapping triggers a suspended state. B wouldnt apply here because only the active unit does Link and Path Monitoring. So ACE.
E is not correct, the command is incorrect: the command will be: show high-availability cluster flap-statistics https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-cli-quick-start/cli-cheat-sheets/cli-cheat-sheet-ha
You're wrong. I just typed it on my PAN, and it worked. admin@palo-1> show high-availability flap-statistics HA not enabled
Yes it's a real command. Here it is on my lab fw, with HA enabled: PA820-1(active)> show high-availability flap-statistics Group 1: myFW-HA Mode: Active-Passive Flap Statistics: Preemptions since flap counter reset : 0 Non-functional states since flap counter reset : 0 Maximum flaps allowed before suspending device : 3
Agree, it is a real command, and it's used to determine if the active unit is flapping between active/passive multiple times (configurable )within a 15 min period. I could see how it would apply here. Not sure if it's the answer tho.
If we consider "General" to be a mistake in the question then answer is A,C,E High Availability > Active/Passive Settings > Passive Link State doesn't exist on PAN.
BCE https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgVCAS
"A is explicitly mentioned in these links" Except is not. "Monitored links" refer to interface monitoring that is used as a condition for failover, not the actual HA interfaces you're using to form you HA A/P cluster. HA interfaces being disconnected will give you other errors. Besides, there's no such thing as "HA link monitoring cables". Since the non-func loop happens when the monitored interface is disconnected on the passive fw, B and C will help you troubleshoot and solve. E will too since it will help you determine if flapping happened.
It is kind of ambiguous, but I think C would not help diagnose the issue, it may be something you could use to solve it after you know what the problem was, but to know that your first need to (E) to confirm that the non-functional loop was triggered due to max flaps, then (B) to confirm that the cause was that the passive link state was set to shutdown and then (A) to check if the cables were connected correctly, which most likely they were not. Only then you may (C) to disable the link and path monitoring if you intentionally needed to disconnect the cables and only re-enable it once you are done with those L1 changes. Otherwise, when you perform (c) you just connect the cables correctly and you have solved the issue. Finally, you manually startup the HA again on the Firewall. Maybe it could be argued that the answer is ABC and you don't even need to do E because you pretty much already know what the problem was when you see the "suspended (Non-functional loop)" next to your Active FW in the HA widget, but oh well, one more ambiguous question for the choose-at-random list.
I think correct option is ACE
Check the HA Link Monitoring interface cables. This is because the interface cables may be loose or disconnected, causing a non-functional loop1. Check High Availability > Active/Passive Settings > Passive Link State. This is because the passive link state may be incorrect or inconsistent, causing a non-functional loop1. Use the CLI command show high-availability flap-statistics. This is because this command can display information about the interface and path monitoring flaps, which may indicate a non-functional loop1.
ABC See sov4
A, B, and C are the correct answers as per the following KB - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgVCAS
It must be ABC.
mohr22 said it