Forum Discussion
jj24_43946
Nimbostratus
NimbostratusiControl, bigip.conf possible descrepancy?
Hi Joe ( and all ),
OS: BIG-IP 10.2.1 Build 511.0 Hotfix HF3
We noticed that health monitors that are associated with iControl ( oranges ) appear differently in the bigip.conf file than the ones that are done manually ( apples ) in the UI. What we see in the UI is that both pools have the same monitors associated: _splash and _monitor. What we find in the bigip.conf after adding manaully is:
Apples===========================
pool apples_B2C_Https {
monitor all https_apples and https_apples_splash
members {
192.168.10.22:https {}
192.168.10.23:https {}
192.168.10.24:https {}
}
}
monitor https_apples {
defaults from https
recv "200 OK"
send "HEAD /splash.html HTTP/1.1\r\nHost: store.apples.com\r\nConnection: close\r\n\r\n\r\n"
}
monitor https_apples_splash {
defaults from https
interval 30
recv "404 Not Found"
send "HEAD /text/mlsplashup HTTP/1.1\r\nHost: store.apples.com\r\nConnection: close\r\n\r\n\r\n"
}
==================================
Please note that in the above example is reflected by what is seen in the GUI-- both monitors are included in the pool definition after doing a manual association. We expect to find something similar in the bigip.conf after associating monitors via iControl, but instead we see that only one monitor is listed in the pool definition.
ORANGES=========================================
pool oranges_B2C_Https {
monitor all https_oranges_B2C_splash
members {
192.168.10.22:https {}
192.168.10.23:https {}
192.168.10.24:https {}
}
}
monitor https_oranges_B2C_monitor {
defaults from https
recv "200 OK"
send "HEAD /splash.html HTTP/1.1\r\nHost: www.oranges.com\r\nConnection: close\r\n\r\n\r\n"
}
monitor https_oranges_B2C_splash {
defaults from https
interval 30
recv "404 Not Found"
send "HEAD /text/mlsplashup HTTP/1.1\r\nHost: www.oranges.com\r\nConnection: close\r\n\r\n\r\n"
}
================================================
Yet, in the GUI when we click on Pools->oranges_B2C_Https, we see both https_oranges_B2C_monitor and monitor https_oranges_B2C_splash listed under the Active Health Monitors column.
I searched through the bigip.conf file to see if there were other subsequent definitions of the missing monitor, but there were not.
Why the discrepancy? We want to begin using iControl to mange our production sites, but we have to understand why these definitions are different. Any help would be appreciated.
Update: I noticed that when I click the update button in the GUI on the pool monitor page ( without making any changes ), the conf file then shows both monitor associations in the pool definition. Still confused.
hooleylistCirrostratus
Are you saving your iControl changes from memory to file?
Aaron
jj24_43946No! I wasn't aware that I had to. Scary. Ok, that certainly is an illuminating piece of information. So how would I go about saving the running configuration using iControl and Perl? Any code example?- jj24_43946Update. Did more testing. Found that after I ran an iControl config save, I'm still seeing the same behavior as is described in the original post ( pool definition is missing an association in the bigip.conf file that exists in the GUI! ) I think the config save works because I see the bigip.conf and other conf timestamps being update. Is this the correct method to save the configuration?
my $ConfigSync = SOAP::Lite -> uri('urn:iControl:System/ConfigSync') -> readable(1) -> proxy("https://$f5_ip/iControl/iControlPortal.cgi"); my $soapResponse = $ConfigSync->save_configuration ( SOAP::Data->name(filename => 'full' ), SOAP::Data->name(save_flag => 'SAVE_FULL' ) ); - hooleylistThat looks right to me. Joe or anyone else, can you comment?
Aaron - hooleylistActually, this should be bigip.conf:
SOAP::Data->name(filename => '/config/bigip.conf'),
Aaron - Can you post the snippet of iControl code you used to associate the monitors with the pool? Could be that in that code you aren't correctly associating both monitors with the one pool.
As for the flushing to disk, this is something we added on early in the development of iControl because we found that users who were trying to make many many changes didn't really like having to wait a second, or two, or more, of overhead for each method call to account for flushing the entire configuration to disk.
-Joe
