Forum Discussion

Michel_van_der_'s avatar
Michel_van_der_
Icon for Nimbostratus rankNimbostratus
Oct 05, 2004

Error question

We have an application which we use to manage 13 pairs (passive/active)

 

of F5 BigIP load balancers. We use the API with perl. Most of our

 

BigIPs are used for http, as well as other protocols (such as LDAP). All

 

of the BigIPs are currently running 4.5.10.

 

 

Our usual mode of operation is to identify the passive system, clear the

 

configuration, push a new config (usually not much changes), fail over,

 

check for issues, synchronize, and continue to work...

 

 

We've seen at times arrors being generated by the BigIP, indicating the

 

following:

 

primary_error code 184, secondary_error_code 0, error_string: Name exceeds maximum length

 

(using the normal SOAP::Lite error trapping).

 

 

Usually, rebooting the passive box or re-synching from the active

 

box clears the problem, after which things start to work as normal.

 

 

I'm at a bit of a loss what the problem is. Any suggestions from the

 

F5 gurus? Obviously this tends to happen on production systems, so

 

reproducing in the Lab has been challenging...

 

 

Anything I could do on the box to dump state, config, etc. that would

 

help me track this down?

 

 

Thanks.
dev
devops
iControl
v4
  • Michel_van_der_'s avatar
    Michel_van_der_
    Icon for Nimbostratus rankNimbostratus
    May 23, 2003
    The pool name is 13 characters, and as I indicated, re-boot/re-synch

     

    ussually clears it up (i.e., I configure using the sames stored config). and

     

    it's all happy.

     

     

    I'll see if I can dig something up next time we run into it.

     

     

    Michel
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Oct 05, 2004
    Hi Michel, Do you know which method you are executing that returns the "Name exceeds maximum length" error? You can use the Perl trace printing to spit out all SOAP requests and responses.

     

     

    use SOAP::Lite + trace => qw(method debug);

     

     

    You can also turn on debug logging on the BIG-IP which will put all iControl method calls with parameter printing in the /var/log/ITCM.log file.

     

     

    $ b db set Local.Bigip.CORBA.LogLevel = "DEBUG"

     

    $ bigstart shutdown portal

     

    $ bigstart restart

     

     

    -Joe
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Oct 05, 2004
    You are correct in that this does not ring a bell. An error of a Name being too long makes me think that the client application is sending the pool_name parameter of the ITCMLocalLB::Pool::create() method in a form that is too large. That is why I recommended the client and server side debugging to find out exactly what the parameters are to the call that is failing. Without this information, I'm not sure how to proceed.

     

     

    -Joe
  • Michel_van_der_'s avatar
    Michel_van_der_
    Icon for Nimbostratus rankNimbostratus
    Mar 16, 2005
    Joe,

     

     

    is the command you gave me:

     

     

    $ b db set Local.Bigip.CORBA.LogLevel = "DEBUG"

     

     

    persistent between restarts? How do I turn it back off if it is?

     

     

    Thanks, Michel

     

  • Loc_Pham_101863's avatar
    Loc_Pham_101863
    Historic F5 Account
    Mar 16, 2005
    To turn off iControl debug logging:

     

     

    b db unset Local.Bigip.CORBA.LogLevel

     

     

    and then restart the iControl portal and servers.

     

     

    Loc
  • Loc_Pham_101863's avatar
    Loc_Pham_101863
    Historic F5 Account
    May 11, 2005
    Can you leave iControl debugging turned on while you try to reproduce the problem? If you only turn on debugging after you see the problem, then no clues on the problems will have been captured. Once you have a debug log that captures the problems, we can help you look into it.

     

     

    Also, is it possible for you to post a snippet of your code to show exact the sequence of calls leading up to the pool creation?

     

     

    Loc

     

     

  • Michel_van_der_'s avatar
    Michel_van_der_
    Icon for Nimbostratus rankNimbostratus
    May 11, 2005
    I've been very hesitant to leave debugging on all the time, because

     

    I'm afraid we'll blow out disk space. The symptoms are the same.

     

    We see a failure when were updating a box that has been running for

     

    extended periods of time. Turning on debugging either before a

     

    modification or after a failed one, always results in the update

     

    working. I track the input to the call, and I know the data

     

    sent to it is not too long (this all comes from a DB, and simply

     

    retrying after a restart portal with debugging on works...).

     

     

    The code I use is somewhat convoluted, since it's buried in a larger system.

     

     

     
 ... 
 $soapResponse = $soap->create( 
     SOAP::Data->name('pool_name' => $name), 
     SOAP::Data->name('lb_method' => 7),  $ISEF5::F5Data::DefaultLBMethod 
     SOAP::Data->name('members'   => $members), 
 ); 
 if ( $soapResponse->fault ) { 
     error("Error creating pool $name" . 
           $soapResponse->faultcode . " " . 
           $soapResponse->faultstring); 
     return 0; 
 } else { 
     print b("Pool $name created"), br, "\n"; 
 ...