Forum Discussion

Bret_Johnson_11's avatar
Bret_Johnson_11
Icon for Nimbostratus rankNimbostratus
Jun 06, 2012

How can I generically get all LB objects & attributes via iControl?

I want to use iControl to dump, in a generic way, all pools, virtuals, profiles, iRules, etc. and all of their attributes. I'd like to be able to read (and actually write) this information in the generic tcl-ish config format output by "bigpipe list". See an example below. Put another way, I'd like to implement the "bigpipe list" command myself, in Java via iControl. How can I do that? I've looked through most all the API and just don't see how to read & write objects in this generic way, without explicitly coding for every kind of attribute that might appear.

 

 

 

 

pool test-pool-III {

 

monitor all http

 

members 10.30.50.8:http {}

 

}

 

virtual ATL_ML_CNS_PR_HTTPS {

 

snat automap

 

pool ATL_ML_CNS_PR

 

destination 66.54.66.195:https

 

ip protocol tcp

 

}

 

 

 

 

 

  • John_Gruber_432's avatar
    John_Gruber_432
    Historic F5 Account
    If you are looking for a serialized format of the bigip configuration, you can directly download the /config files from the BigIP. Let the product developers do your work for you!

     

     

    Look at System::ConfigSync. You will want to first use save_config which will serialize the config to files in the control plane OS's file system. Then you can list the files with get_configuration_list. From that list you can use download_file to pull them through iControl.
  • Thanks. Yes, I considered that. I want to dump individual objects sometimes, but I could parse them out.

     

     

    What about creating objects given the same format? Any tips there? Maybe I should just programmatically ssh in and execute bigpipe commands, if there's no good way to do it via iControl

     

  • John_Gruber_432's avatar
    John_Gruber_432
    Historic F5 Account
    Sorry for the delay.. I was traveling yesterday and the message hit me in the air!

     

     

    I guess I'm missing the point of your exercise. Why would you want to store F5 proprietary formatted objects in your system?

     

     

    The config file format on the BigIP is a mechanism for F5 to serialize the configuration so it can be preserved and recovered through file system tools on the control plane. That's really all it is. It is not really an externally exposed schema or a suggestion of one. In fact the file configuration gets put into a config database format on the BigIP itself for other tools F5 writes to access configuration object (so those tools don't try to understand the file format).

     

     

    In fact it is not supported to load config file 'fragments' cobbled together (while it may work if you are good at it ). You are supposed to use a valid configuration client like bigpipe(pre v11), TMSH (v10+), GUI, SNMP, or iControl. These clients read, or in some cases change, the running configuration which then 'can' be serialized into full configuration files for archival via file system tools (like tar which is used in the ucs archives). The iControl System::ConfigSync interface is there to let you archive/upload complete config files so you can build your own archival system, not construct a config from 'fragments' and use the load mechanism to configure the BigIP. The serialized file format was only ever meant to be relevant to F5 tools on the BigIP control plane, like bigpipe or TMSH.

     

     

    For programmatic remote access, the serialization format is SOAP rpc encoded XML, and the get_list methods on the various configuration objects is how you 'walk' the config. There is no generic 'get_all_box_config', because F5 doesn't force an object model on your systems. The object format presented by the iControl exposed structures can be a strong hint as to the schema you can use in your data access objects, but it certainly isn't a requirement. You can use whatever data access schema is preferred in your model or programming language. If the model wants to store data as serialized JSON or XML.. great, but it doesn't have to look anything like the BigIP config files. Most data access schema reflects what is relevant to the design goals. Don't inherit things from the F5 file formats you don't need, want, or that does not fit in your data model.

     

     

    If you are looking for a tool to automate the archival and restoration of BigIP configurations, take a look at F5's Enterprise Manager. That's what it is built to do.

     

     

    If the goal is to capture whole BigIP archived config in a CMDB or DMS for restoration or comparison, use the System::ConfigSync interface.

     

     

    Did that help?