NTP status displays “No association ID ” error message on Secondary NetScaler

On the Secondary NetScaler, ” No association ID error” gets displayed when “Show NTP Status command ” is executed

Primary NetScaler Appliance:

=======================

> show ntp status

remote refid st t when poll reach delay offset jitter

=======================================================

adljj.john.com .LOCL. 1 u 9 64 7 0.293 -212012 2.175


Secondary NetScaler Appliance:

===========================

> show ntp status

No association ID’s returned

Done

Log Analysis:

==============

1) From the logs, we found that, NTP was configured after upgrade and during that time secondary device interface was down.

2) We can see that interface was down in the time interval of10:01 – 11:18 A.M. In that interval, none of the command gets propagated. Because of that ntp config was missing from secondary.

3) As per current design, even if the Secondary comes UP and the NTP configurations are Synchronized through HA Synchronization, we have to manually restart the NTP Daemon to get the NTP status on Secondary. Which is a current limitation on NetScaler.

4) Hence, Enhancement request was raised to address this limitation. 5) The limitation was fixed in the following versions: 12.1 50.x 12.0 60.x 11.1 60.x

Logs from Primary:

—————————–

var/log/ns.log

ns.log.0:649:Apr 23 10:15:59 <local0.info> X.X.X.X 2018:01:15:59 GMT NetScaler-Internal-TDC-01 0-PPE-1 : default GUI CMD_EXECUTED 136 0 : User nsroot – Remote_ip X.X.X.20 – Command “add ntp server X.X.X.3 -minpoll 6 -maxpoll 10 -devno 32833536” – Status “Success”

ns.log.0:651:Apr 23 10:15:59 <local0.info> X.X.X.X 04/23/2018:01:15:59 GMT NetScaler-Internal-TDC-01 0-PPE-1 : default GUI CMD_EXECUTED 137 0 : User nsroot – Remote_ip X.X.X.20 – Command “unset ntp server X.X.X.3 -autokey” – Status “Success”

Logs from secondary:

——————————–

var/log/ns.log

Apr 23 10:00:34 <local0.info> X.X.X.25 04/23/2018:01:00:34 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default CLI CMD_EXECUTED 131 0 : User nsroot – Remote_ip 127.0.0.1 – Command “logout” – Status “Success”

Apr 23 10:01:13 <local0.notice> X.X.X.25 04/23/2018:01:01:13 GMT NetScaler-Internal-TDC-02 0-PPE-0 : default EVENT DEVICEDOWN 79 0 : Device “interface(0/1)” – State DOWN

Apr 23 10:01:13 <local0.notice> X.X.X.25 04/23/2018:01:01:13 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default EVENT DEVICEDOWN 132 0 : Device “interface(0/1)” – State DOWN

Apr 23 11:18:15 <local0.notice> X.X.X.25 04/23/2018:02:18:15 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default EVENT DEVICEUP 133 0 : Device “interface(0/1)” – State UP

Apr 23 11:18:15 <local0.notice> X.X.X.25 04/23/2018:02:18:15 GMT NetScaler-Internal-TDC-02 0-PPE-0 : default EVENT DEVICEUP 80 0 : Device “interface(0/1)” – State UP

Apr 23 11:18:29 <local0.info> X.X.X.25 04/23/2018:02:18:29 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default AAA Message 134 0 : “rba authentication : user nsroot response_len-0 cmdPolicyLen-0, partitionLen-0 PromptLen-0 timeout 805307268 authPolicyLen-0 authActionLen-0 ssh_pubkey_len

Related:

The following error occurred during an authentication attempt for user:domain.comabc with realm:

At the Storefront server open a command line and run the following command:

>set u

There would be two fields called USERDOMAIN and USERDNSDOMAIN

And these will be like this:

USERDNSDOMAIN=DOMAIN.COM

USERDOMAIN=DOMAIN

Open Netscaler Gateway Virtual server session profile.

Go to Published applications tab and look for SSODomain field

As per the error it would be domain.com

We need to change it to domain, and save the configuration on Netscaler.

Also confirm that Storefront has either “Any” domain selected or has “domain.com” and “domain” added as trusted domain.

Related:

ScaleIO – Unable to upgrade SIO using Gateway “Could not connect to…”

Article Number: 488740 Article Version: 2 Article Type: Break Fix



ScaleIO 2.0.1,ScaleIO 2.0.0,ScaleIO 1.32.6,ScaleIO 1.32.5

Trying to upgrade ScaleIO from 1.32.x to 2.0.0.x using the Gateway/Installation Manager fails with:

Command failed: Could not connect to <IPs>. Ensure that the relevant service is running and that the server can communicate with the node.

