Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Panorama 5.0 with 4.1 devices

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Panorama 5.0 with 4.1 devices

L4 Transporter

We are running Panorama 5.0, but still have some managed devices running 4.1. According to release notes, Panorama 5.0 should be backward compatible with 4.1 devices.

How does Panorama 5.0 treat 4.1 devices when it comes to template configuration? I know that templates are not supported in 4.1, but still it seems to me that some of the configuration I do under templates are pushed to the 4.1 devices when doing a device group commit. As far as I can see, this applies to "server profiles" and "log-settings" under the device tab. When I assign a template to a 4.1 device, and configure a syslog profile(or any other server profile) to that template, that template is actually pushed to the device when I do a device group commit in Panorama.

The reason for asking this, is that I get some kind of verification error when doing a device group commit when some values are configured on both the template and on the device itself. For example log-settings:

I understand the reason for the error, but shouldn't a device group commit ignore the template values when the device is running 4.1?

For this installation I can't simply remove the template from the devices, because log-forwarding in our security policy is actually using some of the server profiles that are defined under the template (happened automatically when we upgraded Panorama to 5.0).

1 accepted solution

Accepted Solutions

L4 Transporter

No, support did not really give me a good explanation for this. Hard to explain this, but out problem turned out to be mainly with Log settings and Server Profiles, and the fact that we could not delete the templates for the 4.1 devices.  When setting a syslog server in a log forwarding profile in 5.0, Panorama can use values configure in the template, but not in the Panorama tab(like in 4.1). We then had to manually add a syslog profile in all templates, even if we had only 4.1 devices. Panorama wouldn't let me commit configuration including the log forwarding profile, unless the syslog profile was configured in device's template. This was an acceptable work around, but we did never get the problem fixed until we upgraded the devices to 5.0.

View solution in original post

4 REPLIES 4

L4 Transporter

The best option is to open a case with support.

The unsupported template options in 4.1 should be dropped at commit time. I.e. Device > Log Settings > Config. These were not supported to be pushed prior to 5.0 so they should be dropped on the device prior to an attempt to commit the combo Device and Panorama config.

Thanks for your reply.

I'll open a case with support, and have them take a look.

Not applicable

We ran into this same issue a few months back, but at the time support wasn't able to provide a solution and we reverted back 4.1.9.  I'm curious, did they provide you with a solution that you could update here?

I've personally found through lab testing that the issue seems to lie with the automatically generated device templates created when panorama is upgraded to 5.0. deleting the device templates for our 4.1.x devices allowed the commits to succeed without issue.

L4 Transporter

No, support did not really give me a good explanation for this. Hard to explain this, but out problem turned out to be mainly with Log settings and Server Profiles, and the fact that we could not delete the templates for the 4.1 devices.  When setting a syslog server in a log forwarding profile in 5.0, Panorama can use values configure in the template, but not in the Panorama tab(like in 4.1). We then had to manually add a syslog profile in all templates, even if we had only 4.1 devices. Panorama wouldn't let me commit configuration including the log forwarding profile, unless the syslog profile was configured in device's template. This was an acceptable work around, but we did never get the problem fixed until we upgraded the devices to 5.0.

  • 1 accepted solution
  • 3296 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!