<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic HA upgrade oddness (no preempt) in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577568#M115893</link>
    <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;just seeing if anyone has an explanation or has experienced this before.&lt;/P&gt;
&lt;P&gt;I followed the HA firewall upgrade guide and experienced this unexpected behavior.&lt;/P&gt;
&lt;P&gt;i suspended the primary, ( secondary went active), installed the new os, and rebooted.&amp;nbsp;&lt;BR /&gt;Upon reboot, it was no longer suspended, came up and went active and caused a split brain. After it recovered, it stayed active, and secondary assumed passive.&amp;nbsp;&lt;BR /&gt;I then continued following the guide and suspended the now passive secondary, installed new os, and rebooted, and again, this one also came up active, split brain occurred, and recovered with primary staying active, and secondary assuming passive.&lt;/P&gt;
&lt;P&gt;i cannot explain this whatsoever, there is no preempt configured and the guide indicates the suspended state should have stayed upon reboot. I have done upgrades in the past and suspended survived a reboot but not this time?&lt;/P&gt;
&lt;P&gt;any one seen this before?&lt;/P&gt;</description>
    <pubDate>Sat, 17 Feb 2024 05:47:13 GMT</pubDate>
    <dc:creator>VK9H13</dc:creator>
    <dc:date>2024-02-17T05:47:13Z</dc:date>
    <item>
      <title>HA upgrade oddness (no preempt)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577568#M115893</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;just seeing if anyone has an explanation or has experienced this before.&lt;/P&gt;
&lt;P&gt;I followed the HA firewall upgrade guide and experienced this unexpected behavior.&lt;/P&gt;
&lt;P&gt;i suspended the primary, ( secondary went active), installed the new os, and rebooted.&amp;nbsp;&lt;BR /&gt;Upon reboot, it was no longer suspended, came up and went active and caused a split brain. After it recovered, it stayed active, and secondary assumed passive.&amp;nbsp;&lt;BR /&gt;I then continued following the guide and suspended the now passive secondary, installed new os, and rebooted, and again, this one also came up active, split brain occurred, and recovered with primary staying active, and secondary assuming passive.&lt;/P&gt;
&lt;P&gt;i cannot explain this whatsoever, there is no preempt configured and the guide indicates the suspended state should have stayed upon reboot. I have done upgrades in the past and suspended survived a reboot but not this time?&lt;/P&gt;
&lt;P&gt;any one seen this before?&lt;/P&gt;</description>
      <pubDate>Sat, 17 Feb 2024 05:47:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577568#M115893</guid>
      <dc:creator>VK9H13</dc:creator>
      <dc:date>2024-02-17T05:47:13Z</dc:date>
    </item>
    <item>
      <title>Re: HA upgrade oddness (no preempt)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577653#M115915</link>
      <description>&lt;P&gt;so you suspended and upgraded the primary?&amp;nbsp;&lt;/P&gt;
&lt;P&gt;it is normal to come out of the reboot unsuspended, but it's upgraded state (OS mismatch) should prevent it from becoming active as it should normally go into 'non-functional&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;unless there is an external factor like HA1 disconnect, this is your root cause&lt;/P&gt;
&lt;P&gt;why is the ha1 getting disconnected, is the ha1 link passing a firewall that could be blocking first packets?&amp;nbsp;&lt;/P&gt;
&lt;P&gt;are you using dedicated links&lt;/P&gt;
&lt;P&gt;did you enable ha1 backup/heartbeat?&lt;/P&gt;</description>
      <pubDate>Mon, 19 Feb 2024 12:07:39 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577653#M115915</guid>
      <dc:creator>reaper</dc:creator>
      <dc:date>2024-02-19T12:07:39Z</dc:date>
    </item>
    <item>
      <title>Re: HA upgrade oddness (no preempt)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577672#M115918</link>
      <description>&lt;P&gt;Yes, suspended primary (active) and it went passive, while secondary took over as active.&lt;/P&gt;
&lt;P&gt;heartbeat backup is enabled, ha1 and ha2 are dedicated links, directly connected to eachother.&amp;nbsp;&lt;BR /&gt;I looked through logs to make sure I wasn’t crazy, and sure enough, after suspending, installing, and rebooting it came up as active and secondary went to passive.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;Question on step 9 of Palo ha upgrade documentation, why is it sometimes I see “make device functional again” is not necessary? I see a lot of times it reboots and should just come up as passive, the only option under operational commands is to “suspend local device for high availability” again rather than “make local device functional for high availability”. ALOT of walk throughs I see, that are not Palo Alto documentation, this is not a required step. Even on Palo Alto’s documentation, step 8, after reboot, it shows a screenshot of the device as passive, not non functional. So step 9 is confusing.&lt;/P&gt;</description>
      <pubDate>Mon, 19 Feb 2024 15:03:58 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ha-upgrade-oddness-no-preempt/m-p/577672#M115918</guid>
      <dc:creator>VK9H13</dc:creator>
      <dc:date>2024-02-19T15:03:58Z</dc:date>
    </item>
  </channel>
</rss>