The step that failed was at “switch to single mode”

.

User-added image

The Gateway/Installation Manager MUST be able to connect to ALL IPs on the configuration. If any IP is not reachable (ie. Managerment IP), the upgrade will fail.

In this situation, the customer was not able to communicate with the Management IPs.

Make sure that the Gateway/Installation Manager is able to communicate via ALL the IPs configured.

Related:

  • No Related Posts

NetScaler GSLB Static Proximity Does Not Work After Upgrading to 11.0/11.1 Firmware

To resolve this issue delete the nslocation.* files from the /var/netscaler/locdb/ directory and then re-run the configuration to add the location file.

root@NS-Cumulus1# cd /var/netscaler/locdb/

root@NS-Cumulus1# ls

GeoIPCountryWhois.csv GeoLite2-City-Locations-en.csv IP2LOCATION-LITE-DB1.CSV nslocation.ck nslocation.db

root@NS-Cumulus1# rm nslocation.*

> add locationfile /var/netscaler/locdb/GeoIPCountryWhois.csv -format geoip-country

Related:

How to Deploy NetScaler Appliances in a High Availability Setup in Two Arm Mode having Multiple Subnets with VLAN IDs

This article contains information about deploying NetScaler appliances in a high availability setup in two arm mode having multiple subnets with VLAN IDs.

Requirements

  • Both the NetScaler appliances must be on the same NetScaler software release version and have the same hardware platform.
  • Configure the appliances in a high availability setup. Ensure that both the appliances are communicating to each other. Refer to CTX116748 – How to Set Up a High Availability Pair on NetScaler.

Background

In this scenario, you have a requirement that NetScaler appliance must communicate with four VLANs such as 200, 201, 202, and 400, and the mode of communication must be in two arm mode.

The IP range for communication of VLAN 200, 201, 202, and 400 are 192.168.200.0/24,192.168.300.0/24,192.168.400.0/24, and 172.17.154.0/24 respectively:

  • Internal VLAN200 / 192.168.200.x
  • Internal VLAN201 / 192.168.300.x
  • Internal VLAN202 / 192.168.400.x
  • DMZ VLAN400 / 172.17.154.x

Related:

How to Enable STA Logging on the STA Servers only in XenApp Environments

This article describes how to enable Secure Ticket Authority (STA) logging on the STA servers only in XenApp environments.

Requirements

  • Secure Gateway or Access Gateway

  • Web Interface

Background

There are issues when an SSL Error is displayed to a user when attempting to launch a published application through Secure Gateway or Access Gateway (when used as a Secure Gateway replacement). Sometimes this occurs when Secure Gateway or Access Gateway has trouble performing the STA ticket validation with the STA server.

Note: Refer to the Secure Gateway or Access Gateway Administrator’s Guide for the application launch process.

To determine whether the Secure Gateway or Access Gateway is able to successfully perform the ticket validation to the STA server, detailed logging can be enabled on the STA servers.

Related:

FAQ: NetScaler Surge Queue

Q: What is NetScaler Surge queue?

A: A Surge queue is a path in the NetScaler appliance through which all client connections are sent, irrespective of the condition of the target service, such as service being loaded or service has reached the maximum connections state. When the number of requests to the servers is low, the connections are not observed in the Surge queue because the connections are sent to the servers quickly and the Surge queue build up is not observed.

Q: When connection is in Surge queue, is there a way to change the number of retries before giving up a connection (default is 7)?

A: No, this is as per design and it is not recommended to change the number of retries.

Q: What is the total maximum interval of 7 attempts of retransmit before NetScaler gives up on a connection? How long does the 7 retries take in total?

A: When there is a SYN without a response, the time is doubled for the retransmit and the time keeps doubling for every SYN without a response.

If you were to capture an nstrace for analysis then you can see the following retry pattern interval – 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds, 32 seconds, 64 seconds and then a RST is sent. This works as per exponential back off algorithm.

Q: How many connections can NetScaler surge queue handle?

A: Surge queue is essentially a list of memory buffer thus there is no hard limit and it can go on building as far as there is memory in the connection pool (NSB/PCB). Till date there is no failover or crash grade issues observed with Surge queue.

Related:

Unable to access Storefront through NetScaler Gateway and getting ” Could reach the page ” error.

– After upgrading to 12.0 build 58.15 , unable to access the Storefront server through NetScaler Gateway and getting ” Could reach the page ” error.

NOTE: On NetScaler Gateway Session profile, the Storefront URL is configured with Storefront Load balancing server IP.

– If Storefront Load balancer IP is replaced with Actual Storefront Server IP, then Storefront is accessible through NetScaler gateway.

