Config File Download
Vilma Steiert
When loading a partial config you have 3 options: replace, merge, append. I can't find a description anywhere as to what exactly each of these does! Especially between merge and append. I did see this KB article but it really doesn't explain the ramifications for each of these choice and neither does the CLI Guide.
I'm doing an AppID optimization project using the Migration Tool 3.3.15 which does not export via API to PANOS 8. Well, it does, it just can't parse the security policies and commit. So, I'm going to import the changes manually using load partial config. All I have to do is remove unused objects, create 1 new service-group and update the security rulebase.
Append: This would put everything in the security stanza in the file x.xml at the end of the existing ruleset and not overwrite what's there. If this is true, what would happen if you had an entry that had the same name? Would it just update it or overwrite it? Generate an error?
God partial config is such a crap feature. Sorry, but it's use case is extremely limited, and I don't recommend you utilize it unless you really know what you are doing. I've ran into so many situations where an admin has tried to merge security rules and havene't properly dealt with zones, objects, or anything else these rules rely on and then for some reason find it acceptable to force commit when they run into issue.
If you are looking to do something like this, I really recommend modifying the config directly through the XML. At least this way you have to actually look at what you are doing and can validate the config off the box.
This essentially acts as a replace, but it won't delete any entries that aren't present and if entries exist with duplicate entry names the rule will simply be combined. Usually Merge is 100% what you would use during a normal partial config instead of the 'replace' or 'append' function. This issue with this is that Merge can have unintended actions if you have two seperate entries with the same name and don't actually realize that until after the fact.
Does exactly what you already guessed. If you target /devices/localhost.localdomain/vsys/vsys1/rulebase/security and replace then it'll remove anything already present and input whatever you have. Useful if you need to do a very quick migration or if two firewalls are switching locations within the network for some reason.
The Migration Tool should be able to export via the API, if you are recieving API errors (sometimes a space on the end of a rule or something similar) you will likely recieve these same errors using the load config partial.
I assume you are going to load all rules back (the original port based and the new app based) In that case I would recommend removing all security policies in the GUI (do NOT commit) then load config partial with append
Thanks for the recommendation, but what do each of these options actually do? What is there affect? That's what I'm trying to figure out because the documentation doesn't describe what exactly, merge, append and replace actually do and when to use each.
I get what you say about load partial being dodgy; its just that I've had issues with in the past taking a full config from MT, loading it onto a firewall and ending up with interfaces that are a total mess. That's after verifying that names match (including case) and everything else related to interfaces, zones, VRs & VSYSs. I've had it where interfaces end up duplicated or that the NAT rule somehow no longer recognizes the interface in the rule. I've always been careful setting up interfaces on the PAN first, exporting the config and using that as the base but it still seems to go south more often than it works.
It's the main reason I was looking at partial load. I'm not messing with interfaces or virtual routers nor even NAT. Just updating objects and security policies. I may try loading the whole config and doing a commit verify. Worse case I revert to running.
For the rulebase I'm also leaning toward replace. I really like merge but I have a number of rules that are just being converted to AppID instead of having the old rule in place with the new AppID rule in front of it. My naming conventions are a little screwy which I should've thought about. I changed the rule with the original name to the AppID rule and used the new Cloned rule as the legacy rule. That way when the client cleans them out, he ends up with the original rule names.
The error I was getting during commit, Missing Service, turned out to be just that. For some reason, 3 security policies were to set to service of 'null'. Once I corrected this the config was able to be parsed.
Thanks for raising this, I have had the same question only to find out by trial and error. With the merge function I have found if an element can only have a single entry or configuration the name of which already exists in the config, it effectively REPLACES that element in the destination x-path. Where an element can have multiple entries (e.g. groups) the merge function will COMBINE the existing config with the new. Understanding this is helpful in case you have existing elements with the same name.
I believe the Append function is designed for policies only, where the imported config is tacked on the end of the existing althouhg I would expect this to have the same result as a merge, especially when an existing rule has the same name (you can't have two rules with the same name even in a candidate config - the 'new' rule is probably going to merge with or replace the existing - I would suggest more trial and error or more consise documentation from PAN
I have done all my optimisation off-site so never had API access to the customer equipment, should that be the case I have no idea what would happen when pushing the conifg to Panorama via the API - would this merge, append or replace the destination element / stanza?
w_window = hiOpenWindow()
geOpen(?window w_window ?lib t_lib ?cell t_cell ?view "schematic" ?viewType "schematic")
when( hdbIsConfig(t_lib t_cell "config")
h_config = hdbOpen(t_lib t_cell "config" "r")
deSetConfigId(w_window h_config) ; set window's config
); when
The notion of that configuration object is documented here although it does not go into all the details (every property available under that object) and to be honest I believe some of them may be considered implementation details where the lack of documentation is intentional.
Meanwhile if the goal is to have this running locally for the purposes of development (with the consideration that not all logic could be tested to completion locally as you would still be running this outside of the Auth0 service) I would consider the following:
We simply needed enough of an object to get through the initial painting of the HTML to the browser without crashing out the JS thread. (We use a variety of onclick events in the UI elements to make the forms look and work nicely. When the parse would fail, all of the onClick events would become inoperable.)
Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.
The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
Alright so I am having some problems with my Mapkeys. I have recently inherited the role of ProE Admin and I have been working with Mapkeys on it for quite some time now. I thought I had them all nailed down and then ran in to a small issue.
I used to have all my mapkeys in the config.pro and it was working great. Well then someone decided to include mapkeys with the same name in their config.win and so it would over ride mine. Then they call and say the mapkeys aren't working right and its just getting old.
What I am trying to do is create a config.sup with some of the mapkeys that are company wide so that they don't get changed. Now the issue I am running into is when I take half the mapkeys out of the .pro and put them in the .sup... they are the only ones that will show when I start ProE. It's like it is completely ignoring anything that is in the config.pro now. If I remove the config.sup then all the mapkeys will show back up.
59fb9ae87f