If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Change Leadership Journal, Sarbanes Oxley on Ulitzer

Blog Feed Post

BIG-IP and Merge File Configuration Changes

Early in my exposure to F5 BIG-IP I was involved in a load balancer migration project from our existing hardware to F5 Load Balancers.  This involved the migration of several hundred configurations, so manual configuration of each new configuration was just not an option.

Direct modification of the configuration file (bigip.conf) was also not an option since it would require a “b load” command to activate any modifications, which is disruptive to active traffic during a reload.

A merge file on the other hand is non-service disrupting.  Meaning that the BIG-IP will not have to reload the entire configuration file and disrupt all other traffic in order to implement your change.  It will only make the changes that you specify.  If your change is disruptive (removing servers from a pool, putting up a maintenance pages or redirect, etc.) those changes will be disruptive for other reasons and not caused by the merge process.

The documentation of the command is pretty vague on usage, and it does not appear that very many people in the community are utilizing this feature which I have found immensely useful.

MERGE(1) BIG-IP Manual

     merge command - Loads the specified configuration file, which modifies the running configuration.

     bigpipe merge (<file> | –)

     The bigpipe merge command loads the specified configuration file or data. This modifies the running configuration. After you run the bigpipe merge command, if you want to save the modified running configuration in the stored configuration files, run the bigpipe save all command.

It is important to note that if you want to replace the running configuration of the BIG-IP system, rather than modify it, you use the bigpipe load command. For more information, see the man page for the bigpipe load command.

Merge files can be utilized to create or modify virtually anything that is contained within the bigip.conf configuration file (Virtual Servers, Pools, Nodes, iRules, Profiles, Classes, etc.). The basic structure of each can be found in the bigip.conf and copied to create a modification merge file (and a back-out merge file to restore the current configuration, so you can adhere to best practices and in compliance with most ITIL change management processes) or act as a template for a new configuration item.


Merge file verification: bigpipe verify merge <file.name>

Merge specified file: bigpipe merge <file.name>



I have a new set of Virtual Servers to implement, but none of the supporting pieces have been implemented yet.  Below is an example of the merge file followed by an attempted merge with the error that you will receive when verifying a merge file that has missing configurations or errors. The verify command will verify the syntax of the content and the existence of the items called in the merge file.

NOTE:  The top line of the Merge File specifies the target partition.  If you have implemented Administrative Domains and Partitions on your BIG-IP, this is where you will specify which partition to place things. You can implement multiple items in different partitions in the same merge file.  If you have not implemented Administrative Domains and Partitions you can specify the Common Partition.



NOTE:  The file extension (.txt) is not necessary.  These would actually be .tcl files if you wanted language recognition in an editor like Notepad++.



After merging the supporting configuration items the verification will return a good result:



Modification with Back-out

If you have a situation where a modification is necessary, you can retrieve the original (current) configuration from your bigip.conf and place it into a merge file(s).  I have discovered that it is a best practice to keep a copy of the original configuration for Back-Out purposes and a second copy to act as a template for a modification.



Merge files can also be change management friendly by allowing application configurations to be exported and kept in source control (and even versioned) with the application code providing a more holistic configuration repository or by attaching the configurations to whatever change management processes you may use.


Lastly, merge order matters….

The order that you plan to merge files will impact the success or failure of a group of merge files because of the configuration dependencies (Example:  You cannot merge a Virtual Server first if it is attempting to utilize a Pool that does not exist yet). 

I have discovered the following order:

    • Classes (iRule Data Groups)
    • Pools
    • iRules
    • Virtual Servers



  • Merge file implementations are fast. Almost instant and implementations / modifications can be done on numerous items at a time.
  • Non-service disruptive to other traffic or configurations
  • Allows for pre-implementation verification
  • Configurations can be exported and kept with an application in source control our used with change management processes

I hope that everyone finds this ability as useful as I have and that it makes your implementations easier. If anyone has any questions about the merge ability of bigpipe please join the Advanced Design and Configuration group on DevCentral and start a new thread in the forum. .

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.