1Y0-241 · Question #134
Which NetScaler service monitor can a Citrix Administrator use to test the three-way handshake between the NetScaler and the backend server?
The correct answer is D. TCP. The TCP service monitor verifies the TCP three-way handshake (SYN, SYN-ACK, ACK) with the backend server. PING uses ICMP (no handshake), UDP is connectionless, and LDAP is an application-layer check.
Question
Which NetScaler service monitor can a Citrix Administrator use to test the three-way handshake between the NetScaler and the backend server?
Options
- APING
- BLDAP
- CUDP
- DTCP
How the community answered
(20 responses)- A10% (2)
- B5% (1)
- D85% (17)
Explanation
The TCP service monitor verifies the TCP three-way handshake (SYN, SYN-ACK, ACK) with the backend server. PING uses ICMP (no handshake), UDP is connectionless, and LDAP is an application-layer check.
Topics
Community Discussion
6TCP is your answer. The TCP monitor is specifically designed to verify the three-way handshake (SYN, SYN-ACK, ACK) between the NetScaler and the backend server, which is exactly what the question is testing, while PING only checks ICMP reachability and UDP has no handshake process at all.
The PING monitor only sends ICMP echo requests, which trips up a lot of people because it does confirm the server is reachable, but reachable is not the same as accepting TCP connections on the service port. TCP is the monitor that actually completes the three-way handshake (SYN, SYN-ACK, ACK) with the backend, so D is your answer and it is the one NetScaler uses by default for most service types.
TCP is your answer here, D, because the three-way handshake, SYN, SYN-ACK, ACK, is literally a TCP thing, so the monitor that tests it has to be TCP. I know PING looks tempting because it feels like the most basic connectivity check, but PING uses ICMP and never does a handshake at all, it just sends echo requests and waits for a reply, so it tells you the host is reachable but not whether the service port is actually accepting connections. UDP is connectionless by design so there is no handshake to speak of, and LDAP is an application-layer monitor for directory services specifically. The question is asking about layer 4 transport behavior, and TCP is the only monitor in that list that actually opens a full connection to the backend port and completes the handshake before marking the service UP.
Right call on TCP, Luis, just worth adding that some load balancers let you configure TCP monitors to do a half-open check, SYN only with no ACK sent back from the client side, which is faster at scale but technically never completes the full three-way handshake, so knowing what your specific platform does matters for exam questions that ask about health check behavior versus strict handshake completion.
TCP is the right call here because it is literally the protocol that performs the three-way handshake (SYN, SYN-ACK, ACK), so the TCP monitor exists specifically to verify that full connection establishment between the NetScaler and the backend service, not just layer 3 reachability like PING does. Quick question though, when you set up the TCP monitor in your labs were you binding it to a specific port on the service, and did you notice any difference in how fast it detected a downed backend compared to leaving it on the default PING monitor?
Yep, binding to the specific service port is key because otherwise the TCP monitor might succeed on a port that has nothing to do with your actual app and give you a false healthy status, which defeats the whole purpose of using TCP over PING in the first place.