Management Articles

Featured Article
Path monitoring enables the firewall to monitor specified destination IP addresses by sending ICMP ping messages to make sure that they are responsive. Use path monitoring for virtual wire, Layer 2, or Layer 3 configurations where monitoring of other network devices is required for failover and link monitoring alone is not sufficient.   Which source IP address to use For virtual wire and VLAN interfaces, enter the source IP address used in the probe packets sent to the next-hop router (Destination IP address). The local router must be able to route the address to the firewall. The source IP address for path groups associated with virtual routers will be automatically configured as the interface IP address that is indicated in the route table as the egress interface for the specified destination IP address.   This example explains how path monitoring works using a specific Vwire configuration.   Setup LAN Network -- Router A -- PANW Firewall (Vwire) -- Router B IP Router A: 1.1.1.254 IP Router B: 1.1.1.1   Device > High Availability > Link and Path Monitoring - HA Path Group Virtual Wire: This is the only place where you need to configure the source IP address.   Go to Device > High Availability > Link and Path Monitoring:   When you commit the configuration, you'll notice the following traffic on your network:   ARP Broadcast sourced from firewall to request the mac address for 1.1.1.1 :    Here is the ARP reply from destination ip 1.1.1.1:  Now the Path Monitoring can start:   Go to the CLI and verify the path monitoring is working fine: (active)> show high-availability path-monitoring   -------------------------------------------------------------------------------- total paths monitored :                         1 hold time to send probe packets :               1000 ms   (after device becomes active) -------------------------------------------------------------------------------- name/type                 destination     suc/total rtt min/max/avg (ms) probe cnt/interval(ms) -------------------------------------------------------------------------------- replay/virtual-wire       1.1.1.1         10/10     0.10/0.11/0.11      10/200     --------------------------------------------------------------------------------   Note: The ARP packet is sent from the vwire interfaces ,the ARP packet sent out will have a unique MAC not attached to any interface.
View full article
rvanderveken ‎07-13-2018 12:02 AM
5,948 Views
0 Replies
2 Likes
As shown in the following screenshot, the ethernet protocol type is:0x7261        owner: rvanderveken
View full article
rvanderveken ‎05-28-2018 04:35 AM
5,766 Views
0 Replies
Connecting HA1 and HA2 – A/P   Use dedicated HA interfaces on the platforms. If the firewalls are in the same site/location. Connect HA1 and HA2 links back to back. This helps in convergence. Always connect backup links for HA1 and HA2 HA1 interface should be faster than HA2. Recommend HA Heartbeat backup.     Configuring HA settings - Passive Link Settings   Set the Passive link state to "Auto". Auto setting will bring the interfaces on the passive firewall to UP physical state, the interface will not pass any data traffic.  This facilitates faster failover times.     HA timers   It is recommended to start with “Recommended” HA timers setting. If needed go with “Aggressive” setting.     HA to act on Network Failures – Link and Path Monitoring   Have both link and path monitoring enabled. Link Monitoring – Monitor all important links for which you need a failover to happen when the link goes down.. Path Monitoring - Monitor more than one path (prefix). Just do not depend on one path.   Networking– Best Practices   Graceful Restart (GR) is enabled by default on BGP and OSPF. GR functionality should be enabled on the neighboring routers as well for it to work. GR helps maintain the forwarding tables during switchover and does not flush them out. This is a way faster mechanism than depending on the routing protocol to converge. If Aggregate Ethernet interfaces (Port Channels) with LACP are used then enable LACP pre-negotiation feature to speed up convergence + passive link state to auto. The LACP pre-negotiation feature helps by sending LACP messages out on the passive FW port channel and bring the AE link up beforehand to help in fast failover.  
View full article
vbalasubra ‎02-08-2018 01:33 AM
4,682 Views
0 Replies
Overview In a High Availability configuration the data interfaces of the passive device can be configured to either be down or up. This "Passive Link State" setting can be found under Device > High Availability > Active/Passive Settings: Active/Passive Link State   Shutdown mode In a High Availability configuration the data interfaces of the passive device will be physically down by default. This mode is called shutdown in the Passive Link State field. Here is a sample of interface output.  The right side is the Active device and the left is Passive. Passive device interface state is down. Passive Link State Shutdown   Auto mode This makes the physical interfaces be 'up' on a passive device, but discards any packets which are received. This option allows  faster failovers  on Layer3 interfaces but could have unwanted side effects on Layer2 interfaces, as some switches may try to send packets over the 'up' interfaces. In the below image, the difference of the passive link state which is UP when the option is set as auto as compared to the shutdown as shown above. Passive Link State Auto   Note: The IP and Mac addresses in the first image are highlighted to show that the L3 interfaces will have same virtual mac and ip addresses on both the Active and Passive devices of HA pair.    
View full article
Phoenix ‎11-21-2017 06:32 AM
20,943 Views
6 Replies
2 Likes
Issue When changing the group ID of a HA configuration from a Panorama template, the following commit error occurs: Mar 12 13:12:19 Error: pan_schema_verify_attribute(pan_schema_types.c:778):attr name failed to verify Mar 12 13:12:19 Error: pan_schema_verify_attr(pan_schema_obj.c:3488): attribute name breaks schema at line 341 Mar 12 13:12:19 Error: pan_cfg_verify_ex(pan_cfg_commit_handler.c:999): invalid confgiuration. Schema verification failed. Mar 12 13:12:19 <line><![CDATA[deviceconfig -> high-availability -> group -> 10 Constraints failed  : Only one HA Group ID allowed Mar 12 13:12:19 Error: pan_jobmgr_process_job(pan_job_mgr.c:2914): error verifying commit candidate Mar 12 13:12:22 Error: pan_cfg_md5sum_by_file(pan_cfg_utils.c:4998): file/opt/pancfg/mgmt/sp/vsys1/pretrans-sp-config.xml doesn't exist Mar 12 13:12:22 Error:pan_cfg_sp_get_shared_policy_info(pan_cfg_shared_policy.c:1606): failed to get md5sum for file /opt/pancfg/mgmt/sp/vsys1/pretrans-sp-config.xml   Resolution :   Steps to be followed on the Managed Firewall :   Log in to the device. Go to Device > Setup > Management. In the Panorama Settings widget, click on "Disable Network Template". In the popup, leave the checkbox blank (so as not to copy the template contents to the local space). Return to the same page and click on “Enable Network Template”. Note: The purpose of steps 1 and 2 are to temporarily free the template contents pushed from Panorama. Go to the High Availability (HA) setup page and set the group id to the desired new value (for example, 10). Note: Each HA group should have its own template so the HA group value is pushed to only that HA pair.   Steps to be followed on the Panorama :     Change the template to have the new group ID and push it again to this device. This causes other template configurations to be recreated on the device. Step 1 caused the template objects to be lost. Make sure that the “Merge with candidate config” is checked, and perform a push just to this device. Now this device has group id 10 and also all the template objects are restored.   owner: kadak
View full article
kadak ‎11-15-2017 12:32 PM
3,590 Views
0 Replies
1 Like
This article is outdated, for updated information please refer to:  Best Practices for PAN-OS Upgrade    
View full article
djipp ‎07-27-2017 02:20 PM
239,313 Views
27 Replies
6 Likes
Question Are there any special considerations when importing the firewall configurations from an HA pair into Panorama? Answer Yes, there are many considerations  that you need to be aware of.   By default, Panorama will create a new device group and a new template when the first firewall's configuration is imported. When importing the second firewall's configuration, it too will require its own template, but it can be associated with the same device group as the first firewall.   SPECIAL NOTE The High-Availability configuration is part of the template and if both firewalls are associated with the same template, then they will both have the same HA configuration and in turn both members will try to become active when turned on. Be sure to double check the templates to avoid this happening.   For guidance on how to import a firewall's configuration into Panorama, please reference:  How to Perform a Device Config Import into Panorama
View full article
jjosephs ‎03-07-2017 09:33 AM
6,467 Views
7 Replies
Question When replacing a PA-7000 SMC, why does the session distribution policy need to be reconfigured after the new SMC is brought online? Answer When replacing a failed SMC, the replacement SMC will have the default session distribution policy setting of ingress-slot. If the session distribution-policy is currently set to another setting, you will need to reconfigure the session distribution setting after the replacement SMC is online, if HA config sync is enabled.   This is due to the replacement SMC's config having a later timestamp than the active PA-7000 config, so the default session distribution setting of ingress-slot from the new SMC will get synced across to the active device.   To prevent this from happening, after getting the replacement SMC online, you can reconfigure the session distribution policy to another setting.   admin@7050> set session distribution-policy > fixed          select a fixed DP > hash           select DP by address hash > ingress-slot   select DP on ingressing slot > random         select random available DP > round-robin    select DP by round robin between active DPs > session-load   select DP based on session load
View full article
pmak ‎11-09-2016 12:40 PM
2,197 Views
0 Replies
Issue The passive unit in an HA pair cannot sync to the active device because it does not have a certificate. When trying to sync the certificate to the passive unit it fails. When trying to add the certificate to the passive unit and perform the sync-to- peer from the active unit, the sync fails and the passive unit deletes the newly installed certificate.   Resolution Import the missing certificate into the passive unit. If the same certificate is used for options like "Forward Trust, Forward Untrust and etc" on the active firewall, make sure that the same Certificate on the passive device must be selected with same options as shown below. Shown below is the Active Device:   Shown below is the Passive Device:   Commit Perform a commit sync from passive to primary by using the following CLI command: > request high-availability sync-to-remote running-config   See Also High Availability Synchronization   owner: nayubi
View full article
panagent ‎11-09-2016 11:05 AM
11,801 Views
2 Replies
Question: Can you have High availability (HA) Between Two(2) Different Firewall Platforms?   Answer: Palo Alto Networks devices only support high-availability between 2 identical devices. If ha1 is connected between two different platforms, both nodes will go into a suspend state. The only way to recover from this situation is to disconnect the ha1 interface and reboot the device.   Prerequisites for HA setup: To set up high availability on your Palo Alto Networks firewalls, you need a pair of firewalls that meet the following requirements:   The same model—both the devices in the pair must be of the same hardware model or virtual machine model. The same PAN-OS version—both the devices should be running the same PAN-OS version and must each be up-to-date on the application, URL, and threat databases. They must also both have the same multiple virtual systems capability (single or multi vsys). The same type of interfaces—dedicated HA links, or a combination of the management port and in-band ports that are set to interface type HA. – Determine the IP address for the HA1 (control) connection between the device pair. The HA1 IP address for both peers must be on the same subnet if they are directly connected or are connected to the same switch. For devices without dedicated HA ports, you can use the management port for the control connection. Using the management port provides a direct communication link between the management planes on both devices. However, because the management ports will not be directly cabled between the devices, make sure that you have a route that connects these two interfaces across your network. – If you use Layer 3 as the transport method for the HA2 (data) connection, determine the IP address for the HA2 link. Use Layer 3 only if the HA2 connection must communicate over a routed network. The IP subnet for the HA2 links must not overlap with that of the HA1 links or with any other subnet assigned to the data ports on the firewall. The same set of licenses—Licenses are unique to each device and cannot be shared between the devices. Therefore, you must license both devices identically. If both devices do not have an identical set of licenses, they cannot synchronize configuration information and maintain parity for a seamless failover. The above text was taken from the PAN-OS Administrator's Guide 6.1 (English)     Page No 148   If you happen to connect 2 different models in the same HA Pair, you will see the following syslog message: HA Group 1: Peer device platform model not matching; going to Suspended state.t   See Also For more information on High Availability Resources, please see this doc: High availability resources   owner: rvanderveken
View full article
rvanderveken ‎10-05-2016 11:49 AM
6,306 Views
3 Replies
Overview This document describes how to migrate the URL database from BrightCloud to PAN-DB on a High Availability (HA) pair of Palo Alto Networks devices.   Steps Suspend the Passive/Secondary device. Go to Device > High Availability > Operational commands  and suspend local device          Or from the CLI, execute the command below:         > request high-availability state suspend Run the following command on the Passive/Suspended device, if not already set: > set session tcp-reject-non-syn no Retrieve PAN-DB URL licenses from Device > Licenses tab. Activate the PAN-DB license on the suspended device (or Activate the Database from Device > License tab): > set system setting url-database paloaltonetworks Once activated, make the secondary device functional with the command below. However, this device will come up as "Non-functional" due to DB mismatch with the peer: > request high-availability state functional Note: When the device is showing as "Non-functional" after issuing the command above, all the interface will still be power down except for HA interface and that is expected. Suspend the Active/Primary device, this will make the secondary device functional. Note: While the device is in non-functional state, the sessions will not be synced. Since non-syn TCP is allowed, most of the existing TCP traffic will not be dropped Download and activate the PAN-DB license on this device (Steps 3 and 4) . Both devices are now using PAN-DB, once both devices are functional failover back to the original Primary/Active device. Revert back to original settings on secondary device:    > set session tcp-reject-non-syn yes   owner: kalavi
View full article
kalavi ‎09-14-2016 04:12 AM
35,965 Views
10 Replies
3 Likes
Details This document describes how to reboot firewalls while in High Availability Active/Passive configuration.   Steps Verify which unit is currently active and which one is currently passive by using the following CLI command, > show high-availability state or check the WebGUI, Dashboard > High Availability section: Active member Passive member Next, start with rebooting the passive device with the CLI command: > request restart system After a couple of minutes, please verify that the passive member has fully rebooted and is in a passive state with the above commands or WebGUI. Once the passive member has been rebooted and you have confirmed its functionality, proceed to manually trigger a failover on the current active member with the CLI command: > request high-availability state suspend Or from the WebGUI > Device > High Availability > Operational Commands - click Suspend local device Suspend local device option in the WebGUI. Verify that the firewall is now in a suspended state before a reboot and the passive member assume the active position. Run the following CLI command on both firewalls: > show high-availability state or check the WebGUI, illustrated below.  HA status showing Suspended (User requested) At the bottom of the WebGUI, it also will show the current status: When the second device has been rebooted, proceed to place it back into a functional state using the following CLI command: > request high-availability state functional Or inside of the WebGUI > Device > High Availability > Operational Commands - click on Make local device functional Option to make device functional in the WebGUI. Both devices have now been rebooted and failover functionality has been confirmed.   Note: If the preemptive option is selected, the device with the higher priority (lower number value 0-255) will take over as active and potentially cause an unwanted failover. Please be prepared for this to happen, unless you disable and commit the preemptive option on both firewall members.  You can start by rebooting either firewall, but keep this note in mind. The passive member is not currently passing any traffic; therefore, it may be more convenient to reboot this first.   The option is located under Device > High Availability >  General > Election Settings as seen below.          
View full article
mmmccorkle ‎09-09-2016 11:09 AM
14,545 Views
0 Replies
1 Like
Overview Even when both the nodes in an HA pair are configured to fetch dynamic updates (threat or antivirus updates) at the same time, the firewall generates a version mismatch alert in the system logs. If email alerts are configured on the firewall, the system admin receives these alerts. This article focuses on explaining the behavior of such alerts in the firewall. Details Even though both members of the firewall have the same update schedule, there would be a brief period of time when both members would have a different version of dynamic updates. During this difference, HA checks generate a system log, mentioning a mismatch in the dynamic updates version. Prior to PAN-OS 7.1, these mismatch alerts were generated with HIGH severity in system logs as follows: 2016/08/02 10:18:05 high ha HA Group 2: Threat Content version does not match 2016/08/02 10:18:05 high ha HA Group 2: Application Content version does not match Now, if the email alerts are configured to send HIGH alerts to the system admin, they would receive a version mismatch alert on the firewalls. However, it is possible that by the time they check on the firewall, there is no version mismatch on the firewall. The reason is, as soon as the version matches on the firewall after that brief period of difference, the firewall generates these alerts with INFO severity as follows: 2016/08/03 10:18:27 info ha HA Group 2: Threat Content version now matches 2016/08/03 10:18:27 info ha HA Group 2: Application Content version now matches Since email alerts were set for only HIGH severity, the system admin does not receive these alerts.     Starting from PAN-OS 7.1, there is a behavior change in how these alerts are generated.   The first time the HA check detects a mismatch in the dynamic update version on both firewalls, these alerts are generated with 'informational' severity:       If this mismatch persists for longer than one hour, the HA check will generate alerts with 'high' severity:         Therefore, if email alerts are configured to send 'high' severity alerts, the system admin gets an alarm only when there is a genuine mismatch and not when there is a mismatch for just a brief period of time.      
View full article
hagarwal ‎09-07-2016 01:14 AM
5,627 Views
0 Replies
1 Like
Question   Why doesn't the HA1 or HA-1 port light up after connecting to an RJ-45 cable that is connected to a firewall or switch? Answer Firewall chassis have dedicated ports for HA1 and HA2. HA1 is used for syncing the configuration and HA2 is used for syncing active sessions.   Unlike the HA2 port, when the firewall isn't part of a cluster, the HA1 port won't light up even when it's connected to another firewall, switch or even a laptop. Setting the link speed or duplex will not change it either.   However, once the firewall becomes part of an HA cluster, even if 'Enable Config Sync' isn't checked, the HA1 physical port light will start glowing.      If HA is disabled on one firewall and enabled on another, HA1 ports on both firewalls will still not light up.   To cause the HA1 physical port to light up, you need to enable HA on both firewalls and make sure that they are both part of the HA cluster.
View full article
shganesh ‎02-09-2016 02:07 PM
3,266 Views
0 Replies
Issue The system logs on the Active device of an HA cluster show the following alert message: "HA queue is full".   Cause In a High Availability (HA) configuration, the Active device keep synchronizing the runtime state of its Management Plane (MP) processes with the passive peer device (using HA1). Sometimes, a process on passive device may experience some lag and not able to process information sent by active device fast enough. In this case, the transmit buffer queue on active device will then become full and the "HA queue if full" alert is raised.   Resolution 1.  Identify the laggy process. In the example below, the userid process is identified: domain: seqno: actionflags: 0x0 type: SYSTEM subtype: userid config_ver: 0 time_generated: vsys: eventid: HA-queue-full object: fmt: 0 id: 0 module: general severity: high opaque: HA queue is full   2.  Connect to the CLI on the passive device and restart the impacted service. For example: > debug software restart user-id   owner: nbilly
View full article
nbilly ‎01-15-2016 05:34 AM
3,005 Views
1 Reply
1 Like
Symptom HA-Sync job on HA peer fails, details on the job id reveal an error similar to the one below:   Inside of the CLI: admin@firewall(passive)> show jobs id <job id>   Enqueued ID Type Status Result Completed -------------------------------------------------------------------------- 2015/06/06 19:09:47 9 HA-Sync FIN FAIL 19:09:52   Warnings: Details:ssl vpn cert file (GlobalProtect) processing failed (Module: rasmgr) global-protect-gateway tunnel interface (tunnel.1) in vsys (vsys1) parsing failed (Module: rasmgr) Commit failed   Cause In this example, the GlobalProtect certificate is selected to also be the WebGUI certificate.   To verify this, go inside of the WebGUI, Device > Certificate Management > Certificates and click on the certificate name (GlobalProtect in this example), and you will see that "Certificate for Secure Web GUI" is selected.   Solution To resolve this error, remove the check for "Certificate for Secure Web GUI"  from the GlobalProtect Certificate, then Commit the changes. The HA will now Sync properly.     If you need to use a SSL certificate for the WebGUI(Secure Web GUI), you will need to create and use a separate certificate for the WebGUI.   owner: mivaldi  
View full article
mivaldi ‎12-31-2015 07:28 AM
3,881 Views
1 Reply
   Problem :   An HA node moves into the "Suspended" state due to Preemption loop.   A node can move into suspended state due to preemption loop in a setup comprising of the following:   The individual nodes are configured with a priority value and pre-emption to advocate prioritisation of an individual node. Link monitoring OR path monitoring is configured on individual nodes.   Suspended (Preemption loop detected)    Cause :   The following sequence of events can cause the failure :   When a link or path monitoring (or both) failure condition is detected by the HA daemon on the Active device, it moves in non-functional state. When the monitoring state is restored, the non-functional nodes moves into passive state. Since preemption is enabled in the setup, the passive device, which has a higher priority and a lower value, moves into the active state. If further instances of failure conditions are encountered, such as link OR path monitoring, the active node will keep changing its state from Active > Non-functional > Passive > Active. The node moves into "Suspend" state due to preemption loop if "Maximum number of flaps" are observed.   A flap is counted when the firewall leaves the active state within 15 minutes after it last left the active state. This value indicates the maximum number of flaps that are permitted before the firewall is suspended and the passive firewall takes over (range 0-16, default 3).   *Maximum number of flaps can be configured as follows:           Solution :   A node in suspended state can only be made functional (Active or Passive) manually. Before making the node functional, consider the following recommendations :   Investigate and the fix the issue of the interface and/or path monitoring flaps. If the node is made functional in an unstable environment, it will likely move into a suspended state again.   Remove the preempt option from the nodes until the monitoring status is stable. This will help the healthy node retain the Active state, while the node encountering flaps will remain in the non-functional/passive state for investigation. It is advised have to "Passive link state" setting to "Auto" since w hen the active device goes to non-functional state and link-state is shutdown, all the interfaces will be in shut down state.The node will not know the status of the interface before it goes in active state.Hence after state changes to passive and subsequently active (due to pre-empt), all the interfaces come up except the interface which is still physically down. This causes monitoring to fail again and may cause pre-emption loop (as per the flap max setting explained above)   If preempt is enabled it is recommended to also set the "Passive Link State" setting to "Auto" to prevent the above scenario from occurring. This will keep the interfaces in an electrically 'up' state that allows the system to detect if an interface is physically down before allowing preempt to re-activate the device:       You can make the node functional using either the CLI or GUI.   Use this command on the CLI: > request high-availability state functional In the GUI, navigate to Device > High Availability > Operational Commands > Make local device functional.       After following the above steps, the affected node moves into  "Passive" state and eventually to the "Active" state due to preemption and its high priority.
View full article
syadav ‎12-08-2015 05:00 AM
28,169 Views
0 Replies
3 Likes
In an HA active passive environment, when the passive link state is set to auto, the SFP ports' link LEDs do not glow when a cable is plugged into them. The SFP link LED only glows for the device that is active.   The 10.66.18.56 and 10.66.18.57 are devices in an HA active passive setup and the passive link state is set to auto. The SFP modules are plugged into ethernet1/22 on each device.   This is what you see in the GUI when the 10.66.18.56 device is active and 10.66.18.57 is passive:         This is what you see in the GUI when the 10.66.18.57 device is active and 10.66.18.56 is passive:      This is expected behavior. The SFP ports in the HA environment do not behave the same way as the RJ-45 ports.  
View full article
achalla ‎11-30-2015 05:13 PM
4,764 Views
2 Replies
When performing a major or minor software upgrade of the HA pair, we expect to see a configuration mismatch after upgrading only one device in the pair. The mismatch is shown in the High Availability widget. The message that the running config is not synchronized is caused by the possible different layout of the XML configuration file in the new version.   The warning dissapears as soon as the upgrade procedure on the second peer finishes, when the software version on both peers is identical.
View full article
ijukic ‎11-12-2015 08:25 AM
14,362 Views
8 Replies
Issue HA (High Availability) synchronization failed and returned the following error: can't find cert 'ssl_cert' for vsys 0   Symptom Run the show jobs command to see the job IDs admin@FW02(passive)> show jobs processed Enqueued ID Type Status Result Co -------------------------------------------------------------------- 2014/05/09 12:47:13 10 HA-Sync FIN FAIL 12 2014/05/09 11:59:07 9 HA-Sync FIN FAIL 11 2014/05/09 11:22:23 8 HA-Sync FIN FAIL 11 2014/05/09 11:12:59 7 Content FIN OK 11 2014/05/09 11:12:34 6 Install FIN OK 11 2014/05/09 11:11:22 5 Antivirus FIN OK 11 2014/05/09 11:10:58 4 Install FIN OK 11 2014/05/09 11:10:03 3 Downld FIN OK 11 2014/05/09 10:55:57 2 AutoCom FIN FAIL 10 2014/05/09 10:55:17 Filter on a specific job ID to view the complete error message admin@FW02(passive)> show jobs id 10 Enqueued ID Type Status Result Co -------------------------------------------------------------------- 2014/05/09 12:47:13 10 HA-Sync FIN FAIL 12 Warnings: Details:Error: can't find cert 'ssl_cert' for vsys 0 (Module: device) Commit failed   Resolution The reason for HA-Sync failure is due to the missing certificate on the passive device. Follow the steps below to resolve the issue: Export certificate from the Active firewall and import it into the Passive firewall Be sure to select the exact same usage for the certificate you just imported. Commit the changes   owner: bsyeda
View full article
bsyeda ‎10-12-2015 06:20 AM
3,574 Views
0 Replies
Overview This document describes how to display interface MAC addresses.   Details The various CLI commands provided below, will display the MAC addresses of the Palo Alto Network interfaces including an HA cluster. For example to display the MACs for all interfaces on the Palo Alto Networks: > show interface all total configured hardware interfaces: 15 name                    id    speed/duplex/state        mac address ------------------------------------------------------------------------------- ethernet1/1             16    1000/full/up              00:1b:17:05:2c:10 ethernet1/2             17    1000/full/up              00:1b:17:05:2c:11 ethernet1/3             18    unknown/unknown/down      00:1b:17:00:0b:12 ethernet1/4             19    unknown/unknown/down      00:1b:17:00:0b:13 ethernet1/5             20    1000/full/up              00:1b:17:00:0b:14 ethernet1/6             21    1000/full/up              00:1b:17:00:0b:15 ethernet1/7             22    unknown/unknown/down      00:1b:17:00:0b:16 ethernet1/8             23    100/full/up               00:1b:17:00:0b:17 ethernet1/9             24    100/full/up               00:1b:17:00:0b:18 ethernet1/10            25    100/full/up               00:1b:17:00:0b:19 ethernet1/11            26    unknown/unknown/down      00:1b:17:00:0b:1a ethernet1/12            27    unknown/unknown/down      00:1b:17:00:0b:1b vlan                    1     [n/a]/[n/a]/up            00:1b:17:00:0b:01 loopback                3     [n/a]/[n/a]/up            00:1b:17:00:0b:03 tunnel                  4     [n/a]/[n/a]/up            00:1b:17:00:0b:04   total configured logical interfaces: 21   To display an individual interface indicate the specific interface in the following command: > show interface ethernet1/1   For example: > show interface ethernet1/1 ------------------------------------------------------------------------------- Name: ethernet1/1, ID: 16 Link status:   Runtime link speed/duplex/state: 1000/full/up   Configured link speed/duplex/state: auto/auto/up MAC address:   Port MAC address 00:1b:17:05:2c:10 Operation mode: ha ------------------------------------------------------------------------------- Name: ethernet1/1, ID: 16 Operation mode: ha Interface IP address: 2.2.2.2/24 Interface management profile: N/A Service configured: Zone: N/A, virtual system: N/A ------------------------------------------------------------------------------- Physical port counters read from MAC: ------------------------------------------------------------------------------- rx-broadcast                  0   The following command displays the MAC addresses of an HA cluster: > show high-availability state   For example: > show high-availability state Group 1:   Local Information:     Version: 1     State: active     Priority: 200     Preemptive: False     Platform Model: PA-4050     Version information:       Build Release: 3.0.5       URL Database: 3233       Application Content: 160-463       Threat Content: 160-463       VPN Client Software: 1.0.2     Passive Hold Interval: 10 ms     Passive Link State: auto     Hello Message Interval: 1000 ms     Management IP Address: 10.30.14.7; netmask: 255.255.255.0     HA1 IP Address: 1.1.1.2; netmask: 255.255.255.0     HA1 MAC Address: 00:30:48:5d:45:f7     HA1 encryption enabled: False     HA2 MAC Address: 00:1b:17:01:18:06     Running Configuration: synchronized     State Synchronization: synchronized     Application Content Compatibility: Match     Threat Content Compatibility: Match     VPN Client Software Compatibility: Match   Peer Information:     Connection status: up     Version: 1     State: passive     Priority: 1     Preemptive: False     Platform Model: PA-4050     Version information:       Build Release: 3.0.5       URL Database: 3233       Application Content: 160-463       Threat Content: 160-463       VPN Client Software: 1.0.2     Management IP Address: 10.30.14.6     HA1 IP Address: 1.1.1.1     HA1 MAC Address: 00:30:48:5d:0c:c1     HA2 MAC Address: 00:1b:17:01:14:06   On the L3 interfaces, the MAC address listed for an interface using the command show interface all for an HA cluster are the VMAC. The format of the virtual MAC is 00-1B-17:00: xx: yy where 00-1B-17: vendor ID 00: fixed xx: HA group ID yy: interface ID   The following CLI command displays VMAC and VIP for Active-Active HA cluster: > show high-availability virtual-address   For example: > show high-availability virtual-address Total interfaces with virtual address configured:   2 Total virtual addresses configured:                 2 -------------------------------------------------------------------------------- Interface: ethernet1/1   Virtual MAC:               00:1b:17:00:05:10   Virtual MAC from the peer: 00:1b:17:00:85:10   107.204.232.53                          Active:yes    Type:floating -------------------------------------------------------------------------------- Interface: ethernet1/6   Virtual MAC:               00:1b:17:00:05:15   Virtual MAC from the peer: 00:1b:17:00:85:15   192.168.90.1                            Active:yes    Type:floating --------------------------------------------------------------------------------   The following CLI command displays VMAC for Active-Passive HA cluster: > show interface all ethernet1/5             20    1000/full/up              00:1b:17:00:0b:14   In the above output example, HA Group ID = 0b Hex (11 Decimal) and Interface ID = 14 Hex (20 Decimal).   Note: The MAC addresses of the HA1 interfaces, which are on the control plane and synchronize the configuration of the devices are unique. The MAC addresses of the HA2 interfaces, which are on the data plane and synchronize the active sessions mirror each other.   owner: gcapuno
View full article
nrice ‎09-15-2015 11:31 PM
39,452 Views
6 Replies
Issue The HA Link monitoring interfaces will go into a non-functional (Active to Passive and Passive to Active) loop when the monitored interfaces have no cables connected.   Cause When two Palo Alto Networks firewall are configured for a HA cluster and when link monitoring is enabled for a group failure condition of "any", then even if the cables are not connected, the monitoring will take effect and the active firewall will move from active to non-functional and then to passive. When the active firewall went to passive the other firewall, which was previously passive will go to active, and again the link monitoring will take effect as the cables are not connected to it making it to move again from active to non-functional and then finally to passive.   In the following example, the interfaces e1/4 and e1/5 are configured for Link Monitoring and the condition is set to "any":   There are no cables connected to these monitored interfaces and are down:   Even if there are no cables connected, the link monitoring will take effect as shown in the following logs. It confirms that both devices are stuck in an active to non-functional to passive loop:   LINK E1/4 and E1/5 ARE DOWN AND THE ACTIVE DEVICE CHANGED THE STATE FROM ACTIVE TO NON_FUNCTIONAL AND THEN FINALLY TO PASSIVE =====================================================================================================================   2014-09-04 14:32:56.904 -0700 Warning:  ha_event_log(src/ha_event.c:47): HA Group 1: Link group 'Link Monitoring' link 'ethernet1/4' is down 2014-09-04 14:32:56.904 -0700 Going to non-functional for reason Link down 2014-09-04 14:32:56.904 -0700 Warning:  ha_event_log(src/ha_event.c:47): HA Group 1: Link group 'Link Monitoring' link 'ethernet1/5' is down 2014-09-04 14:32:56.904 -0700 Warning:  ha_event_log(src/ha_event.c:47): HA Group 1: Link group 'Link Monitoring' failure; one or more links are down 2014-09-04 14:32:56.904 -0700 debug: ha_state_transition(src/ha_state.c:1301): Group 1: transition to state Non-Functional 2014-09-04 14:32:56.904 -0700 debug: ha_state_start_monitor_holdup(src/ha_state.c:2475): Starting monitor holdup for group 1: 500ms 2014-09-04 14:32:56.905 -0700 debug: ha_state_monitor_holdup_callback(src/ha_state.c:2557): Going to Non-Functional state state 2014-09-04 14:32:56.905 -0700 debug: ha_state_move(src/ha_state.c:1386): Group 1: moving from state Active to Non-Functional 2014-09-04 14:32:56.905 -0700 Warning:  ha_event_log(src/ha_event.c:47): HA Group 1: Moved from state Active to state Non-Functional 2014-09-04 14:32:56.905 -0700 debug: ha_sysd_dev_state_update(src/ha_sysd.c:1354): Set dev state to Non-Functional   2014-09-04 14:33:56.905 -0700 debug: ha_state_transition(src/ha_state.c:1301): Group 1: transition to state Passive 2014-09-04 14:33:56.905 -0700 debug: ha_state_start_rt_sync_hold(src/ha_state.c:2023): Group 1: starting runtime state sync hold (0) 2014-09-04 14:33:56.905 -0700 debug: ha_state_rt_sync_hold_callback(src/ha_state.c:2052): Group 1: ending runtime state sync hold 2014-09-04 14:33:56.905 -0700 debug: ha_state_move(src/ha_state.c:1386): Group 1: moving from state Non-Functional to Passive 2014-09-04 14:33:56.906 -0700 HA Group 1: Moved from state Non-Functional to state Passive 2014-09-04 14:33:56.906 -0700 debug: ha_sysd_dev_state_update(src/ha_sysd.c:1354): Set dev state to Passive   SINCE THE ACTIVE DEVICE WENT TO PASSIVE THE EARLIER PASSIVE DEVICE IS TAKING UP THE ACTIVE ROLE ======================================================================================== 2014-09-04 14:30:56.915 -0700 debug: ha_peer_recv_tlv(src/ha_peer.c:3717): Group 1 (HA1-MAIN): Cfg Sync compat from peer set to true 2014-09-04 14:30:56.915 -0700 debug: ha_sysd_dev_peer_state_update(src/ha_sysd.c:1387): Set dev peer state to Non-Functional 2014-09-04 14:30:56.915 -0700 Group 1 peer state moved from Active to Non-Functional 2014-09-04 14:30:56.915 -0700 debug: ha_state_peer_change(src/ha_state.c:471): Group 1: Peer change requests group move to Active state from Passive 2014-09-04 14:30:56.915 -0700 debug: ha_state_transition(src/ha_state.c:1301): Group 1: transition to state Active 2014-09-04 14:30:56.915 -0700 debug: ha_state_start_promotion_hold(src/ha_state.c:2144): Group 1: starting promotion hold (0 ms) 2014-09-04 14:30:56.915 -0700 debug: ha_state_promotion_hold_callback(src/ha_state.c:2201): Group 1: ending promotion hold 2014-09-04 14:30:56.915 -0700 debug: ha_state_move(src/ha_state.c:1386): Group 1: moving from state Passive to Active 2014-09-04 14:30:56.915 -0700 Warning:  ha_event_log(src/ha_event.c:47): HA Group 1: Moved from state Passive to state Active 2014-09-04 14:30:56.915 -0700 debug: ha_sysd_dev_state_update(src/ha_sysd.c:1354): Set dev state to Active   Resolution If the cables are removed the associated link monitoring will never be disabled automatically, as it will defeat the purpose of link monitoring. Disable link monitoring until the cables are plugged in as shown in the below screenshot, or never configure link monitoring for the interfaces in which the cables are not plugged in.   If the cables need to be unplugged for any reason, then disable the link monitoring until the cables are plugged in back so that the HA is stable and active. Go to Device > High Availability > Link and Path Monitoring and uncheck Enabled:   owner: dantony
View full article
dantony ‎09-11-2015 01:26 AM
25,342 Views
1 Reply
1 Like
Details In high availability, Active/Active cluster deployments, Floating IP addresses may be used for highly available virtual addressing that moves between devices in the event of a link or device failure.  Typically, admins will configure a virtual IP address in the same subnet as the physical interface address. However, virtual addresses outside of the physical interface address network may also be used.   When a Floating IP address is configured in the same subnet as the physical interface, routing will automatically be in place due to the physically connected route created by the physical address configuration. In order to use a Floating IP address on a different subnet than the physical interface, routing will need to be explicitly added in order for forwarding to work. This can be accomplished by adding a static route to the network pointing to the interface as the next hop, or by using dynamic routing.   For example, ethernet1/1 is configured with a physical interface address of 10.0.0.1/23, and a Floating IP address of 192.168.0.1/24. The firewall will automatically have a connected route for the 10.0.0.0/23 network, but not the 192.168.0.1/24 network, so although it will respond to ARP requests for 192.168.0.1 it will not be able to route traffic on that network because the forwarding lookup would fail. Once a static route for 192.168.0.0/24 is added pointing to ethernet1/1, traffic will pass the firewall using the virtual Floating IP address on the 192.168.0.0/24 network.   owner: ggarrison
View full article
ggarrison ‎09-10-2015 05:19 AM
8,112 Views
0 Replies
1 Like
Overview No, the session ID is different.   In an High Availability (HA) pair of Palo Alto Networks devices, the active device syncs session details with the passive device. However, the ID for a session is different on each device.   Example admin@PAN2(active)> show session all filter source 10.40.26.51 destination 159.140.160.73 -------------------------------------------------------------------------------- ID      Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port]) Vsys                                      Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 65384   dns            ACTIVE  FLOW       10.40.26.51[61631]/Trust L3/17   10.40.26.51[61631]) vsys1                                     159.140.160.73[53]/Cerner L3 159.140.160.73[53]) admin@PAN1(passive)> show session all filter source 10.40.26.51 destination 59.140.160.73 -------------------------------------------------------------------------------- ID      Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port]) Vsys                                      Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 31619   dns            ACTIVE  FLOW       10.40.26.51[61631]/Trust L3/17   10.40.26.51[61631]) vsys1                                     159.140.160.73[53]/Cerner L3   159.140.160.73[53])   Note:  some session types are not synced between peers in high availability. Refer to Which Sessions Will Sync Between HA Peers?   owner: hshah
View full article
hshah ‎09-09-2015 02:30 PM
3,441 Views
1 Reply
Symptom While testing HA configuration and attempting to ping between the HA2 interfaces, ping does not succeed and displays the message below:   Bind: Cannot assign requested address   Cause The HA2 link is used to synchronize sessions, forwarding tables, IPSec security associations and ARP tables between devices in an HA pair. Data flow on the HA2 link is always unidirectional and thus cannot be designated to issue a ping.
View full article
parmas ‎09-09-2015 09:44 AM
4,150 Views
0 Replies
Scenario A scenario occurs that requires an HA failover, but the passive device takes a long time before finally promoting to active.   Resolution The Promotion Hold Time is used to determine the amount of time the passive or secondary firewall will wait before taking over as active. The default setting is 2000ms (2 seconds) and for aggressive it is 500ms (.5 seconds). Please use caution when adjusting this setting because a value too large will cause unwanted downtime during a failover and a value to small could cause a failover even when the condition doesn't require a failover.     owner: jperry  
View full article
jperry1 ‎09-08-2015 04:05 PM
2,760 Views
0 Replies
Symptom Unable to download the GlobalProtect datafile (under Device > Dynamic Updates) on the Passive device of a High Availability cluster. The threats and antivirus updates are working as expected, and the Active device is able to pull all of the files.   The avdata logs on the passive device show the following: > less mp-log avdata.log Tue Apr 8 16:10:02 EDT 2014 : Data File Version: 0 Tue Apr 8 16:10:02 EDT 2014 : passive device. update version to 0 Tue Apr 8 16:10:02 EDT 2014 : passive device. return right away   Cause The device needs to assume the Active role of the cluster in order to download the GlobalProtect datafile.   owner: ssharma
View full article
ssharma ‎09-07-2015 04:16 AM
2,378 Views
0 Replies
Issue After upgrading one device in the HA group, the device is unable to become active and the dashboard reports the status as: suspended (Peer version too old). The device has been upgraded at least two minor feature releases away from the peer device in the HA group. When upgrading an HA group, each version upgrade has to be performed on both the devices in the HA group before upgrading to the next version.   Resolution Upgrade the peer to the last version this device was upgraded from, if downtime is permitted. Or, downgrade this device to the last version the device was upgraded from and upgrade the peer device to the same version before upgrading the pair to the intended version.   owner: nchong
View full article
nchong ‎09-04-2015 04:56 AM
5,486 Views
0 Replies
Overview In this scenario the user wants to configure HA2-Backup and this document describes how to configure using HSCI ports.   Details The PA-7050 is connected to another PA-7050 on an Active/Passive High-Availability cluster. The HSCI port is set as the HA2 link. HSCI-A and HSCI-B ports are linked between the two PA-7050's.   Symptom When trying to configure HA2-Backup, the only option is 'hsci'. There is no specific reference of ports 'hsci-a' or 'hsci-b' on the High Availability configuration.   If HA2-Backup is configured to be 'hsci', the following error will be received: High-availability ha2 and ha2-backup ports overlap(Module: ha_agent).Commit failed   If HA2-Backup is configured to be an HA designated data port, upon Commit, the following error will be received: High-avilability interfaces HA2 and HA2-Backup cannot mix the hsci interface with inband interfaces(Module: ha_agent). Commit failed   Cause The HSCI ports work as a physical aggregate and the desired redundancy is already handled by the hardware. There is no need to configure the HA-2 Backup, as it is already in place.   owner: mivaldi
View full article
mivaldi ‎09-04-2015 04:03 AM
3,137 Views
1 Reply
Overview In a High Availability (HA) active/passive configuration with devices that use 10 Gigabit SFP+ ports, during an HA state change from active to passive, the 10-Gigabit Ethernet port is taken down, then brought back up to refresh the port, but does not enable transmit until the device becomes active again.   Issue If the neighboring device has monitoring software, it sees the port as flapping because it's going down, then up again. This is different behavior than the action with other ports, such as the 1-Gigabit Ethernet port, which is disabled and still allows transmit, so flapping is not detected by the neighboring device.   Resolution This issue does not affect functionality. Note: If a switch is configured to monitor the port flaps, it could detect the change and take action when the device's  SFP+ port flaps (going down and then up).   owner: aciobanu
View full article
aciobanu ‎09-03-2015 07:02 PM
4,222 Views
1 Reply