Hi,
I've encountered something a little strange.
I'm currently running 15 contexts on a 5550 which are loading their configs from an FTP server (albeit temporarily!) using the config-url ftp://xxxxx line in the context configuration.
The admin context is configured to load its configuration from the local disk0: on the ASA.
Obviously the system context uses the admin context's management IP to pull each of the other "customer" context configurations from the FTP server. This works fine when the admin context is up and running and I can successfully remove and re-add the contexts at will to reload the configs (or write mem from within the context to write changes back to the FTP server).
Ok - all good so far...
The weird thing is that we just had to powercycle the ASA and it took a good 20 minutes to boot up! I discovered that the ASA didn't load the admin context first (despite being first in the system context config)... and therefore the ASA was attempting to load the other contexts first.... which it couldn't because the admin context wasn't live to allow the system context to pull the configs off the ftp server... in fact the admin context was loaded last which meant that inband management connectivity (via ssh etc) was offline while the ASA slowly timed out loading each of the customer contexts. Not good.
Does anyone know whether it is possible to force the ASA to load the admin context first? If not then this issue makes the functionality of storing the contexts configs on remote tftp/ftp/scp/http (etc) servers a little redundant.
Cheers
Paul
