Our first release of Framehawk has been getting a lot of positive feedback in the forums.
This month, support was extended to remote mobile users with the release of NetScaler Gateway 11.0.62, and the new 6.0 release of Citrix Receiver for iOS added Framehawk support.
Check out the latest Framehawk administrator guide for updated instructions.
Framehawk uses UDP for executing much of its magic, which works a bit differently from the TCP world we Citri-xens (yes, I just made that word up) are used to.
Thought I’d collect some of the quick and dirty tips and tricks learned in the field, to help accelerate Framehawk proof-of-concept tests. I’ll keep updating this page as we learn more, but feel free to add your own tips in the comments (that’s what community is for!)
Standard disclaimer before we continue: Citrix does not provide any support or guarantee for the use of tools mentioned in this article. These steps must not be carried out in production environment, unless instructed by Citrix Support to do so.
1. Verifying on the end-point that Framehawk is being used
Typically the protocol is invisible to the end user, as all they rightly care about is the user experience. The DisplayStateGUI.exe may be useful for admins in early demos, to make sure they got the settings right. In its initial release, Framehawk will kick in only if certain requirements are met, as outlined in the administrator’s guide. Citrix engineering developed this small utility for their internal use, that exposes the protocol information at the end point. It runs a banner on Windows end-point containing the state of display channel, either Thinwire or Framehawk (shown as “LFP”).
The more official way to extract this information is using session details in Director, where a new metric (“Graphics – Framehawk”) has been added to the HDX statistics:
So, here’s where you can download the tool, provided for use as-is without any warranty or support, to help your non-production evaluation: DisplayStateGUI.exe
2. Verifying Framehawk functionality on the VDA
Another quick tip is to run a command to validate that settings to enable Framehawk were applied on the virtual machine (where VDA is installed). You are looking for these two pieces of information in the result:
- Component_Provider = VD3D
- IsActive = Active
Use the following command line inputs (CLI) on the VDA to verify that the Framehawk channel is active
- Launch a command prompt (as an administrator) on the VDA.
- Enter wmic on the command line, and press Enter.
- Enter /NAMESPACE:\\root\citrix\hdx, and press Enter.
- Enter path citrix_virtualchannel_framehawk_enum get /VALUE, and press Enter
- Verify that Framehawk-specific data (mentioned above) is returned.
3. Using IPerf to verify Framehawk ports are available across Firewalls
Another Disclaimer: iPerf is an opensource tool, freely available on the Internet. Additional information about IPerf (including binaries and documentation) can be found here. Citrix does not provide any support or guarantee for the use of this tool in production environments.
IPerf is commonly used by network admins to verify network connectivity and performance under load. In this case, it is useful to confirm the connectivity between Citrix clients and server is available on the defined UDP ports, especially in the presence of firewalls. Framehawk uses ports 3224 to 3324 by default (this can be changed in policy). For remote access with NetScaler, port UDP 443 needs to be open on any external firewall to allow secure transport of datagrams. IPerf is run on two machines, one each at either end of a network. For the purposes of simulating Framehawk UDP traffic, we recommend running the IPerf server mode on VDA and directing UDP traffic to the remote client (with Citrix Receiver) outside the firewall network running IPerf in client mode. If the connection fails, it is time to follow up with the network and security teams to help open firewall ports.
Using IPerf to verify Framehawk port availability:
1. Download and install IPerf on the both test machines.
2. Run IPerf in server mode on the VDA (referred to as “listening” mode):
C:\>Iperf –s -p (PORT)
3. Run IPerf in client mode on the machine where Citrix Receiver is installed (referred to as “sending” mode), with -u switch for UDP:
C:\>Iperf –c (IPAddress) –p (PORT) –u –b (SIZE)m –l (MTU) –t (SECONDS)
The sample below illustrates the output where UDP port was available:
c:\Temp\iperf-2.0.5-3-win32>iperf -c 54.204.250.164 -p 3222 -u -b 6m -l 1440 –t 10
————————————————————
Client connecting to 54.204.250.164, UDP port 3222
Sending 1440 byte datagrams
UDP buffer size: 63.0 KByte (default)
————————————————————
[ 3] local 192.168.1.101 port 53235 connected with 54.204.250.164 port 3222
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 7.15 MBytes 6.00 Mbits/sec
[ 3] Sent 5210 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 7.15 MBytes 5.99 Mbits/sec 2.689 ms 0/ 5209 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
The sample below illustrates the output where UDP port was blocked by the firewall:
c:\Temp\iperf-2.0.5-3-win32>iperf -c 54.204.250.164 -p 3222 -u -b 6m -l 1440 –t 10
————————————————————
Client connecting to 54.204.250.164, UDP port 3222
Sending 1440 byte datagrams
UDP buffer size: 63.0 KByte (default)
————————————————————
[ 3] local 192.168.1.101 port 58947 connected with 54.204.250.164 port 3222
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 7.15 MBytes 6.00 Mbits/sec
[ 3] Sent 5210 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
Other considerations for successful demos and evaluation
Avoid these common missteps to make your Framehawk evaluation in a lab environment successful. In a real WAN environment, you would not run into these situations in most cases. They are more relevant to simulated WAN (using some sort of WAN emulator to produce the loss and latency).
Consider the following best practices:
- Set the bandwidth and latency on the network emulator before making a connection.
- Disconnect and reconnect the session every time you change the bandwidth, packet loss, or latency, to allow new calibration by the protocol during handshake.
- Do not cap the bandwidth on WAN emulator. Emulators rarely replicate the opportunity for momentary spikes that are allowed in real WAN. Uncapped bandwidth will demonstrate a more realistic user experience, and average bandwidth will automatically limit itself.
- On the iOS, turn off Auto-rotate and Auto-fit. Use in landscape mode for the best experience.
Note: The Framehawk virtual channel does not currently recalibrate in-session if latency or bandwidth changes are observed.
Share your experiences
We’d love to hear from you on the innovative use-cases that are now possible thanks to Framehawk. This is a first release of the new HDX protocol and will evolve significantly based on community and customer feedback. Keep sharing your experiences, tip and tricks, and questions in the discussion forum to help others with the collective wisdom.
