cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
799
Views
0
Helpful
7
Replies

ACE does not always recover from switch reboot

geraldjacksontx
Level 1
Level 1

6509__________                          -6509____________

ACE1(Primary)    |<-ft trunk->         |ACE2(Backup)        |
Switch1(Primary)|<-10 Gig Trunk->   |Switch2(Secondary) |

______________                            __________________

We power off Primary switch.  For failover testing of Databases.

We turn the Primary switch back on.  ACE1 generally comes up fine.  But occacially it comes up and the scripted LDAP probe are down, which makes our whole system crash.  It fixes it self with a reload of the ACE1.

7 Replies 7

Hi Cecil,

Few things to be clarify and checked:

- What is the FT group configuration you have? Do you have preempt enabled?

- Which ACE was the active unit after you booted up ACE-1?

- What is the probe you are using? is it one of the built in TCL scripts?

- Have you captured any outputs from the ACE units?

- Have you checked the MAC mapping in the downstream and upstream devices after booting up ACE-1?

Best regards,

Ahmad

Software Version A2(3.0)

- What is the FT group configuration you have?

  • seperate lan/trunk for FT
  • everything default except priorty
    • heart inter 200
    • heartbeat count 20
    • hsrp track
    • It seems to work mostly
  • Do you have preempt enabled? Yes

- Which ACE was the active unit after you booted up ACE-1? Yes.  You can login to the box, but with the LDAP probes showing down.  Our system will not work without LDAP

- What is the probe you are using? LDAP probe downloaded from Cisco. Is it one of the built in TCL scripts? No

- Have you captured any outputs from the ACE units? No.  I am usually rushed to get it up. Reboot always brings it up to active state and working state.  It is just when I reboot the switch that it is in that it fails to come up sometimes.

- Have you checked the MAC mapping in the downstream and upstream devices after booting up ACE-1? No.  I am usually rushed to get it up.

I have 4 Contexts and it LDAP probes fails on all 4 contexts.

Hi Cecil,

I don't think you have enough information here to troubleshoot this issue, I would recommend you to schedule another maintenance window and open a TAC case to verify the same activity.

Can you clarify what is the probes you are using? Provide sample configuration is possible.

Best regards,

Ahmad

Cisco LDAP_PROBE

#!name = LDAP_PROBE
########################################################################################
# Description:
#    LDAP_PROBE opens a TCP connection to an LDAP server, sends a bind request. and
#    determines whether the bind request succeeds.  LDAP_PROBE then closes the
#    connection with a TCP RST.
#
#    If a port is specified in the "probe scripted" configuration, the script probes
#     each suspect on that port. If no port is specified, the default LDAP port 389
#     is used.
#
# Success:
#   The script succeeds if the server returns a bind response indicating success
#    (status code 0x0a0100) to the bind request.
#   The script closes the TCP connection with a RST following a successful attempt.
#
# Failure:
#   The script fails due to timeout if the response is not returned.  This
#    includes a failure to receive ARP resolution, a failure to create a TCP connection
#    to the port, or a failure to return a response to the LDAP bind request.
#   The script also fails if the server bind response does not indicate success.
#    This specific error returns the 30002 error code.
#   The script closes any attempted TCP connection, successful or not, with a RST.
#
#  PLEASE NOTE:  This script expects the server LDAP bind response to specify length
#   in ASN.1 short definite form.  Responses using other length forms (e.g., long
#   definite length form) will require script modification to achieve success.
#
# SCRIPT version: 1.0       April 1, 2008
#   
# Parameters:
#   [DEBUG]
#      username - user login name
#      password - password
#      DEBUG        - optional key word 'DEBUG'. default is off
#         Do not enable this flag while multiple probe suspects are configured for this
#         script.
#
# Example config :
#   probe scripted USE_LDAP_PROBE
#         script LDAP_PROBE
#

#   Values configured in the "probe scripted" configuration populate the
#   scriptprobe_env array.  These may be accessed or manipulated if desired.
#
# Documentation:
#    A detailed discussion of the use of scripts on the ACE is included in
#       "Using Toolkit Command Language (TCL) Scripts with the ACE"
#    in the "Load-Balancing Configuration Guide" section of the ACE documentation set.
#
# Copyright (c) 2005-2008 by Cisco Systems, Inc.
########################################################################################

#-------------------------------------------
# debug procedure
# set the EXIT_MSG environment variable to help debug
# also print the debug message when debug flag is on
#-------------------------------------------

proc ace_debug { msg } {
    global debug ip port EXIT_MSG

    set EXIT_MSG $msg
    if { [ info exists ip ] && [ info exists port ] } {
set EXIT_MSG "[ info script ]:$ip:$port: $EXIT_MSG "
    } 
    if { [ info exists debug ] && $debug } {
puts $EXIT_MSG
    }
}

#-------------------------------------------
# main
#-------------------------------------------

# parse cmd line args and initialize variables
## set debug value
set debug 0
if { [ regsub -nocase "DEBUG" $argv "" argv] } {
    set debug 1
}

ace_debug "initializing variable"
set EXIT_MSG "Error config:  script LDAP_PROBE \[DEBUG\]"


set ip $scriptprobe_env(realIP)
set port $scriptprobe_env(realPort)
# if port is zero the use well known ldap port 389
if { $port == 0 } {
    set port 389

#####################
# PROBE START
#####################


# open connection
ace_debug "opening socket"
set sock [ socket $ip $port ]
fconfigure $sock -buffering line -translation binary

# send a standard anonymous bind request
ace_debug "sending ldap bind request"
puts -nonewline $sock [ binary format "H*" 300c020101600702010304008000 ]
flush $sock

#  read string back from server
ace_debug "receiving ldap bind result"
set line [read $sock 14]
binary scan $line H* res
binary scan $line @7H6 code
ace_debug "received $res with code $code"


#  close connection
ace_debug "closing socket"
close $sock

#  make probe fail by exit with 30002 if ldap reply code != success code  0x0a0100
if {  $code != "0a0100" } {
    ace_debug " probe failed : expect response code \'0a0100\' but received \'$code\'"
    exit 30002
}

## make probe success by exit with 30001
ace_debug "probe success"
exit 30001


Hi Cecil,

As I have explained you don't have enough information to troubleshoot this issue, you will need to reproduce the same issue and collect more outputs like:

- Two show techs from the ACE at least.

- Sniffers on the LDAP servers.

- Verify the MAC mapping status on other network devices.

I would recommend to have TAC support during the issue.

Best regards,

Ahmad

Thanks. It is so intermittant that is going to be hard to troubleshoot. I was just hoping that someone had seen a example or same problem.

Review Cisco Networking for a $25 gift card