Jump to content
Welcome to our new Citrix community!

nsconmsg -K newnslog -d event - no events displayed


Recommended Posts

You can see in my attempt to use nsconmsg below that the VPX is showing nothing at all although there 

is plenty of load balancing activity going on. Could the logging be turned off? Other explanation? Thank you.

 

root@ns-adc-sp01# nsconmsg -K newnslog -d event | more
Displaying event information
NetScaler V20 Performance Data
NetScaler NS12.1: Build 54.16.nc, Date: Oct  7 2019, 04:43:41   (64-bit)

 Done.
 

Link to comment
Share on other sites

I added the VPX to a vertical application specific to the company. To keep it simple I set things up as a SSL_Bridge LB for two servers. They've only ever had one - 1500 users on one IIS and their vertical app. Anyhow - the LB setup worked like a champ for like 13 of 14 users. But one user had a couple of types of operations that worked in the non balanced server but not going through the load balancer. They have a department of like 12 people feeding that application whereas it's just me and the load balancer. The new LB is being blamed. The services have been up for days, my sticky by IP was consistent as shown my show persistantconnections, no errors at the system level, CPU good, memory good. I see no problem. Yet here comes the blame train!

 

So I'm trying to find any kind of logging which would show client to VIP and SNIP to server and exculpate the VPX and myself. Or I'd be happy if the logging implicated the VPX. Forensics. 

Link to comment
Share on other sites

I see.

 

In general, I would say, there are just 2 reasons for a SSL bridge:

  • the server has to see client certificates
  • the admin did wrong

I would go away from the SSL bridge. But aside of this: A SSL bridge is totally blind about content, so it is absolutely unable to mess up content. Persistence method for a SSL bridge can either be source IP or SSL session ID. All the rest won't work well. SSL session ID may fail because it may change, so I would try to go with source IP on a first step.

 

You could turn on TCP-logging and log level to all, this would show all TCP-sessions. It will blow up the log file, so you should use this for trouble shooting only.

 

And you could do a network trace of course as well. This would be my approach. Just start a trace, let the packet size remain on 164, filter on CONNECTION.IP.EQ(<ip address of the vserver>) and Trace filtered connection's peer traffic (to see what this ADC sends to the back end).

 

Cheers

Johannes Norz

CTA, CCI, CCE-N

  • Like 1
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...