Ignoring a CLI warning message

[#1]

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!!

[#2]

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
 

[#3]

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.

[#4]

Try the following:

Trigger-Commands:
yes \r
exit

[#5]

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:

crypto key zeroize rsa\ryes\r

[#6]

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:

*** Timeout waiting for device ***

 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!

[#7]

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.

[#8]

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.

[#9]

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.

[#10]

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
##
 

[#11]

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

*** Timeout waiting for device ***  E-ntac-gold-DRT01(config)#hostname e-ntac-gold-drt01 
 % Hostname "E-NTAC-GOLD-DRT0 " is not a legal LAT node name, Using "CISCO_000000" 
 e-ntac-gold-drt01(config)#exit 
 e-ntac-gold-drt01# 
 e-ntac-gold-drt01# 

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!

[#12]

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.

[#13]

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!

[#14]

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.

[#15]

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.