Anyone tested this or know if it is documented on the compatability or not with 8.0 on the log-collectors but everything else on 7.1.
I know the rule of thumb that your manager (panorama) is to be your highest code version, however with the log-collector I could see this not applying.
I plan on labing this but wanted to reach out to the community to see if anyone already proofed it yet.
Our Panorama is on 8.0.1 and our firewalls are currently on 7.1.8. Seems to work fine.
I had the same concerns you did but Panorama is aware of the firewall versions and deals with them accordingly. We were actually advised by the professional services team we're working with to go ahead and update Panorama to the latest version to take advantage of the logging enhancements.
Just be aware if you already have a Panorama setup logging and you're upgrading to 8 then you'll need to go through a process to get it set up, including a log migration that can take a while (ours took about a week).
Will logs still actively show up in Panorama while the process is going on? We have all of our devices on 7.1.5 and Panorama is on 7.1.9. We have all of our devices logging to Panorama. I want to update Panorama to 8.0.1 but I'm not sure if there's anything I can do before hand to help with the log migration.
I believe our installation was indeed still collecting new logs while the old ones were undergoing the log migration process. Our Panorama VM was definitely slower during this time and saw some larger CPU utilization.
Also, just an additional FYI... if your server guys have any issues with the resource requirement increases to run in Panorama Mode and are wanting to try to short-change or skimp you can tell them they can't. The CLI command to switch the installation to Panorama Mode does a system check and will actually report which resources don't meet the minimum required plus the command doesn't actually take effect.
Thank you jsalmans for the response, this was actually a direction we were looking at going. the only issue we found was when we did this with the 7.0 and 7.1 code, the logs from our 7050's were not working correctly.
I did test the option of having a M500 log-collector on 8.0.2 and panorama on 7.1.9, but panorama could not connect.
So we went on ahead and did the upgrade from 7.1.10 to 8.0.4. I can tell you that the documentation only assumes your Panorama has a solid connection to the logger post upgrade and ours mysteriously lost it. 8.0.4 seems to be a little buggy and did not like running the migration command due to some odd connection issue to the logger that eventually cleared itself out. Love when things happen automagically 🙂 . What the documentation did not tell you is that you can run the migration command directly on the logger <request logdb migrate lc start/status/stop>. The total migration time on the single m100 took about 5 days for a typical enterprise setup. What i can tell you for the single logger is that during the migration, current logs were still viewable on the Panorama. Sadly, the separate logger cluster migration failed partly due to a bad disk that was not discovered until post upgrade and during a tshooting session of why no logs were appearing during migration. Long story short, the logging cluster setup was an epic failure but we restored visibility for those devices by separating the cluster and pointing those firewalls to the good single logger.
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!