Question about Change Behaviour Log Collector PANOS 10

[Fariq_Zaidi]

Hi Team,

We have some question regarding Log Collector.

We want to upgrade all devices from 9.1 to 10.1 because the 9.1 is EoL on end of year. But, after we read the document about changes behaviour on PANOS 1, the log collector need minimum 3 log collector on the collector group (https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-release-notes/pan-os-10-0-release-information/c...

On the existing configuration (production), we just have 2 dedicated log collectors on the same collector group.

Is it possible to add the local panorama on the active panorama mgmt server along with dedicated log collectors in the same collector groups? If possible, do you have some pro & cons regarding this configuration?

Thanks and regards,

Fariq

[PavelK]

Hello @Fariq_Zaidi

thank you for posting!

After the upgrade to PAN-OS 10.0 and higher and running only 2 log collectors in the same log collector group the risk you are running into is if one log collector goes down, you will not be able to query logs from remaining log collector until second one comes online. This could be the case if one of the log collector has hardware defect or is disconnected from network. This will however not stop you from upgrading to PAN-OS 10.X and using log collectors to store/query logs.

The scenario to bring local log collector to the same log collector group with the other 2 dedicated log collectors will be possible only if you meet following conditions:

- All log collectors are the same model. For example if your Panorama manager with local log collector is M-200 and dedicated log collectors are M-600, they can't be in the same log collector group.

- All log collectors should have the same number of logging disks (Log redundancy is available only if each Log Collector has the same number of logging disks).

Here is the documentation Doc for reference.

Last year, I went through the exact the same upgrade as you are planning. Prior to the upgrade, I had a chance to talk to one of the System Engineer from Palo Alto. There are couple of alternative options:

- The first option is simple: Buy one more log collector 🙂 Based on my discussion with Palo Alto, they are willing to provide a good discount as this was triggered by version behavior change.

- The other option is to completely remove log collector group and have each log collector to be stand alone.

- The last option is not to invest into additional log collector and purchase instead Cortex Data Lake and enable duplicate logging.

In our case, we have purchased additional log collectors. In your case if your Panorama manager is the same model as your log collectors, then this scenario should work, but disclaimer here, I have not run it myself and I am not aware of anybody who has done it, so will not be able to provide further details about pros and cons.

Kind Regards

Pavel

[Fariq_Zaidi]

Hi Pavel,

thank you for the information and it very helpful.😀

i have additional question if you can help me to answer it.

Recently, we have tried implementing the solution of using Panorama as a local collector in our lab environment. We have built our lab environment using virtual machine (Panorama VM, Log Collector VM, and Firewall VM) and  we are using Panos 10.1.8-h2.

We conducted several test scenarios:

1. All log collectors are UP.

2. LC1 is down, while the other is UP.

3. LC1 is back UP, and all devices are UP.

4. LC2 is down, while the other is UP.

5. LC2 is back UP, and all devices are UP.

With these scenarios, the obtained results are as follows:

1. When all log collectors are UP, the Firewall sends logs to LC1, and Panorama successfully queries and updates logs.

2. When LC1 is down, the Firewall sends logs to LC2. Panorama successfully queries logs, but the logs are not updating (stuck).

3. When LC1 is back UP, the Firewall resumes sending logs to LC1. Panorama successfully queries logs, and logs update normally.

4. When LC2 is down, the firewall continues to send logs to LC1. Panorama cannot query logs, resulting in a blank log monitor.

5. When LC2 is UP, the firewall still sends logs to LC1, and Panorama successfully queries logs and logs are updating.

Based on these results, I believe they do not align with what we expected, even though Panorama has been added as a local collector.

Is this behaviour is normal? Or is it that the solution cannot be applied in a virtual machine environment?

 Thank you

[PavelK]

Hello @Fariq_Zaidi

thank you for reply.

In your LAB setup, are LC1 and LC2 dedicated VM log collectors + third local log collector in Panorama? Are all 3 log collectors part of the same log collector group? If the answer is yes to both, then I agree this is not what I was expecting.

When either LC1 or LC2 are down, personally, I would check logs from CLI in Panorama as well as remaining online log collector to confirm what is really happening: 

less mp-log ms.log

 Kind Regards

Pavel