In the following nstrace screenshot, we could see that the Storefront Load balancer has sent Export cipher in the Server Hello. For which, we could see a FATAL Error message from NetScaler gateway Vserver.

User-added image

Related:

How Do I Configure end-to-end SSL on NetScaler?

NetScaler CLI

Complete the following steps to configure end-to-end SSL on NetScaler using CLI:

  1. Enable SSL Offloading feature:

    enable ns feature ssl

  2. Add SSL based services:

    Note: The service that is configured must use SSL protocol to ensure that the backend connection is secure. If configured as HTTP service, then it will not support NetScaler to backend server security and hence it will not be an end to end SSL configuration.

    > add service servicessl1 10.102 .216.29 SSL 443

    Done

    > add service servicessl2 10.102 .216.30 SSL 443

    Done

  3. Add an SSL virtual server.

    add lb vserver vserverssl SSL 10.102.216.180 443

    Done

  4. Add a certificate-key pair:

    > add SSI certKey sslckey -cert ns -server. cert -key ns-server.key -password ssl -expiryMonitor ENABLED -notificationperiod 30

    Done

  5. Bind the SSL key pair to the SSL vserver.

    bind ssl vs vserverssl -certkeyName sslckey

    Done

  6. Bind the SSL services to the SSL virtual server.

    > bind 1b vserver vserverssl servicessl1

    Done

    > bind 1b vserver vserverssl servicessl2

    Done

NetScaler GUI

Complete the following steps to configure end-to-end SSL on NetScaler using GUI:

  1. Enable SSL Offloading feature.

    Go to System > Settings > Configure Basic Features > check SSL Offloading.

    Note: Ensure that load balancing is checked as well.

    User-added image

  2. Add SSL based services.

    Note: The service that is configured must use SSL protocol to ensure that the backend connection is secure. If configured as HTTP service, then it will not support NetScaler to backend server security and hence it will not be an end to end SSL configuration.

    Go to Traffic Management > Load Balancing > Services > Add.

    User-added image

  3. Add an SSL virtual server.

    Go to Traffic Management > Load Balancing > Virtual Servers > Add.

    User-added image

  4. Add a certificate-key pair.

    On NetScaler GUI: Go to Traffic Management > SSL > Certificates > Install.

    User-added image

  5. Bind the SSL key pair to the SSL vserver.

    Go to Traffic Management > Load Balancing > Virtual Servers > select the virtual server you wish to bind the certificate to > Edit > Certificates > Server Certificates > select the certificate you wish to bind to the virtual server > Bind.

    User-added image

    User-added image

    User-added image

    User-added image

  6. Bind the SSL services to the SSL virtual server.

    Go to Traffic Management > Load Balancing > Virtual Servers > select the virtual server you wish to bind the services to > Edit > Service Binding > select the services to be bound to virtual server > Bind.

    User-added image

For additional configuration details refer to Citrix Documentation – Configuring SSL Offloading.

Additional/Optional Configuration Steps

There are two additional key features on backend SSL which you can configure:

  • Performing server certificate authentication on NetScaler by enabling it on NetScaler.
  • Sending client certificate to the backend sever for authentication.

Server Certificate Authentication on NetScaler

The server certificate authentication can be enabled on a NetScaler SSL service when the NetScaler wants to verify that the certificate sent by the backend server is for the same hostname as requested by the client.

Go to Traffic Management > Load Balancing > Services > select the SSL service on which you wish to enable Server Certificate Authentication > Edit > SSL Parameters > check Enable Server Authentication.

User-added image

Sending Client Certificate to the Backend Server

Usually this option need not be enabled if NetScaler and Server reside in the same secure zone. If not the case, then this option can be enabled for additional security. The bound Client Certificate would be sent to the backend sever when the server demands a certificate from the client (in this case NetScaler) to authenticate its identity.

Go to Traffic Management > Load Balancing > Services > select the SSL service on which you wish to enable Server Certificate Authentication > Edit > Certificates > Client Certificates.

User-added image

User-added image

Related:

How to Configure Double Hop on NetScaler

  • Under Published Applications, you have to add the second hop NetScaler under Next Hop Servers with Port as 443 and Secure checked.

    The moment you configure Next Hop, this NetScaler will understand that it is the first NetScaler in the double hop environment. Also the STA needs to be configured on the first hop NetScaler.

    Note: The Secure Ticketing Authority (STA) will show as down until you configure the second hop NetScaler because until then the connection will not be proxied.

    Note2: After configuring the Second Hop Gateway, if the STAs still show as down, add a route on the Second Hop appliance to the SNIP of the First Hop, to ensure both SNIP (First Hop) and Gateway VIP (Second Hop) can reach one another

    User-added image

  • Related: