I am currently trying to find a way round the issue where by a commit causes a drop in the BGP connections that are peered with the firewall.
During the testing upgraded to 4.1 to use the gradual commit but if i try and install just the Network and Device configuration from the advanced option in the commit it get the attached error - not very descriptive and then seems to make the admin session either lock up or crash when doing any other action.
Has anyone seen this before and is there a way round it.
The main issue i have is that i also need to make sure that when a policy is committed the Network and Device config is not selected by default to stop it dropping the BGP peers but cannot find a way to do this - as per the below pic. This is going into a customer site so i need to make sure that they do not drop connections by mistake when committing rulebase changes.
Hope that all makes sense.
We had the similar error (using 4.1.6, where commiting only Device and Network droped management connection and once caused dataplane restart), and our local support said that it will be repaired in version 4.1.7 (still have to test it, while i already have 4.1.7 installed). How to avoid it? Try to commit while checking both Includes.Had no errors that way. I think that only Policy and Object commit also commited Device and Network changes
Thanks, that is what i found as well - it is just a pain. Will try 4.1.7 in the morning.
The issue i have at the moment relates to BGP peering being dropped when certain changes are made to the config so what i need to find out is how to set it so that only policy changes are commited by default.
Been hammering it all day today and trying to work out what changes cause the peering/routing daemon to reset - there is another tech note about this but just says it is an open case and will be fixed in a futire release.
I have an install where i will be peering the routes through two layers of firewalls with multiple ISP routers (primary and backup) so need to make sure that traffic does not go the wrong way when commiting a policy.... all good fun!
All right, i did a quick test - created test user with my user who has superuser role, assigned custom role (read only with option to create reports and commit) on Device tab. Committed using only "Include Device and Network configuration" - committed successfully with no errors, changes took place - i could log in with that admin user BUT change lock did not disappear. If created test user did some changes, he could not commit because other user had lock. Did changes again with my superuser - changes test user password. Again, changes only in Device tab, committed using only "Include Policy and Object configuration" - commit succeeded, changes took place (! maybe i just don't understand Advanced committing) and lock disappeared. So be aware, while now commit works with no errors, there is still something not quite right. At least for me. Tomorrow i will contact our local support guys and we'll see what they can contribute.
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 Live Community as a whole!
The Live Community thanks you for your participation!