Jump to content
Welcome to our new Citrix community!

Citrix ADC gslbservice_lbmonitor_binding monstate bug?


Shaun Scholes

Recommended Posts

The 'monstate' attribute of the gslbservice_lbmonitor_binding object is always set to 'DISABLED'

 

Even when you create the object with the monstate attribute set to 'ENABLED' and the probe is successful, it shows as 'DISABLED'

 

Modifying via the GUI 'state' checkbox does what it is supposed to operationally but the monstate attribute remains 'DISABLED'

 

Is this a bug or am I doing something wrong here? Also, why is there no API documentation on how to enable/disable this object type?

 

Citric ADC Version: NS13.0 86.17.nc

Edited by Shaun Scholes
Added ADC version
Link to comment
Share on other sites

If the monitor is working and the service goes up/down properly but the gui indicator is wrong, it is likely a gui bug. 

Release notes for 13.0 mention the following (search the link for mon):  https://docs.citrix.com/en-us/citrix-adc/downloads/release-notes-13-0-87-9.html

  •  some instances, the state of the service is not synchronized with the state of the monitor.

    [ NSHELP-31747 ]

When you are comparing settings, where are you looking GUI or CLI?
At the gslb service, the monitor, or something else?

 

Its hard to clarify the info you need. Feel free to share  a screenshot.

 

By default gslb services, have no monitors bound and are controlled by MEP. If you bind a service, you should see its status.  I can't confirm if you are seeing a bug or not, without clarifying the scenario you are describing.

 

 

 

 

Link to comment
Share on other sites

  • 1 month later...

I've been using a combination of the gui and the nitro api for testing this.

 

Even when the gslbservice is UP whilst bound to a monitor the 'monstate' attribute remains 'DISABLED'. There is another 'monitor_status' attribute that does correctly update for the operational state of the service/monitor binding.

 

Is the 'monstate' attribute not a representation on the configured state and therefore should remain set to whatever the client configures it?

 

If you see the images attached, I create a binding object by setting the 'monstate' attribute to 'ENABLED'. In the next image you can see the GET request showing the 'monstate' attribute as 'DISABLED' but the 'monitor_state' is 'UP'.

Create-binding.thumb.png.6d890cc95475a643536eb4368626a022.pngGet-binding.thumb.png.73cd04ca3eb611f6466b6896778cd0ff.png

Link to comment
Share on other sites

Is your gslb service have a monitor bound or not?

If the monitor fails, and the service goes down - then this is likely a cosmetic issue.  Because gslb "borrows" from traditional services, it may have the setting and it doesn't matter. (It also may have been an indicator in the old days; but not any more.)  I can't say for sure if this is the case; so test to see if monitors are working instead, regardless of what this parameter says.

  

If the service is ignoring monitor events for MEP only, then it might be a problem.

 

With no monitor bound; MEP is the sole determiner of up/down states. You test by bringing the remote entity (server/service/vserver) up or down and making sure the other appliance detects the change.

 

With a monitor bound; MEP is ignored for entity up/down states and the monitor is the sole determiner.  Test by creating a monitor and binding it; and then change the dest port or other parameter in monitor to "fail" and see if it brings the associated entity up/down on the appliance sending the probe. And then correct.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...