Who rated this post

@Ayush_paloalto,

Commit Force does a few things, and before going further I think it's important to specify that commit force should be used with extreme care. 

First lets talk about what happens during a normal commit process. When you do a normal commit the device performs a validation of the configuration for any syntax errors, along with a basic semantic validation (will the config actually function). If those checks pass, the candidate config is then loaded as the running-config and the device starts applying any modifications made to the configuration.

Now when you use a commit force it skips the validation process and will load the configuration even if the syntax is incorrect or the semantic validation fails; in essence, the device loads the configuration regardless of what you've input and will try its best to run the configuration as input. If you program exclusively in the GUI or the CLI this shouldn't be a big issue, as the device does a fair job of insuring the commands you input will actually work. You could still run into small semantic issues where the config as applied doesn't actually work as intended, but your device will likely still function perfectly fine. If you modify and load the XML configuration manually and then do a force, you could make your device essentially non-functional and you would need to recover via the console port.

Now directly to your question the way that 'commit' and 'commit force' actually pushes the configuration to the data plane doesn't really vary that much. In the essence of time a commit is essentially a merge between the candidate-config and the running-config; when utilizing a force however its a kin to a "replace" and the candidate-config fully takes the place of the running-config. In essence, the only reason this process changes is because the 'commit force' command allows you to make syntax and semantic configuration issues that wouldn't be able to be merged into the existing configuration loaded on the dataplane.