In article , snipped-for-privacy@bellsouth.net wrote: :If any of these statements get uploaded with extra spaces at the end, :it fails to upload, and locks me out. It seems that it ignores the :spaces on acl statements, but not AAA statements.
Hmmm, what version are you using? I just tried it with a 501 with 6.3(4) and it had no problem at all. Try putting those statements into a config file by themselves and seeing if the problem persists.
:aaa authentication telnet console LOCAL :aaa authentication enable console LOCAL :aaa authentication ssh console LOCAL :aaa authorization command LOCAL
Question: do you happen to have hand-inserted any 'clear' or 'no' commands in your tftp'd configuration? Especially ones having to do with 'rip' or 'route' statements? Or alternately do you happen to be reconfiguring -through- a VPN, and the configuration you are bringing in sets up the crypto maps or has an 'isakmp enable outside' statement?
If either of these cases is true, then unless you are -quite- careful, you can run into race conditions in the way the PIX loads in configuration files.
PIX up to 6.x offers only tftp (other than the undocumented hooks through the https or pdm connections). tftp has the characteristic that it always reads -exactly- one 512 byte block at a time -- the first block that is less than 512 bytes long signals the end of file.
PIX has the characteristic that when you "config net", it loads in one of those 512 byte blocks, processes all the complete lines that it has available, and only then loads in the next 512 byte block [holding on to the beginning of the incomplete line from the previous block] and then it processes the complete lines from there and so on.
Because of this block-by-block processing, if you happen to have statements in your configuration file that destroy the ip address or route (or VPN) to the place you are loading the file from, you only have the time until the end of the block before the address or route or VPN must be re-established so that it can read the next block. If you are careful with your padding to push things onto nice boundaries, then you can usually re-establish IPs or static routes within the same block, and you have a decent chance (but not certain) that you will hear a RIP route in time. However, when it comes to VPNs, the setup usually takes a hair too long, and you usually will not get your VPN back up before the next block is needed. [The trick there is to create a complete new crypto map independant of the one currently in use, and activate it all at one go with a 'crypto map interface' command.]
What, you might ask, does this have to do with whether there are spaces after the AAA statements? The answer is that you could just
-happen- to be in the situation where stripping out those spaces moves the 512 block boundary just enough that a re-establishing command falls into a complete block instead of trickling over into a different block. And the command that gets split up over blocks might be rather some distance from the AAA statements.
If you want to debug how far you are getting in a tftp configuration, about the only method I know of [other than snooping the link] is to introduce deliberate errors into the file being tftp'd. For example, if you add a statement such as
mark 1250
at line 1250, then if the PIX complains about the error in the line then you know it got to the line. The PIX will -not- stop processing when it finds such lines; at the end it will say that the tftp failed instead of OK, but all the lines will still have been processed, so "failed" should not be interpreted as indicating that you are back to the old configuration, just that things didn't go perfectly as far as the PIX parser was concerned.