- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Ignoring a CLI warning message
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-2014 06:03 AM
Hello -
I am trying to adjust the hostnames of some of our Cisco devices. Since our hostnames are typically more than 16 characters the CLI will spit back a LAT warning message:
router(config)#hostname a-very-long-router-name
% Hostname "A-VERY-LONG-ROUT " is not a legal LAT node name, Using "CISCO_000000"
a-very-long-router-n(config)#
When I attempt to do this is in a script the job will halt when the warning is issued.
Is there a way to force the script to ignore errors or CLI warning messages (or have then logged) and continue to execute?
This would he useful information as there are a number of commands that will issue warnings when entered.
Thanks!!
In Perl, you can use a
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-2014 10:47 AM
In Perl, you can use a standard exception handling construct like:
eval { };
if ($@) { ... }
In CCS, give this a try. I just checked and it is not documented, but this looks to be a documentation oversight (I will open a ticket to get that resolved):
# Turn off error handling
SKIPERROR: on
some command that may or may not fail
# Turn error handling back on
SKIPERROR: off
John - I tested the CCS portion and that seemed to do the...
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-2014 01:11 PM
John - I tested the CCS portion and that seemed to do the trick. Thanks!!
Along these same lines (for CCS) - What is the proper way to deal with CLI needing input.
Example:
router#copy running-config startup-config
Destination filename [startup-config]?
copy running-config startup-config requires a follow up command to either input an 'enter' or input 'startup-config'
I have responses coded into the action but it never seems to get passed to the device?
Example:
First attempt:
Action:
ZEROIZE KEY
Action-Timeout
60
Action-Commands:{$RSA_OK = "no"}
config term
crypto key zeroize rsa
yes
exit
SET:$NEED_TO_SAVE = "yes"
Second Attempt:
###############################################
Action:
ZEROIZE KEY
Action-Timeout
60
Action-Commands:{$RSA_OK = "no"}
config term
crypto key zeroize rsa
SET:$NEED_TO_SAVE = "yes"
Output-Triggers:
ZEROIZE_KEY_TRIGGER
##############################################
Trigger:
ZEROIZE_KEY_TRIGGER
Trigger-Timeout:
60
Trigger-Template:
% All keys will be removed.
% All router certs issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no]:
Trigger-Commands:
yes
exit
###########################################
Both methods just hang on the expected input, I end up having to cancel the job or wait for it to timeout.
Try the following:
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-2014 01:28 PM
Try the following:
Trigger-Commands:
yes \r
exit
Twitter: https://twitter.com/sifbaksh
https://sifbaksh.com
Right idea Sif but I don't
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-2014 01:35 PM
Right idea Sif but I don't think that will work. The issue is that when it waits for input without issuing a newline, the parsing code is not triggered. So, you have to just send input without waiting for the response. Something like:
Hmmm something is up... so I
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-08-2014 09:47 AM
Hmmm something is up... so I tested the SKIPERROR feature last week successfully. I reran the scripts and now I am failing at that same spot. I have tried multiple variations but I can't seem to get past it. Not sure why it worked the one time but I must be missing something.
Here is my script for reference (I've eliminated the rest of the actions until I get this part working...again):
############## Start of Script ################
# Update RSA Key
#
# Check and correct all commands for RSA key
#
#################################################
Script-Login: True
Script-Filter:
# Only Cisco
# Only select IOS (no CatOS)
# Must be a type in router, switch-router or switch group
$vendor = "Cisco"
and $sysdescr like /.*IOS.*/
and $type in ["Router","Switch-Router","Switch"]
Script-Timeout:
60
#################################################
Action:
CHECK RSA KEY
Action-Description:
Checks RSA Key
Action-Timeout
60
Action-Commands:
SET: $RSA_DOMAIN_OK = "no"
term len 0
show crypto key mypubkey rsa | inc Key name:
Output-Triggers:
CHECK_RSA_KEY_TRIGGER
####################################################
Trigger:
CHECK_RSA_KEY_TRIGGER
Trigger-Timeout:
60
Trigger-Variables:
$RSA_NAME /.*\./ string
$RSA_DOMAIN /our\.domain\.name/ string
Trigger-Template:
Key name: [[$RSA_NAME]][[$RSA_DOMAIN]]
Key name: .*
Trigger-Filter:
$RSA_DOMAIN like /our\.domain\.name/
Trigger-Commands:
SET: $RSA_DOMAIN_OK="yes"
###########################################
Action:
FIX DOMAIN
Action-Timeout
60
Action-Commands:{$RSA_DOMAIN_OK = "no"}
config term
ip domain-name our.domain.name
exit
SET:$NEED_TO_SAVE = "yes"
##############################################
Action:
CHECK HOSTNAME FOR CAPS
Action-Timeout:
60
Action-Commands:
SET: $HOST_HAS_CAPS = "no"
sho run | inc hostname
Output-Triggers:
CHECK_HOSTNAME_CAPS_TRIGGER
##############################################
Trigger:
CHECK_HOSTNAME_CAPS_TRIGGER
Trigger-Timeout:
60
Trigger-Variables:
$HOSTNAME_CAP /.*[A-Z]/ string
Trigger-Template:
hostname [[$HOSTNAME_CAP]]
Trigger-Commands:
SET: $HOST_HAS_CAPS = "yes"
################################################
Action:
FIX HOSTNAME FOR CAPS
Action-Timeout:
60
Action-Commands:{$HOST_HAS_CAPS = "yes"}
# Turn off error handling
SKIPERROR: on
config t
hostname $name
exit
# Turn off error handling
SKIPERROR: off
SET:$NEED_TO_SAVE = "yes"
##############################################
Here is the output from the job:
CAPS-in-my-hostname#config t
Enter configuration commands, one per line. End with CNTL/Z.
CAPS-in-my-hostname(config)#hostname no-caps-in-the-name
% Hostname "NO-CAPS-IN-THE-N" is not a legal LAT node name, Using "CISCO_000000"
no-caps-in-the-name(config)#
----------------------------------------------------------------------------------------------
Let me also add that I appreciate all the assistance you two are providing! It's really helping get the ROI out of the tool and scripting these types of changes is a big chunk of that!
Hi Chris
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-08-2014 09:59 AM
Hi Chris
Just a guess, but have you tried just using the SKIPERROR on just one command? Perhaps it is not possible to group config t, hostname and exit all at once. Below is what I mean:
###########
config t
# Turn off error handling
SKIPERROR: on
hostname $name
# Turn off error handling
SKIPERROR: off
exit
#########
Regards,
Lon.
Lon - It looks like it
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-08-2014 11:09 AM
Lon - It looks like it produces the same error. I thought it might be something like that as well (placement) but it doesn't seem to care where I put it.
I went back to the one successful attempt at getting past this step:
####################################
Action:
FIX HOSTNAME FOR CAPS
Action-Timeout:
60
Action-Commands:{$HOST_HAS_CAPS = "yes"}
# Turn off error handling
SKIPERROR: on
config t
hostname $name
exit
SET:$NEED_TO_SAVE = "yes"
###############################################
Looks like I turned it on but never turned it off. I retested with just leaving it on with the same results.
The problem here is that the
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-08-2014 12:53 PM
The problem here is that the prompt is changing, so the engine is waiting for the prompt to come back, but it never does.
Let me look into workarounds, if there are any.
Ok, so, there is a directive
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-08-2014 01:22 PM
Ok, so, there is a directive "Trigger-Context-Prompt" that you may be able to use to work around this. This is used internally for virtual device context data collection. I am not sure it applies directly here, but you may be able to use it.
If not, then your options are 1) use Perl, which can simply ignore the warning and continue; or 2) make the prompt change the last thing you do in the script, and send all of the commands without waiting for a response - but this may not be a good idea:
config t hostname $name\rexit\rwrite mem\rexit
Here is an example for Trigger-Context-Prompt:
Trigger: router context Enterasys Trigger-Filter: $Vendor eq "Enterasys" Trigger-Context: true ## ## Command to enter a new context - this could involve a change in the prompt structure ## Trigger-Context-Enter: enable ## ## Regular expression that defines the prompt structure for this context ## Trigger-Context-Prompt: .*# ## ## Command to leave the context - the regular expression prompt structure will be reverted to what it was before. ## NOTE: This is the last thing in the trigger that is processed (i.e. after all Output-Triggers have finished). ## Trigger-Context-Exit: exit ## ## Run some commands within this context ## Trigger-Commands: configure ip route $Network $SubnetMask $Router $Metric exit ## ## Process the output of the above commands ##
Tried the above with Trigger
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-09-2014 09:26 AM
Tried the above with Trigger Context with similar results. What I have noticed that seems to work (or at least gets me past the hostname command) is the \r:
Trigger-Commands:
config t\rhostname $name\rexit
|
I basically get the commands in but I am assuming the parser is looking for some kind of trigger to tell it that it's finished Probably an idendical prompt, as you stated before, but is there a way to send a manual 'break' command to the parser instead? Just force to force it out of the trigger-command section and move on?
Side note - the cypto key zeroize worked like a charm when input as: crypto key zeroize rsa\ryes\rexit Thanks for that!
No, I don't think there is a
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-09-2014 09:31 AM
No, I don't think there is a way to do that. What I was suggesting is that you put enough exits in there to exit the script completely. Once the prompt is changed, it is going to timeout. But exiting the session would end the job successfully. That's why it would have to be the last thing you do in the script.
Ahhhhh I got you! Yes - I
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-09-2014 10:24 AM
Ahhhhh I got you! Yes - I had that in there at first for a few of my test runs and it does indeed kill the script (as it will sever the SSH connection from the device) Unfortnately, there are a number of subsequent commands that need to be run after fixing the hostname. I could break it into two scripts but we'll probably just look into the Perl route for future attempts.
Not the end of the world, there were some caveats on what appears to be older IOS revisions that will deny access if the hostname and RSA key names don't match. That seems to have been relaxed and most of my testing has been successful thus far. This was more of a consistancy thing for me as I use parts of the hostname as a trigger for executing commands or setting variables. I am lazy and didn't want to have to code the same thing looking for caps and lower case.
Thanks for the help everyone!
No problem. Note that even
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-09-2014 10:46 AM
No problem. Note that even with the Perl route you may have some trouble with a changing prompt. You might have to do what we discussed above (have it exit the session) - in Perl you can then re-establish the session after that, so the same script can continue to interact with the device. When you re-connect though, I am not sure if it will overwrite the prior session log or append to it.
One other thing, on the
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-09-2014 10:51 AM
One other thing, on the Trigger Context, just to make sure you tried the right thing. Something like this will likely work:
Trigger-Context: true
Trigger-Context-Enter: hostname $name
Trigger-Context-Prompt: .*#
All subsequent commands will need to be called from this trigger though, or from a sub-trigger.