A BIG-IP configuration file is what is used by the system at start-up to tell it about your environment. When you make changes in the UI or call save_config in iControl, this file is written to disk so that the BIG-IP remembers what you've done.

And that's our first point. We've said it before and we'll likely say it again, simply because we want to avoid creating lost work and frustration for you - your iControl changes will be lost on the next reboot if you do not save them. If you're familiar with the command line tools of another popular vendor, this is the "running config" versus "saved config" issue. We don't want to assume you're ready to make your changes permanent via iControl, so we give you a tool to say "I'm done and this is right, save it". Just remember to use it.

The config file we're going to talk about is the one that is updated regularly. There is another with information that is generally more static that we will talk about in a future Tech Tip. This file is saved on your BIG-IP at /config/bigip.conf. You will need rights to ssh or ftp into the BIG-IP (see your administrator) to access the file, and remember not to edit the original. In fact, play it safe and copy the file off disk before editing, it only takes one mistake to lose big chunks of your configuration at next boot-up.

The following caveat must be made: This is an internal BIG-IP configuration file. We don't guarantee the format (and particularly the order objects are saved, but no guarantees about anything) will not change. Indeed, as we improve our products to better serve you, expect that a at a minimum, items will be added to this format. This document is valid for 9.2, and we know that these fields are valid in later versions, but their might be more objects saved in later versions.

The generic stuff...

 

route default inet {
   gateway 192.168.42.1
}
node * monitor icmp

 

This sets the default route to the gateway, and the default node monitor to icmp. If the device pointed to in the default route is not up, nothing connected to the BIG-IP can communicate with the Internet. All nodes that do not have a monitor explicitly defined to them will get the icmp monitor associated with them automatically.

If you are using partitions, you will also get a partition definition -

 

partition Common {
   description "Repository for system objects and shared objects."
}

 

 

And in newer versions of the software you will get user definitions:

 


user root {
   password crypt "$1$tAiUgKE3$t27ER2uyRzoplfh91./94."
}

 

And routing information is included in the top for the BIG-IP to correctly direct traffic running through it:

 


route 172.27.41.0/24 {
   vlan external
   static
}

 

Simply put, this defines a static route for traffic coming in on the indicated IP range to the vlan named external.

Next are the actual objects that you've defined (and a few that are built in). First is Profiles:

 

profile stats MyStockStats {
   defaults from stats
   field1 total_value
   field2 orders
}

 

This defines a profile named MyStockStats (something someone was doing for testing), that gets all values not explicitly defined from the stats profile, which is built into the BIG-IP. it defines two fields, total_value and orders. That's it. Any of the other zillions of values are pulled from the stats Profile.

Now, let's look at a more complete profile - http.

 

profile http http {
   basic auth realm none
   oneconnect transformations enable
   header insert none
   header erase none
   fallback none
   compress disable
   compress uri include none
   compress uri exclude none
   compress content type include "text/" "application/(xml|x-javascript)"
   compress content type exclude none
   compress prefer gzip
   compress min size 1024
   compress buffer size 4096
   compress vary header enable
   compress http 1.0 disable
   compress gzip memory level 8k
   compress gzip window size 16k
   compress gzip level 1
   compress keep accept encoding disable
   compress browser workarounds disable
   compress cpu saver enable
   compress cpu saver high 90
   compress cpu saver low 75
   response preserve chunk
   lws width 80
   lws separator none
   redirect rewrite none
   max header size 32768
   max requests 0
   pipelining enable
   insert xforwarded for enable
   adaptive parsing disable
   ramcache disable
   ramcache size 100mb
   ramcache max entries 10000
   ramcache max age 3600
   ramcache min object size 500
   ramcache max object size 50000
   ramcache uri exclude none
   ramcache uri include none
   ramcache uri pinned none
   ramcache ignore client cache control all
   ramcache aging rate 9
   ramcache insert age header enable
}

 

That's a big one. It's pre-defined, so we won't delve into each field's definition here. But it does illuminate the difference between a simple one that uses a default profile and a self-defining profile that has all the values filled in right in the configuration file.

 

node 192.168.42.138 {
   screen Arial
}
node 192.168.42.243 {
   screen sanbox
}


Next up are node definitions. There is not much to a node, it knows its IP address and the name presented in the BIG-IP UI. That's all you need - nodes don't track what pools they're in, or ultimately what virtuals rely upon them, that is why we have special code to determine things like that in iControl.

 

 

pool wargamestest {
   member 192.168.42.138:http
}
pool STORAGE_SERVERS {
   monitor all gateway_icmp
   member 192.168.42.243:http
}

 

And then pools. The minimum definition for a pool is the name. The minimum definition for a Pool that can actually service requests is a name and at least one member.

Notice that we set a monitor on the STORAGE_SERVERS pool, but not on the wargamestest pool. The wargamestest pool will use the default node monitor defined above to check the status of each of its nodes, while the STORAGE_SERVERS pool will use the monitor defined here to test status on its nodes.

 

rule rss_stats {
   when HTTP_REQUEST {
set uri [HTTP::uri]

if { $uri starts_with "/rss" }
{
   set actives [active_members STORAGE_SERVERS]
   set vipname [virtual name]
   HTTP::respond 200 content "<rss version='2.0'><channel><title>BIG-IP Statistics</title><link>http://bigip.changedToProtectTheGuilty.com</link><item><description>Virtual server: $vipname has $actives active member(s)</description></item></channel></rss>"
}
else {
   pool STORAGE_SERVERS
}
}
}

 

And then we have rules. The rule is written out in-toto, just as it appears in the iRule editor. There is no supplementary information because like a node, a rule is something that is applied to other things, it does not keep track of who is using it, just it's own name and code. Like Profile fields, iRules documentation can and does fill volumes, so we won't dissect this rule here. Visit the iRule Wiki for detailed information about iRules coding

 

virtual STORAGE_VS {
   destination 192.168.42.251:http
   snat automap
   ip protocol tcp
   profile http stats stream tcp
   pool STORAGE_SERVERS
   rule rss_stats
}

 

And finally we have the Virtuals. This definition has a name, a destination IP - the Virtual IP, or the address it should be DNS'd to, how to handle snat, what IP Protocols it supports, the profiles it should use, what pool services this virtual, and the rules to apply to traffic going through this virtual.

So why would you care about all of this? Well, in general for the reasons stated above - sometimes seeing what was actually created as opposed to what you thought you did with iControl is important. We've also seen a case where an application maintained a data model of the load balancer, and instead of making 5000 iControl calls to populate their model on startup, they downloaded the config file and parsed it locally. In the end, it's handy information to have - we've also used it to validate our code when displaying things in iControl with filters.

Whatever you do with it, avoid editing it directly. The changes won't take effect until next reboot, and trashing this file can cause you a lot of headaches.