Basic Administration For NetScaler 9.2

Bas|c Adm|n|strat|on for O|tr|x
NetSca|er 9.2
ONS-203-3l
Bas|c Adm|n|strat|on for
O|tr|x NetSca|er 9.2
ONS-203-3l
Ju|y 2011
vers|on 3.0
Tab|e of Oontents
Modu|e Modu|e 1: 1: lntroduct|on lntroduct|on and and Course Course Overv|ew Overv|ew ............................................... ............................................... 19 19
Overv|ew ............................................................................................................................... 21
Student lntroduct|ons ....................................................................................................... 21
Fac|||t|es ............................................................................................................................ 21
Oourse Mater|a|s ............................................................................................................... 21
Oourse Prerequ|s|tes ......................................................................................................... 22
Oourse Out||ne - Day One ..................................................................................................... 23
Oourse Out||ne - Day Two .................................................................................................... 24
Oourse Out||ne - Day Three .................................................................................................. 25
Oourse Out||ne - Day Four .................................................................................................... 26
Oourse Out||ne - Day F|ve ..................................................................................................... 27
O|tr|x Educat|on .................................................................................................................... 28
Oourse Eva|uat|on and Oomp|et|on Oert||cate ...................................................................... 31
Modu|e Modu|e 2: 2: lntroduc|ng lntroduc|ng and and Dep|oy|ng Dep|oy|ng C|tr|x C|tr|x NetSca|er NetSca|er .................................. .................................. 33 33
Overv|ew ............................................................................................................................... 35
lntroduct|on to the NetSca|er System ................................................................................... 36
NetSca|er Funct|ona||ty ..................................................................................................... 36
P|ann|ng a NetSca|er Dep|oyment ......................................................................................... 37
Dep|oyment Scenar|os .......................................................................................................... 39
Product Features .................................................................................................................. 43
|ower Tota| Oost o Ownersh|p ........................................................................................ 43
App||cat|on Acce|erat|on .................................................................................................... 44
App||cat|on Secur|ty .......................................................................................................... 44
App||cat|on Ava||ab|||ty ....................................................................................................... 45
S|mp|e Manageab|||ty ........................................................................................................ 46
Web 2.0 Opt|m|zat|on ....................................................................................................... 48
Hardware P|atorms .............................................................................................................. 50
NetSca|er MP 21500/19500/17500/17000 ..................................................................... 50
NetSca|er MP 15500/15000/12500/10500 ..................................................................... 51
NetSca|er MP 9500/ 9010 FlPS/MP 7500/5500/vP 10/200/1000 ............................. 53
nOore ................................................................................................................................ 55
NetSca|er vP .................................................................................................................. 55
Hardware Oomponents ........................................................................................................ 57
Network and Ser|a| lnteraces ........................................................................................... 57
|OD .................................................................................................................................. 57
F||e System ....................................................................................................................... 57
NetSca|er Arch|tecture Overv|ew ........................................................................................... 59
|ogg|ng |n to the NetSca|er System ...................................................................................... 60
Rev|ew .................................................................................................................................. 61
Copyr|ght 2011 C|tr|x Systems, lnc. 3
Modu|e Modu|e 3: 3: Network|ng Network|ng .................................................................................. .................................................................................. 63 63
Overv|ew ............................................................................................................................... 65
NetSca|er Arch|tecture Overv|ew ........................................................................................... 66
Oonnect|on Separat|on ..................................................................................................... 66
Bas|c NetSca|er System Network|ng Ru|es ....................................................................... 66
Mu|t|p|ex|ng ....................................................................................................................... 67
NetSca|er-Owned lP Addresses ........................................................................................... 69
NetSca|er lP Address ........................................................................................................ 69
Subnet lP Address ............................................................................................................ 70
Mapped lP Address .......................................................................................................... 71
v|rtua| lP Address ............................................................................................................. 72
NetSca|er Modes .................................................................................................................. 73
|ayer-3 Mode ................................................................................................................... 73
Oon|gur|ng |ayer-3 Mode ................................................................................................ 73
|ayer-2 Mode ................................................................................................................... 74
|ayer-2 Mode Oons|derat|ons ........................................................................................... 74
Oon|gur|ng |ayer 2 Mode ................................................................................................ 75
|ayer-2 Mode w|th |ayer-3 Mode ..................................................................................... 75
MAO-Based Forward|ng Mode ......................................................................................... 76
Send|ng a O||ent lP Address to Servers ............................................................................ 76
O||ent-lP HTTP Header lnsert|on ....................................................................................... 76
se Source lP Mode ........................................................................................................ 78
Oon|gur|ng SlP Mode .................................................................................................... 79
Network Address Trans|at|on ................................................................................................ 80
lnbound Network Address Trans|at|on .............................................................................. 80
Reverse Network Address Trans|at|on RNAT} .................................................................. 80
lP Addresses or RNAT ..................................................................................................... 81
RNAT Examp|e ................................................................................................................. 81
Oon|gur|ng Reverse Network Address Trans|at|on ........................................................... 82
v|rtua| |oca| Area Networks .................................................................................................. 84
Tagged v|ANs ................................................................................................................. 84
v|ANs and Tagg|ng w|th NetSca|er vP ........................................................................... 85
Oon|gur|ng v|ANs ........................................................................................................... 86
||nk Aggregat|on ................................................................................................................... 88
Oon|gur|ng |AOP Manua||y ............................................................................................. 89
Oon|gur|ng ||nk Aggregat|on w|th |AOP .......................................................................... 90
lnternet Oontro| Message Protoco| ....................................................................................... 91
Path MT D|scovery ............................................................................................................. 92
Dynam|c Rout|ng Support and Route Hea|th lnject|on .......................................................... 94
Rev|ew .................................................................................................................................. 95
Modu|e Modu|e 4: 4: Con|gur|ng Con|gur|ng H|gh H|gh Ava||ab|||ty Ava||ab|||ty ......................................................... ......................................................... 97 97
Overv|ew ............................................................................................................................... 99
lntroduct|on to H|gh Ava||ab|||ty ........................................................................................... 100
H|gh Ava||ab|||ty Funct|ona||ty ........................................................................................... 100
H|gh Ava||ab|||ty Node Oon|gurat|on ................................................................................... 102
4 Copyr|ght 2011 C|tr|x Systems, lnc.
Pre-Oon|gurat|on Oheck||st ............................................................................................ 102
v|rtua| Med|a Access Oontro| Address ............................................................................ 102
Oon|gur|ng Pr|mary and Secondary Nodes .................................................................... 103
H|gh-Ava||ab|||ty Status .................................................................................................... 103
Propagat|on and Synchron|zat|on ....................................................................................... 105
D|sab||ng Oommand Propagat|on ................................................................................... 105
Automat|c Oon|gurat|on Synchron|zat|on ........................................................................ 106
Forced Synchron|zat|on .................................................................................................. 106
Perorm|ng a Forced Fa||over .......................................................................................... 107
H|gh Ava||ab|||ty Management ............................................................................................. 108
pgrad|ng a H|gh Ava||ab|||ty Pa|r .................................................................................... 108
Rev|ew ................................................................................................................................ 109
Modu|e Modu|e 5: 5: Secur|ng Secur|ng the the NetSca|er NetSca|er System System ................................................. ................................................. 111 111
Overv|ew ............................................................................................................................. 113
NetSca|er System Oommun|cat|on ..................................................................................... 114
NetSca|er Oommun|cat|on Types .................................................................................... 114
Secur|ty Parameter Oomponents .................................................................................... 116
Access Oontro| ||sts ........................................................................................................... 117
S|mp|e Access Oontro| ||sts ........................................................................................... 117
Match|ng Access Oontro| ||st Entr|es .............................................................................. 117
Tra|c ldent||cat|on ......................................................................................................... 118
Access-Oontro|-||st Syntax Format and Precedence ...................................................... 119
Access-Oontro|-||sts Precedence ................................................................................... 119
lPv6-Based Access-Oontro|-||st Support ....................................................................... 119
Access-Oontro|-||st Oon|gurat|on ...................................................................................... 120
S|mp|e Access-Oontro|-||st Oon|gurat|on Oommand-||ne lnterace} ............................. 120
Oon|gur|ng Deta||ed Access Oontro| ||sts Oommand-||ne lnterace} ............................. 121
Oreat|ng and Remov|ng Access Oontro| ||sts Oommand-||ne lnterace} ........................ 121
App|y|ng Access Oontro| ||sts Oommand-||ne lnterace} ............................................... 122
v|ew|ng Access Oontro| ||sts Oommand-||ne lnterace} ................................................. 122
Access-Oontro|-||st Pr|or|t|es Oommand-||ne lnterace} ................................................. 123
Remov|ng Access Oontro| ||sts rom the System Oommand-||ne lnterace} .................. 123
Access-Oontro|-||st Syntax Format or D|erent NetSca|er vers|ons ............................... 123
Access-Oontro|-||st Examp|e .......................................................................................... 124
Rev|ew ................................................................................................................................ 125
Modu|e Modu|e 6: 6: Con|gur|ng Con|gur|ng |oad |oad Ba|anc|ng Ba|anc|ng ....................................................... ....................................................... 127 127
Overv|ew ............................................................................................................................. 129
Ent|ty Management ............................................................................................................. 130
Oreat|ng Servers ............................................................................................................. 131
Oreat|ng Serv|ces ............................................................................................................ 131
Oreat|ng v|rtua| Servers .................................................................................................. 132
Mon|tors .......................................................................................................................... 133
|oad-Ba|anc|ng Tra|c Types ............................................................................................. 134
Serv|ce Mon|tor|ng .............................................................................................................. 135
Deau|t Mon|tors ............................................................................................................. 135
Mon|tor Parameters ........................................................................................................ 136
Oreat|ng Mon|tors .......................................................................................................... 138
HTTP Mon|tor|ng ............................................................................................................. 139
EOv Mon|tor|ng ............................................................................................................... 139
HTTP-EOv and TOP-EOv Mon|tor|ng Process ................................................................ 140
HTTP-lN|lNE Parameters ............................................................................................... 140
Reverse Oond|t|on Mon|tor|ng ......................................................................................... 141
Sett|ng Mon|tor Thresho|ds ............................................................................................. 141
|oad-Ba|anc|ng Topo|ogy ................................................................................................... 143
|oad-Ba|anc|ng Methods .................................................................................................... 144
Serv|ce We|ghts .............................................................................................................. 146
Sess|on Pers|stence ........................................................................................................ 147
Non-Pers|stent O||ents .................................................................................................... 147
Pers|stence Methods ...................................................................................................... 147
Pers|stence Tab|es .......................................................................................................... 151
Add|t|ona| |oad-Ba|anc|ng Opt|ons ..................................................................................... 152
Advanced |oad-Ba|anc|ng Methods ................................................................................... 154
Token ............................................................................................................................. 154
Token-based |oad-Ba|anc|ng Examp|e 1 ....................................................................... 154
Token-based |oad-Ba|anc|ng Examp|e 2 ....................................................................... 155
Hash |oad-Ba|anc|ng ...................................................................................................... 155
||nk |oad Ba|anc|ng ........................................................................................................... 159
||nk |oad-Ba|anc|ng Po||cy ............................................................................................. 159
Oustom |oad ...................................................................................................................... 160
|oad Mon|tor Process ........................................................................................................ 161
|oad Mon|tor Parameters ............................................................................................... 161
B|nd|ng Metr|cs .............................................................................................................. 163
Serv|ce and v|rtua| Server Management ............................................................................. 165
Serv|ce and v|rtua| Stat|st|cs ........................................................................................... 166
Mon|tor|ng Tra|c D|str|but|on .......................................................................................... 168
|oad Ba|anc|ng v|sua||zer ................................................................................................... 169
Rev|ew ................................................................................................................................ 170
Modu|e Modu|e 7: 7: Con|gur|ng Con|gur|ng SS| SS| O|oad O|oad ............................................................ ............................................................ 171 171
Overv|ew ............................................................................................................................. 173
SS| and D|g|ta| Oert||cates ................................................................................................. 174
lmportant Ooncepts ............................................................................................................ 175
SS| O|oad Overv|ew ......................................................................................................... 177
O|oad Perormance ........................................................................................................... 178
Features and Bene|ts ..................................................................................................... 178
SS| Adm|n|strat|on ............................................................................................................. 180
SS| Sess|on Process ..................................................................................................... 180
SS| Keys ........................................................................................................................ 182
Generat|ng a Oert||cate S|gn|ng Request ........................................................................ 182
SS| Oert||cates .............................................................................................................. 183
Oert||cate Key Pa|rs ........................................................................................................ 184
SS| O|oad ........................................................................................................................ 186
SS| Term|nat|on Po|nts .................................................................................................. 186
Dep|oyment Scenar|os ........................................................................................................ 188
Front-end SS| w|th Back-end HTTP Requ|rements ........................................................ 188
Secur|ng Tra|c Between a O||ent and the NetSca|er System ......................................... 189
Front-end SS| w|th Back-end SS| Requ|rements .......................................................... 190
Secur|ng Tra|c Between the NetSca|er and the Server .................................................. 190
Front-end SS|_TOP w|th Back-end TOP Requ|rements ................................................. 191
Secur|ng TOP Tra|c Between a O||ent and the NetSca|er System .................................. 191
SS|_Br|dge ..................................................................................................................... 192
SS|_Br|dge Requ|rements .............................................................................................. 192
Oon|gur|ng SS| O|oad ..................................................................................................... 193
Oreat|ng and B|nd|ng SS| v|rtua| Server ............................................................................. 194
Advanced SS| Sett|ngs ...................................................................................................... 195
SS| Red|rect .................................................................................................................. 195
SS|v2 Protoco| and Red|rect .......................................................................................... 195
Oon|gur|ng Advanced Sett|ngs ....................................................................................... 196
Rev|ew ................................................................................................................................ 197
Modu|e Modu|e 8: 8: Con|gur|ng Con|gur|ng G|oba| G|oba| Server Server |oad |oad Ba|anc|ng Ba|anc|ng ................................. ................................. 199 199
Overv|ew ............................................................................................................................. 201
GS|B Ooncepts ................................................................................................................. 202
GS|B Oonversat|on Process .......................................................................................... 203
GS|B Ent|t|es ................................................................................................................. 204
Metr|c Exchange Protoco| ................................................................................................... 206
Metr|c lnormat|on Types ................................................................................................ 206
GS|B Mon|tor|ng Oon|gurat|on ...................................................................................... 206
GS|B DNS Methods .......................................................................................................... 208
Author|tat|ve DNS Serv|ce ............................................................................................... 208
Name Servers ................................................................................................................. 209
Externa| DNS Server Examp|e ......................................................................................... 210
DNS Proxy Oon|gurat|on ................................................................................................ 211
DNS Request Scenar|os ................................................................................................. 211
Resource Records .......................................................................................................... 212
GS|B Pers|stence .............................................................................................................. 213
Oon|gur|ng DNS v|rtua| Servers ......................................................................................... 214
GS|B Oon|gurat|ons .......................................................................................................... 215
lmp|ement|ng Trad|t|ona| GS|B ........................................................................................... 216
lmp|ement|ng Prox|m|ty-based GS|B ................................................................................. 217
Prox|m|ty-Based |oad-Ba|anc|ng Methods ..................................................................... 217
lmp|ement|ng GS|B Fa||over or D|saster Recovery ............................................................ 219
GS|B Ent|ty Re|at|onsh|p .................................................................................................... 220
Oon|gur|ng GS|B v|rtua| Servers ................................................................................... 220
Oon|gur|ng ADNS ........................................................................................................... 221
Synchron|z|ng a GS|B Oon|gurat|on ............................................................................. 221
GS|B S|te Oommun|cat|on Examp|e ................................................................................... 222
Rev|ew ................................................................................................................................ 223
Modu|e Modu|e 9: 9: s|ng s|ng AppExpert AppExpert C|ass|c C|ass|c to to Opt|m|ze Opt|m|ze Tra|c Tra|c .............................. .............................. 225 225
Overv|ew ............................................................................................................................. 227
Po||cy Overv|ew .................................................................................................................. 228
Po||cy Bas|cs ...................................................................................................................... 229
Bas|c Po||cy Oomponents ............................................................................................... 229
Advanced Po||cy ses .................................................................................................... 230
Po||cy B|nd|ngs ............................................................................................................... 231
Po||cy Pr|or|t|es ............................................................................................................... 231
Hypertext Transer Protoco| ................................................................................................ 233
HTTP Request Headers .................................................................................................. 233
HTTP Response Headers ............................................................................................... 234
HTTP Header Sett|ngs .................................................................................................... 235
Express|on Structures ......................................................................................................... 236
Ava||ab|e Qua|||ers or HTTP Tra|c ................................................................................. 236
Ava||ab|e Qua|||ers or Non-HTTP Tra|c ......................................................................... 237
Ava||ab|e Operators ......................................................................................................... 237
W||dcards ........................................................................................................................ 238
Oontext-Sens|t|ve F|e|ds .................................................................................................. 239
S|mp|e Express|ons ......................................................................................................... 239
Oompound Express|ons .................................................................................................. 240
Oontent F||ter|ng ................................................................................................................. 241
Oontent F||ter|ng Act|ons ................................................................................................. 241
Oontent F||ter|ng Ru|es .................................................................................................... 241
ser-De|ned F||ter Act|ons .............................................................................................. 242
lntroduct|on to Oompress|on .............................................................................................. 244
Oompress|on Process ..................................................................................................... 244
Oompress|on Oons|derat|ons .......................................................................................... 244
Oompress|on Responses ................................................................................................ 245
Oompress|on Parameters ............................................................................................... 245
Oompress|on Po||c|es ..................................................................................................... 247
Oompress|on Act|ons ...................................................................................................... 247
Rev|ew Quest|ons ............................................................................................................... 249
Modu|e Modu|e 10: 10: s|ng s|ng AppExpert AppExpert or or Responder, Responder, Rewr|te Rewr|te and and R| R| Transorm Transorm .. 251 251
Overv|ew ............................................................................................................................. 253
nderstand|ng Packet Process|ng F|ow .............................................................................. 254
nderstand|ng Po||c|es ....................................................................................................... 255
Po||cy Process Eva|uat|on F|ow ....................................................................................... 255
ldent|y|ng Advanced Po||cy Express|ons ......................................................................... 256
Advanced Po||cy Express|on Syntax ............................................................................... 256
Act|ons ............................................................................................................................... 258
Act|on Syntax ................................................................................................................. 258
nderstand|ng B|nd Po|nts ................................................................................................. 259
Po||cy B|nd|ng Eva|uat|on Process .................................................................................. 259
s|ng the Po||cy Manager ............................................................................................... 259
Po||cy Manager Oont|nued .............................................................................................. 260
nderstand|ng Po||cy |abe|s ........................................................................................... 260
Oon|gur|ng Po||cy |abe|s ................................................................................................ 260
s|ng Pattern Sets .............................................................................................................. 262
Typecast|ng ........................................................................................................................ 263
Rewr|te, Responder, and R| Transormat|on .................................................................... 264
Transormed E|ements .................................................................................................... 265
ldent|y|ng Packet Process|ng F|ow ..................................................................................... 267
Rewr|te Process ............................................................................................................. 267
Responder Process ........................................................................................................ 268
R| Transormat|on Process .......................................................................................... 269
Oon|gur|ng Po||c|es and Act|ons ......................................................................................... 270
Oon|gur|ng Rewr|te Act|ons ................................................................................................ 271
lnsert|ng and Rep|ac|ng HTTP Headers .......................................................................... 271
De|et|ng HTTP Headers .................................................................................................. 272
lnsert|ng HTTP Headers .................................................................................................. 272
De|et|ng Request Oontent ............................................................................................... 273
Rep|ac|ng Response Oontent ......................................................................................... 274
Bu||t-ln Rewr|te Act|ons ................................................................................................... 274
Rewr|te Po||c|es .................................................................................................................. 276
B|nd|ng Po||c|es .............................................................................................................. 276
Responder Act|ons ............................................................................................................. 278
RespondW|th .................................................................................................................. 278
Bu||t-ln Responder Act|ons ............................................................................................. 279
Responder Po||c|es ............................................................................................................. 280
Oon|gur|ng R| Transormat|on ......................................................................................... 281
R| Transormat|on Oon|gurat|on Procedure ................................................................. 281
Oon|gur|ng R| Transormat|on Act|ons ........................................................................ 281
Rev|ew Quest|ons ............................................................................................................... 283
Modu|e Modu|e 11: 11: s|ng s|ng AppExpert AppExpert or or Content Content Sw|tch|ng Sw|tch|ng ................................... ................................... 285 285
Overv|ew ............................................................................................................................. 287
lntroduct|on to Oontent Sw|tch|ng ....................................................................................... 288
Oontent Sw|tch|ng Based on |ayer Oharacter|st|cs ......................................................... 288
nderstand|ng Oontent Sw|tch|ng ................................................................................... 288
Oontent-Sw|tch|ng v|rtua| Servers and |oad-Ba|anc|ng v|rtua| Servers ........................... 289
Oon|gur|ng Oontent-Sw|tch|ng v|rtua| Servers .................................................................... 291
Oontent-Sw|tch|ng Po||c|es ............................................................................................. 292
B|nd|ng Oontent-Sw|tch|ng Po||c|es ................................................................................. 292
Ru|e-Based Po||cy Examp|e ................................................................................................ 293
Oontent-Sw|tch|ng Ru|e Precedence W|thout Pr|or|ty Spec||ed ...................................... 293
Oontent-Sw|tch|ng Ru|e Precedence W|th Pr|or|ty Spec||ed ........................................... 294
nmatched Tra|c Hand||ng ............................................................................................ 294
Rev|ew ................................................................................................................................ 295
Modu|e Modu|e 12: 12: s|ng s|ng AppExpert AppExpert Advanced Advanced to to Opt|m|ze Opt|m|ze Tra|c Tra|c ....................... ....................... 297 297
Overv|ew ............................................................................................................................. 299
Oompress|on w|th Advanced Po||cy Express|ons ................................................................ 300
Sett|ng Oompress|on Po||c|es G|oba||y ............................................................................ 300
Oon|gur|ng Oompress|on ............................................................................................... 301
lntegrated Oach|ng ............................................................................................................. 302
Reverse-Proxy-Oache Oon|gurat|on ............................................................................... 302
Oontent Groups .............................................................................................................. 303
Oache Se|ectors and Po||c|es ......................................................................................... 304
Oach|ng Stat|c and Dynam|c Oontent ............................................................................. 304
Dynam|c Oontent ............................................................................................................ 304
Oache Act|ons ................................................................................................................ 305
Request and Response Process F|ow ............................................................................ 306
Oache Po||c|es and Oache Express|ons .............................................................................. 308
Oache Po||c|es ................................................................................................................ 308
B|nd|ng Oache Po||c|es ................................................................................................... 309
Oache Po||cy Eva|uat|on .................................................................................................. 309
Eva|uat|on Order ............................................................................................................. 310
Bu||t-ln Po||c|es ............................................................................................................... 311
Graceu| Oache Oon|gurat|on Ohanges .............................................................................. 312
Oache Oontent Groups ....................................................................................................... 313
Reversed Oontent Group Names .................................................................................... 313
Oache Oontent Ag|ng ......................................................................................................... 314
Oontent Group Sett|ngs ...................................................................................................... 315
HTTP Headers and Oontent Group Sett|ngs ................................................................... 315
Oook|e Remova| ............................................................................................................. 316
Other Oontent Group Attr|butes ...................................................................................... 316
F|ashOache ......................................................................................................................... 317
G|oba| Oache Attr|butes ...................................................................................................... 318
Oache Arguments ........................................................................................................... 318
ver|ys|ng Argument ...................................................................................................... 319
HOSTNAME Sett|ng ........................................................................................................ 319
Oach|ng Management ........................................................................................................ 320
AppExpert Temp|ates ........................................................................................................ 321
s|ng AppExpert Temp|ates ........................................................................................... 321
s|ng the App||cat|on lnterace ....................................................................................... 321
App||cat|ons Pane ........................................................................................................... 322
App||cat|ons Pane: App||cat|on n|ts ............................................................................... 323
AppExpert Temp|ate Sca|ab|||ty ....................................................................................... 324
P|ann|ng or App||cat|ons ................................................................................................ 324
Term|no|ogy .................................................................................................................... 325
Methodo|ogy ................................................................................................................... 325
App||cat|on Examp|e: Part 1 ............................................................................................ 326
App||cat|on Examp|e: Part 2 ............................................................................................ 326
AppExpert Temp|ate Dep|oyment ................................................................................... 327
Po||cy-Based Rout|ng ......................................................................................................... 329
Po||cy-Based Rout|ng Parameters ................................................................................... 329
Po||cy-Based Act|on Oon|gurat|on .................................................................................. 329
Rev|ew ................................................................................................................................ 331
Modu|e Modu|e 13: 13: Management Management ........................................................................... ........................................................................... 333 333
Overv|ew ............................................................................................................................. 335
S|mp|e Network Management Protoco| ............................................................................... 336
Managed Dev|ces ........................................................................................................... 336
SNMP Agents ................................................................................................................. 336
Managers ........................................................................................................................ 337
Management lnormat|on Base ...................................................................................... 337
Oommun|ty Str|ngs ......................................................................................................... 338
Traps .............................................................................................................................. 338
Oon|gur|ng SNMPv1 and SNMPv2 ................................................................................. 339
Oon|gur|ng SNMP Managers ......................................................................................... 340
Oon|gur|ng MlB System var|ab|es .................................................................................. 341
Oon|gur|ng Oommun|ty Str|ngs ...................................................................................... 341
Oon|gur|ng SNMP Traps ................................................................................................ 343
Oon|gur|ng A|arms ......................................................................................................... 344
SNMPv3 ............................................................................................................................. 345
SNMPv3 Oomponents .................................................................................................... 345
Dashboard .......................................................................................................................... 347
System and Feature Oounters ........................................................................................ 347
Dashboard Oomponents ................................................................................................. 348
Nav|gat|ng the Dashboard .............................................................................................. 349
Report|ng and Mon|tor|ng Too|s .......................................................................................... 352
Aud|t|ng and |ogg|ng .......................................................................................................... 353
Oon|gur|ng an Aud|t|ng Server ........................................................................................... 354
G|oba| Aud|t|ng Parameters ................................................................................................ 355
Oon|gur|ng Aud|t|ng Po||c|es ............................................................................................... 356
B|nd|ng Aud|t|ng Po||cy .................................................................................................. 356
Aud|t Messages .............................................................................................................. 357
NetSca|er |og Management ............................................................................................... 358
Rep|ac|ng a H|gh-Ava||ab|||ty Node ...................................................................................... 359
Perorm|ng an pgrade ...................................................................................................... 360
Password Recovery ............................................................................................................ 362
Network Tra|c Oapture s|ng NSTOPDMP ..................................................................... 363
Network Tra|c Oapture us|ng NSTRAOE.SH ..................................................................... 365
NSTRAOE Syntax ........................................................................................................... 365
NSTRAOE Opt|ons .......................................................................................................... 365
F||ter Express|ons ............................................................................................................ 366
Rev|ew ................................................................................................................................ 368
Append|x Append|x A: A: Rev|ew Rev|ew Quest|ons Quest|ons and and Answers Answers ............................................. ............................................. 369 369
Rev|ew Answers: lntroduc|ng and Dep|oy|ng O|tr|x NetSca|er ............................................. 371
Rev|ew Answers: Network|ng ............................................................................................. 372
Rev|ew Answers: Oon|gur|ng H|gh Ava||ab|||ty .................................................................... 373
Rev|ew Answers: Secur|ng the NetSca|er System ............................................................... 374
Rev|ew Answers: Oon|gur|ng |oad Ba|anc|ng .................................................................... 375
Rev|ew Answers: Oon|gur|ng SS| ..................................................................................... 376
Rev|ew Answers: GS|B ...................................................................................................... 377
Rev|ew Answers: s|ng AppExpert O|ass|c to Opt|m|ze Tra|c ........................................... 378
Rev|ew Answers: s|ng AppExpert or Responder, Rewr|te and R| Transormat|on ......... 379
Rev|ew Answers: s|ng AppExpert or Oontent Sw|tch|ng .................................................. 380
Rev|ew Answers: s|ng AppExpert Advance to Opt|m|ze Tra|c ......................................... 381
Rev|ew Answers: Management ........................................................................................... 382
G|ossary G|ossary ..................................................................................................... ..................................................................................................... 383 383
Not|ces
Citrix Systems, Inc. (Citrix) makes no representations or warranties with respect to the content or
use of this publication. Citrix specifically disclaims any expressed or implied warranties,
merchantability, or fitness for any particular purpose. Citrix reserves the right to make any changes
in specifications and other information contained in this publication without prior notice and
without obligation to notify any person or entity of such revisions or changes.
Copyright 2011 Citrix Systems, Inc. All Rights Reserved.
No part of this publication may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or information storage and retrieval
systems, for any purpose other than the purchaser's personal use, without express written
permission of:
Citrix Systems, Inc.
831 West Cypress Creek Road
Fort Lauderdale, FL 33309
http://www.citrix.com
The following marks are service marks, trademarks or registered trademarks of their respective
owners in the United States and other countries.
Mark Owner
Active Directory, Microsoft, SharePoint, Microsoft Corporation
Windows
Apache Apache Software Foundation
AppCache, AppCompress, Citrix, Citrix Citrix Systems, Inc.
Access Gateway, Citrix Application Firewall,
EdgeSight, NetScaler, Request Switching,
Branch Repeater
CMP CMP Media, Inc.
FreeBSD FreeBSD Foundation
OpenView Hewlett-Packard Company
Intel Intel Corporation
Linux Linus Torvalds
SSH SSH Communications Security Corp.
Mark Owner
Java Sun Microsystems, Inc.
WhatsUp Ipswitch, Inc.
Other product and company names mentioned herein might be the service marks, trademarks or
registered trademarks of their respective owners in the United States and other countries.
Oonvent|ons
This courseware uses the following typographic conventions to emphasize information.
Convent|on sage
UPPERCASE
- Commands such as DIR and COPY
- Filenames such as AUTOEXEC.BAT and
SETUP.EXE
- Filename extensions such as .COM and
.INI
- Drive letters such as A: and C:
Case sensitive items are the only exception to
the usage listed.
lowercase
- Command line parameters such as /w and -
r
- URL addresses such as
http://finance.yahoo.com
- Internet addresses such as www.citrix.com
- Domain names such as education.ctxs
- E-mail addresses such as
trainingcitrix.com
the usage listed.
Bold Initial Capitalization
- Words or terms that are defined
- Interface items that are selected, deselected,
clicked, double-clicked or right-clicked such
as options and menu items in lab exercises
and procedures
the usage listed.
ITALIC UPPERCASE
- A variable in a system name such as
ProvServX and TargetDeviceX
- A variable in a user name such as UserX
and AdminX
Convent|on sage
italic lcwercase
- Variable drive letters such as z: and x:
- Variable directory names such as
%systemroot% and dir_name
the usage listed.
lcon Exp|anat|on
The note icon identifies additional relevant
information.
The important icon identifies prerequisite
information for a given task.
The tip icon identifies information that can save
time and effort.
The warning icon identifies information that
must be heeded in order to prevent harm to
systems or users.
Ored|ts
Cred|ts
Instructional Designers: Erin Shatara, Hung Ha, Rachel White, Karla Stagray, Roxanne Balolong
Media Developers: Nathan Jackson, Joshua Jack
Manager: Mike Young
Editor: Mark Carter
Subject-Matter Experts: Terry Anderson, Craig Anderson, Arvind Bangari, Florian Becker,
Maribea Berry, Paul Blitz, Robert Chen, Demetris Booth, Erik
Brandsberg, Ryan Butler, John Dell, Stefan Drege, Craig Ellrod, Raj
Galagali, Sovit Garg, Morgan Gerhart, Bino Gopal, Raghu Goyal,
Minoo Gupta, Geetika Gupta, Catherine Hampton, DeeLayna Hurst,
Todd Hurst, Mahesh Illuri, Steve Jacobson, Faisal Jahan, Jorge Juarez,
Sandeep Kamath, Ajay Kapase, Yariv Keinan, Prakash Khemani, Ravi
Kondamuru, Ajay Kumar Nema, Youcef Laribi, Florin Lazurca, Roland
Lee, Daniel McFarland, Leslie Michael, Ronan O'Brien, Graham
Phillips, Ryan Potter, Rich Prillinger, Roland Roetzer, Guy Rosefelt,
Raghav S N, Jacob Salassi, Chandra Sekhar K, Sanjay Sharma, Lavanya
Srikantapuram, Josephine Suganthi, Chad Tripod, Seema Vaibhav
Dubey, Mathew Varghese, Raghu Varma Tirumalaraju, Vijay
Veeranna, Kit Wetzler, Don Williams, Nina Wishbow
Modu|e 1
lntroduct|on and Oourse
Overv|ew
Overv|ew
This module provides you with the opportunity to meet your fellow students and become familiar
with the facilities, course materials and other Citrix offerings.
Student lntroduct|ons
When asked by the instructor, introduce yourself to the class. Include the following information:
- Name and company
- Job title
- Job responsibility
- Networking and load balancing experience
- Citrix hardware and software experience
- Class expectations
Fac|||t|es
Use the following space to document details about the facilities, classroom policies and contact
information:
- Class policies
- Break and lunch schedules
- Emergency contact information
- Parking
Oourse Mater|a|s
The following materials are included with your student kit:
- Name card - Write your name on both sides of the name card so students in front and behind
you will know who you are.
- Student manual - Use the student manual to follow along with the instructor and to document
notes during the class. After the class, take the student manual with you and use it as a
reference.
- Exercise manual - Use the exercise manual to perform the lab exercises. After the class, take the
exercise manual with you and use it as a reference.
- Online Student Resource - Use the Online Student Resources to access reference materials and
links after the attending the class.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 1: lntroduct|on and Oourse Overv|ew 21
Oourse Prerequ|s|tes
To complete this course successfully, you must have the following background and knowledge:
- Intermediate knowledge of TCP/IP, HTTP and of the OSI model
- Experience with network devices, networking protocols and aspects of application and site
architecture
- Moderate exposure to UNIX or Linux
- Exposure to basic systems administration concepts, including logging, software upgrade
procedures and high availability operations
- Familiarity with web server software
- Knowledge of network security threats and site protection concept
- An understanding of basic concepts related to server load balancing and content switching is
recommended.
22 Modu|e 1: lntroduct|on and Oourse Overv|ew Copyr|ght 2011 C|tr|x Systems, lnc.
Oourse Out||ne - Day One
The following descriptions provide an overview of the agenda for the first day of class:
Modu|e 1: lntroduct|on and Course Overv|ew
This module provides essential introductory information regarding course materials, prerequisite
experience, facilities, Citrix resources, Citrix courses and Citrix certifications.
Modu|e 2: lntroduc|ng and Dep|oy|ng C|tr|x NetSca|er
This module provides an overview of the NetScaler system product line and key features. Upon the
successful completion of this module, you will be able to identify the Citrix NetScaler products,
hardware platforms and hardware components. You will also be able to describe common
deployment scenarios and deployments considerations.
Modu|e 3: Network|ng
This module provides an overview of NetScaler networking and routing support. Upon the
successful completion of this module, you will be able to configure Reverse Network Address
Translation and access control lists.
Modu|e 4: Con|gur|ng H|gh Ava||ab|||ty
This module covers how to configure high availability. Upon the successful completion of this
module, you will be able to disable interfaces and monitors, assign node IDs and verify high
availability status. In addition, you will be able to perform synchronization, perform a forced
failover and upgrade a high-availability pair.
Oourse Out||ne - Day Two
Modu|e 5: Secur|ng the NetSca|er System
This module contains a detailed description of NetScaler internal and external communications, as
well as how the NetScaler system access can be regulated through access control lists. At the end of
this module you will be able to design access control lists to secure NetScaler communications,
secure internal and external NetScaler communications and secure access to the NetScaler system
through AAA.
Modu|e 6: Con|gur|ng |oad Ba|anc|ng
This module covers how to manage web traffic using the NetScaler load balancing feature. At the
end of this module, you will be able to create servers and services, configure health checks, create
load balancing virtual servers, enable persistence, configure some of the advanced options of load
balancing and manage services and virtual servers.
Modu|e 7: Con|gur|ng SS| O|oad
This module addresses how to optimize traffic using SSL offloading. At the end of this module, you
will be able to identify common deployments, create and upload certificates, select a cipher key
length, bind certificates and configure advanced options for SSL offloading.
Oourse Out||ne - Day Three
Modu|e 8: Con|gur|ng G|oba| Server |oad Ba|anc|ng
This module provides an overview of the global server load balancing (GSLB) feature and its
configuration. At the end of this module, you will be able to describe the GSLB architecture,
understand the core DNS concepts, understand core GSLB concepts, describe traditional load
balancing GSLB and describe proximity-based GSLB.
Modu|e 9: s|ng AppExpert C|ass|c to Opt|m|ze Tra|c
This module provides an overview of the classic policy expression engine and syntax. At the end of
this module, you will be able to configure classic policy expressions for content filtering and
compression.
Oourse Out||ne - Day Four
Modu|e 10: s|ng AppExpert or Responder, Rewr|te and R|
Transorm
This module explains how to configure the rewrite and responder features on a NetScaler system
using the Advanced Policy Engine. At the end of this module, you will be able to describe the
rewrite and responder features and perform configurations of policies and actions for rewrite,
responder and URL transformation.
Modu|e 11: s|ng AppExpert Advanced or Content Sw|tch|ng
This module describes how to configure content switching using classic expressions. At the end of
this module, you will be able to create and bind content switching virtual servers and policies, and
switch content between servers based on traffic attributes.
Oourse Out||ne - Day F|ve
Modu|e 12: s|ng AppExpert Advanced to Opt|m|ze Tra|c
This module describes how to configure optimizations on the NetScaler system using advanced
AppExpert expressions. At the end of this module, you will be able to configure the NetScaler
system to optimize web traffic: compressing through advanced policies, filtering traffic based on
elements of web traffic, caching frequently served web content to relieve servers and reduce
response time, and using application templates to optimize web traffic from specific applications.
Modu|e 13: Management
This module describes monitoring on the NetScaler system using the Simple Network Management
Protocol (SNMP), the Dashboard, Reporting and the Monitoring tool. It also covers how to
configure auditing and logging. By the end of this module you will be able to monitor the NetScaler
system, and access and manage NetScaler system logs.
O|tr|x Educat|on
C|tr|x Tra|n|ng Bene|ts
Available as instructor-led training (ILT), 24/7 self-paced online learning or a combination of both,
Citrix training courses provide the knowledge and skills that you need to exceed your business
goals.
Benefits to organizations include:
- Maximized return on investment for Citrix products through proper implementation and
support
- Improved reliability and efficiency for Citrix environments with decreased downtime
- Reduced implementation and support costs as more problems can be resolved faster by internal
staff
- Increased employee job satisfaction, leading to higher levels of customer satisfaction
Benefits to IT professionals include:
- Knowledge and skills that can be applied directly on the job to optimize and maintain Citrix
environments
- Enhanced credibility through knowledge and skills current with advances in technology
- Improved work performance, which increases employee value
Citrix training is essential for your organization to ensure successful product implementation and
maintenance. Visit to the www.citrixeducation.com web site and browse to the Training section to
explore the current Citrix training offerings.
C|tr|x Cert||cat|on Bene|ts
IT professionals at more than 213,000 organizations throughout the world rely upon Citrix. These
individuals have no better way to support such a high demand than to become Citrix certified.
Citrix certifications build upon one another, increasing the breadth and depth of technical skills
and knowledge with each advancement.
- The Administrator series consists of the Citrix Certified Administrator (CCA) and the Citrix
Certified Advanced Administrator (CCAA) certifications.
- The Engineer series consists of the Citrix Certified Enterprise Engineer (CCEE) certifications.
- The Architect series consists of the Citrix Certified Integration Architect (CCIA) certification.
Ranked among the most sought after certifications in the industry, Citrix certifications provide:
- Benefits for organizations, including:
- Peace of mind and assurance that certified staff have mastered the skills necessary to do
their jobs
- Valuable credentials to offer as incentive to top performers and to seek in prospective
employees
- Competitive advantage gained by leveraging staff that is trained and certified on a regular
basis
- Benefits for IT professionals, including:
- Demonstrated competency in Citrix products to employers and clients
- The most current technical skills and knowledge necessary to do their jobs
- Enhanced marketability through a well-recognized and respected credential
Investing in Citrix certification helps organizations and IT professionals alike realize their business
goals. To get started, visit the www.citrixeducation.com web site and browse to the Certification
section.
Key Resources
To obtain detailed and updated information on Citrix training and certification, visit the
www.citrixeducation.com web site regularly. The web site contains the latest information on
available and upcoming instructor-led training, self-paced online learning, exams and certifications.
Instructor-led training To view course descriptions, search or register for additional ILT
(ILT) courses courses and schedules in your area including customized training,
go to the www.citrixeducation.com web site and browse to the
Training section to find courses in your region. You may also
contact your Citrix Authorized Learning Center (CALC)
representative.
Self-paced online learning To view course descriptions, search or register for eLearning
courses, go to the www.citrixeducation.com web site and browse to
the Training section.
Exams To download exam preparation guides to prepare for exams, go to
the www.citrixeducation.com web site and browse to the Exam
section. To register for Citrix exams administered by Pearson VUE,
contact the provider directly:
- Web: www.pearsonvue.com
- Telephone: 1-800-931-4084 (Americas) For a list of phone
numbers by region, visit the http://vue.com/citrix/contact/ web
site.
Certification Manager To track your certification progress and publish your Citrix
credentials visit the www.citrixcertmanager.com web site.
Oourse Eva|uat|on and Oomp|et|on
Oert|f|cate
Course Eva|uat|on Survey
Course evaluation is integral to developing an Education program that provides an effective
learning environment and the knowledge and skills necessary to improve job performance while
enhancing the return on investment of Citrix products. Your instructor will carefully guide you
through the course evaluation process and ask that you submit an electronic survey at the
conclusion of the course. This valuable feedback will assist Citrix Education in expanding our
robust curriculum of instructor-led training, self-paced online learning and challenging certification
tracks.
Course Comp|et|on Cert||cate
A course completion certificate is available to those students who complete the course evaluation
survey. Midway through the final day of class, your instructor will provide you with the URL for
the web-based survey. Simply go to the link and complete the requested information. The
evaluation will take no more than 3 minutes to complete. Upon submission of your course
evaluation, the system will automatically generate an electronic version of your course completion
certificate. Enter your name and select the option to print, e-mail or save to HTML prior to closing
the page.
For classrooms where Internet access is not available, you may access the survey after
training by going to the www.metricsthatmatter.com/citrixeval web site. Please have your
course number available in order to launch the survey.
You may select more than one of the options provided to receive your course completion
certificate. When printing the certificate, choose Landscape in order to format the page properly. If
you elect to e-mail the course completion certificate, click the Back button from the e-mail page to
return to the certificate and select an alternative method.
If your classroom is not equipped with a printer, we strongly recommend that you e-mail
or save to HTML. You will not be able to re-access your course completion certificate
after you close the page.
Modu|e 2
lntroduc|ng and
Dep|oy|ng O|tr|x
NetSca|er
Overv|ew
Citrix NetScaler is:
- An asymmetrical solution
- A complete traffic management platform for all types of traffic
- A highly effective solution for optimizing HTTP traffic
- A solution designed from the ground up for high speed and performance
Object|ves
By the end of this module, you will be able to:
- Identify the NetScaler hardware components.
- Identify deployment scenarios.
- Identify deployment considerations.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 2: lntroduc|ng and Dep|oy|ng O|tr|x NetSca|er 35
lntroduct|on to the NetSca|er System
The NetScaler system is an integrated Web application delivery controller that slashes server and
bandwidth requirements, cutting the costs of delivering enterprise applications in half. The
NetScaler system gives IT managers the ability to instantly tap unrealized efficiency gains across all
phases of the application lifecycle, without having to become application experts.
The NetScaler system functions as an application accelerator through caching and HTTP
compression, and provides advanced management through layer 4-7 load-balancing and content-
switching functions. The NetScaler also includes application security using a Web application
firewall, including PCI-DDS security mandated protections, and SSL VPN. The NetScaler system
offloads application and Web servers to ensure application availability, increased security through
SSL, and server consolidation. It reduces the total cost of ownership of Web application delivery
and optimizing the user experience.
NetSca|er Funct|ona||ty
NetScaler content switching and load balancing dramatically improve the throughput and scalability
of an Internet application infrastructure by decoupling each application request/response flow from
the underlying transport. Content switching and load balancing ensure the most efficient use of
transport protocols and resources, even in a scenario in which all of the content is encrypted or
compressed.
The NetScaler system manages the complete lifecycle of the request/response transaction. With this
management, the NetScaler system is uniquely equipped to direct and control application requests
most efficiently, from the client to the server and back again.
Connection multiplexing (also known as connection reuse) allows the servers to handle significantly
fewer connections than are received by the NetScaler system. The more efficient use of the HTTP
specification provides a significant boost to the effective capacity of the server by reducing server
CPU load. With this separation, the NetScaler system can use the TCP proxy architecture to
multiplex and reuse the server-side TCP connection independently from a client-side connection.
This reuse of established and idle server-side TCP connections reduces the TCP overhead on Web
servers.
36 Modu|e 2: lntroduc|ng and Dep|oy|ng O|tr|x NetSca|er Copyr|ght 2011 C|tr|x Systems, lnc.
P|ann|ng a NetSca|er Dep|oyment
The NetScaler system can be deployed in the following network configurations:
One-Arm Mode
The figure depicts a one-arm mode configuration. The client must access the server through a
virtual IP (VIP) address configured on the NetScaler system.
A one-arm mode configuration allows:
- A simple configuration with one physical interface and no risk of bridge loops
- One or many VLANs with 802.1q tagging
- Link aggregation to satisfy bandwidth requirements
One-arm configurations are not recommended:
- When a server needs to see the actual IP address of the client and the default gateway of the
server cannot be changed to an IP address on the NetScaler system
- When the servers are accessed directly and the default gateway has been changed to the
NetScaler system, a situation that is sometimes addressed with the use of name-based services
and explicit server definitions
Two-Arm Mode
The figure depicts a two-arm mode configuration. The appliance is placed between two layer-2
switches, with one network interface on the appliance connected to the client network and another
network interface connected to the server network.
Two-arm mode has the following benefits:
- It allows layer-3 (routed) deployments with split subnets.
- It allows layer-2 (bridged) deployments with one subnet on each side.
- It supports transparent compression and SSL offload.
- It supports Use Source IP (USIP) address processing without server changes.
Two-arm topologies work in some situations in which one-arm does not work. With two-arm
mode, you can use the NetScaler system to route some traffic as well as to balance load.
ln||ne Mode
Inline mode is a special case of two-arm mode. In inline mode, multiple network interfaces are
connected to different Ethernet segments and the NetScaler appliance is placed between the clients
and the servers. The only route is through the NetScaler appliance.
Dep|oyment Scenar|os
The NetScaler system can be integrated into any network either as a complement to existing load
balancers, servers, caches or firewalls, or as a standalone solution capable of providing one or more
of those functionalities. A successful NetScaler deployment requires planning for the correct
deployment type, as well as a full migration of current network functions.
NetScaler deployment options include:
- Flex tenancy
- Displacement
- New technology
F|ex Tenancy
The figure illustrates a flex tenancy deployment scenario. NetScaler physical and virtual appliances
can be used together in a two-tier architecture--a flex-tenancy architecture--with each tier dedicated
to managing specific actions. In the figure, the flex tenancy architecture segments Web application
deployment delivery services into two tiers: share-network-service flex tier and application-specific
tenant tier.
The flex tier runs at the edge of the datacenter or an enterprise network. The flex tier performs
application delivery services and associated policies that are common and applied to all
applications.
The tenant tier runs logically close to the applications, with each tenant getting its own NetScaler
instance. The tenant tier isolates the application delivery needs that vary widely by application.
D|sp|acement
The figure illustrates a displacement scenario. In the figure, a NetScaler system (inserted in-line)
replaces another traffic manager. The NetScaler system often provides superior performance and
more compelling functionality compared to that offered by other traffic managers.
NetScaler systems are deployed in many scenarios to replace other products. As with a new
deployment, it is critical with displacement to analyze and decide how to replicate the current
functions of the network before deployment. Doing so ensures network features are properly
migrated to the new setup. New functionality is typically explored only after the existing functions
are replicated.
New Techno|ogy
The figure illustrates a new technology deployment scenario in a high-availability scenario. Before
starting a new technology deployment, you should first map out the network architecture to
maximize the placement of the NetScaler system. Part of this mapping should include an analysis of
what the current network functions are and what additional NetScaler functions will be added.
Product Features
The key feature sets of a NetScaler system include:
- Lower total cost of ownership
- Application acceleration
- Application security
- Application availability
- Simple manageability
Feature accessibility depends on the hardware, licenses and software of the specific NetScaler
system.
|ower Tota| Oost o Ownersh|p
Citrix NetScaler Pay-as-You-Grow is a simple, on-demand licensing model that provides
investment protection, avoids costly hardware upgrades and reduces total cost of ownership. Most
networking systems require expensive hardware replacements to expand capacity and functionality,
which forces companies to over-provision and pay for more than they need. Pay-as-You-Grow
licensing enables companies to buy only what they need today, knowing they can easily scale up
their network as demand grows with a simple software license upgrade. The flexible licensing
applies to both high-performance NetScaler MPX hardware appliances and software-based
NetScaler VPX virtual appliances.
Pay-as-You-Grow licensing is particularly well suited to cloud-computing environments. It enables
cloud providers to quickly and affordably expand their infrastructure as performance and capacity
requirements dictate, without incurring the heavy fixed costs and service interruptions of hardware
upgrades.
The following table identifies the licenses supported by the NetScaler system for lower total cost of
ownership.
Feature P|at|num Ed|t|on Enterpr|se Ed|t|on Standard Ed|t|on
TCP buffering X X X
TCP multiplexing X X X
SSL offload and X X X
acceleration
Cache redirection X X
App||cat|on Acce|erat|on
The NetScaler system increases end-user performance by 3X or more, while saving on network
bandwidth and making audio and video traffic usable over poor networks. This performance
increase is achieved through:
- Advanced multilevel compression for 3X faster delivery of Web content
- Dynamic content caching to instantly deliver frequently requested content directly
- End-user experience monitor providing true, transparent, non-synthetic monitoring of
application user performance
- Automated TCP optimizations that improve performance of all TCP-based applications
The following table identifies the licenses supported by the NetScaler system for enhancing
application acceleration.
Client and server TCP X X X
optimizations
Citrix AppCompress X X Option
for HTTP
Citrix AppCache X Option
Citrix Branch Repeater X
plug-in
App||cat|on Secur|ty
The NetScaler system provides application security by utilizing an advanced Web application
firewall to block application attacks and protect sensitive information from unauthorized access.
Day-zero attack protection and integrated XML security prevents the loss of valuable corporate and
customer data, and aids in compliance with regulations such as PCI-DSS. Comprehensive AAA
capabilities, along with a powerful distributed denial of service (DDoS) shield, allow secure remote
access and application security while preventing unauthorized access to sensitive information.
The following table identifies the licenses supported by the NetScaler system for enhancing
application security.
L4 DoS defenses X X X
L7 content filtering X X X
HTTP/URL Rewrite X X X
Access Gateway, EE X X X
SSL VPN
L7 DoS defenses X X
AAA security X X
Citrix Application X
Firewall with XML
security
X: Optional feature
App||cat|on Ava||ab|||ty
The NetScaler system is an all-in-one Web application delivery solution that makes applications 3X
better by accelerating performance, ensuring application availability through advanced layer 4-7
traffic management, increasing security with an integrated application firewall and substantially
lowering costs by offloading servers.
The following table identifies the features supported by the NetScaler system for application
availability.
L4 load balancing X X X
L7 content switching X X X
AppExpert Rate X X X
Controls
IPv6 X X X
Global server load X X X
balancing (GSLB)
Dynamic routing X X
protocols
Surge protection X X
Priority Queuing X X
X: Optional feature
S|mp|e Manageab|||ty
The NetScaler System provides key features for simple manageability:
- AppExpert Visual Policy Builder
- AppExpert Service Callouts
- AppExpert Templates
- AppExpert Visualizers
- Role-based Administration
- AAA for Administration
- Configuration Wizards
- Citrix Command Center
- Citrix EdgeSight for NetScaler
AppExpert v|sua| Po||cy Bu||der
The AppExpert Visual Policy Builder keeps policy development simple and policies supportable by
eliminating complex scripts or programs from all NetScaler policies.
AppExpert Serv|ce Ca||outs
AppExpert Service Callouts obtain information from external applications. The callout policy sends
an HTTP request to an external application. An agent deployed in front of the application formats
the request for the application.
When the application returns a response, the agent formats the response for the NetScaler system,
and the callout policy extracts data of interest from the response. For example, you can configure a
callout to send a client's source domain to a server that looks up bad domains from a list. When
the server sends a response, the callout extracts just the allowed" or denied" portion of the
response.
AppExpert Temp|ates
AppExpert Templates encapsulate the entire NetScaler configuration for a specific application into a
logical view. Ongoing changes to configuration and policies can also be made from this view.
AppExpert Templates can be imported and exported, enabling complete NetScaler configurations to
be loaded for the optimization of specific applications. Import/export also makes it easy to share
application-specific configuration within and between organizations and to move application-
specific configurations between different systems.
AppExpert v|sua||zers
The following statistical information for content switching, load balancing, and application entities
can be viewed in the Visualizer:
- Content switching and load balancing virtual servers - The number of requests received per
second at a given point in time at content switching and load balancing virtual server nodes is
displayed on the virtual server node in the Visualizer.
- Rewrite, responder, and cache policies - The number of hits per second at a given point in time
for rewrite, responder, and cache policies is displayed on the rewrite, responder, and cache
policy nodes in the Visualizer.
Ro|e-based Adm|n|strat|on
Role-based administration granularly segments administrative privilege on a NetScaler system.
AAA or Adm|n|strat|on
The following Authentication, Authorization, Auditing (AAA) features are enhanced in this release:
Forms-Based Single Sign- The NetScaler system now supports forms-based single sign-on to
On (SSO) all services. This functionality allows you to configure policies for
automatic submission of web forms by using the user credentials
used for logging in to NetScaler or VPN.
Single Sign-On (SSO) An SSO domain has been added in the timeout session parameter
Domain in Timeout and the timeout session action, to be used for form-based single
Session Parameter and sign-on.
Timeout Session Action
SSO to Services Support The NetScaler system supports single sign-on (SSO) authentication
for 401-based basic, digest, and NTLM authentication in AAA.
Con|gurat|on W|zards
Configuration wizards simplify the setup of load balancing, GSLB, EdgeSight for NetScaler, and
secure remote access and availability for Citrix XenApp.
C|tr|x Command Center
Citrix Command Center is a management and monitoring solution for Citrix application
networking products that include Citrix NetScaler, Citrix Branch Repeater, and Citrix Repeater. The
Command Center allows you to manage, monitor, and troubleshoot the entire global application
delivery infrastructure from a single, unified console.
C|tr|x EdgeS|ght or NetSca|er
EdgeSight for NetScaler monitors Web applications from the perspective of the client, providing
real-time and historic visibility into Web application performance.
EdgeSight for NetScaler:
- Increases visibility into the user perception of Web application response time
- Tracks and reports Web application performance over time, comparing current performance to
historical trends
- Requires no agent or client software on user devices
- Assists in troubleshooting bottlenecks
- Uses HTML-injected data for measuring application performance
Web 2.0 Opt|m|zat|on
NetScaler 9.2 introduces 64-bit shared-memory caching. High-end NetScaler MPX platforms can
provide up to 24 GB of memory cache capacity, to cache large video files at the service provider
edge, or to offload back-end servers. Delivery of Web 2.0 applications are optimized with new Fast
XML XPath support which enables high-performance business logic routing using deep XML
payload inspection.
The following table identifies the licenses supported by the NetScaler system for Web 2.0
optimization.
Rich Internet X X X
application support
XML XPath support X X X
Advanced server X X
offload
Hardware P|atforms
The different hardware platforms currently within the Citrix NetScaler product line include:
- NetScaler MPX 21300
- NetScaler MPX 9010 FIPS
- NetScaler VPX 10/200/1000
Each NetScaler platform has different measured capacities for system throughput, SSL throughput
and compression throughput. The measured peak throughput for each model is based on an
optimized configuration.
NetSca|er MP 21500/19500/17500/17000
The NetScaler MPX 21300/19300/17300/17000 platforms support the Platinum, Enterprise and
Standard Editions.
MP 21500 MP 19500 MP 17500 MP 17000
Height 2U 2U 2U 2U
Power Supplies Dual Dual Dual Dual
Processor Dual Intel Xeon Dual Intel Xeon Dual Intel Xeon Dual Intel Xeon
X3680 (12 cores X3680 (12 cores X3680 (12 cores X3440 (9 cores
total) total) total) total)
Memory 48 GB 48 GB 48 GB 32 GB
MP 21500 MP 19500 MP 17500 MP 17000
Ethernet ports 8x 10GBASE-X 8x 10GBASE-X 8x 10GBASE-X
4x 10GBASE-X
SFP+ SFP+ SFP+
XFP
OR
2x 10GBASE-X
XFP
A^D
8x 10/100/1000
BASE-T
Transceiver 10GE SFP+: SR, 10GE SFP+: SR, 10GE SFP+: SR, 10GE XFP: SR, LR
support LR LR LR
Pay-as-You-Grow Upgrade option to Upgrade option to
software upgrade MPX 21300 MPX 19300 and
MPX 21300
System 30 Gbps 33 Gbps 20 Gbps 18 Gbps
throughput
HTTP requests 4,400,000/sec 4,000,000/sec 3,000,000/sec 1,300,000/sec
SSL transactions 220,000/sec 163,000/sec 110,000/sec 100,000/sec
SSL throughput 11.3 Gbps 10 Gbps 8 Gbps 6.3 Gbps
Compression 11 Gbps 9 Gbps 7 Gbps 6 Gbps
throughput
SSL VPN: 10,000 10,000 10,000 10,000
concurrent users
NetSca|er MP 15500/15000/12500/10500
The NetScaler MPX 13300/13000/12300/10300 platforms support the Platinum and Enterprise
Editions.
MP 15500 MP 15000 MP 12500 MP 10500
Height 2U 2U 2U 2U
MP 15500 MP 15000 MP 12500 MP 10500
Power Supplies Dual Dual Dual Dual
Processor Dual Intel Xeon Dual Intel Xeon Dual Intel Xeon Dual Intel Xeon
E3440(8 cores E3240 (8 cores E3440 (8 cores E3440 (8 cores
total) total) total) total)
Ethernet ports
8x 10/100/1000 2x 10GBASE-X 8x 10/100/1000 8x 10/100/1000
BASE-T XFP BASE-T BASE-T
A^D A^D A^D A^D
8x 1000BASE-X 8x 10/100/1000 8x 1000BASE-X 8x 1000BASE-X
SFP (fiber or BASE-T SFP (fiber or SFP (fiber or
copper) copper) copper)
OR OR OR
2x 10GBASE-X 2x 10GBASE-X 2x 10GBASE-X
SFP+ SFP+ SFP+
A^D A^D A^D
8x 1000BASE-X 8x 1000BASE-X 8x 1000BASE-X
SFP (fiber or SFP (fiber or SFP (fiber or
copper) copper) copper)
Transceiver 10GE SFP+: SR, 10GE SFP+: SR, 10GE SFP+: SR, 10GE SFP+: SR,
support LR; 1 GE SFP: SX, LR LR; 1 GE SFP: SX, LR; 1 GE SFP: SX,
LX LX LX
Pay-as-You-Grow Upgrade option to Upgrade option to
software upgrade MPX 13300 MPX 12300 and
MPX 13300
System 13 Gbps 13 Gbps 8 Gbps 3 Gbps
throughput
HTTP requests 1,200,000/sec 900,000/sec 700,000/sec 300,000/sec
SSL transactions 87,000/sec 73,000/sec 60,000/sec 30,000/sec
SSL throughput 6.3 Gbps 6 Gbps 6 Gbps 3 Gbps
Compression 6.3 Gbps 3.3 Gbps 6 Gbps 3 Gbps
throughput
MP 15500 MP 15000 MP 12500 MP 10500
SSL VPN: 10,000 10,000 10,000 10,000
concurrent users
NetSca|er MP 9500/ 9010 FlPS/MP 7500/5500/vP
10/200/1000
The NetScaler MPX 9300/9010 FIPS/MPX 7300/3300/VPX 10/200/1000 platforms support the
Platinum, Enterprise and Standard Editions.
MP 9500 9010 FlPS MP 7500 MP 5500 vP
10/200/100
0
Height 1U 2U 1U 1U N/A
Power Supplies Single plus Dual Single plus Single only Dependent on
optional optional server platform
second supply second supply chosen
Processor Intel Xeon Intel Xeon Intel Xeon Intel Xeon Minimum
L3410 (4 cores 3.4E GHz (1 L3410 (4 cores E3203 (2 cores Server
total) core) total) total) Requirements:
Dual core
server with
Intel VTx or
AMD-V
Citrix
XenServer 3
(update 3 or
better)
VMWare
ESX/ESXi 3.3
or higher
2 GB RAM/20
GB hard drive
Hypervisor
supported NIC
MP 9500 9010 FlPS MP 7500 MP 5500 vP
10/200/100
0
Ethernet ports 4x 10/100/1000
8x 4x 1000BASE- 8x
BASE-T
10/100/1000B SX SFP (fiber 10/100/1000B
ASE-T or optical) ASE-T
OR OR OR
4x 4x 10/100/1000 4x
10/100/1000B BASE-T 10/100/1000B
ASE-T ASE-T
A^D A^D
4x 1000BASE- 4x 1000BASE-
X SFP (fiber or T
copper)
A^D
4x 1000BASE-
X SFP (fiber
and copper)
Transceiver SX, LX SX, LX SX, LX
support
Pay-as-You- Upgrade
Grow software option to MPX
upgrade 9300
System 3 Gbps 3 Gbps 1 Gbps 0.3 Gbps Up to 1.0
throughput Gbps
HTTP requests 200,000/sec 123,000/sec 100,000/sec 30,000/sec Up to
100,000/sec
SSL 20,000/sec 4,400/sec 10,000/sec 3,000/sec Up to 300/sec
transactions
SSL 3 Gbps 0.3 Gbps 1 Gbps 0.3 Gbps Up to 1.0
throughput Gbps
Compression 2 Gbps 0.4 Gbps 1 Gbps 0.3 Gbps Up to 0.73
throughput Gbps
MP 9500 9010 FlPS MP 7500 MP 5500 vP
10/200/100
0
SSL VPN: 10,000 3,000 10,000 3,000 Up to 300
concurrent
users
nOore
Citrix NetScaler nCore technology dramatically increases the performance and scalability of
NetScaler at no additional cost. nCore technology breaks the single CPU performance barrier that
limits the performance, scalability, and extensibility of most Web solutions. It is a true 64-bit
architecture that is built from the ground up to intelligently distribute packet flows across multiple
CPU cores for high-performance parallel processing.
As Web applications become increasingly complex and demanding due to Web 2.0 trends and the
proliferation of Rich Internet Applications (RIA), Web application delivery will be required to
provide greater levels of Web application delivery controller solutions which provide:
- Layer 4-7 load balancing and content switching functions
- Caching
- Compression
- Application security
- SSL offloading
- Multigigabit speeds
NetScaler nCore application accelerator technology delivers a 7X increase in performance and
scalability and provides new levels of advanced Web application delivery controller performance for
even the most challenging Web applications.
For a list of features supported by the NetScaler 9.2 nCore release, visit the
http//suppcrt.citrix.ccm/prcddccs/index.jsp web site.
NetSca|er vP
NetScaler VPX is a virtual application that provides the functionality of specialized, high-end
network devices that can be easily and dynamically deployed on a single server or across entire
cloud datacenters. The simplicity and flexibility of NetScaler VPX make it easy and cost effective to
fully optimize every Web application and more effectively integrate networking services with
application delivery.
In addition to supporting datacenters relying upon virtualized server and application resources,
NetScaler VPX enables Web application load balancing, acceleration, security, and offload to
become virtualized services that can be easily deployed on-demand anywhere in the datacenter or
cloud infrastructure. This enables combining NetScaler VPX with other virtualized networking
solutions to deliver an end-to-end layer 2-7 virtual networking stack.
Hardware Oomponents
Each NetScaler appliance includes certain hardware components. Some of these components are
easily accessible on the exterior of the appliance and should not be removed. You must be aware of
what and where these components are when administering a NetScaler system. The file systems are
vital for the NetScaler system operations.
Network and Ser|a| lnteraces
On all NetScaler platforms, the network interfaces are located on the front of the appliance.
The RS232 serial console port on the front of each NetScaler appliance provides a direct connection
between the appliance and a workstation or laptop, allowing direct access to the appliance for initial
configuration or troubleshooting.
|OD
Some basic information can be found directly on the front-mounted LCD screen. The LCD screen
cycles through the screen options and displays the current system values.
Refer to Hardware Installaticn and Setup Guide on the http//suppcrt.citrix.ccm/prcddccs/index.jsp
Web site for more information about the values that are displayed.
F||e System
Important data systems include:
RAM Drive The RAM drive is mounted on the root or / file system. During
operation, binaries are executed from the RAM drive. The running
configuration files for BSD level tools will be used from the /etc file
system residing on the RAM drive.
Flash memory The flash memory is mounted in the NetScaler system as /flash.
During start up, the RAM drive is initially populated from a
compressed build file residing on the flash drive, and then the
configuration files needed for BSD-level processes are copied from
the nsconfig directory on the flash drive into the /etc directory in
the RAM drive. The /nsconfig directory is then linked to the
/flash/nsconfig directory as a shortcut. When a save config
command is executed, the running (in-memory) configuration is
saved to this directory.
The flash drive is located on the back of the appliance and should
not be removed.
Hard Disk The NetScaler system hard disk is used to store log data and core
files and is used as long-term storage for unused builds.
The /var directory represents the physical hard disk. The hard disk
is located on the back of the appliance and should not be removed.
NetSca|er Arch|tecture Overv|ew
The NetScaler design is based on a layered module between the NetScaler kernel and the BSD
operating system as shown in the figure. BSD and the NetScaler system share memory
management. The NetScaler kernel operates below the BSD kernel and controls many of the
features, including:
- Time slicing for BSD
- Network packet processing
- SNMP and syslog processing
- SSL offload
BSD manages several integral features of the NetScaler system, including:
- Boot process
- File system access
- Long-term logging
- Management processes
|ogg|ng |n to the NetSca|er System
The NetScaler administrator account is nsroot, and the default password is nsroot. The nsroot
account is part of the default configuration. A best practice is to change the default password
during installation.
The NetScaler system is accessed using the GUI-based Configuration Utility or the command-line
interface. In the Configuration Utility logon window, the start menu and timeout session can be
configured.
You can log on to the NetScaler system using the Configuration Utility when the system and
software requirements for the workstation have been met.
The command-line interface can be accessed directly by connecting a workstation to the NetScaler
serial port or by using SSH to connect to the NetScaler IP address. Refer to the Citrix êtScaler
Ccmmand Reference Guide for general information about the features of the command-line
interface, including SSH.
Rev|ew
Answer the following questions. When everyone has finished, review the answers as a group.
1. A client, such as a web browser, attempts to resolve a host name prior to accessing a resource.
Which NetScaler feature determines the site most available and best able to respond, and
returns the IP address of the site to the client:
a. Cache redirection
b. Content switching
c. Global server load balancing
d. TCP buffering
2. Where is the NetScaler configuration file stored:
a. Flash memory
b. Hard disk
c. RAM drive
d. SATA drive
3. Which feature maximizes server efficiency by consolidating application-level requests and
reducing the number of server-side connections:
a. Link aggregation
b. TCP buffering
c. TCP multiplexing
d. SSL offload
Modu|e 3
Network|ng
Overv|ew
This module contains a detailed description of how networking works on the NetScaler system, as
well as how the NetScaler system is fundamentally different from other devices.
Object|ves
At the end of this module, you will be able to:
- Deploy a NetScaler system as a network gateway device.
- Describe NetScaler networking.
- Explain routing support on the NetScaler system.
- Describe virtual local area networks (VLANs).
- Configure reverse network address translation.
- Use the Link Aggregation Control Protocol (LACP).
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 3: Network|ng 65
NetSca|er Arch|tecture Overv|ew
The NetScaler system is fundamentally a TCP (layer 4) proxy that separates the client connections
from the server connections and manages separate connection tables for client and server
connections. The NetScaler system can provide great traffic optimization as a gateway device by
multiplexing client connections to Web servers.
As a TCP proxy device, the NetScaler system responds to client connections that are targeted at
servers residing behind it, hiding the network topography. The NetScaler system can enforce traffic
security by being the single gateway that clients use to access the network.
The NetScaler system is not a UDP proxy. However, it still proxies the IP address, sourcing from a
mapped IP address or subnet IP address as normal. This behavior can be turned on and off at a
granular level.
Oonnect|on Separat|on
The figure illustrates the NetScaler system configured to act as a virtual server. The client connects
to the virtual IP address on the NetScaler system. The NetScaler system then uses either its Mapped
IP (MIP) address or a subnet IP (SNIP) address on the back-end subnet to connect to the server.
Even though the client connection terminates at the NetScaler system, the client request is
forwarded by the NetScaler system to the servers. In this scenario, the NetScaler system is
transparent to the client. No client-side configuration is required, making the NetScaler system a
transparent proxy.
Bas|c NetSca|er System Network|ng Ru|es
The NetScaler system sends and responds to address resolution protocol (ARP) requests for all IP
addresses on all interfaces. With the binding of a VLAN to an interface, all IP addresses continue to
66 Modu|e 3: Network|ng Copyr|ght 2011 C|tr|x Systems, lnc.
be answered on the interface if a proper ARP request is generated outside the NetScaler system.
ARP can be restricted on a given VLAN by binding a SNIP address to a VLAN with an IP address.
The interfaces on a NetScaler appliance are not marked and do not have assigned IP addresses. This
open architecture allows any connection to the NetScaler system to be created from any port. A
best practice is to control and limit this behavior with the use of VLANs.
The figure shows a network endpoint device and a NetScaler system. Typical network hosts have a
one-to-one mapping of the MAC address to an IP address. On the NetScaler system, IP addresses
are not bound to a particular network interface. Any physical interface can send and receive data
for any NetScaler system-owned IP address. This behavior becomes significant when the NetScaler
system operates in an environment using VLANs.
Mu|t|p|ex|ng
The NetScaler system attempts to reuse TCP connections it creates to back-end servers to optimize
HTTP traffic. It does this by proxying the IP (layer 3) address of the client that the server sees. This
behavior is determined by the service type. The HTTP service type enables TCP offload,
multiplexing, and connection reuse on top of this layer-4 proxying. HTTP processing includes
further capabilities including:
- Compression
- Integrated caching
- Layer 7 content switching
- Layer 7 GET-flood protection
By default, the NetScaler system translates the client IP address to either a MIP address or a SNIP
address to maintain a single connection to the server and multiplexes all client connections to it.
This means that the back-end servers do not see individual clients, since all the traffic appears to
come from the NetScaler system.
In certain circumstances, the IP address cannot be proxied for HTTP services. When the
IP address is not proxied for HTTP, connection reuse benefits are lost across different IP
addresses.
NetSca|er-Owned lP Addresses
The NetScaler system uses different types of IP addresses for management and proxying
connections to the server. These IP addresses are:
- NetScaler IP addresses (NSIP)
- Subnet IP addresses (SNIP)
- Mapped IP addresses (MIP)
- Virtual IP addresses (VIP)
NetSca|er lP Address
The NetScaler IP address (NSIP) is the primary address for management and general system access.
The NetScaler IP address is a unique IP address. When NetScaler systems participate in a high-
availability configuration, the NSIP address is used for primary communication between members
of the high-availability configuration and the NSIP is the only active IP address on the secondary
member in a high-availability pair. The NSIP can be accessed from any enabled interface on the
NetScaler system.
An NSIP address must be configured on a new NetScaler system. The default IP address and
netmask is 192.168.100.1/16 (233.233.0.0).
Configuring an initial NSIP address or changing the NSIP address or subnet mask requires a restart
of the NetScaler system. When configuring changes using the command-line interface, save the
configuration first, change the NSIP address, and then restart the NetScaler system.
Configure NSIP addresses through the setup wizard or through the command-line interface.
Configuration Utility The NSIP can only be changed by running the Setup Wizard:
location System > Setup Wizard.
Command-line syntax
config ns
This will start the text-driven utility that will allow you to configure
and save the NSIP address/subnet.
Authentication traffic, such as LDAP and RADIUS, also uses the NSIP address.
Subnet lP Address
The subnet IP (SNIP) address is used in connection management and server monitoring. A SNIP
address provides the NetScaler system with an ARP presence in subnets to which the system may
not be directly connected. A NetScaler system should have a SNIP address configured for every
directly connected subnet. When a SNIP is added to a NetScaler system, a static route entry is
automatically added to the NetScaler system routing table; this route identifies the SNIP address as
the default gateway on the NetScaler system for the corresponding subnet.
The Use Subnet IP (USNIP) mode can affect how the SNIP address is used by the NetScaler system
to communicate with servers. USNIP mode is enabled by default. When USNIP mode is enabled,
the SNIP address functions as a proxy IP and is used by the NetScaler system for NetScaler-system-
to-server communication. In this mode, the server will see the SNIP address as the source IP in
packets received from the NetScaler system.
If USNIP mode is disabled, the SNIP address is not used to send traffic from the NetScaler system
to the servers. Instead a mapped IP address must be available. In most environments, USNIP mode
is left enabled.
Individual SNIP addresses can be enabled to allow management access. When management access
is enabled, connections to the NetScaler command-line interface over SSH and connections to the
Web-based Configuration Utility can be made using the SNIP address (as if it were a NSIP
address). Using management enabled SNIP addresses allow you to connect to the NetScaler system
from a subnet other than the one where the NSIP is located. It also simplifies managing NetScaler
systems in a high-availability configuration, since only the primary unit will respond to the SNIP.
Management access is not enabled by default. Unlike the NSIP address (but like every other type of
IP address), SNIP addresses are only active on the primary unit of a high-availability pair and show
as passive on the secondary unit.
If multiple SNIP addresses are present on a subnet, the NetScaler will alternate between the SNIP
addresses in round-robin manner when communicating with servers.
Configure SNIP addresses by defining an IP address and a subnet mask:
Configuration Utility Under the Network > IPs node
location
Command-line syntax
add ns ip <IP address> <Subnet Mask> -
type SNIP -mgmtAccess [Enabled | Disabled]
Because of the default behavior of the NetScaler system, IP addresses are not associated
directly to interfaces (MAC addresses). As a result, all SNIP addresses are available on all
interfaces by default, making it very easy to connect the NetScaler system to networks.
This behavior can be modified by configuring VLANs on the NetScaler system and
binding interfaces and SNIP or MIP addresses to a VLAN.
Mapped lP Address
A mapped IP (MIP) address is used for external connections from the NetScaler system. MIP
addresses are used for connectivity in the absence of a SNIP address. For example, the MIP address
is the proxy IP address of last resort. MIP addresses, like SNIP addresses, are used as the proxy
address for NetScaler system-to-server communication. MIP addresses are still used even when the
USNIP mode is globally disabled.
A best practice is to have at least one MIP address configured in the same subnet as the
NSIP address. However, MIP addresses are not required.
The MIP address should be available across all subnets and should never be bound to a VLAN. It is
only active on the primary unit of a high-availability pair, like every other IP address on the system
other than the NSIP address, and shows as passive on the secondary unit.
When both a MIP address and a SNIP address are configured on the same subnet, the NetScaler
system will use the SNIP address to communicate with servers by default (since USNIP mode is
enabled). If USNIP mode is disabled, the MIP address will be used.
If multiple MIP addresses are present on a subnet, the NetScaler will use the MIP addresses in a
round-robin fashion.
Configure MIP addresses by defining an IP address and a subnet mask:
Configuration Utility Under the Network > IPs node
location
Command-line syntax
add ns ip <IP address> <Subnet Mask> -
mgmtAccess [Enabled | Disabled]
v|rtua| lP Address
Virtual IP (VIP) addresses are used for client-to-NetScaler-system communication. Virtual IP
addresses are assigned to virtual servers on the NetScaler system. VIP addresses are generally
presented to the clients as a logical abstraction of a physical server behind the NetScaler system.
When the VIP address is a public IP address, it usually corresponds to the DNS entry for a domain.
A VIP address is automatically created when a virtual server is added. A virtual server is identified
as a unique IP/port combination. A virtual server could be configured using an IP address (VIP1)
on port 80 (HTTP), and a second virtual server could be configure using the same IP address
(VIP1) on port 3389 (RDP). A single VIP address can support a maximum number of 64,000
available TCP ports, corresponding to a maximum of 64,000 separate virtual servers (distinct ports)
on a single VIP address.
Changing the status of a VIP address, such as disabling it, will affect all virtual servers that use the
VIP address.
NetSca|er Modes
Modes on the NetScaler system are global settings that control NetScaler behavior. Most of the
modes modify networking behavior. Unlike features, modes are generally not configurable; modes
are either enabled or disabled. Most modes control a global setting across the NetScaler system. A
few settings such as USIP mode, Client Keep-Alive, and TCP Buffering can be managed globally or
on a per-service basis.
Two modes specifically address the packet forwarding behavior of the NetScaler: layer-2 mode and
layer-3 mode.
This section will specifically discuss:
- Layer-2 mode
- Layer-3 mode
- MAC-based forwarding mode
- Use Source IP (USIP) mode
|ayer-3 Mode
The base behavior of the NetScaler system is to process the packet of any traffic sent to NetScaler-
owned IP addresses. This means that any packet sent to an NSIP address, MIP address, SNIP
address, configured service, or virtual server will be processed by the NetScaler system.
The layer-2 and layer-3 modes determine how the NetScaler system handles packets that are sent to
an IP address that it does NOT own. These modes determine whether the NetScaler system should
act as a switch and bridge the packets (layer-2 mode) and whether the NetScaler system should act
as a router and forward the packets (layer-3 mode).
In the default configuration, layer-3 mode is enabled and layer-2 mode is disabled. These two
modes are not exclusive.
Oon|gur|ng |ayer-3 Mode
With layer-3 mode enabled, the NetScaler system will perform packet forwarding (routing) of any
packet that is not sent to an IP address it owns. If layer-3 mode is disabled, the NetScaler will drop
the packet.
Typically, layer-3 mode is left enabled. However, layer-3 mode can be disabled if the NetScaler
system should not be performing routing functions.
Configure the NetScaler mode in:
Configuration Utility Under the System > Settings node: Configure modes
dialog
Command-line syntax
enable ns mode L3
disable ns mode L3
If both layer-2 and layer-3 modes are enabled, layer-2 mode decisions (based on MAC
addresses) will be processed first.
|ayer-2 Mode
By default, the NetScaler system functions as a layer-3 network device. However, it can be
configured to function as a layer-2 device. With layer-2 mode enabled, the NetScaler system
functions as a bridge. Decisions are based on the MAC address of the packet (layer 2).
If the packet contains a destination MAC address that belongs to the NetScaler system, the
NetScaler system will then look at the IP address destination to determine how to handle the traffic.
The layer-2 mode setting determines how the NetScaler system handles packets whose destination
MAC address does not correspond to a NetScaler-owned MAC address. If layer-2 mode is disabled
(default configuration), the NetScaler system drops any packet that is not destined for a NetScaler-
owned MAC address.
If layer-2 mode is enabled, then the NetScaler system determines whether to process the packet or
bridge the packet. The NetScaler system will process the packet if the destination IP address
corresponds to a NSIP/MIP/SNIP address, configured service, or virtual server. Otherwise, the
NetScaler system will bridge the packet, acting like a switch.
With layer-2 mode enabled, traffic that is not destined for the NetScaler system will be bridged to
the networks that the NetScaler system is connected to. Exceptions to this behavior are:
- Broadcasts that are received on a NetScaler interface assigned to a VLAN are NOT forwarded
to interfaces that are not assigned to a VLAN.
- ICMP and UDP traffic will be dropped if it exceeds the packet rate filters on the NetScaler. The
NetScaler system will not bridge the excess traffic requests.
|ayer-2 Mode Oons|derat|ons
Layer-2 mode is typically not needed in most environments and should be left disabled unless there
is a specific networking need in the environment.
The NetScaler system does not support Spanning Tree Protocol (STP) and drops STP packets.
Spanning Tree Protocol is used on bridged networks to detect bridging loops, meaning:
- Two interfaces on the NetScaler system cannot connect to the same broadcast domain.
- If a NetScaler system is installed in parallel to a layer-2 device, layer-2 mode must be disabled
on the NetScaler system to prevent creating a bridging loop.
A scenario where layer-2 mode might be needed is when servers are connected directly to the
NetScaler system or if the NetScaler system is being used as a transparent bridge. However, both
scenarios are not typical and should not be used without considering the impacts.
One last consideration is due to the way that layer-2 mode functions, it can present some conflicts
with security requirements in the environment. Access control lists (ACLs) are usually configured
to help prevent traffic from reaching specific destinations. However, ACLs are based on the IP
address information in the packet (layer 3) and not the MAC address information in the packet
(layer 2). As a result, if layer-2 mode is enabled, layer-2 bridging decisions are made before IP-
based ACLs are processed. Having layer-2 mode enabled can result in the bypassing of any ACLs in
place and therefore the bypassing of security.
Oon|gur|ng |ayer 2 Mode
Configure the NetScaler mode in:
Configuration Utility Under the System > Settings node: Configure modes
dialog location
Command-line syntax
enable ns mode L2
disable ns mode L2
|ayer-2 Mode w|th |ayer-3 Mode
Layer-2 and layer-3 modes can be enabled or disabled independently of each other. The NetScaler
system makes packet processing decisions by looking at the MAC address first and then the IP
address. Keep in mind that the layer-2 and layer-3 mode behaviors only apply to traffic that is not
being sent to a NetScaler MAC address or a NetScaler-owned IP address.
A best practice is to leave layer-3 mode enabled and layer-2 mode disabled, unless there
are specific networking conditions that require it.
- Packets destined for a NetScaler-owned IP address are always PROCESSED, regardless of the
MAC address.
- Packets destined for a non NetScaler-owned MAC address are:
- DROPPED if layer-2 mode is disabled
- BRIDGED if layer-2 mode is enabled
- Packets destined for a non NetScaler-owned IP address are:
- DROPPED if layer-3 mode is disabled
- FORWARDED (Routed) if layer-3 mode is enabled
MAO-Based Forward|ng Mode
MAC-based forwarding can be used to process traffic more efficiently by avoiding extraneous
route/ARP lookups when forwarding packets. To avoid multiple lookups, the NetScaler system
caches the source MAC address for every connection and returns the data to the same MAC
address.
MAC-based forwarding is useful when using VPN devices because the NetScaler system ensures
that the traffic flowing through the VPN passes through the same VPN device.
Send|ng a O||ent lP Address to Servers
The NetScaler system usually functions in a transparent proxy configuration. Clients initiate
connections to the NetScaler system using a VIP address. The NetScaler system terminates the
connection from the client, processes the packet, and then initiates a connection to the appropriate
server on behalf of the client.
The default behavior of the NetScaler system is to change the source and destination IP address of a
packet received from a client before sending it to the server. The originating packet from the client
contains the source IP address as the client IP address and the destination IP address as the virtual
server IP address (the VIP on the NetScaler system). The NetScaler system then changes the packet
before sending it on to the server so that the source IP address becomes the NetScaler MIP/SNIP
address and a destination IP address becomes the physical IP address of the server.
As a result of proxying the connection, the server is unable to see the IP address of the client that
originated the connection; the server can see only the NetScaler MIP or SNIP address. Since some
applications require the client IP address for proper logging or functionality, the NetScaler system
has two ways of providing this information to the server:
- Client-IP HTTP header insertion
- Use Source IP mode
O||ent-lP HTTP Header lnsert|on
When a back-end server needs to identify or track the client that originated a request, it generally
looks at the source IP address field of the packet header. However, when the connection is being
proxied by the NetScaler system, the packet details do not yield the desired information. Use Source
IP mode can be enabled so that the IP address of the client that originated the request is left intact
in the packet; however, there are several drawbacks to this solution, which will be covered in the
User Scurce IP section. Applications that need this information can usually be configured to retrieve
the information from an HTTP header instead of from the packet. The applications just need to
know the name of the header from which to retrieve the value.
The NetScaler system can perform this client IP header insertion for the HTTP traffic it is
proxying. Applications can still retrieve the originating client IP address, and the NetScaler system
maintains all of the connection multiplexing and proxying benefits while leaving USIP mode
disabled.
Client-IP header insertion is the preferred method to use to pass the client IP address to
back-end servers and applications.
An HTTP header consists of a header name and a value:
Example:
Header name: value
Host: www.example.com
Accept-encoding: gzip, deflate
With client IP header insertion, the NetScaler system inserts a new header into the HTTP request
before sending it to the server:
Header name: value
Host: www.example.com
Accept-encoding: gzip, deflate
ClientIP: 172.30.200.10
Client-IP: 10.10.0.56
GetThis: 192.168.10.17
Client-IP header insertion can be enabled in multiple ways on the NetScaler system. Some methods
apply globally or across a feature set. Others apply to specific services or traffic criteria based on
policies. As a result, there are several ways to set the specific header name that an application is
configured to look form, including:
- Configuring globally, updating the HTTP Parameters (System > Settings), and
enabling/disabling client IP header insertion.
- Configuring on a per-service basis, updating the service properties, and enabling/disabling
client IP header insertion. The service-level setting overrides the global setting.
- Specifying the logging header name within the Application Firewall engine settings. This
header insertion supplies the client IP address in the designated header. The Application
Firewall setting applies globally to the Application Firewall feature and affects any traffic
processed by an Application Firewall policy.
- Configuring a rewrite policy to selectively affect specific traffic criteria.
In most of these options, the HTTP header insertion behavior is already defined and you just need
to specify the header name. If working with the rewrite feature, you can use the custom header
insertion feature to perform the same behavior; this feature will be discussed in more detail in
Module 10.
se Source lP Mode
Use Source IP (USIP) mode is a networking mode in which the NetScaler system uses the actual
client IP address to connect to the server and does not replace the source IP address in packets sent
to the server with a MIP or SNIP address. The server will see the originating client IP address
within the source IP field of the packet. While USIP mode will allow back-end resources to see and
log the client IP addresses, there are several side effects and considerations when USIP mode is
enabled.
By default, when proxying the connection, the NetScaler system manages the connections to the
server. For HTTP protocols, connection reuse and multiplexing result in improved efficiencies and
performance. USIP mode severely limits multiplexing opportunities as each client will require its
own connection to the server. Connection reuse, WAN latency optimizations, and denial-of-service
(SYN) attack prevention are also limited.
Considerations and limitations when activating the Source IP mode feature include:
- USIP mode should not be enabled for NetScaler systems deployed in a one-arm configuration.
- Concurrent HTTP connection limits may be more of a factor since connections are not reused
with USIP mode enabled. If HTTP connections will exceed 64,000 concurrent connections,
USIP mode should be disabled.
- Multiplexing is only used for connections between the NetScaler and the server originating
from the same source IP address, causing significantly more sessions to be established between
the NetScaler system and the server. This behavior is inefficient for the NetScaler system and
creates more overhead for the server.
- Surge protection is unable to function in a USIP mode environment, as the NetScaler system
will be in a constant surge mode. The surge protection feature should be disabled if USIP is
enabled.
- USIP mode requires routing in the environment to direct all of the server response traffic
bound for the client IP address through the NetScaler system.
USIP mode does not eliminate connection reuse completely. The benefits of connection
reuse are simply diminished. Connections from the same source IP address are reused.
They are just a small fraction of the traffic the NetScaler system could be reusing.
If an application requires the original source IP address, then USIP mode can be enabled on a
service-by-service basis.
Oon|gur|ng SlP Mode
USIP mode can be enabled or disabled globally (as a NetScaler mode) or it can be enabled or
disabled on a per-service basis.
At the service level, the USIP setting is a global-override. Enabling or disabling the setting on an
individual service overrides the global setting.
Whenever the global mode is changed, existing services are not modified; they retain their existing
global-override setting. New services that are created will inherit the USIP setting from the global
setting unless the value is explicitly overridden when configuring the service.
As a result, you may enable USIP mode broadly across all services or enable it specifically only for
those services that require it.
As a best practice, if an application requires a client IP address for logging or functional
purposes, rely on client IP header insertion. If client IP header insertion is not suitable,
enable USIP mode only on the specific service or services that require it. Keep the use of
USIP mode as limited as possible.
Because of the limitations and considerations, do not enable USIP mode unless it is absolutely
necessary.
Network Address Trans|at|on
Network address translation (NAT) involves modifying:
- The source IP address
- The destination IP address
- The TCP or UDP port numbers
Enabling NAT enhances the security of a private network and protects it from a public network,
such as the Internet, by modifying the source IP address when data passes through the NetScaler
system.
With NAT entries, an entire private network can be represented using a small number of shared
public IP addresses. Therefore, by using NAT on the NetScaler system, you are better equipped to
handle security and administration issues, as well as a shortage of IPv4 addresses.
The NetScaler system supports the following network address translation capabilities:
Inbound NAT (INAT) The NetScaler system replaces the destination IP address in the
packets generated by the client with the private IP address of the
server.
Reverse NAT (RNAT) The NetScaler system replaces the source IP address in the packets
generated by the servers with the public NAT IP address.
The NetScaler system is also an IP address proxy for reverse network address translation (RNAT)
and for virtual servers. Network Address Translation cannot be implemented without a virtual
server.
lnbound Network Address Trans|at|on
When a client sends a packet to a NetScaler system that is configured for inbound network address
translation (INAT), the NetScaler system translates the public destination IP address of the packets
to a private destination IP address and then forwards the packets to the server at that address.
When the server returns the packets, the NetScaler system translates the source IP address of the
packets to the public source IP address and then sends the packets back to the client.
Reverse Network Address Trans|at|on RNAT}
Reverse network address translation (RNAT) allows server-side addresses to be translated to the
MIP address or a SNIP address of the NetScaler system when servers send data through the system.
This behavior applies to connections that are initiated from the internal servers, as opposed to
client connections passed through the NetScaler system.
RNAT does not alter the data portion of the communication in any way. As a result, if the
application passes the host IP address as part of the data, that IP address is not the same as the
address after the traffic has undergone RNAT. This incongruity causes that application to fail. For
example, using the file transfer option in MSN Messenger is not possible through an RNAT session.
The exception to this rule is File Transfer Protocol (FTP). Specific extended functionality has been
put in place to support FTP through an RNAT session.
RNAT Port Re-use
The NetScaler RNAT is not only based on one port; it is also based on other socket data where the
remote address and port are both taken into account. The NetScaler system can reuse the same port
with the same IP address for multiple outgoing RNAT sessions.
lP Addresses or RNAT
You can configure a non-wildcard virtual IP address as an RNAT IP address.
RNAT can be configured to use a VIP address for address translation. RNAT is configured using
the following command:
set ns rnat network -NATIP <IP_Address>
The address provided as the value for the argument can be a MIP address, SNIP address or virtual
IP address. A wildcard virtual IP address is not a valid selection for the -NATIP argument.
A SNIP or MIP address can be supplied as the NAT IP address when -NATIP is configured. The
NetScaler system round-robins between the SNIP addresses. If there are no SNIP addresses, then
the NetScaler system round-robins between MIP addresses.
In an RNAT configuration, the NetScaler system replaces the source IP addresses of the packets
generated by the servers with a NAT IP address, which is a public IP address.
The default NAT IP address is a MIP address. The NetScaler system can be configured to use other
NetScaler-owned IP addresses.
RNAT Examp|e
The image shows an example of the RNAT process. When performing RNAT, the NetScaler system
replaces the source IP addresses of packets generated by the servers with a NAT IP address.
Oon|gur|ng Reverse Network Address Trans|at|on
Configure RNAT and the ACL and NAT IP address information as necessary.
Configuration Utility Under the Network > Routing node, in the RNAT tab of the
location Routing pane
Command-line syntax
set rnat network netmask
The NetScaler system hides the IP address of all packets originating in that network.
View RNAT statistics pertaining to RNAT and the NAT IP address by defining a particular NAT IP
address. Statistics include:
- Bytes received
- Bytes sent
- Packets received
Not specifying a particular NAT IP address will return global RNAT statistics.
Configuration Utility Monitoring in the upper right corner > RNAT from the Select
location Group list
Monitoring in the upper right corner and selecting RNAT IP from
the Select Group list
Command-Line syntax
stat rnat
stat natip NATIPAddress
v|rtua| |oca| Area Networks
Unlike a typical network host, the NetScaler system does not have a one-to-one mapping of MAC
addresses to IP addresses. As a result, any of the NetScaler interfaces can send and receive data for
any type of NetScaler-owned IP addresses. This behavior can be modified through the use of
VLANs.
All interfaces on a NetScaler system are automatically members of the default VLAN (VLAN 1),
also referred to as the native VLAN. Like a switch, the NetScaler system does not natively bind IP
addresses to interfaces. In a situation where a NetScaler system is connected to multiple subnets,
you may want to enforce separation of the subnets so that only the interfaces connected to the
subnet will respond to IP addresses on that subnet.
This subnet separation can be accomplished by configuring one or more VLANs on the NetScaler
system. An interface and an IP address can be associated with the VLAN once one is created. The
desired separation in subnets is created when a MAC address (interface) and an IP address are
associated with the VLAN.
Each VLAN is identified by a VLAN ID, which is an integer from 1 to 4094. The VLAN created is
empty (without members). However, the VLAN is not active until interfaces are bound to it with
an IP address. VLAN 1 is created by default and cannot be deleted. By default, all interfaces belong
to VLAN 1. When an interface is added to a new VLAN, it is automatically removed from VLAN 1.
When a VLAN to which an interface is bound is deleted, the interface is returned to VLAN 1.
VLANs can be created on the NetScaler system to correspond with the VLANs in use within the
network. The NetScaler supports layer-2 port and IEEE 802.1q tagged VLANs.
When a VLAN is bound to an IP subnet, the NetScaler will perform IP forwarding between the
VLANs when configured as the default router for the hosts on the subnets.
The VLAN feature of the NetScaler system is an implementation option in the following
environments:
- Single subnet
- Multiple subnets
- Single LAN
- VLANs with no tagging
- VLANs with 802.1Q tagging
When configuring tagged VLANs, the tags must match on both ends of the link; the port
to which the NetScaler is connected and the VLAN on the NetScaler interface must be on
the same VLAN.
Tagged v|ANs
The figure shows a tagged VLAN structure. IEEE 802.1Q specifications define the tagging structure
of VLAN traffic. VLAN tagging inserts an additional header between the layer-2 and layer-3
headers in the packet. The additional header contains a protocol ID and a VLAN ID. The virtual
network with which the packet is associated is identified by the VLAN ID. This tagging information
can be used by layer-2 VLAN aware devices to intelligently forward the data to ports associated
with the same network. The NetScaler system tagged VLAN functionality is fully 802.1Q compliant.
v|ANs and Tagg|ng w|th NetSca|er vP
Tagged VLANs are not supported by NetScaler VPX and cannot be configured within the NetScaler
VPX configuration. If a NetScaler VPX is deployed in a tagged VLAN environment, the VLAN
configuration must be handled at the host-server level. On a host server such as XenServer, the
VLAN configuration can be configured by creating the appropriate PIF, network, and VIF objects
on the host server.
The figure shows how the NetScaler VPX interacts with its XenServer host.
Oon|gur|ng v|ANs
The figure shows further information for NetScaler VPX in a two-arm deployment.
Configure a VLAN by defining a VLAN ID, an interface, and a SNIP.
Configuration Utility Under the Network > VLAN node
location
Command-line syntax
add vlan id
show vlan id
bind vlan id[-ifnum InterfaceName [-
tagged]][-IPaddress IPAddress netmask]
Refer to Citrix Hardware Installaticn and Setup Guide, for more information about configuring
VLANs.
||nk Aggregat|on
The figure shows how Link Aggregation combines data from multiple ports into a single high-speed
link. Link aggregation allows multiple interfaces to be used in a combined manner to provide
increased capacity/throughput and availability for the communication channel between the
NetScaler system and other connected devices. Link aggregation is configured to address bandwidth
limitations and to provide redundancy for interfaces (mitigating single points of failure).
In some environments, the speed of a single interface is not adequate for the amount of traffic that
the NetScaler system manages. To address inadequate interface capability, you can combine
multiple interfaces on the NetScaler system into a single, logical high bandwidth 802.3ad interface.
The resulting aggregated interface is treated as a single interface for configuration purposes. The
aggregate interface link throughput is the sum of the bound physical interfaces. The switch
connected to the aggregate interfaces must also support 802.3ad on the NetScaler system.
Because of the default NetScaler behavior, two interfaces should never be plugged into the
same VLAN or broadcast domain unless a link aggregation/802.3ad is being configured.
The add channel command creates the virtual interface. Physical interfaces are added to the channel
as part of the add command or through the use of the bind channel command after the interface is
created. A single link aggregation channel can contain from two to four physical interfaces. If these
(physical) interfaces are of differing speeds, the physical interfaces all function at the lowest
common speed when aggregated.
When two or more interfaces are aggregated, they create a channel. The channel can be configured
or bound to VLANs just like an individual interface. Link aggregation on the NetScaler system can
be configured in two ways: manually (without LACP) or automatically (with LACP).
Channels that are configured manually must be managed manually (at the channel level). Channels
that are configured automatically using LACP must be managed at the interface level through the
LACP properties.
When a new channel is created (either manually or through LACP), any VLAN settings configured
on the member interfaces are lost, and the channel joins VLAN 1 by default. Once a new channel
has been created, you must reconfigure any VLAN settings on the channel instead of on the
member interfaces. The same happens when a channel is removed; member interfaces return to
VLAN 1 and any required tagged VLAN settings must be reconfigured.
Oon|gur|ng |AOP Manua||y
When creating a channel manually, you first create the channel and assign it a channel ID and then
bind two or more interfaces to the channel. Channels are referred to as LA/1, LA/2, LA/3, and
LA/4. Like interfaces, channels can be bound by referencing the channel ID (LA/1 as opposed to
1/8).
The channel will appear down until one more interface has been bound to the channel.
Channel settings include enabling or disabling the channel and setting a minimum required
throughput. If one or more interfaces fail, the available throughput for the remaining interfaces falls
below the minimum value, and the channel appears down. A channel going down can be used to
trigger a high-availability failover event. Other settings such as speed, flow control, and VLAN
tagging are configured on the channel instead of on the individual member interfaces.
The figure shows the LACP being configured in the Configuration Utility.
To delete a channel, unbind the interfaces from the channel and remove the channel. The interfaces
will revert back to being member interfaces of VLAN 1.
Configuration Utility Under Network > Channels
location
Command-line syntax
add channel ID
bind channel ID -ifnum InterfaceName
Oon|gur|ng ||nk Aggregat|on w|th |AOP
When LACP is configured, the link aggregation channel is created automatically. Management of
the channel members occurs at the interface level by modifying the LACP properties on each
interface. The LACP settings must be configured the same on the interfaces and on the switch ports
to which the NetScaler interfaces are connected.
LACP cannot be enabled for interfaces that are members of an existing channel created manually.
When LACP is enabled, the NetScaler system creates the channels dynamically (LA/1 and LA/2).
To control which channel interfaces join, specify the LACP key as 1 to join LA/1, and 2 to join
LA/2.
LACP configurations need to be consistent across all interfaces that are members of the same
channel, both on the NetScaler system and on the device the NetScaler system is connected to.
Configuration Utility Under Network > Interfaces
location
Command-line syntax
set interface ID -lacpMode <lacpMode> -
lacpKey <value> -lacpTimeout <value> -
lacpPriority <value>
lnternet Oontro| Message Protoco|
Internet Control Message Protocol (ICMP) messages are handled in a unique manner on the
NetScaler system. As a result of the specialized role that the NetScaler system plays in the network,
it does not respond in traditional ways to most ICMP messages. The NetScaler system often ignores
or drops ICMP error message traffic and forwards ICMP packets addressed to its MAC address. In
addition, the NetScaler system ignores ICMP packets beyond the 200 packets for every second
threshold.
Path MT D|scovery
The path maximum transmission unit (MTU) identifies the maximum size of a packet that will be
accepted by a network device. The figure shows an analogy of MTU to maximum vehicle weight.
Path MTU discovery is a method in which network devices can dynamically learn the maximum
transmission unit for a network path. With path MTU discovery, information regarding the
maximum segment size (MSS) to use with packets is communicated from a router using an ICMP
error message when a MTU mismatch occurs. Path MTU discovery is defined in RFC 1191.
When network devices route packets between networks, traffic can move to a network that has a
smaller MTU size than the network in which it originated. When traffic is moved to a network with
a smaller MTU size, the network device that is bridging the two networks (usually a router)
fragments the packet as needed so that the packet can continue to its destination. The process of
fragmenting packets can be beneficial in that it decreases retransmission of data based on MTU
conflicts. However, the process of resizing packets from a larger size to a smaller size can add
overhead to the routers performing the fragmentation and can add overhead on the receiving
servers due to the need for the servers to reassemble the original packet from the fragments.
In order for a packet to be delivered, it must be able to fit within the allowed packet size defined by
the MTU of a network segment. When the packet size and the MTU are in conflict, the MTU
usually cannot be changed; therefore, either the packet must be fragmented in transit by an
intermediary network device, or the originating device must send the data in smaller packets to
correspond to the allowed MTU.
Fragmentation of a packet can be prevented through the use of a Do Not Fragment flag in the
packet; this flag indicates that the originating application does not want the packet to be
fragmented.
As a result, in situations in which the packet contains a Do Not Fragment flag and in which the
size of the packet being sent by the originating application exceeds the size of the MTU of upstream
devices, the network device deals with the conflict by sending a notification to the originating
system that it must send the data in smaller packets to reach the destination. In other words, if the
packet cannot be fragmented by the network device, the network device has to get the originating
application to make the packet smaller to be compatible with other network segments that have
smaller MTUs.
NetScaler 6.0 and later provides full support for path MTU messages. NetScaler participation in
path MTU discovery is configurable by enabling or disabling the global mode setting. By enabling
path MTU discovery, the NetScaler system will manage the size of the packet and perform
fragmentation if necessary (and allowed).
Dynam|c Rout|ng Support and Route Hea|th
lnject|on
The NetScaler system supports both dynamic and static routing. Because simple routing is not the
primary role of a NetScaler system, the main objective of running dynamic routing protocols is to
enable route health injection (RHI) so that an upstream router can choose the best route among
multiple routes to a topographically distributed virtual server.
The NetScaler system supports the following dynamic routing protocols:
- Routing Information Protocol (RIP)
- Border Gateway Protocol (BGP)
- Open Shortest Path First (OSPF)
Route Health Injection (RHI):
- Supports dynamic routing with RIP, BGP and OSPF
- Advertises only active entities
- Advertises virtual IP addresses based on virtual server status
Rev|ew
1. When USIP mode is enabled for server communication, which address is used instead of a
MIP or SNIP address:
a. Client IP address
b. Virtual IP address
c. SNIP address
d. Server IP address
2. Determine if the following statement is true or false. 'By default, the NetScaler system operates
in layer-3 mode, which provides a higher level of security than layer-2 mode.'
a. True
b. False
3. Which of the following statements regarding Link Aggregation Control Protocol (LACP) is
true:
a. When the speed of one interface is more than adequate for the traffic flow that is
managed by the NetScaler system, LACP is used.
b. When interfaces on a NetScaler system are combined, the aggregate link speed is the
total speed of the bound physical interfaces.
c. Up to five physical interfaces can be bound to a single link aggregation channel.
d. When the physical interfaces are added to a channel and are of differing speeds, they
operate at the highest common speed when aggregated.
Modu|e 4
Oonf|gur|ng H|gh
Ava||ab|||ty
Overv|ew
When two NetScaler systems are deployed in an environment as a cluster, they are referred to as a
high-availability pair. Using a high-availability pair deployment ensures that NetScaler-provided
services are always available even if one system fails.
Object|ves
- Create a high-availability pair.
- Disable interfaces.
- Enable high-availability monitoring.
- Assign node IDs.
- Verify high-availability status.
- Perform synchronization.
- Perform a forced failover.
- Upgrade a high-availability pair.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 4: Oon|gur|ng H|gh Ava||ab|||ty 99
lntroduct|on to H|gh Ava||ab|||ty
In a high-availability pair configuration, only one system is active. This system, which is known as
the primary, actively accepts connections and manages servers. All shared IP addresses are active on
the primary system only.
The secondary system monitors the health of the primary system. If the secondary system is in a
healthy state, it is ready to actively accept connections if the primary system is experiencing issues.
This process prevents downtime and ensures that the services provided by the NetScaler system
remains available even if one system ceases to function.
The terms primary and secondary refer to the current state of a node, which can change as network
conditions change. A way to specify a preference for primary status on either node, also known as
preemption, does not exist.
High-availability packets are sent untagged by default, which can be an issue with a switch
that handles tagged packets only.
H|gh Ava||ab|||ty Funct|ona||ty
100 Modu|e 4: Oon|gur|ng H|gh Ava||ab|||ty Copyr|ght 2011 C|tr|x Systems, lnc.
The figure shows a typical two-arm high-availability configuration. Both systems in a high-
availability pair exchange UDP heartbeat messages that communicate the state of the other and
ensure that only one unit is taking traffic at a time. This configuration is known as active/passive.
High availability does not require feature enablement; however, high availability needs to be
configured.
If a component of the primary system fails, a message to the secondary system instructs it to take
over as the primary system. If the secondary system does not receive a heartbeat message from the
primary system after a specific interval of time, it automatically assumes the primary role. This
scenario is known as failover.
Three heartbeat messages must be missed for a failover to occur. High-availability
heartbeat messages are sent every 200 milliseconds on UDP port 3003.
After a failover, all clients must reestablish their connections to the managed servers, but session
persistence tables are synchronized between the primary and the secondary systems, honoring the
previous persistence decision. Refer to Citrix êtScaler êtwcrking Guide, located at
support.citrix.com, for more information on TCP connection failover.
Neither system is considered primary if the primary node experiences a failure and
attempts to failover to a secondary system that is not healthy. Therefore, it is possible for
both systems to be secondary at the same time, and for neither system to process traffic.
H|gh Ava||ab|||ty Node Oonf|gurat|on
A pair of NetScaler systems must be configured to become a high-availability pair. The process for
configuring a high-availability pair involves first configuring the node desired to be primary and
then configuring the node desired to be secondary.
A best practice is to set the status of the desired secondary node to stay secondary when nodes are
configured. This practice ensures that an accidental failover does not occur during the
configuration process, resulting in changes being made to the secondary rather than the primary
node. Any changes that are made to the secondary node are not propagated to the primary node.
You should not use NetScaler VLANs when configuring high availability because it limits
the NSIP address subnet. The NSIP address subnet should be available on all interfaces
during high-availability configuration.
In a high-availability configuration, you can designate which interfaces to monitor for failing
events. A failover occurs when any high-availability monitored interface goes down. If a particular
interface is not being used, or if a failover is not required upon failure, the high-availability monitor
should be disabled.
If an interface is not going to be used at all, a best practice is to disable it and turn off the
associated high-availability monitor.
Pre-Oon|gurat|on Oheck||st
Before configuring high-availability-pair nodes:
- Ensure that the NSIP addresses for the primary and the secondary nodes are unique from any
other device on the network.
The NSIP address can be changed using the set ns config command, which requires a restart.
- Ensure IP address conflicts can be viewed in the shell with the dmesg command.
While the RPC node password must be identical in a high-availability configuration, the
nsroot password on both systems does not have to be the same.
v|rtua| Med|a Access Oontro| Address
The primary and secondary nodes in a high-availability setup share the same virtual media access
control (VMAC) address. The primary node owns floating IP addresses, such as the MIP, SNIP and
VIP addresses, and responds to address resolution protocol (ARP) requests with its own MAC
address. Therefore, the ARP table of an external device, such as an upstream router, is updated with
the floating IP address and the MAC address of the primary node.
The VMAC must be configured on both nodes of a high-availability pair with both nodes having
identical MAC addresses. When a failover occurs, the MAC address of the secondary node remains
unchanged, and the ARP tables on the external devices do not need to be updated.
When a failover occurs and the secondary node takes over as the new primary node, it uses the
gratuitous address resolution protocol (GARP) to advertise the floating IP addresses that it learns
from the primary node. The MAC address that the new primary node advertises is the MAC
address of its own network interface. Because some devices do not accept GARP messages, the
external devices retain the IP address-to-MAC address mapping that the old primary node formerly
advertised, which may result in a GSLB site becoming unavailable for those networks.
Oon|gur|ng Pr|mary and Secondary Nodes
You can use the following procedure to configure the primary and secondary nodes using the
Configuration Utility or the command-line interface:
1. Disable the interfaces that are not connected or being used for traffic.
2. Disable monitoring for the interfaces whose failure should not cause a high-availability mode
failover.
3. Assign a node ID to each NetScaler system.
4. Save the configuration.
Before two nodes are able to function in a high-availability pair, they must first be made aware
of each other.
You join a new NetScaler system with an existing system to form a high-availability pair
because it is a best practice to enable stay secondary status on the new system. If stay secondary
status is not enabled during high-availability configuration, the new system may be elected to
become the primary node, and the configuration settings on the existing system are replaced
with the settings (typically a blank configuration) on the new system.
When stay secondary status is enabled on the new system, the existing system becomes the
primary node if it passes its health checks and its configuration settings are synchronized with
the new system.
H|gh-Ava||ab|||ty Status
After two NetScaler systems in a high-availability pair have been configured, it is important to
verify the status of each node to ensure that the system is prepared in case of failover. For each
node, the node state should be UP and the master state should be either primary or secondary, as
appropriate. You should check that the sync state shows success on the secondary node because it
verifies the successful completion of the configuration synchronization process.
ver|y|ng Status on the App||ance
In addition to checking the master status of a node remotely using either the Configuration Utility
or the command-line interface, you can refer to the NetScaler appliance, which displays the status
on the Configuration Display on the LCD, as shown in the figure.
Propagat|on and Synchron|zat|on
Command propagation, enabled by default, causes any command issued on the primary node to
execute on the secondary node. Consequently, you can test if high availability is working by making
configuration changes to the primary node and then testing to see if the changes have propagated
to the secondary node.
Configuration synchronization occurs when a node comes up for the first time in a secondary state.
The secondary node pulls the configuration from the primary node and overwrites its existing
configuration.
In addition to automatic configuration synchronization, forced synchronization between two nodes
is also supported. Forced synchronization is used whenever you want to ensure that changes made
to a NetScaler configuration are transferred from the primary to the secondary system. For
example, if a network interruption occurs and the systems are unable to communicate, a forced
synchronization ensures that any changes made during the interruption are present on both
systems.
If the nodes in a high-availability pair are running different versions of the NetScaler operating
system, the node running the newest software version goes into listen mode as of release 8.0 and
later. When a node is in listen mode, neither command propagation nor configuration
synchronization occurs.
- Changes made using the config ns command in the command-line interface are not
propagated. Any configurations made using this command must be performed on each node
separately.
- High-availability configuration synchronization occurs on TCP port 3010.
- Command propagation between the primary and secondary occurs on TCP port 3011.
- The heartbeat messages are UDP packets sent to port 3003 of the other node in a high-
availability pair.
- Secure high-availability configuration synchronization occurs on TCP port 3008.
D|sab||ng Oommand Propagat|on
In some cases, command propagation may not be desired.
For example, if you make changes to the system configuration that causes problems, the changes
are also made to the secondary node if command propagation is enabled. When command
propagation is disabled, you can first make changes on the primary node. Once the configuration is
completed and is verified to be functioning properly, you can use the force ha sync command to
ensure that the changes propagate to the secondary node.
Automat|c Oon|gurat|on Synchron|zat|on
By default, configuration synchronization between the systems in a high-availability pair occurs
automatically. Configuration synchronization occurs when:
- A node first comes up in the secondary state.
- A failover event occurs.
- A forced synchronization is issued.
When a save configuration is issued on the primary system, the running configuration on both
systems is saved from memory to the ns.conf file on the flash drive. In some cases, automatic
synchronization may not be desired.
For example, if you are testing two different configurations in a high-availability pair, the changes
are also made to the secondary node if configuration synchronization is enabled. When
configuration synchronization is disabled, you can first make changes on the primary node and
then make changes on the secondary node. You can still failover to the secondary node with the
original configuration on the primary node.
Once the configuration is completed and is functioning properly, you can use the force ha sync
command to ensure that the changes synchronize to the secondary node.
Forced Synchron|zat|on
Forced synchronization can be performed on either the primary or the secondary node; however, if
synchronization is already in progress, the command fails, and a warning message is displayed.
Before performing a forced synchronization, you must save the configuration because the
saved configuration is copied over but not the running configuration.
The saved configuration file is the ns.conf file. The running configuration is stored in memory and
may contain unsaved configuration changes.
Forced synchronization will also fail when it is executed in the following circumstances:
- On a standalone NetScaler system
- On a NetScaler system that has high availability disabled
- On a NetScaler system that has high-availability synchronization disabled
The DONE message that is displayed after the force ha sync command is executed does
not indicate that synchronization has been successful. To verify that synchronization is
successful, execute the show node command to verify that the configurations on both
nodes are the same.
Perorm|ng a Forced Fa||over
When a failover occurs because the primary node fails, the primary node becomes secondary and
the secondary node becomes primary. A forced failover is an administratively initiated failover on a
node that produces the same results. A forced failover is desired if you want to test whether a high-
availability pair configuration is performing correctly or to replace or upgrade the primary node.
Forced failover is performed in the Configuration Utility or with the force ha failover command in
the command-line interface.
The command can be issued on either the primary or the secondary node. A forced failover will
work only when:
- The primary node is able to determine that the status of the secondary node is UP.
- The health of the secondary node is good.
- The secondary node is not configured to stay secondary.
Performing a forced failover from the Configuration Utility may cause the client to lose
connectivity with the NetScaler system. A best practice is to perform a forced failover in
H|gh Ava||ab|||ty Management
While a high-availability pair can be managed using the unique NSIP addresses assigned to each
node during initial configuration, a best practice is to manage the pair using either a MIP or SNIP
address. When a shared IP address is used to connect to either the command-line interface or the
Configuration Utility, the connection is made to the primary node in the pair. If a failover occurs,
the secondary node becomes primary, and the same MIP or SNIP address then connects to the new
primary node. Using a MIP or SNIP address is also helpful when you need to perform
configurations from a subnet different from that of the high-availability pair.
Every NetScaler system is assigned a MIP address or a range of MIP addresses during initial
configuration; however, management access must be enabled on the MIP or SNIP address before it
can be used to manage a high-availability pair.
A best practice is to secure management access in the NetScaler system.
pgrad|ng a H|gh Ava||ab|||ty Pa|r
When the nodes of a high-availability pair are running different versions of the system software, the
node running the newest version goes into listen mode. When a node is in listen mode, neither
propagation nor synchronization occurs.
Listen mode is used if you want to test the newest software version on one node before upgrading
the second node. To conduct such a test, you perform a forced failover on the upgraded system,
causing it to take over as the primary node. When a forced failover occurs, neither propagation nor
synchronization occurs, and all connections need to be re-established.
Rev|ew
1. Determine if the statement is true or false. 'In a high-availability pair, when the primary node
experiences a failure and attempts to failover to a secondary system that is not healthy, the
primary node stays as the primary.'
a. True
b. False
2. Which two IP address types have the option to enable management access: (Choose two.)
a. NSIP address
b. MIP address
c. VIP address
d. USIP address
e. SNIP address
3. Before two nodes are able to function in a high-availability pair, how are they made aware of
each other in the command-line interface:
a. By issuing the sync command from the primary system
b. By issuing the sync command from the secondary system
c. By issuing the add node command on each node of the pair
d. By issuing the set node command on each node of the pair
4. Which statement refers to a default high-availability setting:
a. In a high-availability pair, management access and communication are secured
through SSL.
b. Synchronization between the systems in a high-availability pair has to be enabled after
the nodes are connected.
c. In a high-availability pair, both the primary and the secondary NetScaler systems
actively accept connections and manage servers.
d. When the nodes of a high-availability pair are running different versions of the system
software, the node running the newest version goes into listen mode.
Modu|e 5
Secur|ng the NetSca|er
System
Overv|ew
Securing access to the NetScaler system requires a detailed understanding of NetScaler internal and
external communications. Regulating those communications along with system access can be done
through the use of access control lists.
Object|ves
- Design access control lists to secure NetScaler communications.
- Secure internal and external NetScaler communications.
- Secure access to the NetScaler system through authentication, authorization, and auditing.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 5: Secur|ng the NetSca|er System 113
NetSca|er System Oommun|cat|on
To secure NetScaler system communication, you must first understand the external and the internal
communication that occurs when the NetScaler system is deployed.
Inline Topology You need to consider both the topology of the network and the
communication that needs to take place on the NetScaler system
before communication can be secured.
Inline topology deployment is a best practice for securing the
NetScaler system. It is important to consider Virtual Local Area
Network (VLAN) creation when securing a NetScaler system.
NetScaler Operation Layer NetScaler communication types and layers must be secured. The
NetScaler system uses layer 2 for internal, external, and
management communication. Access control lists also communicate
on layer 2, layer 3, and layer 4.
NetSca|er Oommun|cat|on Types
Typical communication types include:
System-to-system High availability is a type of system-to-system communication.
communication High-availability communication occurs by default on TCP port
3010 and 3011. High-availability communication is secure on TCP
port 3008 and 3009 and is used for command synchronization and
command propagation. UDP port 3003 is used for the high-
availability heartbeat and is a health-check industry standard.
GSLB is a type of system-to-system communication that occurs by
default on TCP port 3011. GSLB communication is secure on TCP
port 3009 and is used for GSLB metric exchange protocol
communication.
114 Modu|e 5: Secur|ng the NetSca|er System Copyr|ght 2011 C|tr|x Systems, lnc.
Management The command-line interface is a type of management
communication communication involving SSH on TCP port 22 (Secure Telnet). The
command-line interface is accessed through Telnet on TCP port 23,
which is not secure and is disabled by default.
The Configuration Utility and GUI are a type of management
communication that includes the front-end and the Java applet. The
front-end is on TCP port 80, which is the default port. It is secure
on TCP port 443. The Java applet is on TCP port 3010, which is the
default port. It is secure on TCP port 3008.
SNMP request and SNMP request and response traffic (polling) is a type of
response traffic communication that occurs on UDP port 161. SOAP XML API
communication occurs on TCP port 80 using HTTP, and it is secure on TCP port
443 using HTTPS.
A best practice is to limit communication to the NSIP
address to management access.
Port Type se Secure
22. TCP HTTP SSH Non-secure
80. TCP HTTP GUI web front end, Non-secure
XML-API
161. UDP HTTP SNMP Non-secure
request/response traffic
(polling)
162. UDP HTTP SNMP traps Non-secure
443. TCP HTTPS GUI web front end, Secure
XML-API
3003. UDP HTTP HA Heartbeat Non-secure
3008. TCP HTTPS GUI Java applet, HA Secure
Communication
3009. TCP HTTPS HA Communication, Secure
GSLB MEP
communication
Port Type se Secure
3010. TCP HTTP GUI Java applet, HA Non-secure
Communication
3011. TCP HTTP HA Communication, Non-secure
GSLB MEP
communication
Secur|ty Parameter Oomponents
The components that are necessary when configuring security parameters on a NetScaler system are
access, authentication, authorization, and accounting.
Access Limits, by network, the ability to access the devices by protocol
Authentication Verifies that a user has the proper credentials
Authorization Verifies that each user has the authority to perform various actions
Accounting Logs what actions were taken and by whom
Some of this security behavior is covered in relation to one specific configuration. The
information provided does not cover areas that apply to other configurations. Information
for the specific topology that is being secured must be carefully adjusted.
Access Oontro| ||sts
Access control lists can be configured on the NetScaler system. The NetScaler system compares
incoming packets against the access control lists. If a packet matches an access control list rule, the
action specified in the rule is applied to the packet.
All access control lists are enabled by default. The NetScaler system compares incoming packets
against all the access control lists. If an access control list is not required as part of the lookup table
but is retained in the configuration, then it should be disabled before applying the access control
lists. Once the access control lists have been applied, the system does not compare incoming
packets against disabled access control lists.
S|mp|e Access Oontro| ||sts
You can configure simple access control list packet filters based on only the source IP address and
the port. If both simple and standard access control lists are configured, simple access control lists
are applied first. If the simple access control list returns a DENY, then the configured action is
taken. If the simple access control list returns an ALLOW, then the standard access control list is
applied, and the return value determines the action. The NetScaler system allows 100,000 simple
access control lists to be configured.
The standard access control list limit is 1024, but simple access control lists can be created as
memory allows.
Match|ng Access Oontro| ||st Entr|es
The NetScaler system can implement IP address-based traffic control on data that it handles using
access control lists. This functionality is inherent to the NetScaler system, and it does not need to
be enabled.
The ways in which traffic can be handled once it is matched are:
Allowed Traffic is allowed and is processed by the NetScaler system.
Bridged Traffic is forwarded through the NetScaler system but is not
processed.
Denied Traffic is dropped.
If no access control list entry is matched, then the traffic is allowed.
Tra|c ldent||cat|on
The access control list can be created to identify traffic by specifying eight different attributes of the
IP packet. The following table describes these attributes.
Attr|bute Descr|pt|on
Source IP address The IP address, IP address range or subnet of
the source system where the traffic originates
Source port The traffic port from the source system
Destination IP address The IP address, IP address range or subnet of
the destination system
Destination port The traffic port to the destination system
Source MAC address The MAC address of the source system
Protocol or protocol number The protocol corresponding to the protocol field
in the IP header
VLAN ID The VLAN ID of the VLAN where the packet is
generated
Interface The interface on which the packet arrives
If the traffic matches more than one access control list, the most specific match is used. If it
matches different access control list entries for the source and the destination, the most specific
destination access control list is used. You should not create access control lists with the same
parameters.
Loopback traffic is never processed by access control lists.
Access-Oontro|-||st Syntax Format and Precedence
The access-control-list syntax format of the add ns acl command is virtually the same for NetScaler
7.0 and above editions. Both versions support the use of the same eight packet attributes for
defining access control lists. Refer to the appropriate Ccmmand Reference Guide located at
support.citrix.com, for the NetScaler version in use for more detailed information on parameters
and options.
Access-Oontro|-||sts Precedence
Access-control-list precedence is determined according to the following rules:
- The most specific access control list takes priority unless the priority is assigned.
- The destination takes priority over the source when there is no priority assigned.
- The first access control list that matches determines how the packet is processed. The packet is
only affected by a single access control list or no access control lists if there is no match.
lPv6-Based Access-Oontro|-||st Support
Access control lists based on Internet Protocol version 6 (IPv6) are configured in the Configuration
Utility. To create an IPv6 access control list, create an extended access control list and select the
appropriate IPv6 protocol.
The NetScaler system extends its IPv6 support to server-side implementation. End-to-end IPv6
support enables the use of IPv6 addresses for SNIP addresses, virtual servers, services and servers.
IPv6 management utilities can also be used, such as Ping6 and Traceroute6. IPv6 support also
extends to OSPFv3.
Static routes can be:
- Configured using IPv6 addresses to any destination
- Assigned values for distance and cost
- Enabled in the advertising of static routes to IPv6 routing protocols
Access-Oontro|-||st Oonf|gurat|on
You can perform the following access-control-list-related processes on the NetScaler system:
- Create access control lists
- Modify access control lists
- Define access-control-list processing mode
- Define access-control-list priority
- Activate access control lists
- Disable access control lists
- Remove access control lists
Access-control-list entries can be viewed in the Configuration Utility under the Networking node
and under the access-control-list subnode. New access-control-list entries can be added, modified
and removed.
Access control lists are used to restrict access to the Configuration Utility from specific IP addresses
or ranges. Access control lists can be used to force Configuration Utility connections to be allowed
only over secure ports and HTTPS instead of unsecured ports, such as HTTP.
By default, access control lists are assigned priorities in the order in which they are created if an
explicit priority is not specified. The system defaults to assigning priorities by multiples of 10 to
provide spacing between access control lists. Explicit priorities are assigned to access control lists
using the add command when creating an access control list or when using a set command to
modify an access control list. These commands allow you to configure the order in which access
control lists are processed.
S|mp|e Access-Oontro|-||st Oon|gurat|on Oommand-||ne
lnterace}
You can use the following command to create a named access-control-list entry using a source IP
address and destination IP address (add acl or add ns acl is allowed):
add ns acl aclNameaclAction -srcIP IPAddress -destIP IPAddress
Example:
add ns acl test1 ALLOW -srcIP 10.10.1.1-10.10.1.3 -
destIP 10.10.1.4
Oon|gur|ng Deta||ed Access Oontro| ||sts Oommand-||ne
lnterace}
You can use the following command to add an access control list to the system configuration in the
command-line interface:
add ns acl aclNameaclAction
-srcIP operatorsrcIPVal
-srcPort operatorsrcPortVal
-destIP operatordestIPVal
-destPort operatordestPortVal
-TTL PositiveInteger -srcMac MACAddress
-protocol protocol -established -vlan PositiveInteger
-interface InterfaceName -icmpType PositiveInteger
-icmpCode PositiveInteger -priority PositiveInteger
-state ENABLED
Each inbound packet is matched against configured access control lists, and the specified action is
applied to the packet. This command adds the access control list to the configuration space. To
commit this operation, the access control list must be applied. This entry can be enabled or
disabled as needed. The apply ns acls command takes all enabled access-control-list entries and
makes them active on the NetScaler system.
Oreat|ng and Remov|ng Access Oontro| ||sts Oommand-
||ne lnterace}
You can use the following command to enable access-control-list entries in the command-line
interface:
add ns acl aclName aclAction
This command creates the named access control list on the system. The access control list is
enabled but not activated (applied) by default. The apply ns acls command must be run after the
add ns acl command to activate the access control list.
The remove ns acl command is used to remove individual access control lists from the system.
However, the apply ns acls command should be used to apply the change to the NetScaler system.
You can use the following command to remove an access control list in the command-line
interface:
remove ns acl aclName
To remove all access control lists from the system, you can use the clear ns acls command. This
operation does not require an explicit application. You can use the following command to clear all
access control lists in the command-line interface:
clear ns acls
App|y|ng Access Oontro| ||sts Oommand-||ne lnterace}
You can use the following command to commit the access control list to the configuration and to
activate the access control list on the system in the command-line interface:
apply ns acls
This command is required after any modification is made to the access control list; it activates
access control lists and commits changes to the system. After running this command, all existing
sessions are revalidated and any sessions matching a drop command are dropped.
Each access control list has an active status and an applied status. The active status indicates
whether an access control list is ENABLED or DISABLED. The applied status indicates whether the
access control list is APPLIED or NOTAPPLIED (NOTAPPLIED is one word). Applied access
control lists are saved to the configuration, and the active status determines whether traffic is
compared against the access control list.
Any change to an access control list requires that the apply ns acls command is issued to propagate
the change to the configuration. Unapplied access control lists are not saved to the ns.conf file. The
apply ns acls command allows you to change the access-control-list configuration without having
the changes take effect until the apply command is issued. Any access control lists that are not
applied are not retained in the NetScaler system. If access control lists are selectively disabled or
enabled, then you should use the enable ns acl command and disable ns acl commands. Disabled
access control lists are applied but not active. They are retained by the system following a save ns
config command.
You can use the following commands to commit a change to an access control list after running the
apply ns acls command in the command-line interface:
add ns acl
set ns acl
remove ns acl
enable ns acl
disable ns acl
v|ew|ng Access Oontro| ||sts Oommand-||ne lnterace}
You can use the following command to display the access control lists in the command-line
interface:
show ns acl [aclName]
This command shows access control lists on the NetScaler system and the configuration details,
including active and applied status information. If a name is specified, then only that particular
access-control-list information is displayed. If it is not specified, all configured access control lists
are displayed.
You can use the following command to display access-control-list statistics in the command-line
interface:
stat ns acl aclName -detail -fullValues -ntimes PositiveInteger -
logFile InputFilename
Access-Oontro|-||st Pr|or|t|es Oommand-||ne lnterace}
If necessary, you can reassign access-control-list priorities using the renumber access-control-lists
command. This command renumbers the priorities to multiples of ten. For example, 10, 20 and 30
introduce gaps between access-control-list priorities. This command does not affect the behavior of
access control lists. You can use the following command to renumber the access control lists in the
renumber ns acls
Remov|ng Access Oontro| ||sts rom the System
Oommand-||ne lnterace}
The remove ns acl command is used to remove individual access control lists from the system.
However, the apply ns acls command should be used to apply the change to the NetScaler system.
You can use the following command to remove an access control list in the command-line
interface:
remove ns acl aclName
To remove all access control lists from the system, you can use the clear ns acls command. This
operation does not require an explicit application. You can use the following command to clear all
access control lists in the command-line interface:
clear ns acls
Access-Oontro|-||st Syntax Format or D|erent NetSca|er
vers|ons
The NetScaler system supports other access-control-list commands, including:
- Enable
- Disable
- Add
- Remove
- Set
- Unset
- Apply
- Clear
- Renumber
- Show
- Stat
Refer to the Ccmmand Reference Guide, located at support.citrix.com, for further command-line
interface syntax or argument information.
Access-Oontro|-||st Examp|e
The following example demonstrates how to configure an SSH access control list in the command-
line interface. The following values are used in the example:
- NSIP address: 192.168.0.2, 192.168.0.3
- MIP address: 192.168.0.1
- Trusted Network A: 10.10.1.1-20
- Trusted Network B: 172.16.0.1.-20
The following command example shows configuring SSH access control list in the command-line
interface:
add acl bastion1-ssh ALLOW -srcip 10.0.0.1-10.0.0.20 -
destip 192.168.0.1-192.168.0.3 -dstport 22
-protocol TCP
The bastion1-ssh access control list is used to create an access control list to allow traffic from a
trusted network to connect to the NetScaler-owned IP addresses for the high-availability pair over
port SSH. This example secures access to the command-line interface from an allowed range of
trusted bastion hosts.
Rev|ew
1. Which port is commonly used for the HA heartbeat:
a. 162
b. 443
c. 3003
d. 3009
2. Which two statements apply to ACL precedence: (Choose two.)
a. The destination takes priority over the source when there is no priority assigned.
b. The most specific ACL takes priority despite the assigned priority.
c. The first ACL that matches determines how the packet is processed.
d. The packet is affected by multiple ACLs if there is no match.
Modu|e 6
Oonf|gur|ng |oad
Ba|anc|ng
Overv|ew
Load balancing allows the NetScaler system to distribute client requests across multiple servers to
optimize resource utilization. Load balancing improves server fault tolerance and user response
time.
Server performance can degrade in a real-world scenario in which a limited number of servers
provide service to a large number of clients. The NetScaler system uses load-balancing criteria to
prevent bottlenecks by forwarding the client requests to the server best suited to handle them.
Object|ves
- Create and configure system entities.
- Configure service monitoring.
- Create load-balancing virtual servers.
- Configure advanced load-balancing options and methods.
- Manage services and virtual servers.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 6: Oon|gur|ng |oad Ba|anc|ng 129
Ent|ty Management
Entities in the NetScaler system are any configurable objects that are used with NetScaler features.
Each entity is given a name when created. The entity name used to associate the entity with a
NetScaler feature. Entity names on the NetScaler system can have a maximum of 127 characters.
The most commonly used entities are listed below.
Server A server entity represents a physical server to which the NetScaler
system will mange or distribute traffic. A server is identified by the
IP address of the physical server. A server entity is also created
automatically when you configure a service, which is associated with
a server entity.
Service A service entity is a logical representation of a server and identifies
a particular service or application running on the server. A service is
defined by an IP address, port, and protocol. The service identifies
the type of traffic associated with a given server. Multiple services
may be configured for the same server. For example, a server can be
running HTTP, FTP, and TCP services/applications. The NetScaler
system directs traffic to the server using the appropriate service.
When a service is created, it is associated with a server object. For
load balancing, services are bound to virtual servers. The virtual
servers will then load-balance traffic across the available servers,
based on these services.
Services are tracked as being in an UP or DOWN state using
monitors. When a service is in a DOWN state, the virtual server
does not direct traffic to the service. The server is bypassed for load
balancing for the traffic type (or application) identified by the
service.
Virtual Server A virtual server is an aggregated system entity that usually
comprises multiple servers and services. Rather than traffic being
routed directly to the server, it is sent to a virtual server, which then
makes a decision about which server to forward the traffic to based
on the services bound to the virtual server. The state of the virtual
server determines whether the client requests are accepted.
130 Modu|e 6: Oon|gur|ng |oad Ba|anc|ng Copyr|ght 2011 C|tr|x Systems, lnc.
Monitor Service monitors (also known as health checks) are used by the
NetScaler system to periodically check the health of a service to
determine its state. The monitor sends a probe to a specified
destination along with a specified request and an expected service
response. Based on the response received by the probe, a monitor
can mark the state of a service as UP or DOWN and either allow or
deny traffic requests for a particular service.
Oreat|ng Servers
Before a NetScaler system can begin load balancing for physical servers in the environment, server
and service entities that represent these servers must first be created using either the Configuration
Utility or the command-line interface.
Servers can be created explicitly as named entities before creating services. The service is then
created and references the existing server object. However, if the service is created first, the system
automatically creates a server object based on the IP address used when configuring the service.
Create a Server
Create a server entity on the NetScaler system by specifying a server name and IP address:
Configuration Utility Under the Load Balancing > Server node
location
Command-line syntax
add server serverName (IPAddress | domain)
Oreat|ng Serv|ces
A service entity defines a particular service running on a server object, identified by the IP address,
service type and port on which it is running.
A service represents an application running on a server and is identified by a unique IP
address/port combination. The service defines the traffic type between the NetScaler system and a
server. Services are associated with a load-balancing virtual server by binding services to the virtual
server. Services must be bound to virtual servers before the NetScaler system is able to load-balance
incoming traffic between servers.
When the service is created, the service type is specified identifying the protocol/traffic type in use.
The different service types available on the NetScaler system provide the ability to handle the traffic
appropriately. Service types on the NetScaler system include:
- HTTP
- SSL
- FTP
- DNS
- TCP
- UDP
- ANY
The use of both server objects and service objects allows the application running on a server to be
abstracted from the physical entity. This abstraction allows multiple services running on a single
server to be treated independently of each other.
Create a Serv|ce
Create a service entity on the NetScaler system by specifying the service, the service type and the
port to which the service is assigned.
Configuration Utility Under the Load Balancing > Services node
location
Command-line syntax
add service serviceName IPAddress serviceType
port
The add service command requires as a parameter either the IP address of the physical server or
the name of an existing server entity created on the NetScaler system. To use the server name, you
must first add the server entity. By using the IP address instead of the name, you automatically
create a server entity when adding the corresponding service.
Oreat|ng v|rtua| Servers
A virtual server provides the client access to the actual servers behind the NetScaler system. The
client connects to a virtual server which consists of an IP address, port and protocol combination
that accepts incoming traffic. The virtual server is bound to a number of physical services running
on physical servers. These physical services consist of the IP address and port of the physical server.
The client request is routed from the virtual server to the physical server based on the service that
handles the inbound request. DNS is not required to make an arbitrary round-robin load-balancing
decision; instead, DNS returns the VIP address of the load-balancing virtual servers to the client.
Multiple load-balancing virtual servers can be configured on the same VIP address as long as the
combination of the VIP address, port and service are unique.
Create a v|rtua| Server
Create a virtual server on the NetScaler system by specifying the server name, the VIP address, the
protocol and the port number:
Configuration Utility Under the Load Balancing > Virtual Server node
location
Command-line syntax
add lb vserver vserverName serviceType
IPAddress port -
persistenceType persistenceType
B|nd|ng Serv|ces
Most entities in the NetScaler system can be created independently but will not serve a function
until they are bound to another related entity.
Bind a service to a virtual server on the NetScaler system by specifying the virtual server and
activating the service:
location
Command-line syntax
bind lb vserver vserverName serviceName
Mon|tors
Monitoring of a service will not take place until the monitor is bound to a service. The NetScaler
system supports multiple monitors for any given service. When a service is bound to multiple
monitors, the status of the service is based on the results sent by all the monitors. For example, a
service is marked as UP only if all monitors associated with that service return an UP status after
probing. If any monitor returns a DOWN status, the service is marked as DOWN. Additionally,
monitor weights and thresholds can be configured for a service, which specifies that some but not
all the monitors must pass a health-check probe for a service to be marked as UP.
Monitors are associated with every service to verify that the service is UP and available. Depending
on the type of service, different kinds of monitoring may be required.
|oad-Ba|anc|ng Traff|c Types
A load-balancing virtual server can be configured to support any number of traffic types. Multiple
load-balancing servers can be configured on the same virtual IP address but for different services.
App||cat|on Protoco|s
HTTP, FTP, DNS, NNTP, and HTTPS are all application-layer protocols for which switching is
performed at the request level rather than at the connection level. Request level switching allows
greater granularity in the load-balancing process. The SSL setting represents HTTPS and instructs
the virtual server to terminate and decrypt the HTTPS connection. You can configure a load-
balancing server as type SSL and associate it with a service of type HTTP. The traffic from the user
is encrypted to the NetScaler system, and plain text HTTP traffic is forwarded from the NetScaler
system to the server.
Sess|on Protoco|s
The load-balancing server can be associated with a session protocol, either TCP or UDP. TCP-
based protocols other than HTTP can also be secured using SSL. If the incoming traffic is SSL
encrypted but not HTTP, a virtual server of type SSL_TCP is created. This server decrypts the
traffic on arrival and forwards it based on the protocols defined on the services bound to it.
Genera| Tra|c
The ANY traffic type is used for any TCP, UDP, and Internet Control Message Protocol (ICMP)
service. The configuration of ANY is used with some firewall load-balancing and link load-
balancing configurations where load balancing is time-based.
The following table provides an overview of the load-balancing traffic types.
Traffic Type Application protocols Session protocols General traffic type
ANY
- HTTP - TCP
- FTP - UDP
- DNS - SSL_TCP
- NNTP
- SSL (HTTPS)
- RTSP
- SSL_BRIDGE
Serv|ce Mon|tor|ng
The purpose of service monitoring is to check the state of the services periodically. Monitors specify
the types of requests sent to a service and the expected response from the service; this probe is
known as a health check. If a service responds appropriately to the health check within the specified
period of time, the state is marked as UP and that service continues to have requests directed to it.
If, however, a service fails a health check, the state is marked as DOWN, and it no longer receives
requests.
Each service defined on the NetScaler system requires some form of monitoring to ensure that
requests are not sent to an unavailable service. Depending on the type of service, different kinds of
monitoring may be required. Each monitor type requires its own set of parameters.
The function of a particular service must be considered when defining monitors. Is a completed 3-
way handshake enough to verify that the service is running: Does the service rely on other services
in the enterprise to function: While the default monitors facilitate simple deployments, many
environments are better served with the additional types of monitors available in the system.
The state of a service is maintained across high-availability pairs.
B|nd|ng Mon|tors
Every service requires a monitor to determine its state. A monitor must be bound to a service to
ensure the service can receive traffic.
Bind a monitor on the NetScaler system by specifying the service and the monitor to be bound:
Configuration Utility Under the Load Balancing > Service node
location
Command-line syntax
bind lb monitor monitorname servicename
Deau|t Mon|tors
When a service is created, one of two types of default monitors is automatically enabled if no other
monitor is specified. Depending on the service type, either the TCP-default or PING-default
monitor is enabled. Default monitors cannot be bound, unbound, removed, or changed.
The following table provides a list of the default pre-configured monitors.
PING HTTP-ECV TCPS TCP-ECV LDNS-TCP
TCP UDP-ECV HTTPS FTP LDNS-DNS
HTTP DNS LDNS-PING TCPS-ECV
TCP-Deau|t
The TCP-default monitor is associated with all TCP service types. When a TCP-default monitor is
used, the NetScaler system establishes a TCP connection with the service specified by the monitor
when performing a health-check probe.
If the system observes TCP traffic flow to the service, TCP monitoring requests are not sent.
When a monitor is bound to a service, the default monitor is automatically disabled.
When all monitors are unbound from a service, the default monitor is automatically re-
enabled.
While default monitors may serve simple deployments, most deployments should use one of the
system-defined monitors to ensure the monitor meets the needs of a particular service.
PlNG-deau|t
The PING-default monitor is associated with all non-TCP service types. The following process
provides an overview of the ping process:
1. The NetScaler system sends an ICMP echo request to the service specified by the monitor.
2. If the NetScaler system receives an ICMP echo response from the service, the service is marked
as UP. If not, the service is marked as DOWN.
Mon|tor Parameters
Two types of parameters can be configured for monitors:
- Parameters that are standard and apply to all monitors, regardless of type
- Parameters that are specific to the type of monitor being defined
Standard Parameters
Standard parameter types apply to all load-balancing monitors, regardless of type. Each of the
parameters can be set independently for individual monitors. For example, an HTTP monitor can
be configured with a response timeout of 13 seconds, while another HTTP monitor may be
configured with a response timeout of 10 seconds.
The following standard parameters can be applied to any monitor, regardless of type:
Interval The interval parameter specifies the frequency at which the health-
check probe is sent to a service.
Response Timeout The response-timeout parameter specifies the interval of time for
which the system waits before it marks the health check probe as
FAILED. As long as the server responds within the response
timeout period, the server state will remain UP, and the service will
participate in load balancing. If a service fails the health check by
not responding within the response timeout period, the monitor
failed count is incremented. An increment of the monitor failed
count constitutes one of a number of retries as specified in the
retries parameter. A successful response resets the monitor failed
count to zero.
Down Time The down time parameter specifies the duration for which the
system waits before sending the next health-check probe once a
service is marked as DOWN. The default down-time value is 30
seconds, except for LDNS monitors, which have a default down
time value of 20 seconds.
Retries The retries parameter specifies the number of consecutive health-
check probe failures after which the system marks the service as
DOWN. The default retries value is 3.
Success Retries A monitor periodically evaluates the state of services to indicate
whether it is UP or DOWN. If the monitor did not receive a
response in the configured time and if the number of retries fails,
the service is marked as DOWN. The monitor probes may fail
intermittently. The monitor evaluates the state of the service as
DOWN, making it unavailable. When you configure the success-
retries parameter, the monitor marks the state of the service as UP
only when the monitor probe succeeds for a consecutive number of
retries.
Failure Retries The failure retries parameter specifies the number of failed probes
that are required to mark the state of a service as DOWN.
Reverse The reverse parameter specifies whether a monitor is configured for
reverse conditions. When the reverse parameter is set to YES, a
health check probe will fail if the condition of the monitor is
satisfied. In normal conditions, a probe will fail when the conditions
of a monitor are not met. The reverse parameter is disabled by
default.
Secure The secure parameter allows the NetScaler system to monitor SSL
services. When the state of the parameter is set to YES, the
NetScaler system establishes a TCP connection with the destination
of the monitor and then performs as SSL handshake with the server.
The secure parameter is disabled by default.
Executing the show service command for a service
monitor displays:
- The total number of probes made by the monitor
- The total number of failed responses
- The current contiguous failed response count
- The result of the most recent response
Oreat|ng Mon|tors
Create a monitor on the NetScaler system by specifying the monitor name, monitor type and values
for the appropriate parameters:
location
Command-line syntax
add lb monitor monitorName type [-
interval integer [units]] [-
resptimeout integer [units]][-
Retries integer] [-
successRetries integer] [-
failureRetries integer] [-downTime integer
[units]] [-reverse ( YES | NO )] [-
transparent ( YES | NO )] [-
secure ( YES | NO )]
The default response timeout unit is seconds. To change the unit to milliseconds, seconds
or minutes, the optional values of msec, sec or min can be appended following the integer
value.
HTTP Mon|tor|ng
HTTP monitors are used to verify the health of an HTTP service. The following process describes
how HTTP monitoring occurs on the NetScaler system:
1. The NetScaler system establishes a TCP connection with the service destination specified by the
monitor.
2. The NetScaler system sends an HTTP request to the service.
3. The NetScaler system compares the received response to a set of acceptable response codes that
were configured in the monitor parameters.
4. If the response matches any configured responses, the probe is a success. If the response does
not match any configured responses, the probe fails.
If the response code parameter is left empty, any response from the service is considered a
match. The NetScaler system looks for matching response codes in the first 24 KB of data
in the body of the response.
The parameters for the HTTP monitor can be configured as follows:
HTTP Request The HTTP request parameter specifies the HTTP request to be sent
to the service bound to the monitor.
Default value: HEAD /
Response Codes The response codes parameter specifies a set of HTTP response
codes expected from the service bound to the monitor.
Default value: 200
EOv Mon|tor|ng
Extended content verification (ECV) monitors are used for verifying content in HTTP, TCP, and
UDP payload. ECV monitors are considered kernel monitors because they are basic, high-
performance probes that originate from the BSD kernel. General limitations of ECV monitors
include:
- Having one request/response
- Having 127 characters in the probe request
- Having only the first 24 KB of the probe response parsed
For HTTP and TCP services, predefined Extended Content Verification (ECV) monitors are
available. For ECV monitors, it is not enough to see that a TCP connection was accepted; some
particular reply in the connection is required to mark the service as UP. For these monitors, a
request string is configured along with an expected reply string. If the reply string received by the
monitor matches the expected string, then the service is marked as UP.
HTTP-EOv and TOP-EOv Mon|tor|ng Process
The -secure (YES | NO) option allows the NetScaler system to monitor SSL services. TCP-ECV and
HTTP-ECV probes include:
- TCP connection
- SSL handshake
- Encrypted server data (TCP-ECV probes only)
- Encrypted HTTP request (HTTP-ECV probes only)
The process describes how an HTTP-ECV or TCP-ECV monitor performs a health-check probe:
1. The NetScaler system establishes a TCP connection with the service destination specified by the
monitor.
2. The NetScaler system sends data specified in the send string parameter to the service.
3. The NetScaler system compares the HTTP response or data received by the service to the
expected response specified by the receive string parameter.
4. The probe is a success if the response matches the data in the receive string parameter. The
probe fails if the response does not match.
If the receive string parameter is left empty, any response from the service is considered a
match. The NetScaler system looks for matching responses in the first 24 KB of data in
the body of the response.
HTTP-lN|lNE Parameters
Unlike a monitor type, HTTP-INLINE monitors analyze live client traffic to a service instead of
sending probes to servers. When no real traffic is sent to the server, the configured URL is used to
probe the server like a regular HTTP monitor. Like an HTTP monitor, HTTP-INLINE monitors
have timeout values and a retry for failures. Therefore, when the number of retries exceeds the
configured value, the state of the monitor and service are changed.
HTTP-INLINE monitors are only configured for HTTP and HTTPS service types.
Parameters that can be configured for HTTP monitors include:
HTTP request The HTTP request parameter specifies the HTTP request to be sent
to the service bound to the monitor.
Default value: HEAD /
Response codes The response codes parameter specifies a set of HTTP response
codes expected from the service bound to the monitor.
Default value: 200
Action The action parameter specifies the action to take upon failure. The
service is marked as DOWN and no longer receives traffic. Any
persistent connections to the service are discarded. A log entry is
made in the /var/log/ns.log file.
Reverse Oond|t|on Mon|tor|ng
The reverse parameter specifies whether a monitor is configured for reverse conditions. When the
reverse parameter is set to YES, a health-check probe will fail if the condition of the monitor is
satisfied. In normal conditions, a probe will fail when the conditions of a monitor are not met.
For example, an HTTP-ECV monitor is configured with a send string of GET /FILE, a receive
string of ERROR, and the reverse parameter is set to YES. If the NetScaler system sends a probe
that returns a response with the string ERROR, the probe will fail. If the response does not match
ERROR, the probe is successful.
The reverse parameter is disabled by default.
Sett|ng Mon|tor Thresho|ds
The NetScaler system uses monitor thresholds to determine the state of services. The threshold
value is used to minimize the impact of spikes in load from shutting down a service.
The threshold value from the monitor specifies a value that determines the state of the service as
UP. The NetScaler system determines the state of the service as UP only when the sum of the
monitors that are UP is equal to or greater than the threshold value you configured on the service.
Set a monitor threshold for a service on the NetScaler system:
Configuration Utility Under Load Balancing > Services
location
Command-line syntax
set service ServiceName -monThreshold Value
|oad-Ba|anc|ng Topo|ogy
In a load-balancing topology, a NetScaler system is logically located between the client and the
server farm. Load balancing is used to manage traffic flow to the servers in the server farm.
|oad-Ba|anc|ng Process
The figure and the following process describe the load-balancing process:
1. The NetScaler system receives a user request.
2. A virtual server processes the request.
3. The monitor checks the service to determine whether it is available.
4. The load-balancing subsystem sends the request to the service.
|oad-Ba|anc|ng Methods
Load-balancing decisions for incoming traffic are made based on the load-balancing method
assigned to the service. The following sections provide available load-balancing methods.
|east Connect|ons
Least connections is the default load-balancing method for the NetScaler system and is the most
accurate method to distribute load intelligently. The least connection calculation used to determine
the service with the fewest number of connections is calculated differently depending on the service
type. The following table provides an overview of the services used by the least connections load-
balancing method.
Serv|ce Descr|pt|on
TCP, HTTP, HTTPS, SSL_TCP Uses established, active connections to a service,
and connections to a service waiting in the
Surge Queue for the least connections
calculation
UDP Uses all sessions between the client and the
physical server for the least connections
calculation
These sessions are logical, time-based entities
and are created on the UDP packet that arrives
first. If weights are configured, they are taken
into account when server selection is completed.
Round Rob|n
Round robin is the simplest load-balancing method, distributing traffic based on a server-rotation
system, regardless of load.
An incoming request is sent to Server 1, the next request is sent to Server 2, the next request is sent
to Server 3, and when all servers have received a request, the cycle begins again.
This method is sufficient if all requests result in the same load on servers, but in most cases, a more
robust load-balancing method based on metrics should be used.
|east Bandw|dth
The least-bandwidth load-balancing method distributes traffic based on the amount of bandwidth
being directed to each service. When this load-balancing method is configured, the NetScaler
system routes traffic to the service currently serving the smallest amount of traffic. If weights are
configured for a service, they are taken into account in the calculation to determine server selection.
|east Packets
The least-packets load-balancing method distributes traffic based on the rate of packet traffic to a
service. The NetScaler system will make a load-balancing session based on the service currently
serving the fewest packets per second. If weights are configured for a service, then they are taken
into account in the calculation to determine server selection.
|east Response T|me
The least-response-time load-balancing method can be used with HTTP or HTTPS virtual servers
to distribute traffic based on the average response time of each service. The response time, also
referred to as Time to First Byte (TTFB), is the time interval between sending a request packet to a
service and receiving the first response packet. A virtual server configured for least-response-time
load balancing will direct traffic to the service with the shortest average response time. If weights
are configured for a service, they are taken into account in the calculation to determine server
selection.
The response-time calculation is always historical. As a result, it may not be a good metric for
environments that have traffic that fluctuates greatly over short periods of time.
Hash|ng
The hashing load-balancing method refers to a number of different load-balancing methods that all
use a hash value. The hash value is calculated based on a particular aspect of the client request, and
the resulting value determines where to forward traffic. Hashing methods allow the virtual server to
categorize requests and direct these requests types to the same physical resource. Depending on the
hashing method used, the type of the requests can be controlled.
Token
The token load-balancing method distributes traffic based on the value of a token extracted from a
client request. For subsequent requests that contain the same token, the virtual server chooses the
same physical server that handled the initial request.
Token-based load balancing is content-aware and operated differently depending on the type of
service being used. For HTTP and HTTPS services, the token is found in the HTTP headers or
URL and is configured through an expression. For TCP services, tokens are extracted from the TCP
payload.
The advantage of token load balancing is that it can be used across VIP addresses to ensure that
requests within the same token are directed to the same physical servers, regardless of the protocol.
The disadvantage is that it works only on the request. Token load balancing cannot tie the token
from the request to the server it was sent from, so token load balancing is generally not useful for
jsessionid or other server-set tokens.
- This list of load-balancing methods covers only the basic methods.
- Server Application State Protocol (SASP) is supported for all load-balancing methods
that use service weights. Refer to Citrix êtScaler Traffic Management Guide on the
http://support.citrix.com Web site for a complete list of load-balancing methods or
for more information on SASP load balancing.
Serv|ce We|ghts
Service weights allow you to more closely manage load-balancing decisions in an environment.
Because services can be assigned different weights, the values are compared, and traffic is divided
based on the effective weight ratio. Service weights are useful when load balancing the traffic in an
environment where a new server has been added that can handle more traffic than other servers.
Service weights can be configured for the following load-balancing methods:
- Least connections
- Round robin
- Least bandwidth
- Least packets
- Least response time
Serv|ce We|ghts Examp|e
Services A and B with respective weights of 20 and 30 are configured to use round-robin load
balancing. In this case, traffic would be distributed as follows: AABBBAABBB. The same net
distribution as 20 Service A requests followed by 30 Service B requests is accomplished but
without inundating one server and then the other.
Create a service weight on the NetScaler by specifying the weight value for the appropriate servers:
Configuration Utility Under the Load Balancing > Virtual Servers node
location
Command-line syntax
add lb vserver vserverName -
weight positiveInteger serviceName
Sess|on Pers|stence
While load-balancing decisions are normally made based on the configured load-balancing method,
applications may require a client to connect to the same server for all subsequent requests, such as
with shopping carts used on e-commerce Web sites. Session persistence is configured to ensure that
all requests from a client are directed to a particular server, regardless of the load-balancing
method. Persistence can be configured for each load-balancing virtual server, as well as for groups
of load-balancing virtual servers.
- When persistence is used, and a service is selected that is not in the UP state, a new
server selection is made based on the configured load-balancing method. The new
server becomes persistent for subsequent requests from the client.
- Persistence is not configured by default.
Session persistence is not the same as persistent TCP connections. Persistent TCP connections are
required for connection multiplexing and reuse of layer 4; session persistence operates at layer 7, to
send users to the server that has their stored session information.
Configure session persistence on the NetScaler system by selecting the virtual server and specifying
the appropriate persistence method:
location
Command-line syntax
set lb vserver vserverName -
persistenceType (sourceip |cookieInsert|
sslSession | rule | urlPassive |
customServerID | destip | srcipdestip
|callid | none) timeout -minutes
Non-Pers|stent O||ents
An RTSP session can spread across multiple TCP connections (non-persistent cases), which can be
easily addressed because the server IP address and port are encoded in the session ID or through
session entries maintained on the NetScaler system.
Pers|stence Methods
Persistence methods are determined based on the method assigned to the service. The following
sections provide information about available persistence methods.
Cook|e-lnsert Pers|stence
Cookie-insert persistence inserts an HTTP cookie in the client responses. The cookie is then used
to direct subsequent requests from the client to the same physical server that handled the initial
request. The cookie contains the IP address and port number of the service to which the client
request is directed.
If a client is unable to store a cookie, subsequent requests from that client will not have a
cookie and session persistence will not be honored. A load-balancing decision will be
made based on the configured method.
The timeout value for cookie-insert persistence is the period of inactivity for a session. If the
timeout value is set to 0, the session never expires in the NetScaler system; however, the expiration
time is dependent on the client software used, and cookies usually expire when the client software
is closed.
If cookie-insert is configured as the primary persistence method and source-IP-address is
configured as the backup, different timeout values can be set for each method.
Backup persistence is the method used when the primary persistence method fails. When cookie-
insert persistence is used, source-IP-address persistence can be configured as the backup persistence
method in order to maintain persistence sessions. For example, if a client is using a Web browser
that does not support cookies, persistence is based on the source IP address of the client instead.
Source-lP-Address Pers|stence
Source-IP-address persistence routes a client request based on the configured load-balancing
method, and then directs all subsequent requests from the same IP address to the physical server
that handled the initial request.
Traffic passing through a NAT device will appear to originate from the same IP address.
If most client requests flow through a NAT device, source IP address persistence may not
be the most efficient load-balancing method because every request will be directed to the
same physical server even though the requests originate from multiple clients.
Source-IP-address persistence sessions are stored in a persistence table, which consumes system
resources. A maximum of 236,000 entries can be stored in the persistence table at any one time.
The timeout value for source-IP-address persistence is the period of inactivity for a session. Once
the timeout value is reached, the session is discarded, and server selection resumes based on the
configured load-balancing method.
If cookie insert is configured as the primary persistence method, and source-IP-address is
configured as the backup persistence method, different timeout values can be set for each
method.
SS| Sess|on lD Pers|stence
SSL-session-ID persistence is based on the arriving SSL session ID in a request, which is part of the
SSL handshake process. Requests containing the same SSL session ID are directed to the physical
server that processed the initial request.
SSL-session-ID persistence sessions are stored in a persistence table and therefore consume system
The timeout value for SSL-session-ID persistence is the period of inactivity for a session. Once the
timeout value is reached, the session is discarded and server selection resumes based on the
SSL-session-ID persistence is not generally recommended as many Web browsers
renegotiate the SSL session as often as every two minutes. In such a case, the persistence is
often broken. The SSL session is generally not long enough to use as a persistence criteria
for typical Web sessions.
R| Pass|ve Pers|stence
URL-passive persistence looks for an embedded server ID in client requests and then directs the
request to the physical server that corresponds to the ID. Because this persistence method does not
consume system resources, it can accommodate an unlimited number of persistent clients.
A server ID containing the IP address and port number of a physical server is embedded into the
URL query of HTML links. When subsequent requests are made from the same client, the system
extracts the server ID from the request and routes the traffic to the physical server that processed
the initial request.
URL-passive persistence requires an expression to be configured that specifies the location of the
server ID in the client request. URL-passive persistence can accommodate an unlimited number of
persistent clients because it does not consume system resources. URL-passive persistence does not
use a timeout value. Persistence sessions are maintained as long as the server ID can be extracted
from client requests.
Custom Server lD Pers|stence
Custom-server-ID persistence looks for an embedded server ID in client requests and then directs
the requests to the physical server that corresponds to the ID. The server ID is an administratively
configured integer, ranging from 0 to 63,333, which is embedded into the URL query of HTML
links. When a request is received that contains a server ID, the request is routed to the
corresponding physical server.
Custom-server-ID persistence requires an expression to be configured that specifies the location of
the server ID in the client request.
If the server ID cannot be extracted from a request, a load-balancing decision is made
based on the configured load-balancing method.
Custom-server-ID persistence does not use a timeout value. Persistence sessions are maintained as
long as the server ID can be extracted from client requests.
Ru|e-based Pers|stence
Rule-based persistence evaluates a client request against a configured rule and creates a persistence
session if the request is a match. If a request matches the contents of the rule, a persistence session
is created, and all subsequent matching requests are directed to the physical server used to process
the initial request. If the request does not match, it is routed to a server based on the configured
load-balancing method.
Rule-based persistence requires an expression to be configured that defines the rule to be used in
matching.
Rule-based persistence sessions are stored in a persistence table and, therefore, consume system
The timeout value for rule-based persistence is the period of inactivity for a session. Once the
timeout value is reached, the session is discarded and server selection resumes based on the
Dest|nat|on lP Address Pers|stence
Destination-IP-address persistence is used with link load balancing. When this persistence method
is used, the system selects a service based on the configured load-balancing method and then directs
all subsequent packets that are destined to the same IP address as the first packet to the same
service.
The timeout value for Destination-IP-address persistence is the period of inactivity for a session.
Once the timeout value is reached, the session is discarded, and server selection resumes based on
the configured load-balancing method.
Source/Dest|nat|on lP Address Pers|stence
Source/destination-IP-address persistence is used with intrusion-detection-system (IDS) load
balancing. When this persistence method is used, the system selects a service based on the
configured load-balancing method and then directs all subsequent packets traveling from the same
source to the same destination to the same physical service that received the first packet.
The timeout value for source/destination-IP-address persistence is the period of inactivity for a
session. Once the timeout value is reached, the session is discarded and server selection resumes
based on the configured load-balancing method.
Pers|stence Tab|es
Session persistence information for each session is stored on the NetScaler system in a persistence
table. The following information is displayed in the table.
- Persistence type
- Source IP address
- Destination IP address
- Destination port
- Virtual server name
- Persistent session timeout
- Reference count
- SIP CALLID
View session persistence information on the NetScaler system by accessing the persistence table:
Configuration Utility Under the System > Diagnostics > Monitoring node
location
Command-line syntax
show ns persistencesession
Add|t|ona| |oad-Ba|anc|ng Opt|ons
In addition to the basic load-balancing options already discussed, the following advanced load-
balancing options can be configured on the NetScaler system.
Sp|||over
Spillover occurs when a virtual server exceeds a set threshold value, and new connection requests
are diverted to a backup virtual server.
The following table provides an overview of the three types of spillover.
Sp|||over Descr|pt|on
Connection-based Connection-based spillover occurs when the
number of active connections or SSL sessions
exceeds the configured threshold value, which is
applicable for both load-balancing and content-
switching virtual servers.
Connection-based spillover is available
only on address- and content-based
virtual servers.
Bandwidth-based Bandwidth-based spillover occurs when the
bandwidth of a virtual server exceeds the
configured threshold value, which is applicable
for both load balancing and content switching
virtual servers.
Dynamic Dynamic spillover occurs when the number of
client connections to a virtual server exceeds the
sum of the Max Client values on all of the
active services that are bound to the virtual
server. It is only applicable for load-balancing
virtual servers.
Dynamic spillover must be enabled before it can
be used and is available only on address-based
virtual servers.
Services bound to the virtual server should be
configured with appropriate Max Client values.
For example, if the Max Client value is set to 0,
the spillover limit is treated as infinity, and
spillover will never occur.
Max C||ent and Max Bandw|dth
The Max Client setting specifies the maximum number of open connections that can be made to a
service. The Max Bandwidth setting specifies the maximum bandwidth in Kbps that can be used by
a service. This setting is used as part of bandwidth-based spillover.
Red|rect R|
An option for managing a disabled virtual server or one whose state is set to DOWN is to configure
a redirect URL that sends clients to a site that communicates the site status. A redirect URL can be
used on any virtual server of type HTTP or HTTPS and can be either a local or remote link.
If a complete URL is provided in the redirect setting, the HTTP Redirect sends the client to the
exact URL specified. If the URL is incomplete, the path that the client was requesting is appended
to the redirect URL, and the client is sent to that composite resource.
Backup v|rtua| Servers
If a virtual server goes down for any reason, then traffic can automatically be redirected to a backup
virtual server if one is configured. Backup virtual servers are often used to inform clients about site
outage or maintenance.
When the original virtual server is restored to UP status, new connections are once again directed
to it. The virtual server designated as a backup may have a backup virtual server of its own. This
nested backup virtual server configuration may exist up to ten layers deep.
Advanced |oad-Ba|anc|ng Methods
Three advanced load-balancing methods that are available on the NetScaler system are least-
response-time based on monitoring, token-based load balancing, and hash load balancing. The
least-response-time method chooses the service with the minimum average response time. Token
load balancing is based on matching a token with the request or TCP payload. Hash load balancing
includes several methods that use a hash value of some aspect of the client request to determine
where to forward the request.
The NetScaler hashing types include:
- URL hashing
- Domain-name hashing
- Source-IP-address hashing
- Destination-IP-address hashing
- Source/destination IP hashing
Token
A token is created based on the client request, and the request is forwarded to a service based on
the results of that token. The exact choice of variables and token configuration are user
configurable. An advantage of this kind of load-balancing method is that it works across different
virtual servers. For example, it ensures that requests for HTTP and FTP are served from the same
physical server, even though they are advertised through two different virtual servers.
Token-based |oad-Ba|anc|ng Examp|e 1
You can use the following command-line expression to load balance physical servers based on the
token inside each request URL query:
URLQUERY contains token=token -l 2
This command tells the NetScaler system to look for the token inside the URL query after matching
the string token=token. The length of the token is two bytes.
For HTTP services, the NetScaler system looks for a configured token in the first 24 KB of the TCP
payload. For other TCP services, the system looks for the configured token in either the first 16
packets or the first 24 KB, whichever is shortest. The location and size of the token are configured
with options -dataoffset and -datalength of the add lb vserver or the set lb vserver commands.
This load-balancing method is used across virtual IP addresses of different types. It ensures that the
requests and the same token are directed to the physical services on the same physical servers
regardless of the protocol.
Token-based |oad-Ba|anc|ng Examp|e 2
The figure illustrates a NetScaler system with two virtual IP addresses, VIP_HTTP and VIP_TCP,
on two physical servers, S1 and S2.
Each server has two HTTP services, S1_HTTP and S2_HTTP, listening on port 80 and two TCP
services, S1_TCP and S2_TCP, listening on a different port. The TCP services are bound to
VIP_TCP, and the HTTP services are bound to VIP_HTTP.
A request is sent to VIP_HTTP with the token AA, and the VIP_HTTP chooses the service
S1_HTTP, bound to the physical server S1, to process the request. A different request is sent to
VIP_TCP with the same token, AA, and the VIP_TCP directs this request to the service S1_TCP
bound to the same physical server, S1.
Hash |oad-Ba|anc|ng
Hashing comprises a number of different methods that all use a hash value of a particular aspect of
the client request to determine where to forward the request.
Hashing methods allow the load balancer to direct similar requests to the same physical resource.
Depending on the type of hashing, the similarity of the requests can be controlled. For example,
source IP address hashing allows clients from the same subnets to be directed to the same service.
URL Hashing The NetScaler system chooses a service based on the hashed value of
an incoming HTTP URL. By default, the NetScaler system calculates
the hash value based on the first 80 bytes of the URL. To use a
different number of URL bytes to calculate this value, you can use
the following optional argument with either the add lb vserver
command or set lb vserver command in the Command-line
Interface:
-hashLength PositiveInteger
The -hashLength argument value can be set as less than or
more than the default value.
Domain-Name Hashing The NetScaler system chooses a service based on the hashed value of
the domain name in the HTTP request. The domain name is taken
either from the incoming URL or from the host header of the
HTTP request. If the domain name appears in both the URL and
the host header, the NetScaler system gives preference to the URL.
If domain name hashing is configured and an incoming
HTTP request does not contain a domain name, the
NetScaler system defaults to the round robin load-
balancing method for that request only.
The hash value is calculated by taking the name-length or hash-
length value, whichever is smaller. By default, the NetScaler system
calculates the hash value from the first 80 bytes of the domain
name. To specify a different number of bytes in the domain name
when calculating the hash value, you must use the -hashLength
Positive_Integer optional argument with either the add lb vserver
command or the set lb vserver command in the command-line
interface.
Source-IP-Address When source-IP-address hashing is configured as the persistence
Hashing method, the NetScaler system routes a client request based on the
configured load-balancing method and then directs all subsequent
requests from the same IP address to the physical server that
handled the initial request.
Traffic passing through a NAT device will appear to
originate from the same IP address. If most client requests
flow through a NAT device, source-IP-address persistence
may not be the most efficient load-balancing method
because every request will be directed to the same physical
server even though the requests originate from multiple
clients.
Source-IP-address persistence sessions are stored in a persistence
table, which consumes system resources. A maximum of 236,000
entries can be stored in the persistence table at any one time.
The timeout value for source-IP-address persistence is the period of
inactivity for a session. Once the timeout value is reached, the
session is discarded, and server selection resumes based on the
If cookie insert is configured as the primary persistence
method, and source IP address is configured as the backup
persistence method, different timeout values can be set for
each method.
Destination-IP-Address The NetScaler system chooses a service based on the hashed value of
Hashing the destination IP address in the HTTP header. You can use the -
netmask netmask optional argument with either the add lb server
command or the set lb vserver command to mask the destination IP
address before calculating the value in the command-line interface.
All IP addresses belonging to a particular network are directed to
the same server.
This method is appropriate with the cache redirection
feature of the NetScaler system.
Source/Destination-IP- The NetScaler system chooses a service based on the hashed value of
Address Hashing the source and destination IP addresses in the HTTP header.
Hashing is symmetric, thus yielding the same value if the source
and the destination IP addresses are reversed. The symmetrical
ensures that all packets flowing from a particular client to the same
destination are directed to the same server. This load-balancing
method is used in intrusion-detections-systems load balancing.
Least Response Time Based The NetScaler system chooses the service with the minimum
on Monitoring average response time. The least response time based on monitoring
(LRTM) load-balancing method uses the existing monitoring
infrastructure. This load-balancing method requires application-
specific monitors to be bound to each service, and LRTM mode to
be enabled on these monitors. The NetScaler system then uses the
response times to monitor probes to make load-balancing decisions.
This method can be used to select non-HTTP and non-HTTPS
services and can also be used when several monitors are bound to a
service. The virtual server uses all monitor response times to
calculate an average response time for each physical service.
The same set of monitors should be bound to all services.
Failure to do so might result in one service receiving more
traffic than the other services.
Some subtleties exist in the process of generating a response time.
These subtleties must be considered when configuring LRTM load
balancing on a NetScaler system.
Monitors determine response times using different protocols. While
the response time for the PING monitor is the time difference
between the ICMP echo request and ICMP echo response, the
response time for the TCP monitor is the time difference between
the SYN request and SYN+ACK response. If the calculations on
which the response times are based are understood, it is easier to
determine whether LRTM load balancing meets the specified needs
and how it needs to be configured.
||nk |oad Ba|anc|ng
Link load balancing transparently load balances inbound and outbound traffic across multiple
Internet connections. An example of link load balancing in use is an organization connecting to the
Internet through multiple service providers.
The link load-balancing feature enables enterprises that have more than one link to the Internet or
a private network to monitor and control traffic so users are routed over the best available Internet
link. This is accomplished by monitoring routers.
||nk |oad-Ba|anc|ng Po||cy
You should be aware of the following considerations when configuring a link load-balancing policy:
- A load-balancing decision is applied whenever the packet is routed through the load-balancing
route.
- The load-balancing feature gets its input from the virtual IP address associated with the load-
balancing route.
- The preferred IP address and preferred port parameters are valid only if the persistence feature
is enabled.
- The server statistics update and link load balancing on the NetScaler system returns the server
structure for the selected router if the preferred router is up.
- The ideal router is selected based on the load-balancing policy from the server list of the virtual
IP address if the preferred server is not available.
Link load balancing supports the following load-balancing methods:
- Round robin
- Least bandwidth
- Least packet
- Destination-IP-address hash
Link load balancing does not support the default load-balancing policy of least
connections.
Oustom |oad
The custom load-balancing method calculates load by using metrics that have been created and
bound to a metric table. Once a metric has been created and bound, the metric table is then
associated with a load monitor. Metrics can then be bound to the monitor from the pool of
available metrics that reside in the metric table.
The custom load-balancing method distributes traffic based on the load calculations made by load
monitors. The service with the least load value, as calculated by the monitors, is chosen to handle
the client requests.
All services bound to a virtual server for which the load-balancing method is custom load
must have load monitors bound to them. If no load monitors are bound, the virtual server
will use the round-robin load-balancing method.
The local metric table is implicitly bound to the monitor and no additional binding
operation is required.
|oad Mon|tor Process
A load monitor performs load balancing based on server parameters such as CPU or memory
usage. While other NetScaler monitors perform health checks that determine whether to include the
service in load balancing, load monitors calculate the load on a service to distribute the traffic
appropriately between the services.
A load monitor is used strictly for load balancing and, unlike service monitors, does not
determine the state of the service to which it is bound.
A load monitor uses the following process when calculating the load on a service:
1. The load monitor sends an SNMP request for load metrics to a specified server.
2. The server returns an SNMP response with the requested metrics.
3. The load monitor calculates the load for the service to which it is bound based on the SNMP
response received from the server. When the load monitor is configured, it can contain up to
ten SNMP OIDs (object identifiers) for the query. Each OID can have its own weight and
threshold levels configured, which are then used in calculating the load when the SNMP
response is received.
4. Based on the results of the calculation, the service is included in or excluded from the load-
balancing decision.
|oad Mon|tor Parameters
The parameters that can be configured for load monitors are described in the following list.
Metric table The metric table defines which metrics can be used by a load
monitor. Metric tables can be one of three types: local, default, or
custom. The default value is local.
- The local table is present in the system by default and consists
of four NetScaler-specific metrics:
- Connections
- Packets
- Response time
- Bandwidth
These four metrics are system-specific for the service
bound to the load monitor and cannot be altered. SNMP
queries are not originated for these services.
- Default tables can be used for the load balancing of third-party
load-balancing devices. The following default metric tables are
included: NETSCALER, CISCO-CSS, F3, FOUNDRY, and
ALTEON.
The default tables include pre-bound metrics. These metrics can
be deleted, and others can be added depending on the needs of
the environment.
- You can define custom tables. Individual metrics and
corresponding SNMP OIDs are specified based on the
monitoring needs of each environment.
You can choose metrics from one or more metric tables.
Metrics The metrics are bound to a metric table and are identified by an
alias and an SNMP OID. Depending on the metric table selected,
various metrics are available for binding to a load monitor.
When using the custom load-balancing method, the metrics to be
used for calculating load must first be created and bound to a
metric table. Once a metric has been created and bound, the metric
table is then associated with a load monitor. Metrics can then be
bound to the monitor from the pool of available metrics that reside
in the metric table.
The local metric table is implicitly bound to the monitor,
and no additional binding operation is required.
Threshold The threshold value of a metric is used by the load monitor when
determining if a service should be considered for load balancing.
An SNMP query specifying the OID for a particular metric is sent
by the load monitor to the server. The response returned by the
server is the metric value.
The load monitor compares the metric value to the threshold value
that you configured. If the metric value is lower than the threshold,
the service is considered for load balancing.
The threshold value is also used in the calculation of the load on a
particular service.
The threshold value must be defined, or the monitor is
effectively disabled. An SNMP OID with a threshold of 0
returns an error.
Weight The weight value of a metric determines the priority given to each
metric. The higher the value, the higher the priority. For example, if
the weight of service A is 1 and the weight of service B is 2, for
every one request sent to service A, service B will receive two, as
follows: ABBABBABB. The default value is 1.
The weight value is also used in the calculation of the load on a
particular service.
B|nd|ng Metr|cs
Add a metric table and bind metrics on the NetScaler system by specifying the name of the metric
table, the name for the metric and the SNMP OID:
Configuration Utility Under the Load Balancing > Metric Tables node
location
Command-line syntax
add metrictable metricTable
bind lb metrictable metricTable metric
snmpOID
set lb monitor monitorName load -
metrictable metricTable
bind lb monitor monitorName -
metric metricName -
metricthreshold positiveInteger
Serv|ce and v|rtua| Server Management
Once load balancing has been configured in a NetScaler system, you are able to manage entities and
traffic using various tools and commands.
Serv|ce and v|rtua| Server Stat|st|cs
You can easily monitor statistics for a service or a virtual server to manage the health of a NetScaler
deployment.
The following statistics are tracked for services and virtual servers.
Stat|st|cs Serv|ces v|rtua| Servers
IP address X X
Port X X
Request X X
Responses X X
Request bytes X X
Concurrent server and client X X
connections
Service type X
State X
Maximum server connections X
Request in a surge queue X
Connections in a reuse pool X
Average server TTFB X
Current load on the service X
Virtual server protocol X
State X
Spillover threshold X
Serv|ce and v|rtua| Stat|st|cs
Services and virtual server statistics can be managed and monitored from the Configuration Utility
or the command-line interface.
Serv|ce Stat|st|cs
Display service statistics by specifying the service name:
location
Command-line syntax
stat service serviceName
v|rtua| Server Stat|st|cs
Display virtual server statistics by specifying the virtual server name on the NetScaler system:
location
Command-line syntax
stat lb vserver vserverName
D|sab||ng Serv|ces
Disabling services may be necessary to bring a server down for maintenance. When disabling a
service, specify a delay period, during which the service will continue to receive new connections or
requests from clients that have persistent sessions. All other connections or requests are load
balanced among other available services. After the delay period has elapsed, no requests or
connections are sent to the service. Setting a delay of 0 immediately disables the service.
Disable a service by setting the service to a disabled state and specifying the delay time on the
NetScaler system:
location
Command-line syntax Command-line syntax
D|sab||ng v|rtua| Servers
Disabling a virtual server may be necessary to stop traffic from being accepted on the virtual server.
Disabling the VIP address disables all the associated virtual servers.
Disable a virtual server by setting the server to a disabled state on the NetScaler system:
location
Command-line syntax
disable lb vserver vserverName
Remov|ng Serv|ces
Removing a service from the NetScaler system may be necessary if a service is no longer required to
accept any traffic and will no longer be used in the NetScaler configuration.
Remove a service by selecting the appropriate service on the NetScaler system:
location
Command-line syntax
remove service serviceName
Remov|ng v|rtua| Servers
Removing a virtual server from the NetScaler system may be necessary if a virtual server is no
longer required to accept any traffic and will no longer be used in the NetScaler configuration.
Remove a virtual server by selecting the appropriate virtual server on the NetScaler system:
location
Command-line syntax
remove lb vserver vserverName
Mon|tor|ng Tra|c D|str|but|on
Monitoring traffic distribution in a NetScaler deployment is important to determine whether a
system configuration is achieving the desired results. The following information can be found by
using the Statistical Utility and by using the stat lb vserver command in the command-line
interface:
- Virtual server information
- IP address
- Port on which the service is running
- Protocol associated with the virtual server
- Current state of the virtual server
- Total virtual server hits
- Total number of requests received on the virtual server (for HTTP/SSL service types)
- Total number of responses received on the virtual service (for HTTP/SSL service types)
- Total number of request bytes received on the virtual server
- Total number of response bytes received on the virtual server
- Number of current client connections
- Number of client connections in an established state
- Number of current connections to the physical servers behind the virtual server
- Spillover threshold for the virtual server
|oad Ba|anc|ng v|sua||zer
The Load Balancing Visualizer can be used to view and modify load-balancing configurations in
graphical format.
Using the Load Balancing Visualizer, you can:
- View a summary of all services and service groups that are bound to a particular virtual server
and all of the monitors that are bound to the services.
- View the configuration details of any displayed element.
- View policies (for example, rewrite policies) that are bound to the virtual server.
- View the type of traffic that will be directed to the load-balancing virtual server.
- Detect a mismatch in service configuration.
- Simultaneously bind multiple entities to another entity using a drag-and-drop operation.
- Modify an existing configuration.
Bind and configure entities in the Configuration Utility under Load Balancing > Virtual Servers >
Visualizer.
Rev|ew
1. You have created a server entity with a name of serverA and an IP address of 123.43.67.89. He
now wants to create an HTTP service entity with the name of serviceA on port 80 that is
associated with serverA. Which command results in a successful service entity creation:
a. add service serviceA serverA HTTP 80
b. add service serviceA:80:HTTP
c. add service serviceA 123.43.67.89
d. add service serviceA 123.43.67.89:80 HTTP
2. Which type of monitor is used to analyze live client traffic to verify the health of an HTTP
service:
a. HTTP
b. HTTP-INLINE
c. HTTP-ECV
d. TCP-ECV
3. Which parameters specifies the number of consecutive failed health check probes after which a
service is marked as DOWN:
a. Reverse
b. Down time
c. Retries
d. Response time
4. Which hashing type includes the NetScaler system choosing a service based on the hashed
value of the client IP address in the HTTP header:
a. Source IP
b. URL
c. Destination IP
d. Domain name
Modu|e 7
Oonf|gur|ng SS| Off|oad
Overv|ew
The need for organizations to maintain privacy while transmitting private data over public
networks was the primary impetus behind the development of the SSL protocol and digital
certificates. SSL offloading on the NetScaler system can be used to optimize traffic, while maintain
the security of the private data.
Obect|ves
- Identify SSL certificate requirements.
- Identify common virtual SSL server deployments.
- Create and upload an SSL certificate.
- Bind an SSL certificate key.
- Create appropriate servers, services and virtual servers.
- Configure advanced SSL options.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 7: Oon|gur|ng SS| O|oad 173
SS| and D|g|ta| Oert|f|cates
Unfortunately, the processing of SSL transactions by a Web server is CPU-intensive enough to
negatively affect Web application performance. Configuring SSL offload on the NetScaler system
can free the Web servers from handling the SSL encryption/decryption tasks, while maintaining
security without degrading Web server performance.
SS|
SSL is a session-layer encryption and authentication protocol used with HTTP and other protocols
to secure communication between clients and servers. SSL, which is widely used to support e-
commerce sites, specifies a method for a client and a server to exchange cryptographic information
and to build a secure channel through which to send requests and responses. However, SSL can be
used to secure other types of traffic- nothing in SSL relies on HTTP being sent through the
encrypted channel. Transport Layer Security (TLS) is a descendant of SSL that abstracts the security
protocol from any specific underlying service.
Key Encrypt|on
SSL and TLS make use of public and private key cryptography to verify the identities of the server
and client and to set up the initial secure channel for the communication. Public-private key
encryption is a form of asymmetric encryption, meaning that two separate but related keys are
required. A message encrypted by one key can only be decrypted by the related key. Public-private
key encryption is a resource-intensive process.
174 Modu|e 7: Oon|gur|ng SS| O|oad Copyr|ght 2011 C|tr|x Systems, lnc.
lmportant Ooncepts
The following list provides important SSL concepts and their definitions:
SSL SSL is a protocol used to secure HTTP, TCP, and other types of
traffic.
Keys Keys are strings of bits used to encrypt and decrypt messages. The
NetScaler system supports RSA keys, which use public PGP
encryption, and DSA keys, which use FIPS-standard digital
signature algorithms.
Public-Key Encryption Public-key encryption is a method of encrypting messages that pairs
a public key and a private key. Messages encrypted with the public
key can be decrypted only using the private key. In turn, messages
encrypted with the private key can be decrypted using only the
public key.
Digital Certificates Certificates are small files that contain public keys and verify the
identity of the holder. Certificates are issued by a Certificate
Authority (CA).
Certificate Authority (CA) A CA is an entity that issues certificates after verifying the identity
of a server.
Root Certificates A root certificate is an unsigned public key certificate, or a self-
signed certificate, that is part of a public key infrastructure scheme.
The most common commercial variety is based on the ITU-T X.309
standard. Normally, an X.309 certificate includes a digital signature
from a CA, which vouches for the correctness of the data contained
in a certificate.
Server Certificates Server certificates are unique to a particular fully-qualified domain
name (FQDN) of a server. Server certificates are copies of the public
key of a server, signed by the private key of a CA, and contain
information about the server that allows a client to identify the
server before sharing sensitive information.
Intermediate Certificate An intermediate certificate is a subordinate certificate issued by a
trusted CA. Intermediate certificates are used to create server
certificates in a certificate chain.
Client Certificate A client certificate is an optional security component that contains
information about a user and the SSL client.
Certificate Signing Request A CSR is a file sent to a CA that requests that the CA sign the
(CSR) public key of the requesting server with the private key and provide
a new SSL certificate.
Certificate Revocation List A CRL is a list of the serial numbers of certificates that have been
(CRL) revoked and are no longer valid. Users should never accept this type
of certificate to establish access to a secured resource.
If client or server SSL certification validation is required, the
NetScaler system can perform validation against a local certificate
revocation list in a local file.
This list can be updated on a specified interval automatically.
Supported update methods include HTTP and LDAP. Validation is
not on by default and must be enabled.
Diffie-Hellman (DH) The DH key agreement protocol permits two users to swap a
confidential key over an unprotected medium without any previous
secrets.
SS| Off|oad Overv|ew
The SSL offload feature of the NetScaler system handles the CPU-intensive SSL encryption and
decryption processing, allowing the Web servers to dedicate more processing power to content
requests. The SSL offload feature increases the performance of Web sites that carry out SSL
transactions.
The figure provides an overview of a strict SSL offload scenario in which all SSL encrypted
communication between the NetScaler system and the client is handled by the NetScaler system.
Communication between the NetScaler system and the back-end server is unencrypted, providing
load reduction on the server, and allowing the server to focus on performing the application role
instead of on managing SSL encryption/decryption processes.
In other scenarios, the security of the data needs to be maintained end-to-end and should not be
transmitted in a non-encrypted format. Encryption will occur between the client and the NetScaler
system and also between the NetScaler system and the server. The server still needs to perform
work to encrypt the data, but the NetScaler system is able to optimize the traffic and improve
efficiencies by reusing the SSL connections.
Off|oad Performance
The NetScaler system supports extremely high-performance SSL encryption and session creation.
For example, the NetScaler MPX platforms support:
- 6 Gbps of bulk encryption
- 48,000 new SSL handshakes per second
The NetScaler system can offload a significant portion of the total application load from the servers
it supports as well as switch the resulting SSL traffic. This offload cannot be done efficiently by
traffic management systems. If the traffic management system is not decrypting the data, it is
unable to make load-balancing decisions based on application data, such as HTTP header
information or cookies. Instead, legacy traffic management systems must treat all of the traffic like
raw IP traffic and make decisions based on source and destination IP addresses. By decrypting the
traffic as it enters the NetScaler system, SSL processing can be offloaded from application servers,
allowing the robust traffic management functionality of the NetScaler system to come into play.
The NetScaler system can also provide protection against encrypted attacks by terminating and
offloading SSL. By terminating the SSL, the NetScaler system can inspect and protect all traffic
going to the servers in addition to switching it intelligently. Without this benefit, attacks can be
wrapped in SSL and delivered securely to the server.
Features and Bene|ts
The NetScaler SSL implementation supports a full feature set and is interoperable with all common
SSL clients.
Feature Bene|t
Integrated or 1-arm Scalability
SSL protocol support (SSLv2, SSLv3, TLSv1) Rich protocol suite
Cipher suite support: Rich cipher suite
- Key-exchange: RSA, DSS, DH [Max key:
The level of security can be adjusted based on
4096 bits]
client needs with a full range of key exchange,
encryption and authentication protocols.
- Encryption: RC4, DES, 3DES, RC2, IDEA
- MAC: SHA, SHA-1, MD3
Client authentication
- Authenticity of the user requesting the Web
object
- Web access on a per-user basis.
Feature Bene|t
Certificate Revocation List (CRL) Greater security, with ability to block clients
with revoked certificates
- Up to 48,000 secure transactions per sec - Better performance
- 6 Gbps bulk encryption rate - Quicker response time
- Handling of traffic surges such as flash
crowds
Centralized certificate/key management Ease of management
Easy drop-in installation
- No changes are needed to the Web servers.
- No additional hardware or software is
needed.
SS| Adm|n|strat|on
An SSL certificate and key can be obtained for use on the NetScaler system using one of the
following ways:
- Request certificate and key from a certificate authority (CA).
- Use an existing SSL certificate and key.
- Generate a new SSL certificate and key using the self-signing tools on the NetScaler system.
The process to create an SSL certificate is the same for the certificate authority or the NetScaler
certificate tools:
1. Create a private key file.
2. Create a certificate signing request (CSR).
3. Submit the CSR to the certificate authority to create the certificate. If you are working with an
external certificate authority, (such as Verisign), submit the request to the CA which issued the
certificate file. If you are using the NetScaler self-signing tools, the NetScaler system will use
the CSR to generate the certificate.
Steps 1-3 can be skipped if a certificate and key file exist.
4. Install the certificate and key file on the NetScaler system.
Use the NetScaler tools to create the key and request files when submitting a request to an
external CA.
SS| and Po||c|es
Like other features of the NetScaler system, SSL offload can be controlled through policies.
SS| Sess|on Process
For a client to establish a secure connection between a web browser and a server in most cases, a
root certificate must be installed in the browser certificate store and on the server-which could be
a web server, a service or a NetScaler system. The following page describes the process in which a
client and server initiate an SSL session.
The figure and the following process provide an overview of the process in which a client and
server initiate an SSL session.
1. The client sends a Client-Hello with a set of supported cipher suites.
2. The server responds with a Server-Hello.
3. The server sends its public key in the server certificate signed by the CA, along with a selected
cipher.
4. The server sends ServerHelloDone.
3. The client uses its root certificate to verify the signature of the server certificate. It then
confirms that the certificate is still valid and that the subject name on the certificate matches
the server name. The client generates a common key called the Premaster Secret.
6. The client transmits either the RSA-encrypted Premaster Secret or the Diffie Hellman (DH)
parameters. Both options allow the client and the server to agree on the same Premaster Secret.
7. The client and the server, independently and in parallel, generate the same Master Secret using
the Premaster Secret.
8. The client and the server generate session keys form the Master Secret.
9. The client and the server encrypt their communication using the session keys for the remainder
of the SSL session.
SS| Keys
Keys are generated in the following situations:
- Before generating and submitting a certificate signing request to a certificate authority
- Before generating a self-signed certificate for testing purposes
The create key commands do not create objects in the NetScaler configuration; the
commands create objects that are saved to the file system. Once generated, keys are saved
by default to the /nsconfig/ssl directory in the NetScaler configuration.
When generating a key, you must designate the key size, or cipher key length, in bits. The two most
common key sizes are 312 bits and 1024 bits, although the NetScaler system supports a key size up
to 4096 bits for RSA and DSA certificates. Higher key sizes result in more secure encryption
algorithms.
Generate a key on the NetScaler system by specifying the key type, format and encryption:
Configuration Utility Under the SSL node
location
Command-line syntax RSA Key
create ssl rsakey keyFile bits [-
exponents (3 | F4)] [-
keyform (DER | PEM)] [-des] [-des3] [-
password string]
DSA Key
create ssl dsakey keyFile bits [-
keyform (DER | PEM)] [-des] [-des3] [-
password string]
Generat|ng a Oert||cate S|gn|ng Request
Obtaining an SSL certificate from an authorized certificate authority (CA) requires the creation and
submission of a certificate signing request (CSR).
Generate a CSR on the NetScaler system by specifying the key filename, format and encryption:
location
Command-line syntax
create ssl certReq reqFile [-
keyFile keyFileName][-
fipsKeyName string] [-keyform (DER | PEM)
SS| Oert||cates
The NetScaler system supports SSL certificates that are either self-signed or signed by a trusted CA.
The NetScaler system can act as a certifying authority and provides options for generating a self-
signed certificate for testing.
The NetScaler certificate tools can be used to generate the following certificate types:
- Root CA certificates
- Intermediate certificates
- Server certificates
- Client certificates
Root CA Cert||cates
Client devices use certificates to recognize which network entities to trust. Certificates are assigned
to clients by a certificate authority (CA) and carry an equivalent trust to that of the CA itself. For a
network entity to act as a CA and issue its own certificates to clients, it requires a root-CA
certificate. This separate certificate is used to issue the client certificates. The root-CA certificate is
critical, as it acts as the authority stamp on all client certificates that the CA will issue.
A NetScaler system can act as a CA and generate self-signed certificates by creating the root-CA
certificate itself. In this scenario, clients must be configured to accept the NetScaler created root-CA
certificate to trust the client certificates that the NetScaler system will issue. To create a root-CA
certificate, you must supply a key file and a certificate request.
lntermed|ate CA Cert||cates
Root CAs can assign certificates for an intermediate CA. An intermediate CA can then issue server
certificates, personal certificates, publisher certificates, or certificates for other intermediate CAs.
The intermediate CA is located between your root CA and enterprise CA and requires another level
of validation, creating a verification chain.
Server Cert||cates
The NetScaler system must have a server certificate for an initial client SSL session. The server
certificate verifies the server identity to the client. The certificate authority verifies that the
company using the server certificate was authorized to issue a certificate for the domain. To create
a server certificate, you must specify the certificate request, the root-CA, or intermediate CA
certificate that should be used to generate the server certificate, details regarding the key format,
and an output file for the CA serial number.
C||ent Cert||cates
Client certificates are issued to a user by a certification authority. The certificate, which consists of
the public key portion and a private key, can be used only by the client for whom the certificate
was issued. The difference between server and client certificates is that server certificates provide
encryption and security functionality, whereas client certificates provide user authentication
functionality.
Different parameters are required when creating each of the above certificates.
Generate a Cert||cate
Generate a certificate on the NetScaler system by specifying the certificate format, certificate type,
the CA certificate file format, the CA key file name, the CA key file format, whether the CA key is
encrypted and the CA serial number file:
location
Command-line syntax
create ssl cert certFile reqFile certType [-
keyFile input_fileName] [-
keyForm (DER | PEM)] [-
days positive_integer] [-
certForm (DER | PEM)] [-
CAcert input_fileName] [-
CAcertForm (DER | PEM)] [-
CAkey input_fileName] [-
CAkeyForm (DER | PEM)] [-
CAserial output_fileName]
Oert||cate Key Pa|rs
For SSL processing to occur, an SSL key file must be bound to the virtual server. An SSL key file is
an integral element of the SSL encryption and decryption process, which is used during the SSL
handshake to determine the cipher that will be used for SSL processing and also to establish the
identity of the SSL server.
Cert||cate Key Pa|r
Before a client certificate can be used for SSL processing, it must be paired with its corresponding
key file which resides on the NetScaler system. This certkey pair is then bound to the client
connection for SSL processing.
A certificate key pair is used on a per connection basis. Each client connection requires a
unique certificate key pair.
Add|ng a Cert||cate Key Pa|r
Add a key file on the NetScaler system by specifying the certificate file name, the private file name,
the password and the certificate format:
location
Command-line syntax
add ssl certkey certkeyName -
cert fileName[(-key fileName [-
password]) | -fipskey string] [-
inform (DER | PEM)][-
expiryMonitor (ENABLED | DISABLED)][-
notificationPeriod positive_integer]
B|nd a Key F||e
Bind a key file by specifying the virtual server name, and the key file name on the NetScaler system
Configuration Utility under the SSL node
location
Command-line syntax
bind ssl certkey certkeyname ocspResponder[
<string>] -priority positive_integer
SS| Off|oad
The SSL offload feature ensures the secure delivery of Web applications without degrading user
performance. The NetScaler system intercepts SSL transactions on behalf of back-end Web servers.
The NetScaler system then processes these transactions, applies system policies and relays the
transactions to the servers in either plain text or encrypted mode.
The following components and settings are required in order to properly configure SSL offload:
- A defined SSL termination point
- A server certificate installed on the NetScaler system
- Root, intermediate and client certificates installed on the client, depending on environmental
needs
- Appropriate servers, services and virtual servers configured on the NetScaler system
SS| Term|nat|on Po|nts
To properly configure the NetScaler system, you must determine the SSL termination points. SSL
transactions may be terminated on one of the following devices:
- Citrix NetScaler Application Switch
- Citrix Application Firewall
- Network firewall
- Web server
The following termination methods can be used on the NetScaler system or on the servers:
- Terminating SSL on NetScaler System
- Terminating SSL on the servers
Term|nat|ng SS| on the NetSca|er System
Terminating SSL on the NetScaler system has several benefits:
- The server is freed from the extensive CPU cycles required for the handshake, encryption, and
decryption processes.
- Switching decisions can be made based on request content.
- Denial-of-service attack protections can be implemented.
Term|nat|ng SS| on the Servers
The primary benefit to terminating SSL on the servers is the ability to deploy a NetScaler system
without any changes to the server configuration. Furthermore, if the NetScaler system is
intercepting the connection, SYN attack prevention benefits can be maintained. However, the server
will require significant processing power to handle the SSL transactions.
In most cases, SSL sessions will be terminated on the NetScaler system. In critical banking or
financial transactions, SSL encryption must continue through to the servers to ensure that the
transaction cannot be compromised under any condition.
Dep|oyment Scenar|os
The SSL requirements for a particular environment depend on how SSL will be deployed. The
following scenarios are the most common:
Front-end SSL with Back- Front-end SSL with back-end HTTP refers to a network
end HTTP configuration that allows the NetScaler system to offload SSL
encryption and decryption, and pass traffic to Web servers in plain
text.
Front-end SSL with Back- Front-end SSL with back-end SSL refers to a network configuration
end SSL that allows the NetScaler system to pass traffic to Web servers in
encrypted mode. Although the NetScaler system does not fully
offload SSL processing, it can provide a benefit through SSL
connection multiplexing or the use of a smaller cipher.
Front-end TCP over SSL Front-end TCP over SSL with back-end TCP refers to a network
with Back-end TCP configuration that allows the NetScaler system to offload SSL
encryption and decryption for client connections, as well as pass any
TCP traffic to servers in plain text. An example of this type of
deployment scenario is providing secure access for LDAP
directories.
Front-end SS| w|th Back-end HTTP Requ|rements
The figure and the following list provide an overview of the requirements necessary for a front-end
SSL with back-end HTTP configuration:
- An installed certificate
- A load-balancing virtual server using the SSL protocol
- One or more HTTP services associated with back-end Web servers
Secur|ng Tra|c Between a O||ent and the NetSca|er
System
Secure the traffic between a client and the NetScaler system using the following process:
1. Export an existing key or certificate or generate a key and CSR.
2. Convert the certificate file to PEM or DER using OpenSSL, if applicable.
3. Upload the certificate and key to the NetScaler system using an SCP or SFTP application.
4. Create a certkey entity to install the certificate and key pair on the NetScaler system.
3. Create servers that point to the back-end Web servers.
If the servers have been created previously, this step is not necessary.
6. Create an HTTP service associated with the Web servers.
If the service has been created previously, this step is not necessary.
7. Create a load-balancing SSL virtual server using port 443.
8. Bind the virtual server to the services.
9. Bind the certkey to the virtual server.
Front-end SS| w|th Back-end SS| Requ|rements
SSL with back-end SSL configuration:
- An installed certkey for traffic between the NetScaler system and client
- A load-balancing virtual server set to use the SSL protocol
- An SSL service or services associated with back-end Web servers
An optional, more secure configuration is to install a certkey for traffic between the NetScaler
system and back-end Web servers.
Secur|ng Tra|c Between the NetSca|er and the Server
Secure the traffic between the NetScaler system and Web servers using the following process:
1. Install certificates to secure traffic between the client and the NetScaler system, as well as
between the NetScaler system and the back-end Web servers.
3. Create SSL services associated with the Web servers.
If the services have been created previously, this step is not necessary.
4. Create an SSL virtual server for the Web servers.
3. Bind the virtual servers to the appropriate services.
6. Bind the back-end certificate/certkey.
Front-end SS|_TOP w|th Back-end TOP Requ|rements
SSL_TCP with a back-end TCP configuration:
- An installed certkey
- A load-balancing virtual server using the SSL_TCP protocol
- A TCP service or services associated with back-end Web servers
Secur|ng TOP Tra|c Between a O||ent and the NetSca|er
System
Secure TCP traffic between a client and the NetScaler system, as well as pass TCP traffic to server
using the following process:
1. Install certificates to secure traffic between the client and the NetScaler system.
3. Create TCP services associated with the servers.
If the services have been created previously, this step is not necessary.
4. Create an SSL_TCP virtual server.
3. Bind the virtual servers to the appropriate services.
6. Bind the appropriate certkey to the SSL_TCP virtual server.
SS|_Br|dge
The SSL_BRIDGE functionality allows all secure traffic to be transparently bridged directly to the
back-end Web server. The system does not terminate or offload this traffic. In this scenario, the
Web server must handle all SSL-related processing.
This configuration should be used only if an acceleration unit (for example, a PCI-based
SSL accelerator card) is installed in the Web server to handle the SSL processing overhead.
In an SSL_BRIDGE setup, the system is configured to load balance and maintain server persistency
for secure requests using the SSL Session-ID. Other features, such as content switching, Sure
Connect and cache redirection, do not work because the traffic passing through the NetScaler
system is encrypted. Because the system does not carry out any SSL processing in an SSL_BRIDGE
setup, there is no need to bind a certkey to the SSL_BRIDGE virtual server.
SS|_Br|dge Requ|rements
The following requirements are necessary for an SSL_Bridge configuration:
- A load balancing virtual server using the SSL_Bridge protocol
- A SSL_Bridge service or services associated with back-end Web servers
Oonf|gur|ng SS| Off|oad
SSL must be enabled to configure the NetScaler system for SSL Offload.
The figure and the following steps provide an overview of the process used to configure SSL
Offload on the NetScaler system.
1. Enable SSL Offload on the NetScaler system.
2. Create HTTP/TCP services on the NetScaler system.
3. Create SSL virtual servers on the NetScaler system.
4. Use an existing key and certificate or obtain a key and certificate.
3. Upload the key and certificate to the NetScaler system.
6. Create the certkey entity on the NetScaler system from the uploaded key and certificate.
7. Bind the certkey to the SSL or SSL_TCP virtual server.
8. Bind the services to the virtual server.
Oreat|ng and B|nd|ng SS| v|rtua| Server
An SSL virtual server accepts encrypted traffic, decrypts it, and sends the clear text messages to the
services that are bound to the virtual server. This process allows for offloading SSL processing to
the NetScaler system, and the back-end servers to process a greater number of requests.
Creat|ng an SS| v|rtua| Server
Create an SSL virtual server in the NetScaler system by specifying the vServer name, service type, IP
address and port of the virtual server:
Configuration Utility Under the SSL Node
location
Command-line syntax
add lb vserver <name> <serviceType>
[<IPAddress> <port>]
At least one service must be bound to a virtual server for the virtual server to accept incoming
client requests.
B|nd|ng an SS| v|rtua| Server
At least one service must be bound to a virtual server for the virtual server to accept incoming
client requests.
Bind a service to the SSL vServer by specifying the vServer name and the service name:
location
Command-line syntax
bind lb vserver <name> <serviceName>
Advanced SS| Sett|ngs
Three commonly used advanced SSL configuration options are:
- SSL redirect
- SSLv2 protocol
- SSLv2 redirect
SS| Red|rect
Enabling SSL Redirect causes the NetScaler system to convert any HTTP 302 redirect responses
from back-end servers to HTTPS redirects. SSL Redirect is useful if HTTPS is being used between
the client and the NetScaler system, but HTTP is being used between the NetScaler system and
back-end server.
For example, without SSL Redirect enabled, when a client has an SSL session established and
follows a URL that begins with HTTP://, the SSL session will be broken. By enabling SSL Redirect,
the NetScaler system will intercept the redirect and append an S to the URL protocol, making the
URL begin with HTTPS:// instead. The NetScaler system maintains the secure channel without
requiring any changes to the back-end server.
For more information about SSL Redirect, refer to the http//suppcrt.citrix.ccm/prcddccs/index.jsp
web site.
SS|v2 Protoco| and Red|rect
SS| v2
SSL protocol version 2 (SSLv2) is disabled by default because of known vulnerabilities. However, if
you know that clients connecting to the network support only SSLv2, it can be enabled through the
Configure SSL Params screen of the Configuration Utility.
SS|v2 Red|rect
The SSLv2 Redirect feature enables the NetScaler system to redirect any requests from SSLv2 clients
to a precise error message, either user configured or internally generated, instructing the client
about a further course of action. For example, the redirect could instruct users on how to upgrade
to an SSLv3 client. The SSLv2 protocol must be disabled in order for SSLv2 Redirect to work;
otherwise, the NetScaler system will negotiate the SSLv2 handshake.
Oon|gur|ng Advanced Sett|ngs
Configure advanced settings on the NetScaler by configuring parameters of the virtual server.
Configuration Utility Under the SSL Offload node.
location
Command-Line Syntax
set ssl vserver vserverName@ [-
clearTextPort port] [-
dh (ENABLED | DISABLED) -
dhFile fileName] [-
dhCount positive_integer] [-
eRSA (ENABLED | DISABLED) [-
eRSACount positive_integer]] [-
sessReuse (ENABLED | DISABLED)[-
sessTimeout positive_integer]] [-
cipherRedirect (ENABLED | DISABLED)[-
cipherURL URL]] [-
sslv2Redirect (ENABLED | DISABLED) [-
sslv2URL URL]] [-
clientAuth (ENABLED | DISABLED) [-
clientCert (Mandatory | Optional)]] [-
sslRedirect (ENABLED | DISABLED)] [-
redirectPortRewrite (ENABLED | DISABLED)] [-
nonFipsCiphers (ENABLED | DISABLED)][-
ssl2 (ENABLED | DISABLED)] [-
ssl3 (ENABLED | DISABLED)] [-
tls1 (ENABLED | DISABLED)]
Rev|ew
1. Which two options are valid means of obtaining a server certificate for use in a production
environment: (Choose two.)
a. Request a certificate from a trusted certificate authority.
b. Generate a self-signed certificate on the NetScaler system.
c. Use an existing certificate from a back-end web server.
d. Install a standard server certificate issued with most web browsers.
2. Which two NetScaler protocols would you use to terminate SSL sessions: (Choose two.)
a. SSL
b. SSL_TCP
c. SSL_HTTP
d. SSL_BRIDGE
3. Which benefit results from terminating SSL transactions on the NetScaler system rather than
on the server: (Choose two.)
a. The server is freed from CPU-intensive SSL processing.
b. SSL encryption can be passed to the back-end server.
c. A NetScaler system can be deployed without changes to the server configuration.
d. SSL transactions terminated on a NetScaler are less able to be compromised than those
terminated on a server.
Modu|e 8
Oonf|gur|ng G|oba|
Server |oad Ba|anc|ng
Overv|ew
Global Server Load Balancing (GSLB) enables the NetScaler system to make intelligent traffic
direction decisions. For example, if a site fails, the NetScaler system detects the failure and directs
traffic to another available site. This feature prevents client requests from being sent to a site that is
unavailable or overloaded.
Object|ves
- Describe GSLB architecture.
- Identify core DNS concepts.
- Identify core GSLB concepts.
- Describe traditional GSLB.
- Describe proximity-based GSLB.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 8: Oon|gur|ng G|oba| Server |oad Ba|anc|ng 201
GS|B Ooncepts
GSLB is a DNS-based solution that load balances services between geographically distributed
locations. GSLB operates under many of the same general principles as load balancing, but it relies
on DNS for directing client requests. A major benefit of GSLB is the reduction of application
latency.
Typical uses of GSLB include:
- Network traffic distribution across multiple sites
- Server load distribution across multiple sites
- Disaster recovery
GS|B H|erarchy
GSLB networks have a maximum of 32 sites. NetScaler systems can be deployed in Hierarchy mode
for scenarios that require additional units.
202 Modu|e 8: Oon|gur|ng G|oba| Server |oad Ba|anc|ng Copyr|ght 2011 C|tr|x Systems, lnc.
GS|B Oonversat|on Process
The figure and the following steps illustrate general GSLB architecture. The asterisks in the figure
denote that the back-end DNS server is necessary in a proxy DNS configuration only. The
NetScaler system answers the site DNS requests in authoritative DNS configurations:
1. The user enters www.example.com in a Web browser.
2. The client sends a DNS lookup query for www.example.com to the name server that is
configured.
3. The name server returns the IP address for a name server that is authoritative for
www.example.com as delivered by the root server. The returned address is the one registered
for the www.siteA.example.com site. The top-level servers (root servers) circle through the list
round robin and return the next IP address in line.
4. The client queries the NetScaler system in the GSLB configuration at the IP address returned in
the prior step. The NetScaler system, based on its configured load-balancing method, returns
the IP address the client needs to query for the service for which it is looking, such as HTTP
and HTTPS.
3. The responding NetScaler system queries the back-end DNS server for the address to serve the
lookup request if the GSLB configuration is a proxy DNS configuration.
The site to which the NetScaler system directs the client is either:
- A site the NetScaler system is hosting within the load-balancing configuration
- Another GSLB site within the membership of sites
GS|B Ent|t|es
GSLB configuration is comprised of entities on the NetScaler system that direct client traffic to
applications and resources. The figure and the following items identify the entities in a GSLB
environment.
GSLB Site A GSLB site is typically a datacenter in which a NetScaler system is
located. The terms local site and remote site are used to refer to the
site in relation to the NetScaler systems in the GSLB deployment. A
local GSLB site is located on the NetScaler system, whereas a remote
site is located on a different NetScaler system.
GBLS Service A GSLB service is a service which is bound to a load-balancing or
content-switching GSLB virtual server, which determines how
incoming traffic is routed.
GSLB Virtual Server A GSLB virtual server enables client requests to be forwarded to the
appropriate data GSLB site. A GSLB virtual server is assigned one or
more GSLB services, and load balances the incoming traffic between
the services. The GSLB virtual server monitors the services based on
the assigned method to determine the appropriate service.
DNS virtual servers are only necessary in a DNS proxy
configuration. Otherwise, in an ADNS configuration, each GSLB site
will use the locally configured DNS service with mirrored static
DNS records for each site in the configuration.
Load-Balancing or Load-balancing or content-switching virtual servers load balance
Content-Switching Virtual incoming traffic to the appropriate server.
Server
ADNS Service The ADNS service accepts incoming client requests.
Metr|c Exchange Protoco|
The NetScaler system uses the proprietary metric exchange protocol (MEP) to exchange site
metrics, network metrics and persistence information between sites. A single, long-lived connection
between two sites is used to exchange all metric information. The site with the lower GSLB site IP
address initiates the connection with the site with the higher GSLB site IP address. By default, this
connection is made from the NSIP address to the GSLB site IP address. However, you can
configure the NetScaler system to use an IP address other than the NSIP address.
Performing user authentication before metric information is exchanged provides controlled access.
All sites taking part in metric exchange should have the same nsroot user ID and password.
The communication process is accomplished between each GSLB site on TCP port 3011 or port
3009 if secure. You must open the correct port on any firewalls between the NetScaler systems. The
public IP address of the site needs to be allowed on any blocking firewall.
When MEP is disabled, GSLB methods are limited to round-robin, static-proximity and source-IP-
address hash. All other methods revert to round robin when MEP is disabled.
Metr|c lnormat|on Types
The GSLB site metric exchange interval is one second. Metric information types include:
Site Site information consists of the current number of connections and
current packet rate for a load-balancing virtual server.
Network GSLB sites exchange RTT information about the learned DNS of the
clients when dynamic proximity-based GSLB is enabled. This
information is exchanged every five seconds.
Persistence GSLB site information is exchanged every five seconds.
GS|B Mon|tor|ng Oon|gurat|on
The following table illustrates how MEP behaves with explicit monitors.
Mon|tor|ng MEP Enab|ed MEP D|sab|ed
Explicit monitors Health status controlled by Health status controlled by
monitoring monitoring
Mon|tor|ng MEP Enab|ed MEP D|sab|ed
No explicit monitors Health status controlled by All services belonging to that
MEP site are marked down
MEP is used to exchange all statistics, including service health state, related to a GSLB service. If an
explicit monitor is bound, the NetScaler system ignores the GSLB service state collected through
MEP, and GSLB uses the state reported by the monitor.
GSLB monitoring precludes MEP health monitoring. When configuring GSLB monitoring,
NetScaler monitors can be used instead of or in addition to MEP.
GS|B DNS Methods
The NetScaler system can be configured to respond to DNS queries in the following ways:
Authoritative Domain The NetScaler system in ADNS mode is the authority for a domain
Name Server (ADNS) and all the records within that domain. It resolves the domain name
received in the client DNS query to one or more IP addresses. It
does not support zone transfers. This method:
- Occurs when the NetScaler system is assigned and is
authoritative for a domain
- Is typically used for GSLB internal-facing deployments
- Presents challenges with Active Directory
Domain Name Server As a proxy to an external DNS server, the NetScaler system caches
(DNS) Proxy the DNS responses sent by the external name server. This method:
- Occurs when the NetScaler system forwards or proxies DNS
requests to a DNS server
- Does not have an internal DNS on the NetScaler system
DNS sub-delegation DNS sub-delegation occurs when the DNS server assigns the
responsibility for a subdomain to a NetScaler system. The DNS
server redirects DNS requests to the NetScaler system that resolves
the IP address. This method:
- Occurs when the DNS server assigns the responsibility for a
subdomain to a NetScaler system
- Has the DNS server redirecting DNS requests to the NetScaler
that resolves the IP address
Author|tat|ve DNS Serv|ce
The NetScaler system can be configured with single or with multiple instances of an Authoritative
DNS server, where each instance listens on a different IP address, and all instances reference the
same name table. The ADNS service is a local service type listening for incoming DNS requests on
UDP port 33.
In an authoritative configuration, the NetScaler system answers the DNS query. In this
configuration, the NetScaler system:
- Is locally configured as Start of Authority (SOA) for the GSLB domain
This configuration creates similar DNS records for each site in the configuration.
- Can be configured for a maximum of 32 sites
- Does not support zone transfers or recursive query
- Can be set to participate as authoritative
Name Servers
Name servers store information about one or more zones. The following list contains descriptions
of name servers that can be added internally on the NetScaler system:
IP address-based The user has to specify the IP address of the name server to contact.
Virtual server-based The user has to specify the name of the DNS virtual server
configured in the NetScaler system.
Externa| DNS Server Examp|e
The figure illustrates an example of an external DNS server with a VPN connection:
1. The user opens a web browser locally and enters www.blue.net into the browser. Split
tunneling is disabled. The VPN client intercepts the DNS query, packages it in a HTTP request
and forwards it over the tunnel.
2. A load-balancing decision is made and the request is sent to a back-end DNS server for
resolution.
3. The DNS server hands the response back to the NetScaler system.
4. The DNS virtual server wraps the response in HTTP and forwards it across the tunnel back to
the client. The VPN client unwraps the HTTP request and forwards the DNS response to the
client.
DNS Proxy Oon|gurat|on
The figure illustrates a DNS proxy configuration. In a proxy configuration, the NetScaler system
passes domain requests to the DNS server. The following considerations can apply in a proxy
configuration:
- If the NetScaler system is authoritative for the requested zone, the NetScaler system responds
to the query.
- If the request is for a zone that is within the GSLB domain, the NetScaler system responds with
the optimal virtual IP server address in the GSLB domain.
DNS Request Scenar|os
The NetScaler system uses existing virtual server and service functionality when responding to DNS
requests. The NetScaler system uses a MIP address or SNIP address as the source IP address for
queries. The DNS server responses are cached on the NetScaler system until the time to live (TTL)
expires.
For clients making DNS requests, two different scenarios exist:
Local DNS
- A local DNS server is created on the NetScaler system.
- The local DNS is an authoritative DNS server for the zone
configured.
- The local DNS listens on an IP address provided in the
configuration. Clients can configure their local TCP/IP stack to
forward queries to this IP address.
Load-balancing DNS
- A DNS load-balancing virtual server is created and provides an
IP address.
- The services are added to redirect traffic to DNS servers.
- The clients configure the load balancing virtual server IP
address as their DNS server IP address.
Resource Records
On the NetScaler system, DNS records contain DNS data. The following DNS records are
supported on the NetScaler system:
- Address (A) records
- Canonical Name (CNAME)
- Mail Exchange (MX)
- Name Server (NS)
- Start of Authority (SOA)
- Service Record (SRV)
- Pointer Record (PTR)
- Authentication, Authorization, Accounting and Access (AAAA)
GS|B Pers|stence
GSLB persistence is a type of decision logic. When configuring GSLB persistence, you must be
familiar with site persistence, cookie-based persistence and connection proxy.
S|te Pers|stence
Site persistence ensures LDNS requests are sent to the same site and are not load balanced.
Set source IP address persistence by specifying the GSLB virtual server IP address and a unique
identifier for the persistence type:
Configuring Utility Under the GSLB > Services node
location
Command-line syntax
set gslb vserver gslbvip -
persistenceType IPAddress -persistenceID
PositiveInteger
Cook|e-based Pers|stence and Connect|on Proxy
Cookie-based persistence and connection proxy allow the HTTP level persistence setting. Cookie-
based persistence is configured on local GSLB services with the following arguments in the
- -SitePersistence ConnectionProxy
- -cookieTimeout integer
- -CIP ENABLED cipheader
Oonf|gur|ng DNS v|rtua| Servers
A DNS virtual server can be configured as a DNS server on the client device. The virtual server
typically has an IP address, port and protocol type configured. The NetScaler system listens for
incoming DNS queries and calculates the best metric depending on the load-balancing algorithm in
use for request distribution to the DNS server.
Create a DNS service pointing to a server with IP address 10.10.0.110 for DNS queries using the
following command-line syntax:
add dns NameServer 10.10.0.110
In the same step, the NetScaler system also creates a virtual server without an IP address. The
service created is automatically bound to the virtual server. This configuration scenario is used
when the NetScaler system has to make a name resolution, such as in a VPN scenario, in which the
client tries to resolve a name. The name resolution is passed over the tunnel, and the NetScaler
system passes it on to the local virtual server for resolution. Because there is no IP address
representing the DNS service, clients cannot make a direct request to the NetScaler system for
name resolution.
GS|B Oonf|gurat|ons
A number of configuration steps are required to implement GSLB. All steps must be performed at
all sites. Once all sites, virtual servers and services are reported as UP, you can customize DNS,
GSLB methods, persistence and site affinity as necessary.
Configure a GSLB implementation by using the following process on the NetScaler system of each
site:
1. Enable required features.
2. Create GSLB sites.
3. Configure load-balancing virtual servers, services, and bind them.
4. Create GSLB virtual server and services, local and remote for all the remote sites.
3. Bind GSLB virtual servers to GSLB services and to the GSLB domain.
lmp|ement|ng Trad|t|ona| GS|B
When the DNS request from the resolver of the client is received by the NetScaler system, the load-
balancing and the site fault-tolerance decision is made based on the health status and the load of
the participating sites. When the host name of the URL is resolved, all traffic from the client is sent
directly to the resolved site.
When the DNS request from the resolver of the client is received by the NetScaler system, the site
load information is exchanged between the GSLB sites. When the host name of the URL is resolved,
all traffic from the client is sent directly to the resolved site. For GSLB to work as defined, either
the MEP should be enabled, or explicit monitors should be bound to remote services.
MEP Fa||over
If the MEP fails for any of the participating sites because of external factors, then the default
method, round robin, is used instead of least-response time, least connections, least bandwidth and
least packets. If the remote service belonging to the site for which MEP has failed has an explicit
monitor bound to it, and its state is UP, then it is included in the round-robin rotation; otherwise,
it is not.
lmp|ement|ng Prox|m|ty-based GS|B
When enabled, the proximity-based GSLB method allows the NetScaler system to make load-
balancing decisions based on the proximity of the local DNS server (LDNS) of the client in relation
to different sites. Proximity can be measured both statically and dynamically. The dynamic
determination of proximity is based on the current network status, while the static determination of
proximity is based on the geographic location of the LDNS of the client and the sites the client is
accessing.
The main benefit of the proximity-based GSLB method is faster response time resulting from the
selection of the closest available site.
Proximity methods require a specific license for NetScaler versions prior to 8.0.
Prox|m|ty-Based |oad-Ba|anc|ng Methods
Proximity-based load-balancing methods include:
- Dynamic network proximity
- Round Trip Time (RTT)
- Static proximity
Dynam|c Network Prox|m|ty
Network proximity is a measure of how far a user is from a data resource in terms of network
distance or time. The GSLB feature monitors the real-time status of the network and directs the
request of the client to the best site. GSLB uses a smoothed RTT metric to measure network
proximity. Using the smoothed RTT metric could result in network congestion.
The RTT between the LDNS of the client and each of the participating sites is measured. The
system then uses this metric to make its load-balancing decision. The DNS response generated by
the system carries the IP address of the site closest to the LDNS of the client in terms of RTT.
Round Tr|p T|me RTT}
The GSLB solution uses its proprietary MEP to exchange metrics between participating sites. Using
this protocol, the system learns the network metric information RTT of the LDNS of the client.
When the LDNS of a client accesses the GSLB site for the first time, the RTT information is not
available with the system. In such cases, the GSLB virtual IP address selects a site using the round-
robin method and directs the client to this site. The system then starts calculating the RTT between
the site and the LDNS. The system deployed at the participating site begins to calculate the RTT
between the LDNS and the GSLB site. Periodically, the system participating in GSLB reports the
RTT to other participating systems. When the DNS query is sent the next time, the system selects
the best site using the network metrics.
The NetScaler system uses different mechanisms, such as ICMP echo request/reply (ping), UDP
(DNS) and TCP, to probe the RTT metrics between the LDNS and the sites participating in the
GSLB domain. First, a ping probe is performed to obtain the RTT. If the ping probe fails, the DNS
probe is performed to calculate the RTT. If the DNS probe also fails, the TCP probe is performed.
Stat|c Prox|m|ty
The static proximity feature uses an IP-address-based static location database. The database used to
implement the static proximity method often contains all of the GSLB site locations. The NetScaler
system uses this database to determine the proximity between the LDNS of the client and the GSLB
sites. The NetScaler system responds with the IP address of the closest site that matches the
proximity criteria.
The locations in the static GSLB database consist of an IP address range and up to six qualifiers for
this range. The custom database is stored in ns.conf, and a static third-party or NetScaler system
database is stored in the /var/netscaler/locdb directory by default.
lmp|ement|ng GS|B Fa||over for D|saster
Recovery
The NetScaler system supports backup site configuration for GSLB. If the primary site goes down,
then the IP address of the backup site is provided in the DNS response. This process is known as
failover.
Con|gur|ng the Backup S|te
All sites that are bound as services to the GSLB virtual IP address are considered primary sites. If
the site IP address is configured as the backup, then the site is considered the backup site. If the
GSLB virtual IP address is UP, the GSLB virtual server sends the DNS response with one of the
primary site IP addresses, as selected by the configured load balancing policy.
If all of the configured primary sites in the GSLB virtual IP address are DOWN, then the ADNS or
DNS load balancing virtual server sends the DNS response with the backup IP address. Persistence
is not honored when the backup IP address is configured.
Configure the backup site on the NetScaler system by binding and setting the GSLB virtual server
in the command-line interface:
bind gslb vserver gslbVServer -domain string -backupIP IPAddress
GS|B Ent|ty Re|at|onsh|p
The figure illustrates GSLB entity relationships. DNS virtual servers are only necessary in a DNS
proxy configuration. Otherwise, in an ADNS configuration, each GSLB site will use a locally
configured DNS service with mirrored static DNS records for each site in the configuration (NS
and A records for each site).
Oon|gur|ng GS|B v|rtua| Servers
Create a GSLB load balancing virtual server by specifying the name of the virtual server:
Configuration Utility Under the GSLB > Virtual Server node
location
Command-line syntax
add gslb vserver vserverName serviceType
Oon|gur|ng ADNS
To create an ADNS for DNS in the command-line interface, you must ensure that the domain alias
is bound to the GSLB virtual server and that an authoritative DNS service is added for the required
addresses within the domain.
Configure ADNS for DNS by specifying the IP addresses or virtual IP addresses of the server:
Configuring Utility Under the DNS > Name Servers node
location
Command-line syntax
add dns nameServer IPAddress
Synchron|z|ng a GS|B Oon|gurat|on
For GSLB to work, all participating NetScaler systems must share identical GSLB configurations.
Updating configurations in multiple locations can be expansive and cause downtime. The Auto-
Sync feature allows one NetScaler system to push its configurations to other units in its GSLB
network.
The Auto-Sync feature:
- Aids in configuring GSLB in multiple locations
- Requires configurations only on one unit
- Overrides any GSLB configurations on the target units
Caution is highly recommended when using this command as it will propagate a number
of changes automatically. The [-preview] option allows you to view the commands that
will be executed on the other NetScaler systems.
Automatically synchronize and verify a GSLB configuration using the following command-line
syntax:
sync gslb config [-preview] [-debug]
show gslb syncstatus
GS|B S|te Oommun|cat|on Examp|e
The figure and the following processing illustrate GSLB site communication when a client uses
www.example.com to make a DNS query:
1. A client or non-authoritative DNS server forwards a query to the ADNS/DNS virtual server on
the NetScaler system. The www.example.com web site contains a DNS entry type GSLB domain
pointing to the local GSLB virtual server.
2. The local DNS server/service forwards the query to the GSLB virtual server asking to respond
with an IP address for the www.example.com site. The GSLB virtual server checks its metric
table and returns the IP address of the load balancing virtual server, which returns the best
metric at the time of the client query.
3. The GSLB server forwards the IP address to the local DNS server.
4. The local DNS server responds to the client with the respective IP address.
3. The client makes a connection to the load balancing virtual server using the IP address that has
been returned.
Rev|ew
1. Which statement in NOT true about the GSLB function:
a. GSLB distributes Internet traffic across multiple sites.
b. GSLB relies on DNS for directing client requests.
c. GSLB reduces application latency.
d. GSLB distributes the server load across multiple sites.
2. Which feature applies when a NetScaler system is in an authoritative configuration:
a. Support for zone transfers and recursive query
b. Configuration for a maximum of 30 records
c. Participation of only one NetScaler system to be authoritative
d. Configuration that is local for Start of Authority
3. Which metric exchanges GSLB-site information every five seconds:
a. Network
b. Persistence
c. Server
d. Site
4. Which traditional load-balancing method does not require MEP to be enabled if explicit
monitoring is configured:
a. Source-IP-address hash
b. Least connections
c. Least packets
d. Proximity-based
Modu|e 9
s|ng AppExpert O|ass|c
to Opt|m|ze Traff|c
Overv|ew
AppExpert classic is an expression language used with some features, such as content filtering and
compression, to optimize traffic.
Object|ves
By the end of this module, you should be able to:
- Identify the classic policy expression.
- Use classic policy expressions for content filtering and compression.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 9: s|ng AppExpert O|ass|c to Opt|m|ze Tra|c 227
Po||cy Overv|ew
Policies have a fundamental influence on the behavior of NetScaler features, such as load balancing,
content switching, rewrite, responder, integrated caching, Access Gateway, and Application
Firewall. Policies control how the NetScaler system evaluates data, which ultimately determines
what it does with the data.
The NetScaler system uses two types of policies: classic and advanced. Both classic and advanced
policies derive their ability to control NetScaler behavior from the evaluation of a logical expression
or rule in the policy. The NetScaler system evaluates requests, responses, or other data based on the
rule, and takes one or more actions based on the outcome of the evaluation.
228 Modu|e 9: s|ng AppExpert O|ass|c to Opt|m|ze Tra|c Copyr|ght 2011 C|tr|x Systems, lnc.
Po||cy Bas|cs
Policies provide the foundation for the behavior of most NetScaler features, enabling the features to
interpret the data, such as SSL requests, HTTP requests, TCP requests, and HTTP responses which
pass through it. Typically, if a policy matches the data being evaluated, the NetScaler system takes
one or more actions that are associated with the policy. For example, in rewrite, if an HTTP request
matches a rewrite policy, the NetScaler can take an action to change (rewrite) the information in
the request.
Most of NetScaler features have built-in policies. The number and type of user-defined policies that
a feature requires differ for each feature and the implementation requirements.
A NetScaler feature can use one of two policy types:
Classic policies Classic policies evaluate basic characteristics of traffic and other
data. For example, classic policies can identify whether an HTTP
request or response contains a particular type of header or URL.
Advanced policies Advanced policies can perform the same type of evaluations as
classic policies. In addition, advanced policies enable the analysis of
more data (for example, the body of an HTTP request) and to
configure more operations in the policy rule (for example,
transforming data in the body of a request into an HTTP header).
Bas|c Po||cy Oomponents
Classic and advanced policy components include:
Name Each policy has a unique name.
Rule The rule is a logical expression that enables the NetScaler feature to
evaluate a piece of traffic or another object. For example, a rule can
enable the NetScaler system to determine whether an HTTP request
originated from a particular IP address, or whether a Cache-Control
header in an HTTP request has the value No-Cache.
Advanced policies can use all of the expressions that are available in
a classic policy, with the exception of classic expressions for the SSL
VPN client. In addition, advanced policies enable you to configure
more complex expressions.
Bindings Bindings ensure that the NetScaler can invoke a policy when it is
needed. You can bind the policy to one or more bind points.
Action An action is a separate entity from a policy. Policy evaluation
ultimately results in the NetScaler system performing an action.
For example, an integrated cache policy can identify HTTP requests
for GIF or JPEG files. An action that you associate with this policy
determines that the responses to these types of requests are served
from the cache.
Advanced Po||cy ses
Advanced policy uses include:
DNS DNS is used to determine how to perform DNS resolution for
requests.
Integrated Caching Integrated Caching is used to determine whether HTTP responses
are cacheable.
Responder Responder is used to respond or redirect a client request from a
particular subnet to a specific URL.
Content Switching Content switching is used to determine what server or group of
servers is responsible for serving responses, based on characteristics
of an incoming request, such as device type, language, cookies,
HTTP method, content type, and associated cache server.
Rewrite Rewrite is used to identify HTTP data to be modified before serving
the data and to provide rules for its modification.
Access Gateway, Clientless Access Gateway, Clientless Access function is used to define rewrite
Access function rules for general Web access using the Access Gateway.
Po||cy B|nd|ngs
A policy is associated with, or bound to, an entity that enables the policy to be invoked. For
example, you can bind a policy to a request-time evaluation that applies to all virtual servers. A
collection of policies that are bound to a particular bind point constitutes a policy bank.
The different types of policy bind points include:
Request time global A policy can be available to all components in a feature at request
time.
Response time global A policy can be available to all components in a feature at response
time.
Request time, virtual A policy can be bound to request-time processing for a particular
server-specific virtual server. For example, you can bind a request-time policy to a
cache-redirection virtual server to ensure that particular requests are
forwarded to a load-balancing virtual server for the cache, and other
requests are sent to a load-balancing virtual server for the origin.
Response time, virtual A policy can also be bound to response-time processing for a
server-specific particular virtual server.
User-defined policy label For advanced policies, you can configure custom groupings of
policies (policy banks) by defining a policy label and collecting a set
of related policies under the policy label.
Other bind points The availability of additional bind points depends on the type of
policy (classic or advanced) and specifics of the relevant NetScaler
feature. For example, classic policies for the Access Gateway have
user and group bind points.
Po||cy Pr|or|t|es
The lower the number, the sooner a policy is evaluated relative to other policies. For example, if
you have three policies with priorities of 10, 100, and 1000, the policy assigned a priority of 10 is
performed first. All features except the rewrite feature on the NetScaler system implement only the
first policy that a connection matches. The rewrite policy implements multiple policies in order of
priority, so policy priority is important to get the results you intend.
As a best practice, you can leave room to add policies by setting priorities with intervals
of 30 (or 100) between each policy.
Hypertext Transfer Protoco|
Hypertext Transfer Protocol (HTTP) is the standard client-server protocol used to access Web
content. HTTP consists of a number of request methods that the client submits to the server and
the response codes that the server returns along with any requested data.
By design, the HTTP protocol is stateless, meaning that from the point of view of the server, each
request is fulfilled by a response on a one-to-one basis.
In Web applications, requests may require incremental replies. For example, a request for some
data may require the server to gather additional information before providing access to the
resource. In this case, the initial request cannot be served with a single response. Additional
requests and replies occur before the data is sent to the client. In this case, the server must be able
to recognize that this series of requests and replies represents a single transaction rather than
multiple separate exchanges.
Cook|es
To accomplish the necessary tracking of the transaction state, Web applications often use cookies.
Cookies are strings of data that the server sends to the client and that the client includes in
subsequent requests to the server. By examining the data in the cookies, the server is able to track
the relationships between various requests made by the client.
SS|
HTTPS is an implementation of HTTP using SSL security added at the Session Layer to encrypt
data that is exchanged between the client and the server. HTTPS traffic is regular HTTP. The
encryption of SSL is wrapped around basic HTTP transactions. From the point of view of requests
and responses, there is no difference between HTTP and HTTPS.
HTTP Request Headers
HTTP request header items include:
GET/HTTP/1.1 Defines the client method and the version of HTTP that is being
used
Host Defines the server being contacted
User-Agent Defines information about the client software making the request
Accept, Accept-Language, Define the types of file content, languages, compression algorithms
Accept-Encoding, Accept- and character sets that the client will accept from the server
Charset
Keep-Alive Defines the time the session should be kept open
Connection Defines a request to keep the session open even after the data is sent
HTTP Response Headers
HTTP response header items include:
HTTP/1.1 200 OK Is the status of the request
HTTP/1.1 200 OK Common response codes are:
- 200 = OK
- 302 = content moved
- 404 = file not found
Connection Is the reply of the server to the client request to keep the connection
open
Set-Cookie Sets the cookie values on the client so that the connection state can
be maintained
Cache-Control Instructs the client and any systems passing data to the client not to
cache the page data
Pragma Instructs the client and any systems passing data to the client not to
cache the page data
The Pragma field is backward compatible to HTTP/1.0,
where the Cache-Control header is defined in HTTP/1.1.
Expires Instructs the client and any systems passing data to the client not to
cache the page data
The Expires field shows the date that the data is set to
expire. The value of -1 is another way to dissuade systems
from caching the data.
HTTP Header Sett|ngs
The NetScaler system can alter the HTTP header settings as it intermediates communication with
the client, allowing for optimization of the TCP connection.
For example, a NetScaler system can suppress the connection, close the header and maintain a
connection to the client while multiplexing many client connections to the server on the back-end.
This behavior improves performance for both the client and the server. For example, you can
modify HTTP data to redirect a request to a new home page or a new server, based on the address
of the incoming request. You can also modify the data to mask server information in a response for
security purposes. The URL Transformer function identifies URLs in HTTP transactions and text
files for the purpose of evaluating whether a URL should be transformed.
The NetScaler system can also perform intelligent caching of data based on specific traffic
conditions and parameters.
Express|on Structures
An expression defines the types of requests and associated responses to which the NetScaler system
applies an action. Expressions can be simple or compound.
Inline and named expressions are used in both classic and advanced policies. Inline expressions are
part of a policy and cannot be reused by other policies. Named expressions are a common pool of
logical statement conditions that are applied to the content entering the NetScaler system. Named
compound expressions are independent entities and can be reused by other policies.
The NetScaler system uses a proprietary language based on Perl Compatible Regular
Expression (PCRE) format that adds special terms, allowing the designation of aspects of a
connection at a highly granular level.
Qua|||ers, Operators and Express|on va|ues
Qualifiers on a NetScaler system specify what the policy examines. Operators determine how the
qualifier will be examined. A qualifier is compared with the expression value, which can be literal
text, a substring of text or a numeric value.
Ava||ab|e Qua|||ers or HTTP Tra|c
Qualifiers for HTTP traffic include:
METHOD Refers to the HTTP method used in the request, usually GET or
POST, although all HTTP/1.1 standard headers are accepted for
expressions
URL Refers to the contents of the URL in an HTTP header, not including
the query string
URLLEN Refers to the length of the URL header contents, including the
query string
URLQUERY Refers to the query portion of the URL header contents
URLQUERYLEN Refers to the length of the query portion of the URL header
contents
URLTOKENS Refers to special tokens in the URL
VERSION Refers to the HTTP request version in the form of HTTP/x.x, in
which x is an integer
HEADER Refers to the header portion of the HTTP request by name
Ava||ab|e Qua|||ers or Non-HTTP Tra|c
Qualifiers for non-HTTP traffic include:
DESTIP Specifies the destination IP address or network
DESTPORT Specifies the destination service port
SOURCEIP Specifies the source IP address or network
SOURCEPORT Specifies the source service port
LOCATION Specifies the location value as defined in the GSLB database
Ava||ab|e Operators
The contents of the operator and value fields change depending on the qualifier selected. The
following list describes available operators:
==, EQ Tests for URLs that are case sensitive for exact value text string
matches.
!=, NEQ Tests for URLS that are case sensitive for items that do not match
the exact value text string.
>, GT Tests for URLs and query strings with lengths that are greater than
the value integer. This operator is used with qualifiers such as
URLLEN and QUERYLEN.
<, LT Tests for URLs and query strings with lengths that are less than the
value integer. This operator is used with qualifiers such as URLLEN
and QUERYLEN.
>=, GE Tests for URLs and query strings with lengths that are greater than
or equal to the value integer. This operator is used with qualifiers
such as URLLEN and QUERYLEN.
<=, LE Tests for URLs and query strings with lengths that are less than or
equal to the value integer. This operator is used with qualifiers such
as URLLEN and QUERYLEN.
CONTAINS Tests against the specified qualifier to determine if the specified
string is contained in the qualifier. This operator is not case-
sensitive.
NOTCONTAINS Tests against the specified qualifier to determine if the specified
string is not contained in the qualifier. This operator is not case-
sensitive.
EXISTS Tests for the existence of a particular qualifier.
NOTEXISTS Tests if the particular qualifier does not exist.
CONTENTS Tests if the qualifier exists and if it has contents.
W||dcards
The wildcard character can be used to match a string within the specified qualifier. This character
can appear only once within a string. By using wildcard characters, you can restrict the processing
of a string. For example, the string /gif" will match on the first instance of gif, but not on further
instances of gif if there is more than one gif in the string. This concept is of particular importance
when using rule-based persistence, therefore, carefully configure the strings to be matched when
using rule-based persistence.
Oontext-Sens|t|ve F|e|ds
In the Configuration Utility, context-sensitive fields are displayed depending upon the qualifier and
operator selected.
If the Header qualifier is selected, then type the appropriate header in the Header Name field. If the
CONTENTS operator is selected, then type the length and offset in the Length and Offset fields.
The -length and -offset parameters are used to control what part of a text string is examined for
matching the operator and value. The -length parameter controls the number of characters used
and the -offset parameter defines how far from the beginning of the field the capture begins. For
example, if a string of MSAccess" is examined by an expression with a length of 6 and an offset of
2, Access" is the resulting parsed string sent for evaluation.
S|mp|e Express|ons
The simple expression is the basic building block of policies. A simple expression consists of a
single logical comparison, such as SOURCEIP = 10.12.120.12. In this example, the qualifier is the
source IP address of the traffic and the operator is equal to."
The following expression matches traffic with a source IP address of 63.219.20.0 and a netmask of
233.233.233.0:
add pol exp bad_boys REQ.IP.SOURCEIP == 65.219.20.0 -
netmask 255.255.255.0
The expression string is marked by quotation marks in the command-line interface and the ns.conf
configuration file. The following expression matches requests for specific content in the URL:
add pol exp big_java REQ.HTTP.URL contains big_job.jsp
The following expression matches requests with URL lengths over 236 characters:
add pol exp big_url REQ.HTTP.URLLEN > 256
The following expressions match requests based on the HTTP request headers:
add pol exp accepts_html REQ.HTTP.HEADER accept contains
text/html
add pol exp has_cookie_header REQ.HTTP.HEADER cookie exists
Oompound Express|ons
Compound expressions can be made up of logical combinations of existing simple and compound
expressions. Compound expressions compare the results of the separate expressions with Boolean
logical operators to determine if the compound expression, as a whole, is true or false.
The logical operators that can be used with compound expressions are:
- AND, represented by the double ampersand (&&)
- OR, represented by the double pipe (||)
In the NetScaler system, compound expressions are created from the same interface as simple
expressions within the Configuration Utility.
Unlike simple expressions, compound expressions cannot be modified once they are created
because of the risk of creating an expression loop.
The following compound expressions are built from simple expressions:
add pol exp big_bad (bad_boys && big_java)
add pol exp big_bad_or_long (big_bad || big_url)
Compound expressions cannot contain any qualifier other than COMPOUND. The COMPOUND
qualifier does not need to be explicitly used. By referencing other expressions in the add expression
statement, the statement assumes the use of COMPOUND== before the expressions. For example,
the big_bad expression would be listed in the expression table as add policy expression big_bad
COMPOUND== (bad_boys && big_java).
Oontent F||ter|ng
Content filtering offers protection for Web sites from malicious attacks at the content level. When
this feature is enabled, the NetScaler system inspects every incoming request with the configured
rules based on any HTTP URLs or HTTP headers.
Two commonly used content filtering actions are DROP and RESET, allowing the NetScaler system
to screen unwanted requests from the protected server. It reduces the exposure of the back-end
servers to potential attacks.
Oontent F||ter|ng Act|ons
Content filtering actions include:
RESET Sends a request to terminate the client connection
DROP Drops the client connection
Error Code Sends an HTTP response from the system
Forward Redirects the request to a separate, configured honeypot server (a
server designed to accept and analyze hostile traffic without
exposing valuable resources)
RESET sends a packet to the client to close the connection, and the client gets an
immediate response. DROP completely drops that connection and does not send a
response.
Oontent F||ter|ng Ru|es
The content-filtering feature is built upon the traffic management technology of the NetScaler
system. It filters Web requests on a transaction basis onto servers according to user-defined
policies. Only HTTP Web transactions are filtered.
Content filtering of HTTP requests can be configured for specific conditions with the classic
policies. Rules can be configured based on a combination of:
- URL
- URL query
- URL tokens
- HTTP methods
- HTTP versions
- Standard HTTP headers
- Standard HTTP header values
- Custom HTTP headers
- Custom header values
- Source IP address of the client
If content filtering is enabled, the NetScaler system examines traffic that it encounters and tries to
match it to an existing filter. When traffic matching a filter is detected, the specified filter action is
taken. Content filtering can be used to control traffic that is allowed to flow through the NetScaler
system.
After enabling the feature on the NetScaler system, you define the individual filters. The filters
specify the expressions used to match traffic.
ser-De|ned F||ter Act|ons
Configuration is flexible for rules that are based on HTTP headers and URLs. Commonly-used
user-defined rules include:
Deny Extensions Rejects the request if the file extension associated with the request
matches the configured extensions (for example, suffix)
Deny URL with Path Rejects the request if the URL path associated with the request
matches the configured URL path (for example, prefix)
Deny Long URLs Rejects the request if the URL length (URL length + query length)
associated with the request is longer than the configured length
Deny Long URL Query Rejects the request if the URL query length associated with the
String request is longer than the configured length
Deny URL with Patterns Rejects the request if the URL length (URL length + query length)
associated with the request contains the configured string pattern
Deny URL with Tokens Rejects the request if the URL query associated with the request
contains the configured tokens
Deny URL with Tokens Supported tokens include: ,&,=,:,+ and !
Deny Cookies with Rejects the request if the cookie header content associated with the
Patterns request contains the configured string pattern
lntroduct|on to Oompress|on
By default, the NetScaler system compresses text/HTML and text/plain Multipurpose Internet Mail
Extensions (MIME) formats for all browsers. For other (text/) MIME formats, the NetScaler
system compresses traffic based on the format supported by the browser.
The NetScaler system can compress content generated by most Common Gateway Interface (CGI)
applications. It does not, however, automatically compress images in GIF and JPEG formats as they
are already compressed and would not benefit from further compression. Compressing content that
is already compressed typically leads to larger files and decreased performance. You can configure
the NetScaler system to compress responses based on file size. This threshold is applicable to
responses of any content length but you can set it only if the response consists of one packet.
Oompress|on Process
A NetScaler system configured with compression policies intercepts requests from compression-
aware clients and applies the compression policies to determine whether the client can accept
compressible content. After the NetScaler system receives the HTTP response from the server, the
content is examined again to determine if it is compressible. If the content is compressible, it is
compressed and the compressed content is forwarded to the client. The response header is modified
to indicate the type of compression performed.
Oompress|on Oons|derat|ons
The following list identifies considerations for using compression on the NetScaler system.
Compression algorithm The NetScaler system supports compression through the
GZIP/Deflate mechanism. This mechanism is the default for the
NetScaler system, and is an open standard described in RFCs 1930,
1931 and 1932.
Compression ratio HTML content is compressed to a typical ratio of 3:1 with a data
size of 32 KB available for compression. The exact ratio depends on
the type of data and the global compression setting. Data with a
significant amount of formatting and URL references compresses
more effectively. Similarly, a 20 KB page yields a better compression
ratio than a 200 byte page. The increase in compression ratio is not
linear with data size.
Browser awareness Only compression-aware browsers are provided with compressed
data. Other browsers receive uncompressed data. Configuration is
not needed for browser types. Internet Explorer version 3.0 and
above is an example of a browser that supports compression.
Browsers compatible with the compression feature of the NetScaler
system are listed in the Browser Compatibility" section of the
êtScaler Applicaticn Switch Installaticn and Ccnfiguraticn Guide -
Vcl. 1.
HTTPS compression HTTPS compression is supported when encryption is offloaded by
the NetScaler system. The responses of the server are compressed
and encrypted before they are sent to the HTTPS client.
HTTP versions Both HTTP versions 1.0 and 1.1 are supported with GZIP/deflate in
the Accept-Encoding header.
Oompress|on Responses
Responses are compressed; requests are not compressed.
Compression is done only on responses with a 200 status code. Responses for which the
content length is zero are not compressed.
Additionally, if the response is already compressed, it is detected and bypassed by the
compression engine, enabling the originating sites to use existing server-based
compression in conjunction with the compression feature of the NetScaler system.
The NetScaler system generates a content-length response only if the full response fits within the
NetScaler internal buffer (size of 36,000 bytes).
Oompress|on Parameters
Compression parameters include:
Quantum size Specifies the minimum quantity of data the NetScaler system should
compress. The default quantum size is 37,344 bytes. The quantum
size can vary between 1 and 63,488
Compression level Specifies the level of compression to be carried out
Compression level The options are:
- Optimal
- Best Speed
- Best Compression
Threshold ratio for Specifies the threshold compression ratio for heuristic base file
heuristic expiry expiration, multiplied by one-hundredth
Threshold ratio for For example, 123 indicates a threshold ratio of 1.23. The default
heuristic expiry threshold ratio is 100, and the range is from 1 to 1,000.
History weightage for Specifies the weightage-to-delta-compression history for the
heuristic expiry heuristic base file expiration, as a percentage
History weightage for The default value is 30, and the range is 1 to 100.
heuristic expiry
Minimum HTTP response Specifies the minimum file size to be compressed
size
Minimum HTTP response The default value is 0, meaning that all HTTP responses are
size compressed. The value is expressed in bytes. This parameter helps
eliminate CPU usage for the small files that do not benefit from
compression. This parameter can be configured in the
Configuration Utility and the command-line interface.
Bypass compression on Specifies the percentage of CPU level at which the NetScaler system
CPU usage bypasses the compression feature while processing traffic
Server-side compression Enables compression on the server
Server-side compression When this is enabled, the data transfer between the NetScaler
system and the server is compressed. This parameter is enabled by
default.
Heuristic basefile expiry Enables heuristic base file expiration
Oompress|on Po||c|es
Compression policies enable the NetScaler system to identify the content that needs to be
compressed. Each compression policy consists of an expression and an action. An expression is
created to identify the files entering the system (for example, HTML files, ASP files or PDF files).
An action defines the action the system performs on the file identified by the expression. For
example, you can configure a compression policy comprised of an expression that identifies PDF
files and an action that compresses the PDF files.
A deployment in which compression policies are bound globally enables the compression policies to
act on any service regardless of the virtual server to which the service is bound. Compression
policies can also be bound to a load-balancing virtual server. The compression policies are then
evaluated for only the services bound to the virtual server. The virtual server identifies the least-
loaded originating server and directs client requests to the corresponding service.
Disabling the compression feature will disable compression on the entire NetScaler system
even if it is enabled at the service level.
Oompress|on Act|ons
NOCOMPRESS Disables the compression of data
GZIP Uses the GZIP algorithm to compress data for browsers that
support GZIP compression
GZIP If GZIP compression is not supported on the browser, the system
does not compress data.
DEFLATE Uses the DEFLATE algorithm to compress data for browsers that
support DEFLATE compression
DEFLATE If DEFLATE compression is not suported on a browser, then the
system does not compress the data.
COMPRESS Enables compression for a specific policy using the GZIP or
DEFLATE algorithm based on the browser
Rev|ew Quest|ons
1. Which option describes the EXISTS operator:
a. This operator performs checks against the specified qualifier to determine if the
specified string is not contained in the qualifier.
b. This operator checks if the qualifier exists and if it has contents.
c. This operator checks if the particular qualifier does not exist.
d. This operator checks for the existence of a particular qualifier.
2. Determine if the statement is true or false. A classic policy consists of two parts: an expression
and a request.
a. True
b. False
3. Which statement describes the purpose of a Host header in an HTTP request:
a. Defines the client method and the version of HTTP that is being used.
b. Defines the server to which the request is sent.
c. Defines information about the client software making the request.
4. Which action is used to send a request to close a client connection:
a. DROP
b. RESET
3. Content filtering can be configured in the Configuration Utility in the __________________
node.
a. System features
c. Protection features
d. Load balancing
Modu|e 10
s|ng AppExpert for
Responder, Rewr|te and
R| Transform
Overv|ew
AppExpert Advanced is an expression language used with some features, such as with responder,
rewrite and URL transformation.
Object|ves
- Identify the syntax and uses for advanced policy expressions.
- Configure policies and actions to transform header and other elements of Web traffic.
- Configure responses to specific requests.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 10: s|ng AppExpert or Responder, Rewr|te and R|
Transorm 253
nderstand|ng Packet Process|ng F|ow
As traffic through the NetScaler system is evaluated by the different features, each feature performs
policy evaluation. Whenever a policy matches the traffic, the NetScaler system stores the action and
continues processing. The NetScaler system typically applies all matching actions after processing is
completed.
This figure illustrates the overall packet processing flow for evaluation order. For the majority of
the features, the packet evaluation order does not matter because the events are logged. The
important factor is that some of features, such as Application Firewall, responder and caching, are
first in the packet processing flow. If it matches these, it may not continue evaluation depending on
the configured action. These specific feature evaluations are performed more frequently on the
incoming request, not the transformed data.
254 Modu|e 10: s|ng AppExpert or Responder, Rewr|te and R| Transorm Copyr|ght 2011 C|tr|x
Systems, lnc.
nderstand|ng Po||c|es
The NetScaler feature set uses the policies to evaluate specified conditions and to define the actions
to be taken if conditions are met. The actions defined are specific to the feature for which the
policy is created. The order and flow of policy evaluation depends on the feature set and policy
expression type.
Po||cy Express|ons
Policy expressions compare information to a particular value to determine whether the connection
matches the policy. The end result of any complete policy expression must produce a boolean value
or, with advanced policy expressions, an UNDEF value, to tell the NetScaler system unambiguously
whether a particular connection matches the policy. When a policy expression is bound or
activated, the feature set being bound to or activated evaluates whether the policy expression is
valid for that specific feature.
Po||cy Process Eva|uat|on F|ow
As the figure shows, the evaluation of a policy produces three possible outcomes:
True A true outcome means that the connection matches the policy
expression.
Transorm 255
False A false outcome means that the connection did not match the
policy expression.
Undefined An undefined outcome occurs when a policy cannot be evaluated.
The exact packet processing evaluation flow depends on the feature set performing the
evaluation.
ldent|y|ng Advanced Po||cy Express|ons
The advanced policy expression language is an object-oriented, general purpose expression language
capable of extremely precise data manipulation.
Advanced policy expression types include:
- Non-compound advanced policy expressions
- Compound advanced policy expressions
In a policy, advanced policy expressions can be combined using boolean operators, allowing the
NetScaler system to test multiple connection elements in a structured manner. Advanced
expressions are supported in several features, including DNS, GSLB, content switching, responder,
and rewrite policies.
Advanced Po||cy Express|on Syntax
NetScaler advanced policy expressions read from left to right. The left-most term designates what
part of the connection the expression is analyzing. The values described in the following list can
appear in this position.
CLIENT Designates the client portion of the connection. Use this term to
extract information from the client, such as the client IP address.
HTTP Designates a complete HTTP connection, including both the request
and the response. Use this term to extract information from an
HTTP connection.
SERVER Designates the server portion of the connection. Use this term to
operate on information from the server, such as the hostname.
Systems, lnc.
SYS Designates the NetScaler system and NetScaler operating system.
Use this term to operate on the date and time of the connection or
to insert a classic expression in a larger advanced policy expression.
TARGET Designates the connection target. Use this term to operate on the
target.
TEXT Designates any piece of text. Use this term to operate on any text
values associated with the connection.
URL Designates the URL in the HTTP request. Use this term to operate
on the URL.
VPN Designates any connection that occurs through a virtual private
network VPN that is managed by the NetScaler system.
Successive terms to the right refine the first term to define specific attributes of the connection.
Each term is separated from the preceding or the following terms with a period. Arguments appear
in parentheses following the term to which they apply.
Transorm 257
Act|ons
An action:
- Is bound to or activated by policies
- Cannot depend on results of other actions
- Is applied at the end of the policy evaluation process
- Is owned by individual NetScaler features
For example, actions configured in the responder module are different from those configured
in the rewrite module. The individual feature ensures that the respective actions are applied.
Act|on Syntax
The figure illustrates that the add rewrite action command consists of different parts when used in
Systems, lnc.
nderstand|ng B|nd Po|nts
Bind points were carried over from classic policies, which used virtual server or global bind points,
even though it is not explicitly displayed with classic policies. The bind point and binding to
request or response capability is an important consideration. Where a policy is bound affects when
the action is taken.
One major difference between bind points for classic and advanced bind points is the process of
evaluation through priorities. The evaluation order for advanced policies is:
1. Label-specific policies
2. Global-default labels
The evaluation order for classic policies is
1. Global overrides
2. Virtual server bind points
3. Global default
When a bind point is invoked, the NetScaler system evaluates the policies that comprise the bind
point in the order of the assigned priorities. The scope of the priority assigned to a policy is limited
to the bind point to which the policy is bound. The priority of a policy is only relative to the
priorities of the other policies bound to the same bind point. This function allows grouping of
policies.
Po||cy B|nd|ng Eva|uat|on Process
In the policy evaluation process, a request is being evaluated by the NetScaler system. The following
table explains the evaluation process.
1. The bind point selector selects a bank based on the configuration.
2. The NetScaler system evaluates the request for matches in the selected bank.
3. The NetScaler system finds a match and the policy evaluation process ends. The specified
actions are performed.
4. The NetScaler system invokes the next bank of policies and the request is evaluated against the
next policy bank if no match is found.
3. The NetScaler system performs the identified action if a match is found.
The NetScaler system performs the rule-specific or the global UndefAction in instances when
no match is found and all of the identified policy banks and policies have been evaluated.
s|ng the Po||cy Manager
The policy manager provides an easy interface for managing bind points, priorities and policy labels
in the Configuration Utility. The policy manager makes configuring priorities within bind points
Transorm 259
much easier because the logic is built-in and will not let you configure faulty logic. For example, the
GoToExp logic is built into the policy manager. The NetScaler system cannot use GoToExp to go to
another policy label. The first three policy labels are most frequently used. Configuring for a global
bind point results in all traffic being evaluated.
The virtual server bind point applies to a subset of the global traffic. For example, content switching
will hit a subset of the traffic through that virtual server. When binding, start with the most specific
type first, then go to content switching virtual server and then to the global default. Lastly, there is
a special policy label that can global override all of the prior three labels. The processing is the same
as it is listed in the policy manager dialog box in the Configuration Utility.
Po||cy Manager Oont|nued
The policy manager in the Configuration Utility has all of the necessary logic built into it. For
instance, when a policy is moved, the priority changes and all of the logic in the policy used to
evaluate the traffic is moved.
In NetScaler versions prior to 9.0, you had to create 20 different policy labels to share the same
piece of logic from 20 virtual servers. With NetScaler version 9.0 and later, you can create a single
policy and reuse it for the 20 virtual servers.
nderstand|ng Po||cy |abe|s
A policy label is a user-defined bind point to which policies are bound. The policy label command
allows you to logically group policies and define the order in which they are evaluated. The policy
labels must be invoked to evaluate the user-defined policy banks.
Policy labels are invoked from other policies. When a policy label is invoked, all the policies bound
to it are evaluated in the order of priority. When a policy is matched and the expression is
evaluated to be true, the appropriate action is logged, and the control is returned to the policy that
invoked the policy label.
The policy defines the next policy to be evaluated using GoToExp, or the action ends and goes to
the next priority policy or the next policy bank. Policy labels are specific to certain features such as
the rewrite and responder features.
Oon|gur|ng Po||cy |abe|s
The figure illustrates the commands for adding policy labels in the command-line interface,
including the correct syntax for adding a rewrite policy label and responder policy label for
respollbl2.
Systems, lnc.
Transorm 261
s|ng Pattern Sets
Pattern sets are found in the AppExpert node in the Configuration Utility. Pattern sets are similar
to policy labels in that they allow for reuse. Specifically, they allow you to group similar
components and reuse them for multiple expressions as one reusable object.
Pattern sets allow multiple pattern checks in a tree, or simultaneous checks. This method is more
efficient than multiple separate expressions, which would have to be evaluated one after the other.
Responder, rewrite and integrated caching all use pattern sets.
An example of a pattern set in action is:
http.REQ.HEADER(host).CONTAINS_ANY(host_headers)
In this example, the host_headers is a pattern set and can contain a list of domains.
Systems, lnc.
Typecast|ng
Typecasting converts data streams to numeric and other values and is only available with the
advanced policy engine.
The following list describes some of the values for controlling typecast results.
typecast_text_t Includes structured text
typecast_num_t Includes a string as an integer value
typecast_http_url_t Recognizes a string as a URL
typecast_list_t('&') Check the '&' delimiter in the query part of the URL and put each
argument in a list
typecast_time_t Recognizes the string presented as a time value
Transorm 263
Rewr|te, Responder, and R|
Transformat|on
Rewrite The rewrite feature modifies the header section of an HTTP request
or response but not the data section or chunked data. HTTP
headers control the behavior of the Web server and browser.
Headers communicate to the Web server what type of browser the
client is using so that the server can send the appropriate type of
content. Headers control browser caching of server content, allow
tracking of user sessions and per-user customization of content, and
can support language- and character-set negotiations. The data
section of a request or response contains the information to be
transmitted. Requests often do not contain a data section. If a data
section exists in the request, then the request contains information
entered into a Web form. In response, the data section contains the
text and images that appear in the browser. The only limitation with
rewrite is the inability to handle chunked responses, which is
handled with URL transformation. In addition, the rewrite feature
currently buffers the body. Therefore, when a NetScaler system is
configured to buffer responses, there is a performance effect over
megabyte buffers.
Responder The responder feature functions like an advanced content filter and
generates responses from the NetScaler system to the client. Some
common uses of this feature are the generation of redirect responses
and custom responses or resets. The responder feature deals with
only the request side of the NetScaler system unlike the content
filtering feature, which deals with requests before they are sent to
the back-end servers. The responder is the first module on the
system to process client requests. Custom responses are set up for
different types of requests using this feature. Responder policies are
configured to look for certain types of data in the client request and
to take an action based on the data. If a request matches a
configured responder policy, then the corresponding action
generates the response and sends it to the client. The response often
contains some pieces of the request. For example, when generating a
redirect response, the incoming URL is included in the response.
Systems, lnc.
URL Transformation URL transformation identifies URL patterns in HTML pages and
modifies them to a different form. The feature can translate URLs
from their external appearance to a different appearance for internal
resources. It also offers an ability to handle chunked data. URL
transformation is among the first NetScaler system operations. It
begins on the request side with a policy evaluation.The policy is
evaluated during the request for the entire transaction. The
NetScaler system creates the transformed, internal URL from the
original, external URL and then changes the rewriting request
headers among the last NetScaler system operations. Then, it
rewrites the response headers and URLs in the body. Chunked
encoding and character encoding are both possible with URL
transformation. The feature uses the Application Firewall to parse
the body so the NetScaler system can review the request. Even if the
URL is encoded, URL transformation can modify the URL.
Application Firewall does not need to be enabled in order for this
feature to be configured and work. URL transformation looks only
for specific objects or type of objects. URL transformation addresses
some of the limitations of rewrite as it can handle character
encoding. This character encoding, such as with Chinese and other
character sets, causes problems with rewrite.
If URL transformation and rewrite are configured to act
on the same portion of data, then the NetScaler system
does not perform any actions on that data.
Transormed E|ements
Both relative and absolute URLs are transformed. Variables start at one for the transformation
process and logic.
Elements transformed during the request include:
- Method header (for example GET and POST)
- Host header
- Referrer header
URL transformation does not modify the request body.
Elements transformed during the response include:
- Location header
- Content-Location header
- P3P header
Transorm 265
- Set-Cookie header
- URL attributes under HTML tags in the body, such as href, src, and codebase
Non-HTML content, like JavaScript and CSS, is not transformed.
Systems, lnc.
ldent|fy|ng Packet Process|ng F|ow
The flow process begins with the HTTP request being sent by the client. The NetScaler system
receives the HTTP request and performs configured functions. The process flow varies slightly
between rewrite, responder and URL transformation.
Rewr|te Process
The following steps describe the rewrite process:
1. The client browser sends a request to the Web server through the NetScaler system.
2. The NetScaler system checks the request time policy bank for applicable policies.
3. The NetScaler system builds a set of actions to apply after evaluating the list of prioritized
policies.
4. The NetScaler system rewrites the request and forwards it to the Web server.
3. The Web server receives the request and sends a response.
6. The NetScaler system checks the response time policy bank for applicable policies.
policies.
8. The NetScaler system rewrites the response and forwards it to the client browser.
Transorm 267
Once rewrite rules and policies are configured, enabled and bound to the proper policy bank, the
NetScaler system begins to apply those policies. When the browser of a user sends a request to the
Web server, the NetScaler system checks the request time policy bank. If the NetScaler system finds
rewrite policies, the system evaluates each policy in order of priority, starting with the lowest
number and proceeding to the highest number.
Responder Process
The following steps illustrate the responder process:
2. The NetScaler system checks the request time policy bank for applicable policies.
policies.
4. The NetScaler system responds to the client request with either a redirect or a respondwith.
Systems, lnc.
R| Transormat|on Process
The following steps describe the URL transformation process:
2. The policy is evaluated during the request for the entire transaction.
3. The NetScaler creates the Transformed/Internal URL from the original/external one.
4. The NetScaler rewrites request headers among the last request operations.
3. The NetScaler reverts response headers back to their original state among the first response
operations.
6. The NetScaler reverts URLs in the page body.
Transorm 269
Oonf|gur|ng Po||c|es and Act|ons
Rewrite and responder policies are configured using the Advanced Policy Engine. These policies
must have an action and a rule and must be bound to a bind point. After the policies are bound to
a bind point, the NetScaler system performs rewrite actions.
Con|gur|ng Rewr|te or Responder Po||c|es
Use the following procedure to configure a rewrite or responder action and policy:
1. Define an action to be performed.
2. Create a policy.
3. Define the rule, or expression, which determines when to apply the action.
4. Attach the action for the outcome of the evaluation.
3. Bind the policy (rule + action) to a bind point to perform rewrite.
6. Attach a priority to each policy, which determines the sequence of policy execution.
7. Optional: Refer to the next policy to be evaluated using a goto expression.
8. Optional: Invoke a policy label.
Systems, lnc.
Oonf|gur|ng Rewr|te Act|ons
The Configuration Utility provides an interface, the AppExpert Visual Policy Editor that is easy to
use to build Advanced Policy Engine expressions. The command-line interface is useful for fast
deployment of actions; however, it requires familiarity with the correct syntax of the add
commands.
Visit the Citrix community Web site at http://community.citrix.com/appexpert for
information on the AppExpert Visual Policy Editor.
Actions can be defined using the advanced expression syntax. For example, the following two
commands add a rewrite action to replace the URL path /home.html using advanced syntax:
add rewrite action rw_act_SendToHome
replace HTTP.REQ.URL.PATH \/home.html\
lnsert|ng and Rep|ac|ng HTTP Headers
The figure illustrates adding an INSERT_HTTP_HEADER rewrite action in both the Configuration
Utility and in the command-line interface.
Headers often need to be inserted in the request or response in order to control the client or server
behavior. Some of the behaviors of HTTP insertion addresses include:
- Controlling cache behavior
Transorm 271
- Adding cookies to a request or response for tracking purposes
- Inserting a client IP address in a request for logging purposes
- Adding cache-control, pragma and expires headers to the response
- Deleting cache-control, pragma and expires headers from the response
De|et|ng HTTP Headers
HTTP headers are generally deleted for security or are deleted in conjunction with header insertion
to override a behavior. Some of the reasons for removing an HTTP header include:
- Removing the server header in the response to hide the type of Web server in use
- Removing a cache control header in a response
- Preventing an action on the server, such as removing the accept-encoding header to prevent
compression
When you use the delete_http_header actions, all headers of the same name are deleted.
The figure illustrates the process of adding a DELETE_HTTP_HEADER rewrite action in both the
Configuration Utility and in the command-line interface.
lnsert|ng HTTP Headers
Add an INSERT_HTTP_HEADER rewrite action by using the following command in the
add rewrite action act_insert INSERT_HTTP_HEADER Client_ip
`CLIENT.IP.SRC'
Add a REPLACE rewrite action by using the following command in the command-line interface:
Systems, lnc.
add rewrite action act_replace REPLACE HTTP.REQ.URL.PATH.GET(1)
\citrix\
The REPLACE action is used to match a header or string and to replace it with a new value.
INSERT_BEFORE and INSERT_AFTER are used to insert a new value either before or after a
specified string. These actions replace or insert on only the first instance of the header when they
are applied to a header value.
The figure illustrates three examples of adding a rewrite action in the command-line interface:
- The first example deletes a rewrite action.
- The second example adds a rewrite action to replace a header.
- The third example adds a rewrite action to insert before a specified URL string.
- The fourth example adds a rewrite action to insert after a specified URL string.
De|et|ng Request Oontent
The DELETE action is used to delete a value contained in a URL, a query string or a value
associated with a header. The DELETE_ALL variant finds multiple matching values and deletes
them.
Transorm 273
The figure illustrates adding a DELETE rewrite action in both the Configuration Utility and in the
command-line interface.
Perform a DELETE rewrite action using the following command in the command-line interface:
add rewrite action act_delete DELETE
HTTP.REQ.HEADER("\host\").VALUE(0)"
Rep|ac|ng Response Oontent
REPLACE_HTTP_RES is used to replace a server response, such as a 300 error or a 404 error. No
error checking is performed on the response. Because of the processing flow, integrated caching and
Application Firewall processing still occur on this response. All generated responses will be FIN
terminated automatically.
The figure illustrates adding a REPLACE_HTTP_RES rewrite action in both the Configuration
Utility and in the command-line interface.
Perform a REPLACE_HTTP_RES rewrite action using the following command in the command-
line interface:
add rewrite action retry_request
replace_http_res \HTTP/
1.1 302 Temporary Redirect\\r\\nLocation:
http://www.example.com/\\r\\n\\r\\n\
Bu||t-ln Rewr|te Act|ons
Built-in rewrite actions include:
NOREWRITE Does not perform rewrite
Systems, lnc.
RESET Resets the current client and server connections
UndefAction Is used if the expression evaluation results in an undefined state
The UndefAction is specified for each policy. The global UndefAction is applied to each policy that
does not have a specified UndefAction. NOREWRITE and RESET are the only valid actions for
UndefActions.
Transorm 275
Rewr|te Po||c|es
Rewrite policies are configured in the Configuration Utility and in the command-line interface.
Valid action values include:
- Rewrite action name
- NOREWRITE
- RESET
An UndefAction has a value of NOREWRITE or RESET. The policy evaluation returns a Boolean
result. The figure illustrates an example of adding a rewrite policy with a reset action.
B|nd|ng Po||c|es
Only bound policies respond or rewrite on the NetScaler system. Binding occurs in the
Configuration Utility and in the command-line interface.
Each policy needs a priority assigned to it that is a positive integer constant. A lower value priority
number is interpreted as a higher priority. For example, a priority value set to 10 is a higher
priority than a priority value set to 30. Duplicate priorities are not allowed within each bind point.
Possible GotoPriorityExpression values include:
END Terminates policy evaluation and proceeds to apply the action
NEXT Proceeds to the next policy in the priority ranking
Systems, lnc.
Positive integer Proceeds to the policy with the priority ranking as the specified
type, indicating the type of global bind point
Transorm 277
Responder Act|ons
The actions created are associated with responder policies with the add responder policy command.
The following arguments are identified when adding a responder action:
Name Identifies the name of the action
Type Identifies the type of action
Target Identifies the content with which to respond
Red|rect Act|on
The responder redirect action creates a redirect on a particular event. After providing the URL to
redirect the client, this action is included in the location header of a redirect.
RespondW|th
The figure illustrates configuring a RespondWith action in the Configuration Utility and in the
command-line interface. RespondWith allows for the creation of a fully formed response to the
client. RespondWith does not perform error checking. This maximum length of a response
expression for the RespondWith action is 1300 bytes. The RespondWith action requires proper line
termination between the headers. If proper line termination is not included, then the action is not
performed.
Systems, lnc.
Bu||t-ln Responder Act|ons
The built-in responder actions include NOOP, RESET and UndefAction. A NOOP action does not
send a response. A RESET action resets the current client and server connections.
An UndefAction is used when the expression evaluation results in an undefined state. UndefAction
is specified per policy. If an action for UndefAction is not specified, then the global UndefAction is
applied. As shown in the figure, NOOP and RESET are the only valid Actions.
Transorm 279
Responder Po||c|es
Responder policies are configured in the Configuration Utility and in the command-line interface.
As shown in the figure, the following arguments are identified when adding a responder policy:
Rule Expression used by the responder policy that returns a Boolean
result
Action Responder action name, NOOP or RESET
UndefAction Responder action to be taken in the case of an undefined event
during policy evaluation, with value of NOREWRITE or RESET
Systems, lnc.
Oonf|gur|ng R| Transformat|on
The URL Transformation feature identifies URL patterns in HTML pages and modifies them to a
different form by translating URLs from their external, public appearance to an internal, hidden
resource. This feature simplifies the external appearance of Web sites, hides back-end applications
and architecture and allows infrastructure changes without impacting the user experience. It also
redirects links to third-party service providers and reduces the number of broken links.
To plan for URL transformation, identify the transformed elements:
- URL transformation policy: When to perform transformation
- URL transformation profile: Where to find URLs and actions
- URL transformation action: How to transform and what to do
R| Transormat|on Oon|gurat|on Procedure
To configure URL transformation:
1. Verify the Rewrite feature is enabled.
2. Create a URL transformation profile.
3. Add actions to the profile.
4. Create a URL transformation policy.
3. Bind the policy.
Oon|gur|ng R| Transormat|on Act|ons
The URL Transformation action fields and the variables that can be used include:
Con|gur|ng R| Transormat|on Act|ons
The request and response from fields:
- Contain PCRE expressions to match URLs
- Up to five back-references (wildcards)
When configuring the request into and response into field, you can:
- Use the text field with $ (dollar sign) as special character to access wildcard data by its number
- Use $$ for a literal dollar character
Cookie domain into field is a text field. You can use $ (dollar sign) as a special character to access
wildcard data in the Response URL From field.
Transorm 281
It is possible to transform only the request or the response side of a transaction.
Troub|eshoot|ng R| Transormat|on
You can enable the debug logs for URL transformation to assist in troubleshooting issues with the
feature configuration.
You can use the following tools to troubleshoot URL transformation:
- Debug log messages
- Memory statistics for URL transformation using nsconmsg
Systems, lnc.
Rev|ew Quest|ons
1. What are valid reasons for removing an HTTP header:
a. Removing the server header in the response to hide the type of web server in use
b. Removing a cache control header in a response
c. Removing the server header in the response to show the client the type of web server
in use
d. Preventing an action on the server, such as removing the accept-encoding header to
prevent compression
2. Which description best describes the globally bound policy type of Response Default:
a. Policies bound to this bind point constitute the default request processing behavior.
b. Policies bound to this bind point are only evaluated for responses.
c. Policies bound to this bind point constitute the default response processing behavior.
d. Policies bound to this bind point are only evaluated for requests.
3. What information completes the following sentence: Two major differences between the URL
transformation feature and the rewrite feature is that __________ and __________. (Choose
two.)
a. Rewrite can handle chunked data.
b. Rewrite can handle character encoding.
c. URL transformation can handle chunked data.
d. URL transformation can handle character encoding.
Transorm 283
Modu|e 11
s|ng AppExpert for
Oontent Sw|tch|ng
Overv|ew
Content switching allows the NetScaler system to direct traffic to servers based on the content that
the user is attempting to access. Content switching involves configuring:
- Load-balancing servers
- Services
- Virtual servers
- Content-switching policies
Object|ves
- Describe content switching and the configuration process.
- Design content-switching policies.
- Describe rule precedence in content switching.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 11: s|ng AppExpert or Oontent Sw|tch|ng 287
lntroduct|on to Oontent Sw|tch|ng
Content switching allows HTTP and HTTPS traffic requests to be intercepted and switched in a
method that is transparent to the client. A NetScaler system can switch static and dynamic content.
Content switching provides the ability to direct traffic and client requests to back-end services
based on an aspect of the request beyond the IP/port pair. Content switching allows the design of a
complex internal system to appear to the public behind a single IP address. As clients connect to
and request data from a single address, the NetScaler system examines the type of connection and
sends it to the appropriate back-end service.
The NetScaler system diverts the application requests transparently to the client and the application,
allowing the application to be managed separately from the hosting site.
When switching both static and dynamic requests, you must configure one load-balancing
virtual server for static requests and a separate load-balancing virtual server for dynamic
requests.
Oontent Sw|tch|ng Based on |ayer Oharacter|st|cs
The NetScaler system can also perform TCP content switching based on various characteristics,
such as:
- Layer-3 characteristics, including:
- Source IP address
- Layer-4 characteristics, including:
- TCP port
- TCP maximum segment size (MSS) value
- Buffered TCP payload
If the content-switching policy uses buffered TCP payload, the connection may stop
responding if the client blocks the response of the server and the NetScaler system buffers
the data.
The command syntax for TCP content switching is the same as HTTP content switching. Layer 3-
based and layer 4-based content switching can be configured using classic policies.
nderstand|ng Oontent Sw|tch|ng
A typical content-switching configuration consists of a content-switching virtual server, content-
switching policies and load-balancing virtual servers. Content switching is applicable to HTTP,
HTTPS and TCP traffic.
288 Modu|e 11: s|ng AppExpert or Oontent Sw|tch|ng Copyr|ght 2011 C|tr|x Systems, lnc.
SSL offloading needs to be enabled for HTTPS traffic.
When requests reach the content-switching virtual server, the NetScaler system applies the content-
switching policies to them. The requests are then routed to the appropriate load-balancing virtual
servers bound to the policies. The load-balancing virtual servers then send them to the services.
The content-switching feature allows the NetScaler system to replace application logic for directing
traffic to servers. Content-switching virtual servers can send client requests only to other virtual
servers. The figure shows the relationship between load-balancing virtual servers and content-
switching virtual servers.
Oontent-Sw|tch|ng v|rtua| Servers and |oad-Ba|anc|ng
v|rtua| Servers
A content-switching virtual server is different from a load-balancing virtual server in the following
ways:
- The content-switching feature can be configured using classic or advanced policies, but not
both.
If classic policy expressions are bound to a virtual server, advanced policy expressions
cannot be bound to the same virtual server.
- The content-switching virtual server does not directly address services; it points to load-
balancing virtual servers. The load-balancing virtual servers associate the traffic with real
services and servers.
- The process of distributing traffic among the associated load-balancing virtual servers is
determined by the content-switching policy. On a load-balancing virtual server, this decision is
made by the chosen load-balancing method.
- If the traffic does not match any content-switching policy, then the virtual server sends the
traffic to a default load-balancing virtual server if one is defined.
- If no default server is defined on the content-switching virtual server, the non-
matched traffic is dropped.
- The content-switching virtual server must perform SSL offload if the client is using
SSL.
Oonf|gur|ng Oontent-Sw|tch|ng v|rtua|
Servers
An essential part of configuring content switching is creating content-switching virtual servers.
Content switching is available for:
- HTTP traffic
- HTTPS traffic
- Some TCP traffic
v|rtua| Server Con|gurat|on
The figure illustrates, configuring a content-switching virtual server is very similar to configuring a
load-balancing virtual server.
Configure a content-switching virtual server by defining a service, external IP address, and a port:
Configuration Utility Under the Content Switching > Virtual Servers node
location
Command-line syntax
add cs vserver name serviceType IPAddress port
For example:
add cs vserver cs_http http 10.102.29.70 80
Oontent-Sw|tch|ng Po||c|es
You need to consider several factors when creating content-switching policies, including whether a
policy is configured as URL-based or rule-based and how unmatched traffic is handled.
For URL-based policies, server selection is based on matching the incoming URL with the
configured URLs. In this mode, the content switch returns the most appropriate URL-based content
group (usually the longest matching configured URL) among the configured URLs.
Rule-based policies can be configured in the system so that the content group is selected with the
first matching rule (in the configured order). No specific precedence is set in case of multiple
matching rules. Precedence is based only on the configured order: the rule that was configured first
will be applied first, the rule that was configured second will be applied next, and so on.
URL-based policies have priority over rule-based policies.
B|nd|ng Oontent-Sw|tch|ng Po||c|es
Once the content-switching virtual servers and content-switching policies are created, you must
bind the content-switching policy to the content-switching virtual server. During the binding
process, you should specify the policy to be matched. The content-switching process will not work
properly until the policy to be matched is specified.
Bind a content-switching policy by defining a service, external IP address, and a port:
Configuration Utility Under the Content Switching > Virtual Servers node
location
Command-line syntax
bind cs vserver name targetVserver -
policyName string
A policy does not need to be specified during a bind operation. If a policy is not specified,
a default policy is bound to the virtual server during the bind operation.
bind cs vserver name targetVserver
Ru|e-Based Po||cy Examp|e
The following command-line interface commands create two rule-based content-switching policies:
add cs policy match_big_bad_or_long -rule big_bad_or_long
add cs policy html_w_cookie -
rule accepts_html && has_cookie_header
The first command defines a policy as matching a rule that is a compound expression. The -rule
parameter links an expression to the policy. The second command creates a policy based on a
compound expression that is defined as part of the policy statement. The effect of the two policies
is to define two different types of traffic: one with characteristics of malformed URLs and the other
with a classification of browsers with a specific cookie present.
The following command-line interface commands bind the policies to the content-switching virtual
server:
bind cs vserver cswvip honeypot_lbvip -
policy match_big_bad_or_long
bind cs vserver cswvip normal_lbvip -policy html_w_cookie
bind cs vserver cswvip default_lbvip
The content switching server is bound to these policies so that the potentially malicious traffic is
directed to a honeypot server (a server designed to accept and analyze hostile traffic without
exposing valuable resources). The cookie-enabled browsers are directed to the existing customer
site, and all other traffic is directed to a default server.
Oontent-Sw|tch|ng Ru|e Precedence W|thout Pr|or|ty
Spec||ed
A rule precedence often follows the order in which the rules are configured. If no priority is used
when binding the policy, the policy is assigned a priority of 0, making it the highest priority. If
there is more than one policy with the same priority, they are evaluated in the order that they are
created.
bind cs vserver cswvip lbvip1 -policy cs_policy_a
bind cs vserver cswvip lbvip2 -policy cs_policy_b
bind cs vserver cswvip lbvip3 -policy cs_policy_c
Evaluation order: cs_policy_a > cs_policy_b > cs_policy_c
Oontent-Sw|tch|ng Ru|e Precedence W|th Pr|or|ty Spec||ed
The -priority parameter can be configured when the rule is bound to the virtual server using a
policy. If a priority is provided, the rules are processed from lowest priority value to highest, as
shown in the following example:
bind cs vserver cswvip lbvip1 -policy cs_policy_a -priority 10
bind cs vserver cswvip lbvip2 -policy cs_policy_b -priority 20
bind cs vserver cswvip lbvip3 -policy cs_policy_c -priority 15
Evaluation order: cs_policy_a > cs_policy_c > cs_policy_b
nmatched Tra|c Hand||ng
If a default group is configured for the content-switching virtual server, then the request is
forwarded to the configured default group. If the configured default group is down, or no default
group is configured, an HTTP 404 Not Found error message is sent to the client.
Rev|ew
1. True or False: When switching content to different servers, you only need to configure one
load-balancing virtual server for both types of requests.
a. True
b. False
2. Content switching for HTTPS transactions requires that ________________ and
________________. (Choose two.)
a. SSL offloading be enabled
b. SSL offloading be disabled
c. SSL transactions are not switched in a method that is transparent to the client
d. the traffic type of the content-switching virtual server be set to SSL
3. Which statement concerning how a content-switching virtual server differs from a load-
balancing virtual server is true:
a. A content-switching virtual server is available only for HTTP/HTTPS traffic and is not
implemented for any other protocol.
b. If the traffic does not match any content-switching policy, the virtual server will send
the traffic to a default load-balancing server if one is defined.
c. A content-switching server references actual services.
d. A content-switching virtual server can be configured using both classic and advanced
policies.
Modu|e 12
s|ng AppExpert
Advanced to Opt|m|ze
Traff|c
Overv|ew
AppExpert advanced is useful for optimizing traffic with features such as compression, integrated
caching, and policy-based routing.
Object|ves
- Configure the NetScaler system to optimize Web traffic by:
- Implementing compression examples with advanced policies.
- Caching frequently served Web content to relieve servers and reduce response time.
- Routing traffic based on specific parameters.
- Use application templates to optimize Web traffic from specific applications.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 12: s|ng AppExpert Advanced to Opt|m|ze Tra|c 299
Oompress|on w|th Advanced Po||cy
Express|ons
Advanced policies:
- Support richer expressions.
- Can be used to inspect the HTTP body.
- Can either be bound globally or to HTTP/HTTPS load-balancing or content-switching virtual
servers.
Support or Advanced Po||ces |n HTTP Compress|on
Support for advanced policies in HTTP compression includes:
- All compression policies bound to a load-balancing or content-switching virtual server should
only be of one type (classic or advanced).
- Compression policy actions are executed at response time.
- A content-switching virtual server that uses advanced policies for content switching can have
classic compression policies.
If an advanced compression policy matches at request time:
- Response-time advanced compression policy evaluation is skipped.
- The compression action corresponding to the policy that matched at request time is executed at
response time.
Sett|ng Oompress|on Po||c|es G|oba||y
Either the classic or advanced compression global policy set can be used for compression policy
evaluation for entities:
- HTTP/HTTPS load-balancing or content-switching virtual servers with no compression policies
bound
- Transparent HTTP/HTTPS services
Control the selection using the NetScaler command-line interface command:
set cmp parameter -policyType (CLASSIC | ADVANCED)
Virtual servers that have no compression policies bound use the globally bound classic compression
policies by default. This behavior is the same behavior as NetScaler versions prior to 9.2.
300 Modu|e 12: s|ng AppExpert Advanced to Opt|m|ze Tra|c Copyr|ght 2011 C|tr|x Systems, lnc.
Classic compression polices will not be converted to their advanced equivalents during an
upgrade; They should be manually converted after the upgrade, if required.
Oon|gur|ng Oompress|on
Configure compression in the Configuration Utility or in the command-line interface. Policy labels
are used to invoke the compression policies. The following code demonstrates the commands and
syntax used to manage advanced compression policy labels:
add cmp policylabel <labelName> -type ( REQ | RES )
rm cmp policylabel <labelName>
bind cmp policylabel <labelName> -policyName <string> -
priority <positive_integer>
[-gotoPriorityExpression <expression>] [-
invoke (<labelType> <labelName>) ]
unbind cmp policylabel <labelName> <policyName> [-
priority <positive_integer>]
show cmp policylabel [<labelName>]
You can use the same commands to manage classic compression policies and advanced
compression policies.
lntegrated Oach|ng
Integrated caching stores frequently requested content in the memory cache of the NetScaler
system. It intercepts all HTTP client requests and sends the response to the client if the response is
stored in the memory cache. Responses for requests may or may not be stored in the cache.
NetScaler integrated caching offers:
- HTTP caching: HTTP and (SSL offloaded) HTTPS traffic only
- HTTP/1.1 and HTTP/1.0 only
- Fine-grained configuration supporting static and dynamic content
- Seamless integration with other NetScaler system features
- Fast in-memory cache
- Usage of up to 30 of the physical memory on the system
- Easy manageability
Reverse-Proxy-Oache Oon|gurat|on
As the figure illustrates, a reverse proxy is a proxy server that is installed within the neighborhood
of one or more servers. All connections coming from the Internet addressed to one of the content
servers are routed through the proxy server, which may either deal with the request itself or pass
the request wholly or partially to the main content server. It is useful in an integrated caching
solution to have the NetScaler system serve as a reverse proxy.
Oontent Groups
Content groups are entities that store cached content; every cached object is a member of a content
group, as illustrated in the figure. Content groups can be used to control common settings for
content cached within that group, such as content-expiry method, prefetch, cookie removal, and
header modification settings.
Oache Se|ectors and Po||c|es
Cache Se|ectors
Cache selectors are patterns or expressions that are formed from a combination of different parts of
a request. When a client requests dynamic content, selectors search through the cache to locate the
appropriate response for the client.
Po||c|es
Policies are the combination of an action and an expression to determine which requests and
responses should be cached and in which cache content group the object will be stored. Policies can
also be used to invalidate cached objects or content groups.
Oach|ng Stat|c and Dynam|c Oontent
Integrated caching is capable of caching dynamically generated content, which is typically marked
non-cacheable by Web servers and application servers. Static content remains the same for multiple
users, including page-based caching, such as search engine pages, and object-based caching, such as
Web-based application graphics. Dynamic content periodically changes, which includes object-
based caching only, such as stock updates, sports scores, and news.
Dynam|c Oontent
Caching dynamic Web application content requires complex configuration. To cache dynamic
responses, you must understand the application behavior and determine which responses are
cacheable. Most applications declare almost every dynamic response as non-cacheable, but any
response that does not change with every request is potentially cacheable. Dynamic content requires
a time-based refresh to maximize content caching.
You can select one of the following parameters to cache dynamic objects:
- The duration for which the response can be cached
- The trigger that causes the response to change
If configuring a trigger that causes a response or change, then you should determine whether that
trigger is used to flush the object from the cache. Dynamic content caching often requires
parameterized caching.
Oache Act|ons
The following table lists the cache actions.
Actions Description
CACHE This action makes the transaction cacheable. If
it is associated with a content group, then the
response is stored in that content group.
Otherwise, it is stored in the DEFAULT content
group.
NO CACHE This action makes the transaction non-
cacheable. The response is not stored in the
cache.
MAY_NOCACHE If neither request nor response cache policies
match, then the default action is to cache the
response. The MAY_NOCACHE action reverses
this behavior for chosen requests. This action,
associated with a request cache policy, makes
the response non-cacheable if no response cache
policy is matched. The MAY_NOCACHE
request time directive can be overridden by a
CACHE response time directive.
MAY_CACHE This action, associated with a request
cacheability policy, makes the response
cacheable if no response cacheability policy
matches, which is very similar to the default
behavior. This action can also take the name of
a content group. The DEFAULT content group
is assumed if no content group name is
specified. The response gets cached, if at all, in
the specified content group.
The MAY_CACHE request time directive can
be overridden by a NOCACHE directive at
response time. A CACHE response time
directive without any content group specified
results in the response being cached in the
content group specified with the MAY_CACHE
action. A CACHE response time directive with
a content group different from the content
group specified with the MAY_CACHE action
results in the response not getting cached.
INVAL This action invalidates some cached objects. The
INVAL action also has the side effect of making
a transaction non-cacheable. The assumption is
that an invalidation request modifies an object
or transaction at the origin, and it cannot be
cached.
Request and Response Process F|ow
The integrated-caching process flow and request, and response-policy-evaluation flows are
important in understanding built-in cacheability policies. Two sets of built-in cacheability policies
exist. One policy is for request-time processing, and the other is for response-time processing.
These built-in policies encode the standard HTTP behavior, which is part of the integrated cache
default behavior.
The figure shows how integrated caching occurs early on in the request and response process flow.
The client request hits or misses, as well as undergoes request-side policy checking. The server
response undergoes response-side policy checking and goes through a CACHE or NOCACHE
action.
Oache Po||c|es and Oache Express|ons
You can use cache policies and cache expressions to configure integrated caching.
Cache Po||c|es
Cache policies use the powerful NetScaler policy framework. Policies can be used to override and
add to the built-in standard HTTP caching behavior. Policies determine what transactions are
cacheable. They decide into which content group a cacheable object goes, and they determine which
set of objects in the cache get invalidated by a given HTTP request.
In order to configure the NetScaler system for dynamically generated content or a non-standard
static object, you need to configure cache policies to encode the desired behavior.
Cache Express|ons
The expression specified with the policy is evaluated on the incoming request or response. The
expressions are standard classic-policy-engine expressions with one exception. Whereas the syntax,
semantics and operators are the same, an expression can contain request-only expressions or
response-only expressions, but not both.
Depending on whether the rules have request-only expressions or response-only expressions, cache
policies can be classified as request policies or response policies. Other than controlling when a
policy is evaluated, this classification also controls what kind of action can be associated with a
policy.
Oache Po||c|es
Cache policies:
- Are either request-side or response-side
- Equal a name + rule + action
- Name a content group in which cached objects are stored
- Are built-in and non-modifiable or are custom and modifiable
- Are HTTP/1.0 and HTTP/1.1 request cacheable only
- Are only GET method cacheable
- Are non-cacheable with a response pragma header
- Are non-cacheable with a response Set-Cookie header
B|nd|ng Oache Po||c|es
Cache policies must be bound to be active. The policies can be bound by using the Activate Policies
button in the Configuration Utility or by using the bind cache global command in the command-
line interface.
Options for binding cache policies are:
Priority The priority determines the evaluation order of policies. The lower
the value specified for the priority option, the higher the priority of
the associated policy.
Precede Default Rules The Precede Default Rules option designates that the policy will be
evaluated prior to (and therefore take precedence over) the built-in
policies.
Policies with an INVAL action must be bound with a
higher priority than other policies with the Precede
Default Rules option selected.
Oache Po||cy Eva|uat|on
Policies are made up of expressions for policy evaluation and a corresponding action to be applied
when the expression is matched. Moreover, policies must be bound with priorities to define their
evaluation order when multiple policies are present.
l Then
A request matches an invalidation policy That request bypasses the cache.
l Then
Bypass is enabled The hit evaluation happens only after the pre-
default, default and post-default request
cacheability policies have been evaluated.
If bypass is enabled, then the request-
time cache policies have already been
evaluated to test whether the request
should bypass the cache or not. If the
matching object is present but has
expired, then the cache policies are not
evaluated again unless the -
alwaysEvalPolicies argument is set to
YES in the content group of the
expired object.
Bypass is not enabled Hit evaluation will happen before the request
cacheability policies are evaluated.
Not enabling bypass leads to better
performance because most hits are
served without any cacheability policy
evaluation.
No policies match (built-in or user configured) The response is cached in the DEFAULT
content group.
The cacheability decision has already been made No further cacheability policy evaluation takes
at request time place.
A request matches a request-time cacheability The request-time cacheability policies with
policy with a MAY_CACHE or a lower priorities are not evaluated. The response
MAY_NOCACHE action cacheability policies are still evaluated.
The first CACHE or NOCACHE policy that matches determines whether the response object and
the group that the object belongs to are cacheable. Cacheability evaluation happens only for
requests that do not find a matching object in the cache, such as cache misses.
Eva|uat|on Order
The following information applies to the evaluation order of cache policies:
- The cache policies are listed in the order in which they are evaluated during the lifetime of an
HTTP transaction.
- The response cacheability policies can have only CACHE or NOCACHE actions. The CACHE
action can further specify a non-parameterized content group in which to store the response
(otherwise, DEFAULT is assumed).
- The policy evaluation order is controlled by the priority to which it is bound within each
classification. The NetScaler system ensures that you cannot specify inconsistent priority. For
example, you cannot specify a priority for a cacheability policy that is higher than the priority
of any invalidation policy.
- No two policies can have the same priority value.
- The action that becomes effective is the one that is associated with the first policy in the
priority order that matches within each classification.
Bu||t-ln Po||c|es
The integrated cache has built-in request and response default policies. The NetScaler system
evaluates the policies in a particular order. These policies are hard-coded for efficiency. The built-in
policy names start with an underscore (_). You can view the built-in policies from the
Configuration Utility and the command-line interface using the show cache policy command.
You can override these built-in policies with a user-defined policy that is bound to a request-time
override or response-time override policy bank.
Gracefu| Oache Oonf|gurat|on Ohanges
Integrated caching is on unless disabled, and reconfiguring while integrated caching is enabled can
lead to unexpected behavior. To avoid unexpected behavior, you can configure changes gracefully.
To perform graceful changes to the integrated cache:
1. Disable integrated caching.
2. Flush the cache.
3. Make configuration changes.
4. Enable integrated caching.
By default, the caching feature caches all cacheable content when the feature is enabled.
You need to configure the caching feature if the default caching behavior is not desired.
Oache Oontent Groups
Every cached object is made a member of a content group. The association happens at the time the
object is being downloaded and stored. This association is declared in the policy that resulted in the
caching of this object.
Cache content groups are used to organize content so that settings may be managed at a group
level rather than for each policy.
The following content group names are reserved:
- DEFAULT
- ALL
Reversed Oontent Group Names
DEFAULT refers to a built-in content group. If a group name is not specified in a cache policy,
then all objects cached by that policy are cached in the DEFAULT content group. Although the
DEFAULT content group cannot be removed, the DEFAULT group is no different from any other
explicitly configured group.
Unless it is changed, the DEFAULT content group uses the standard HTTP mechanism for
expiring the objects. The DEFAULT content group is not parameterized and has prefetch enabled.
For more information about built-in settings, refer to the Citrix Hardware Installaticn and Setup
Guide.
Changing the settings of the DEFAULT content group does not affect any other group in
any way.
The name ALL is also reserved. ALL refers to all content groups, including the DEFAULT group.
Oache Oontent Ag|ng
Controlling content aging involves calculations regarding the expiry time of an object and is set as
an attribute of the cache content group. Expiration types include:
User-configured recurring The absolute expiry time specifies the exact time when the object
absolute expiration must expire everyday. The time is specified in the HH:MM format,
and either in local time or GMT time.
The absolute expiry can be configured to occur up to four times
daily.
User-configured recurring The relative expiry time specifies the number of seconds or
relative expiration milliseconds from the time the request missed the origin to the
expiry time of the object.
Heuristic expiration The heuristic expiry time determines the time of expiry by
considering the last modified header. The time of expiry is
expressed as a percentage of the duration since the object was last
modified. The heuristic that remains unmodified for a longer time is
likely to have a longer expiry period.
Weak positive relative The weak positive relative expiry is set in conjunction with heuristic
expiration expiration. The setting is used to set relative expiration for
responses that do not contain a last modified header.
Weak negative relative The weak negative relative expiry is used to set relative expiration
expiration for negative responses (such as 404 Page Not Found or 301 Content
Moved).
Oontent Group Sett|ngs
Content group settings affect content aging, memory usage, HTTP headers, cookie removal and
other attributes.
Memory ||m|t
Content group settings that affect memory include:
- Memory limit
- Minimum response size
- Maximum response size
- Pinned
A memory limit can be configured for each content group. This configuration allows you to limit
the amount of available cache space that a specific content group can consume.
There is a minimum and maximum response size to cache in the cache content group.
Selecting the pinned option prevents objects in the content group from being flushed under
memory pressure.
HTTP Headers and Oontent Group Sett|ngs
Each of the following content group settings affects HTTP headers:
Insert Age If this action is configured, the Age header is inserted into responses
served from cache. The Age response-header field conveys the
sender's estimate of the amount of time since the response message
(or its revalidation) was generated at the origin server.
Insert Via If this action is configured, the Via header is inserted into responses
served from cache. The Via header denotes that the object was
served out of the NetScaler cache.
Insert Etag If this action is configured, the Etag header is inserted into
responses served from cache. An Etag is an HTTP response header
returned by an HTTP/1.1 compliant Web server used to determine
change in content at a given URL. When a new HTTP response
contains the same Etag as an older HTTP response, the content is
determined to be the same without further downloading.
Cache-Control A Cache-Control header can be specified in the response. Any valid
entry for a Cache-Control header can be specified.
Oook|e Remova|
Cookies are often personalized for each user. Therefore, sharing them across users may lead to
undesired behavior. You may want to configure cookie removal for every content group that stores
embedded objects, such as images.
If a content group has cookie removal configured, then the Set-Cookie and Set-Cookie2 headers are
removed before storing any response in that content group. If cookie removal is not configured,
and if the response contains cookies, then cookies are stored and served with every hit.
The default behavior is not to store any response with Set-Cookie or Set-Cookie2 headers
unless the response is an image. When images get cached because of the default behavior,
then the Set-Cookie and Set-Cookie2 headers are removed.
Configure cookie removal for an existing content group in the command-line interface:
set cache contentgroup name -removeCookie YES
Other Oontent Group Attr|butes
The following table describes other content group attributes.
Attr|butes Descr|pt|on
Poll every time This setting forces the system to revalidate all
objects with the server before serving a response
from the cache.
Prefetch This parameter is used to decide whether the
integrated cache should attempt to refresh an
object immediately before it is expired.
Minimum hits This setting specifies the minimum number of
accesses for an object to be stored in cache. The
default value is 0.
F|ashOache
The FlashCache feature reduces the impact of flash crowds. When enabled, this feature causes the
NetScaler system to allow only one request to reach the server. All the other requests are queued
until the server responds. The response from the server is then returned to all queued requests,
improving flash-crowd handling.
If the originating server responds with an error message, the same error message is repeated across
all the recipients. Upon receiving a request, the NetScaler system queues the clients with the
assumption that the response is cacheable. If the response becomes non-cacheable while being
stored, the NetScaler system aborts storing and continues to send the response from the server to
all the queued clients.
As the figure illustrates, the FlashCache feature can be enabled on a per-content group basis. Poll
every time (PET) and FlashCache cannot be enabled on a single content group. FlashCache can be
used in conjunction with the Expire at Last Byte option if the content should not be retained in
cache.
G|oba| Oache Attr|butes
Cache global settings apply to all objects stored in the cache regardless of the content group in
which they belong. Cache global settings include:
- ON | OFF
- Via
- memLimit (up to 30 of memory)
Oache Arguments
The set cache parameter command modifies the global configuration of integrated cache. You can
use the following command to cache parameters in the command-line interface:
set cache parameter -memLimit MB -via string -verifyUsing verifyusing -maxPostLen PcsitiveInteger
-prefetchMaxPending PcsitiveInteger -enableBypass ( YES | NO)
memLimit The memory limit for integrated cache is configured by memLimit.
The default is no value. Value settings include:
- Minimum: 0
- Maximum: 4,093
via A via header is inserted in all responses served from a content
group if its insertVia flag is set.
verifyUsing The criterion for deciding whether a cached object can be served for
an incoming HTTP request is configured with verifyingUsing.
prefetchMaxPending The maximum number of outstanding prefetches in integrated
caching is configured with prefetchMaxPending. The default is no
value and the maximum value is 4,294,967,294.
enableBypass The bypass argument is configured with enableBypass. If set to NO,
then an incoming request serves a hit if a matching object can be
found in the cache storage, regardless of the cacheability policy
configuration. If set to YES, then the bound request cacheability
policies are evaluated before any hit selection in the cache storage is
attempted. If the request matches a policy with NOCACHE action,
then the request bypasses all cache processing. This flag does not
affect the processing of those requests that match an invalidation
policy. The default is no value.
ver|ys|ng Argument
Value settings for verifyUsing are:
- HOSTNAME
- HOSTNAME_AND_IP
If the value of this attribute is set to HOSTNAME, then the URL, host name and host port values
in the incoming HTTP request header must match before a cached object can be served. The IP
address and the TCP port of the destination host are not matched. For certain deployments, the
HOSTNAME setting can be a security risk.
A rogue client can access a rogue server through the integrated cache using the following HTTP
request:
GET / HTTP/1.1
Host: sensitive.foo.com
In this example, the integrated cache stores the rogue page served by the rogue server. Any
subsequent client trying to access the root page from sensitive.foo.com is served the rogue page.
HOSTNAME Sett|ng
The HOSTNAME setting should be set only if it is certain that no rogue client can access a rogue
server through the integrated cache. The YES setting can lead to more hits if DNS-based load
balancing is in use, and the same content can be served by multiple servers.
If the attribute is set to HOSTNAME_AND_IP, then the URL, host name, host port in the
incoming HTTP request header, IP address and TCP port of the destination server must match.
If the set cache argument attribute is set to DNS, then the URL, host name, host port in the
incoming HTTP request and the TCP port should match. In regards to the IP address of the
destination server, the hostname is used to perform a DNS lookup, and it is compared with the set
of addresses returned by the DNS lookup. The default value is DNS, with a DNS default of no
value.
Oach|ng Management
The objects in cache can be invalidated two ways with the command-line interface:
- Expiring an object ensures that the object is not served by integrated caching without re-
validating it by the origin. Objects that do not carry validators, such as Etag or last-modified
headers, cannot be revalidated. For these objects, flushing or expiring has the same effect.
- Flushing an object ensures that the object is never served by integrated caching again.
Invalidations are carried out at different levels of granularity. If the object is part of a non-
parameterized content group, then the URL must match byte by byte with the stored URL. If the
object is part of a parameterized content group, then the group name has to be specified, and the
URL must match the stored URL. The hostname and port must be the same strings that were
present in the Host HTTP request header of the cached object. If a port is not specified, then port
80 is used.
AppExpert Temp|ates
AppExpert templates, which are reusable bundles of configuration information, provide an easy way
to configure the NetScaler system to optimize the traffic of specific applications.
AppExpert templates require the application expert to categorize the workflow of the application
into units. Then rules are planned for each of these units before you can start deploying the
application using the NetScaler system.
The application view also provides a single interface to manage in a few clicks all of the application-
specific settings.
An additional benefit of being able to import and export templates is the ability for you to
exchange these templates. Within organizations and between organizations, you and application
experts can share optimizations and best practices.
The terminology used when discussing AppExpert templates is more commonly used with
applications. The interface provides an executive view of configuration and acts as one-stop shop to
configure most of the NetScaler features.
s|ng AppExpert Temp|ates
AppExpert templates are accessible from the Applications section of the AppExpert node within the
Configuration Utility.
You can use AppExpert templates to:
- Configure the various application features that the NetScaler system is optimizing.
- View which NetScaler functional modules, such as compression, caching and Application
Firewall, are optimized and active for a given application unit.
AppExpert templates can be downloaded, imported, modified and exported. Download specific
AppExpert templates built or certified by Citrix from the AppExpert community Web site at
http://community.citrix.com/display/ns/AppExpert+Templates.
These templates are easily imported into any NetScaler system running NetScaler 9.0 or higher,
jump starting the configuration and deployment process. Templates developed in-house can be
easily exported and shared within the organization, or posted back to the AppExpert community
Web site.
The public endpoints and back-end service information are two crucial pieces of information when
configuring AppExpert templates.
s|ng the App||cat|on lnterace
The interface for AppExpert templates allows you to see the following information by application
component and NetScaler module:
- Which individual NetScaler features are configured for an application
- Which features are inactive but available for configuration for an application
You can use the Configuration Utility to create and activate policies in each feature or deactivate
individual policies for an application. Available activities related to AppExpert templates include:
- Downloading an application template from the AppExpert community Web site
- Importing an AppExpert template
- Creating an application
- Creating application units
- Configuring back-end services
- Configuring public endpoints
- Modifying the expression of an application unit
- Changing the order of application units
- Applying features
- Exporting an application as a template
- Viewing statistics
- Viewing the visualizer
App||cat|ons Pane
AppExpert templates, not to be confused with entity templates, are found under the AppExpert
node. The figure illustrates the two menu items available in the AppExpert Applications pane:
- Application names
- Application units
You can perform the following tasks in the Applications pane for the NetScaler system:
- Create a new application on the NetScaler system.
- Remove an application from the NetScaler system.
- Import an AppExpert template to be used with the NetScaler system.
- Export an application into an AppExpert template configuration to use on other NetScaler
systems.
- View statistics for the application or corresponding application units.
- Use the visualizer to view a graphical representation of the application.
App||cat|ons Pane: App||cat|on n|ts
Application units describe the content that you may want to optimize. As the figure illustrates, the
following tasks can be performed for application units:
- Add a new application unit to the application.
- Configure policies for compression, caching, rewrite, content filtering, responder and
Application Firewall.
AppExpert Temp|ate Sca|ab|||ty
You can design a unique application configuration, export it to an application template, and then
import it on other NetScaler systems. The figure shows the export and import functions for an
application template.
An exported template has the .gz file extension.
P|ann|ng or App||cat|ons
Before creating and configuring a NetScaler system for an application, you need to identify the
workflows of interest. Key terminology to guide the planning process includes application
workflows, also known as application units within the Configuration Utility. These terms are used
to define logically how the NetScaler system interfaces with a specific application.
The creation and use of AppExpert templates can be divided into two major tasks. Both tasks can
be carried out by the same person or team in an organization.
Create the AppExpert The first task is performed by an application expert, who knows the
Template and Application intricacies of the application, its workflows and the optimizations
Units that would benefit the application. This knowledge is used to create
the AppExpert template and its application units (workflows) and to
configure optimization and security policies for the application. The
resulting template is exported providing a reusable AppExpert
template that you can import whenever a similar application is
deployed in the environment.
Import the AppExpert The second task is performed by an administrator who is
Template responsible for deploying the NetScaler configuration of an
application. The administrator imports the existing AppExpert
template to the NetScaler system and provides the deployment
unique to the environment such as the IP addresses and ports of
public endpoints and back-end services. This import results in a
new completely configured application that appears on the system.
You can, if required, further tweak the policies or application units
of the created application.
Term|no|ogy
Application units define a subset of traffic for an application for which you are interested in
creating policies. Examples include:
- Reports
- Documents
- Images
- Stylesheets
- Web Services
- Portal Pages
The definition of application units should be request based, because the expressions are built upon
request-based rules.
Methodo|ogy
The methodology behind deploying a NetScaler configuration for an application requires two steps:
1. Identification of application workflows of interest according to the type of content they
generate from server to client
2. Creation of application units based on the identified workflows, defining specific rules that
allow the NetScaler system to recognize each workflow
During the process of creating an application in the NetScaler system, you can enter the expression
of the rule to identify each application unit (workflow). You can configure policies for features,
such as compression, caching, rewrite, filtering, responder, and Application Firewall, that pertain to
this application.
What is chosen as an application unit by the application expert depends on what needs to be
optimized. For instance, if the application expert determines that compressing all Word documents
will benefit the application, then the expert can create an application unit called 'Word documents'
with a rule that identifies the requests of this workflow (for example URL contains /.doc").
It is beneficial to identify application units by which one can configure multiple features. This
action streamlines the application definition by reducing the number of application units needed in
an application.
Identifying and planning the workflows of an application, and the optimization policies that can be
applied to each is the main task of the application expert, and requires knowledge of the application
in order to optimize benefits of the feature.
App||cat|on Examp|e: Part 1
The following table provides an example of the SharePoint application broken down by workflow,
the workflow characterizations, and the components of the workflow.
The workflows are broken into general categories, such as document management and portal
management. The content is identified by specific file types, such as .doc and .asp file types, in the
components column. These file types can be used to build application units.
Work|ow Character|zed By Components
Document Management Document Sharing & Storage, .doc, .docx, .ppt, .pptx, .dot,
MS Office Documents, Reports, .dotx, .docm, .dotm, .rtf, .txt,
Spreadsheet, Forms .wps, .pot, .potx, .pptm, .potm,
.thmx, .ppsx, .ppsm, .pps,
.ppam, .pdf, .csv, .prn, .xsn, .xls,
.xslx, .xlt, .xltx, .xlsb, .xlsm,
.xltm, .dif, .slk, .xlam, .xla
Styles and Scripts Stylesheets, Javascript .css, .js
Image Management Images .gif, .jpg, .jpeg, .tif, .tiff, .bmp,
.wmf, .emf, .png
Portal Management ASP.NET, Web Pages .asp, .aspx, .htm, .html, .mht,
.mhtml, .xhtml, .xml, .jsp, .jspx
Web Services Definitions WSDLs and WSILs :wsdl, .wsdl, :wsil, .wsil, .xml
Web Services Schema XSDs .xsd
App||cat|on Examp|e: Part 2
The table illustrates taking the plan for this example one step further. In this example, after
identifying the content workflows or pertinent content, a NetScaler administrator determines what
policies can be applied to optimize the application. Some of this determination is based on general
NetScaler best practices, some is based on application-specific best practices, and some is based on
internal organizational preferences.
For example:
- Documents can be compressed and cached.
- Images can be cached but not compressed.
- Portal pages should not be compressed or cached.
Every organization has unique philosophies on what content can or should be cached,
compressed and configured for optimization. You should coordinate with the appropriate
groups before configuring an application.
SharePo|nt Compress| Cach|ng Rewr|te F||ter Responder
on
Documents X X
Styles and X X
Scripts
Images X
Portals
Web Services X
Web Service X X
Schema
Default X X
AppExpert Temp|ate Dep|oyment
To deploy an application template:
1. Configure the back-end services and public endpoints.
2. Create application units.
3. Apply the desired features.
The order of the tasks necessary for deploying an application varies depending on whether the
application is generic, such as Microsoft SharePoint, or custom.
For many of the generic applications, you can download a template that includes the majority of
the generic optimizations. From there, you import the template, configure the public endpoints and
back-end services and make any desired customizations to the feature rules.
For custom applications, a template might have been prepared by a local application expert. If this
is the case, you can import that template and configure the public endpoints and back-end services.
Even when you create and configure an application directly on a NetScaler system
(without using an existing template), a good practice is to export the application once
configured into an AppExpert template. Use that template when configuring the same
application on other NetScaler systems, instead of re-building the application
configuration from scratch on each system.
Po||cy-Based Rout|ng
Use cases for policy-based routing are:
- Traffic originating from different network might need to be routed differently, such as selecting
a different next hop
- Secure or non-secure links for different types of originating traffic
- Traffic isolation achieved for environments with shared infrastructure, such as those using
different routes for different virtual IP addresses would simulate service provider multi-tenant
deployments
An example of policy-based routing is traffic from an internal IP range gets redirected to an
internal intranet site, while Internet traffic gets routed to the public site. These sites would exist on
different networks and would not be virtual servers and services configured on the NetScaler
system, as the NetScaler system supplies the next hop, and not the destination of the request.
In multi-tenancy environments, the same IP addresses might be configured for different users of
the same appliance. To cope with these complexities, use policy-based routing to treat or route
traffic differently based upon their source or destination IP addresses.
Po||cy-Based Rout|ng Parameters
Policy-based routing provides a way to select the next hop based on the following parameters:
- Source IP address
- Source port
- Destination port
- Protocol
- VLAN
- Interface
- MAC address
Po||cy-Based Act|on Oon|gurat|on
The configuration process for policy-based routing is similar to access-control-list configuration. If
there is an ALLOW action, then the next hop is invoked. If there is a Deny, the packet is routed
normally.
This figure shows the process flow for how policy-based routing is evaluated, and the resulting
action. Resulting actions include changing the next hop as configured, or routing as normal.
Rev|ew
1. Which one of the following parameters cannot be used to configure policy based routing:
a. VLAN
b. HTTP URL
c. Source Port
d. MAC Address
2. What outcome is a result of a policy that evaluates as not applicable to the current request:
a. DEF
b. TRUE
c. FALSE
d. UNDEF
3. Which two of the following are a source for new application templates:
a. Another NetScaler system
b. The NetScaler community web site
c. The NetScaler CD
d. NetScaler updates
4. What top-level object provides operations on system wide data:
a. CLIENT
b. HTTP
c. SERVER
d. SYSTEM
Modu|e 13
Management
Overv|ew
The NetScaler system can be monitored with the following tools:
- Simple Network Management Protocol (SNMP)
- Dashboard
- Monitoring tool
The NetScaler system has the following auditing and logging features:
- Support for syslog and nslog auditing
- Log access and management
Object|ves
- Configure monitoring with SNMPv1 and SNMPv2 on the NetScaler system.
- Monitor the NetScaler system with the Dashboard.
- Monitor the NetScaler system with the Monitoring tool.
- Configure syslog and nslog logging.
- Access and manage NetScaler logs.
Copyr|ght 2011 C|tr|x Systems, lnc. Modu|e 13: Management 335
S|mp|e Network Management Protoco|
Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a
method for network devices to communicate status and configuration information to a
management station. By default, SNMP uses UDP on port 161 for queries and port 162 for traps.
You can perform the following SNMP configurations on the NetScaler system:
- Specify system information that can be displayed using the NetScaler SNMP MIB.
- Specify SNMP traps that track various parameters, such as usage and interface status.
A NetScaler system supports SNMPv1, SNMPv2 and SNMPv3. SNMPv1 and SNMP v2 use a simple
and non-secure authentication feature called community strings. SNMPv3 adds security with
authentication, privacy and access control. SNMPv3 is not a replacement for previous versions; it
defines a security capability to be used in conjunction with SNMPv1 or SNMPv2.
SNMPv1 and SNMPv2 consist of the following components:
- Managed devices
- Agents
- Managers
- Management Information Base (MIB)
- Community Strings
- Traps
Managed Dev|ces
Managed devices are network nodes that reside in a managed network. Managed devices collect and
store management information and make this information available to a network management
system (NMS) using SNMP. Managed devices are sometimes called network elements and can be
routers, access servers, switches and bridges, hubs, computer hosts, or printers. The NetScaler
system is an example of a managed device.
SNMP Agents
Agents are software modules that reside on managed devices. Agents listen on port 161 for request
packets from managers and respond to requests for information and actions. In addition to the
protocol and application layers, agents must also communicate with the operating system kernel.
Typically, SNMP uses UDP port 161 for the agent and port 162 for the manager communications.
The manager may send requests from any available port (source port) to port 161 for the agent
(destination port). The agent response will be sent back to the source port, and the manager will
receive traps on port 162. The agent may generate traps from any available port
336 Modu|e 13: Management Copyr|ght 2011 C|tr|x Systems, lnc.
The NetScaler system allows traps to be sent to a different port other than 162 if needed.
Managers
Managers are devices that poll agents for information. Managers can perform a passive statistics-
gathering function, or they can attempt to manage the network actively by setting new values in
read-write variables on some hosts.
SNMPv1 managers (programs on other servers that request SNMP information from the NetScaler
system) use the NS-MIB-smiv1.mib file when processing SNMP queries. SNMPv2 managers use the
NS-MIB-smiv2.mib file.
Management systems tested with the NetScaler system include:
- OpenView
- WhatsUp Gold
- Net-SNMP (Linux)
- MGSoft (Windows)
Management lnormat|on Base
A management information base (MIB) is a collection of objects. Each object in a MIB has a unique
object identifier (OID) and represents a piece of information from an agent. A MIB is organized
hierarchically. A new MIB is defined for each new device.
The NetScaler system contains the standard MIB and a private MIB for NetScaler-specific data. The
standard MIB contains items, such as ifOperStatus and ifInOctets, whereas the private MIB
contains items such as virtual server current connections and total requests/responses.
The enterprise registered OID for the NetScaler system is 1.3.6.1.4.1.3931.4 (3931).
The following table provides a list of the most commonly polled SNMP OIDs.
ltems Descr|pt|ons
HA Current State 1.3.6.1.4.1.3931.4.1.1.23.24
Average CPU 1.3.6.1.4.1.3931.1.1.0.31
Memory Utilization () 1.3.6.1.4.1.3931.4.1.1.41.2
Server Connections 1.3.6.1.4.1.3931.4.1.1.46.1
ltems Descr|pt|ons
Client Connections 1.3.6.1.4.1.3931.4.1.1.46.2
HTTP Requests 1.3.6.1.4.1.3931.4.1.1.48.67
HTTP Responses 1.3.6.1.4.1.3931.4.1.1.48.33
Interface Stats (table) 1.3.6.1.4.1.3931.4.1.1.34
The NetScaler system generates OIDs for name-based virtual servers and services. Custom IDs are
derived by encoding the virtual server and service names in decimal numbers.
Oommun|ty Str|ngs
A community string is a type of authentication that allows access to managed devices. The manager
and agent must be in the same community.
If a manager sends a request with the correct community string, the device responds with the
requested information in accordance with the allowed level of access for that community string. If
the community string is incorrect, the device simply discards the request and does not respond.
Community string types include:
- Read-only community string
- Read-write community string
- Trap community string
The default community string on the NetScaler system is public. The default community string
should be changed to read-only, read-write, or trap.
Traps
The only type of communication initiated from the agent to the manager is a trap. A trap is an
alert or auto-fire event sent when some event or threshold is reached. A trap that is supported by
almost all SNMP agents is the Authentication trap. This alert is raised whenever an unknown
manager attempts a query on the agent. The NetScaler system supports SNMPv1 and SNMPv2
traps, but not SNMPv3 traps.
All SNMP traps are logged in syslog.
Oon|gur|ng SNMPv1 and SNMPv2
You can use the following procedure to configure SNMPv1 and SNMPv2 on the NetScaler system.
1. Set access privileges for the network management application by configuring a manager.
Configure a manager by specifying the IP address and subnet mask:
Configuration Utility Under the System > SNMP node
location
Command-line syntax
add snmp manager IPAddress[-netmask netmask
2. Set access privileges for the network management application user by configuring the
community string.
Configure the community string by specifying the SNMP community string and permissions:
location
Command-line syntax
add snmp community communityName permissions
3. Set the MIB variable by specifying the contact, name, location, and custom ID:
location
Command-line syntax
add snmp mib [-contact string] [-
name string] [-location string] [-
customID string]
4. Configure a trap by specifying:
- Trap type
- Trap version
- Destination port
- Source IP address
- Minimum severity (this is only applicable to NetScaler-specific traps)
- Community name
location
Command-line syntax
add snmp trap TrapClass TrapDestination [-
version (V1 | V2)] -destPort port -
communityName string [-srcIP IPAddress] -
severity severity
3. Set a trap threshold.
Configure an alarm by enabling the alarm, and specifying the severity level and current state of
the alarm:
location
Command-line syntax:
set snmp alarm TrapName [-
state ENABLED | DISABLED]
Oon|gur|ng SNMP Managers
You can configure up to 100 managers on a NetScaler system. If no SNMP manager is configured,
the NetScaler system accepts and responds to SNMP queries from all IP addresses on the network.
If one or more SNMP managers are configured, then the NetScaler system accepts and responds to
only SNMP queries from those specific IP addresses.
Add a manager on the NetScaler system by specifying the IP address and subnet mask:
Configuration Utility Under the System node
location
Command-line syntax
add snmp manager IPAddress [-
netmask netmask]
View details for the manager on the NetScaler system by specifying the IP address and subnet
mask:
location
Command-line syntax
show snmp manager IPAddress [-
netmask netmask]
Oon|gur|ng MlB System var|ab|es
A management information base (MIB) represents the set of values that can be requested from a
particular agent. Each network device may have its own MIB that includes the types of information
appropriate to the device. For example, a firewall has different values than a layer-2 switch.
Show and set the SNMP MIB on the NetScaler system by specifying the contact person, system
name, physical location of the system, and the custom ID for the system:
location
Command-line syntax
set snmp mib [-contact string] [-
name string] [-location string] [-
customID string]
Oon|gur|ng Oommun|ty Str|ngs
A maximum of 20 SNMP communities can be configured on the NetScaler system. Each
community string can be a maximum of 32 characters. The permissions are:
- GET, which receives a piece of management information
- GET_NEXT, which retrieves sequences of management information
- GET_BULK, which is a faster way to receive sequences of management information
- ALL, which enables all access permissions
Add a community string on the NetScaler system by specifying the community name and setting
the permission values:
location
Command-line syntax
add snmp community CommunityName permissions
SNMPv1 and SNMPv2 Oommun|cat|on Process
The figure and the following process provides an overview of the SNMPv1 and SNMPv2
communication process occurring between an SNMP manager and the NetScaler system, which is
the managed device running the SNMP agent and housing the MIB.
1. The manager makes a GET request to the NetScaler system to retrieve data.
2. The NetScaler system validates the request by evaluating the community string and source IP
address of the manager.
You can configure up to 100 managers on a NetScaler system. If no SNMP manager is configured,
the NetScaler system accepts and responds to SNMP queries from all IP addresses on the network.
If one or more SNMP managers are configured, then the NetScaler system accepts and responds to
only SNMP queries from those specific IP addresses.
Oon|gur|ng SNMP Traps
You can configure two types of traps on the NetScaler system:
- Generic SNMP traps (standard to all SNMP-enabled devices)
- NetScaler specific traps
Each of these trap types can be enabled and sent to different destinations on a configurable port.
The available generic SNMP traps is authenticationFailure. An SNMP management application
without access privileges attempts to access the Application Switch.
Add an SNMP trap on the NetScaler system by specifying the IP address:
location
Command-line syntax
add snmp trap TrapClass trapDestination [-
version (V1 | V2) ] [-srcIP IPAddress]
Oon|gur|ng A|arms
Alarms are configured on the NetScaler system to generate a trap message when an event
corresponding to an alarm occurs. Configuring an alarm consists of enabling the alarm and setting
the severity level at which a trap is generated. The five alarm severity levels are critical, major,
minor, warning, and informational. A trap is sent on two events:
- When an entity breaches the high threshold to indicate the error condition
- When the entity stabilizes to indicate a normal level
After an alert trap is sent, if the counter drops to the normal level or below, a second normal trap is
sent. If more than 10 authentication traps are generated in a span of twenty seconds, the NetScaler
system does not generate additional authentication traps for the next 60 seconds. This behavior is
useful when the system is under an SNMP attack.
Configure an alarm on the NetScaler system by enabling the alarm and specifying the severity level:
location
Command-line syntax
- Enable/disable an alarm
set snmp alarm trapName [-
state ENABLED | DISABLED ]
- Specify the severity level
set snmp alarm trapName [-
severity severity]
SNMPv3
SNMPv3 is based on the structure and architecture of SNMPv1 and SNMPv2 and uses the same
protocol operations implemented by SNMPv1 and SNMPv2. SNMPv3, however, enhances the basic
architecture to incorporate administration and security capabilities, such as authorization, access
control, data integrity checking, data origin verification, message timeliness checking, and data
confidentiality.
SNMPv3 configuration packets (views, groups, users, and engineID) are sent to the SNMP daemon
on the same UDP port 161 with source number IP address and destination number IP address of
the loopback address (127.0.0.1) to distinguish them from protocol data units.
SNMPv3 provides security features, such as message-level security and access control. To
implement these features, SNMPv3 introduces the following models:
User-based Security Model USM provides message-level security. It enables you to configure
(USM) users and security parameters at the agent and the manager to
ensure:
- Data integrity, protecting messages from being modified during
transmission through the network
- Data origin verification, authenticating the user who sent the
message requests
- Message timeliness, protecting against message delays or replays
- Data confidentiality, protecting the content of messages from
being disclosed to unauthorized entities or individuals
View-based Access Control VACM allows the configuration of access rights to a specific subtree
Model (VACM) of the MIB based on various parameters, such as security level,
security model, user name, and view type. It enables the
configuration of agents to provide different levels of access to the
MIB to different managers.
SNMPv3 Oomponents
The NetScaler system supports the following components that enable you to implement the security
features of SNMPv3:
SNMP Engine An SNMP engine resides in an SNMP agent and implements the
functions for sending and receiving messages, authenticating and
encrypting/decrypting messages, and controlling access to managed
objects. SNMP engines are uniquely identified using engine IDs.
The NetScaler system has a unique engine ID based on the MAC
address of the loopback interface. The engine ID is configurable.
SNMP Views The SNMP views restrict user access to specific portions of the MIB.
SNMP views are used to implement access control.
SNMP Groups The SNMP groups are logical aggregations of SNMP users. They are
used to implement access control and to define the security levels.
You can configure an SNMP group to set access rights for users
assigned to that group, thereby restricting the users to specific
views.
SNMP Users The SNMP users are the SNMP managers that are configured on
the agent to access the MIB. Each SNMP user is assigned to an
SNMP group. These entities function together to implement the
SNMPv3 security features. Views are created to allow access to
subtrees of the MIB. Groups are then created with the required
security level and security access to the defined views. Finally, users
are created and assigned to the groups.
SNMP users, groups, and views are propagated to the
secondary node in a high availability pair; the engine ID is
not.
Dashboard
The Dashboard, also referred to as the Statistical Utility, is a Web browser-based application that
allows you to monitor and plot the real-time performance of the NetScaler system.
You can obtain similar statistical information using the stat command in the command-
line interface. Refer to the Citrix êtScaler Ccmmand Reference Guide for more
information about the stat command.
System Requirements The Dashboard is a Java applet. This applet requires version
1.4.2_07 of the Java applet plug-in. Refer to the Citrix Hardware
Installaticn and Setup Guide for platform-specific system
requirements.
Launching the Dashboard Click the Dashboard link in the Configuration Utility to launch the
Dashboard.
System and Feature Oounters
The Dashboard monitors both system and features counters.
System counters include:
- CPU utilization
- Memory utilization
- System throughput
- System statistics
- Protocol statistics
- High availability
- Bridge
- Access control list
- Network entities
- SNMP
- System logs
Feature counters include:
- Audit
- AAA
- VPN
- TCP compression policy
- Load balancing
- Content switching
- Services
- HTTP compression
- Decompression
- Integrated cache
Certain features are dependent on the enabled licenses.
Dashboard Oomponents
The Dashboard components provide you with information on the health and status of the NetScaler
system.
CPU Utilization Pane The CPU Utilization pane displays the real-time CPU utilization of
the system as a percentage of the total capacity. The color codes for
the pane are:
- Green, which indicates that the CPU utilization is within safe
limits
- Yellow, which indicates that the CPU utilization is high
- Red, which indicates that the CPU utilization has reached a
critical limit
Memory Utilization Pane The Memory Utilization pane displays the real-time memory
utilization of the system. While the dial indicates the percentage of
the memory used, you can drag the mouse cursor over the pane for
an absolute value. The color codes for the pane are:
- Green, which indicates that the memory utilization is within
safe limits
- Yellow, which indicates that the memory utilization is high
- Red, which indicates that the memory utilization has reached a
critical limit
System Throughput Pane The System Throughput pane displays throughput in terms of
incoming and outgoing traffic.
HTTP Requests per Second The HTTP Request per Seconds pane illustrates the HTTP requests
Pane served by the system per second.
System Log Pane The System Log pane provides a view of system events and alerts
that are generated when the Dashboard is connected to the system.
The data is real-time and has an unlimited history; however, all data
is lost when the Dashboard is restarted.
Built-in Comparative The Built-in Comparative Charts pane monitors a built-in set of
Chart Pane counters using charts. The charts depict the variation of two or
more counters over time. Options for viewing the charts include
chart type, chart appearance, legends, independent window views,
and custom charts.
Group Monitoring Pane The Group Monitoring pane provides a view of all counters
pertaining to a feature or protocol and the ability to plot any
number of counters on custom charts. By default, this pane provides
a snapshot of the system.
Nav|gat|ng the Dashboard
The Dashboard offers several clickable options that allow information to be viewed and analyzed in
a meaningful manner.
Single-Click Options The availability of single-click options on a pane is indicated by the
default mouse cursor changing to the hand cursor. Single-click
options on the Dashboard can result in the following actions
depending on the context or area in which they are invoked,
including the launching of the:
- Custom chart window if the pane supports the Custom Charts
option.
- Change Counter dialog box if the pane does not support the
Custom Charts option.
- Legend View option if neither the Custom Charts nor the
Change Counter options are supported.
- Plot windows for specific counters, such as CPU Utilization,
Memory Utilization, and Throughput.
- System log window with contents from the system log pane.
The contents of this pane are updated with the other windows.
Right-Click Options The right-click option is available for panes that have a menu-bar or
that support the single-click option.
The Application menu does not support the right-click
option. It is also not available in some cases, such as the
Add Counters dialog box for the Custom Chart even
though it has a menu bar.
Double-click Options The availability of double-click options is not indicated by the
change of the cursor. The panes are:
- Feature/Device Group
The double-click option is available for feature/device groups.
This action always results in a comparative, tabular window
listing the identification parameters and critical statistical
parameters of all the items/entities configured under a given
feature/device group. The groups for this option are:
- Load Balancing Virtual Servers
- Load Balancing Services (bound to a load balancing virtual
server)
- Services (independent/bound to virtual servers)
- Content Switching virtual servers
- TCP Compression Policy
- Interfaces
- VLANs
- Custom Charts
The Custom Charts option is also available in the Custom
Chart/Add Counters dialog box. You can add or delete counters
by double-clicking it.
Report|ng and Mon|tor|ng Too|s
The NetScaler system provides two tools that parse and display the data contained in the syslog file.
Reporting Tool The Reporting tool, a Web-based interface, provides built-in reports
that display statistics collected by the nscollect utility.
Reports allow you to plot and monitor statistics for the various
functional groups over a specified time interval, which allows for
the troubleshooting and analyzing of the behavior of the NetScaler
system.
The Reporting tool is accessed by selecting Reporting when logging
in to the NetScaler System.
Monitoring Tool The NetScaler GUI provides a built-in monitoring tool that provides
historical performance data for all features on the NetScaler system.
The charts are updated every seven seconds and are generated on
the NetScaler system. The performance charts are:
- CPU, Memory Utilization and System Throughput
- Pie
- Bar
The Monitoring tool is accessed by clicking Monitoring in the
Configuration Utility.
Aud|t|ng and |ogg|ng
Auditing is a feature that is available on the NetScaler system that provides a log of system events.
The NetScaler system allows you to customize the logging of system events according to the need of
a site. Events can be recorded either to files on the NetScaler system or to external log servers. The
NetScaler system supports two logging formats:
- Syslog
- Nslog
By default, the NetScaler system records system events in syslog format to /var/log/ns.log using
local0 and records SSL VPN events to /var/log/nsvpn.log using local1. Logging of these events is
enabled by default. Syslog uses UDP over port 314, and syslog traffic is sent in clear text. The
NetScaler kernel controls syslog processing. Nslog is a proprietary binary format, which records
more detailed event information than the syslog format. Syslog and nslog events can be logged to
either a local file on the NetScaler system or to a remote server.
Syslog.conf should not be modified.
Oonf|gur|ng an Aud|t|ng Server
An external nslog audit server can run either the Linux, FreeBSD or Windows operating system.
The audit server executable installation files can be either copied from the NetScaler product CD or
downloaded from the ftp.netscaler.com Web site.
Local logging still occurs on the NetScaler system when an external audit server is
configured.
Configure an audit server on the NetScaler system by specifying the following:
- Audit server name
- Auditing type
- IP address of the external server used to store auditing messages
- Port number used for communication between the system and the external logging server
- Level of logging detail
- Date format
- Time zone
- Log facility value
- TCP logging
Configuration Utility Under the System > Auditing node
location
Command-line syntax
add audit logAction name ServerIPAddress [ -
serverPort port] -loglevel LogLevel [ -
dateFormat ( MMDDYYYY | DDMMYYYY )] [-
logFacility logFacility] [ -
tcp (None | ALL )] [ -
timeZone ( GMT_TIME | LOCAL_TIME )]
Replace logAction with the type either syslogAction for a syslog auditing server, or
nslogAction for an nslog auditing server.
G|oba| Aud|t|ng Parameters
Global auditing parameters help you log all the states and status information collected by different
modules in the kernel, as well as in the user-level daemons in the NetScaler system.
Configure global auditing parameters on the NetScaler system by specifying the following:
- Auditing type
- IP address of the external server used to store auditing messages
- Port number used for communication between the system and the external logging server
- Level of logging detail
- Date format
- Time zone
- Log facility value
- TCP logging
location
Command-line syntax
add audit Params name ServerIPAddress [ -
serverPort port] -loglevel LogLevel [ -
dateFormat ( MMDDYYYY | DDMMYYYY )] [-
logFacility logFacility] [ -
tcp (None | ALL )] [ -
timeZone ( GMT_TIME | LOCAL_TIME )]
Replace Params with either syslogParams for a syslog auditing server, or nslogParams for
an nslog auditing server.
Oonf|gur|ng Aud|t|ng Po||c|es
Auditing policies determine which messages are generated and logged during the session. These
messages are logged in the syslog or nslog format. Different types of messages are logged based on
the level of logging selected.
Auditing policies are used for the Access Gateway feature of the NetScaler system.
Add an auditing policy on the NetScaler system by specifying the policy name and rule action:
Configuration Utility Under the System > Auditing > Policies node
location
Command-line syntax
add audit Policy name rule action
B|nd|ng Aud|t|ng Po||cy
On the NetScaler system, auditing can be configured at multiple levels in the following order of
priority:
1. Global
2. Virtual server
3. Group
4. User
At each of these levels, multiple auditing policies can be defined. Auditing policies can be bound
globally and can be bound to virtual servers, groups and users.
Bind an auditing policy on the NetScaler system by specifying the policy and assigning a priority:
Configuration Utility Under the System > Auditing > Policies node
location
Command-line syntax
bind system global [PolicyName [-
priority PositiveInterger]]
Aud|t Messages
You can view recent and historical audit messages in both the Configuration Utility and in the
command-line interface.
View recent audit messages on the NetScaler system by specifying the level of detail to be displayed
and the number of audit messages to be shown and the style in which to display the messages:
location
Command-line syntax
show audit messages [-loglevel LogLevel] [-
numOfMesgs PositiveInterger]
View historical audit messages on the NetScaler system by clicking Syslog messages in the
System > Auditing node of the Configuration Utility.
NetSca|er |og Management
Newnslog stores console messages, events, and performance statistics, which are written to
newnslog every seven seconds. Every three hours the log is saved. Once saved, these newsnslog files
roll on a periodic basis based on a specified lifetime of the nsconmsg process. When a log rolls,
each older log file is compressed using GZIP and saved with a number from 0 through 100.
Newnslog is a binary file stored in /var/nslog.
The Manage Logs option in the Diagnostic pane provides the ability to view information from the
log files, save viewed data, download the log files, and delete the unwanted log files from the
NetScaler system. The following actions can be performed:
Viewing Events View events in the log table by clicking View event and specifying
the log file in the System > Diagnostics node of the Configuration
Utility.
Viewing Log Files View the time span of a selected log file by clicking View log file
Duration duration and specifying the log file in the System > Diagnostics
node of the Configuration Utility.
Viewing Events from a View the events from a specific time by clicking View events from
Specific Time specific time and specifying the log file and date in the System >
Diagnostics node of the Configuration Utility.
Viewing Console Messages View the console messages by clicking View console messages and
specifying the log file in the Configuration Utility.
Downloading Log Files Download log files from the NetScaler system by clicking Download
log files and specifying the log file and the destination folder in the
System > Diagnostics node of the Configuration Utility.
Deleting Log Files Delete log files by clicking Delete log files and specifying the log file
in the System > Diagnostics node of the Configuration Utility.
Rep|ac|ng a H|gh-Ava||ab|||ty Node
When one node in a high-availability pair fails, the secondary node is the only NetScaler system
accepting incoming traffic. A new node must be added to complete the high-availability pair. The
configuration of the primary node is propagated to the new replacement node after it has been
added.
Use the following process to replace a failed node in a high-availability pair:
1. Configure the active node to stay primary.
2. Specify the NSIP address on the new system and restart.
3. Copy all the necessary files, such as certificate files, key files, and custom monitors from the
primary node.
4. Turn off all unused interfaces on the new system.
3. Create a new high-availability pair on the new system.
6. Force synchronization on the new system.
7. Enable high availability on the primary node.
Perform|ng an pgrade
The two different options for upgrading the NetScaler system are upgrading as a standalone, or
upgrading a high-availability pair.
pgrad|ng as a Standa|one NetSca|er System
Use the following process to upgrade a standalone NetScaler system using the command-line
interface:
1. Create a backup copy of the ns.conf file.
2. Create a release number nsinstall subdirectory in the /var/nsinstall directory.
3. Create a build folder subdirectory in the /var/nsinstall/release number directory.
4. Download and extract the contents of the installation package to the /var/nsinstall/release
number/build folder.
3. Run the installns script to install the new version.
6. Restart the NetScaler system.
The NetScaler system can be upgraded in the Configuration Utility using the Upgrade
Wizard.
pgrad|ng a H|gh-Ava||ab|||ty Pa|r
To upgrade the system software on NetScaler units in a high-availability pair, the software on the
secondary node is updated first and then on the primary node.
Use the following process to upgrade a high-availability pair. Before the upgrade, System A is the
primary node and System B is the secondary node:
Step Descr|pt|on System
1 Perform a standalone upgrade B
on the secondary node.
2 Verify after the restart that the B
system is the secondary node,
and that synchronization and
propagation are disabled.
Step Descr|pt|on System
3 Perform a standalone upgrade A
on the primary node.
4 Verify after the restart that the A
system is the secondary node,
and that synchronization and
propagation are disabled.
3 Verify that system B is now the B
new primary node.
6 Verify that the configuration of A
the secondary node has been
synced with the new primary
node.
7 Save the configuration. B
Password Recovery
The NetScaler system default user account is nsroot. The password for this account should be
changed prior to saving your initial NetScaler configuration. It is also best practice to create a back-
door super-user account.
In the event that the passwords for both accounts cannot be located, the password for the nsroot
default account can be recovered.
For detailed information on recovering the nsroot password visit the Citrix Suppcrt Web site.
Network Traff|c Oapture s|ng NSTOPDMP
The nstcpdump.sh script is used for low-level troubleshooting, or troubleshooting when low traffic
volume does not support the nstrace.sh script. The nstcpdump.sh script does not collect all the
information that the nstrace.sh script can collect; this point should be considered before using the
nstcpdump.sh script for troubleshooting. The nstcpdump.sh script should not be used if a complete
output of the nstrace.sh script is needed for the appropriate analysis of a NetScaler system issue.
Filters based on IP address, TCP, or UDP port numbers can be set for the output of the
nstcpdump.sh script. This output provides targeted data which can more easily be analyzed.
NSTCPDMP syntax
The nstcpdump.sh script is run at the shell prompt by using the following syntax:
nstcpdump.sh [options] [filter_expression]
If a packet count is not specified in the syntax, the nstcpdump.sh script is stopped by
running the kill command or by pressing Ctrl-C.
TOPDMP Opt|ons
The nstcpdump.sh script supports the use of tcpdump options to allow you to capture specific data.
-c Specifies the number of packets to record and to automatically
terminate the script
-X Sends the script output to stdout, and displays packet content in
hexadecimal and ASCII format
-w <destination_file> Writes the recorded packets to the specified file in standard
tcpdump format
The complete path is used when specifying the file.
-I <interface_number> Restricts packet recordings to a specific interface
This option is used multiple times to select multiple interfaces.
NSTRAOE F||ter Express|ons
The following list provides options that are used in the TCPDUMP NSTRACE filter expression.
Multiple expressions can be combined using Boolean operators.
host <IP_Address> Restricts packets recordings to or from the selected host IP address
net <Subnet_Address> Restricts packet recordings from the specified subnet
mask <Netmask>
port <Port_Number> Restricts packet recordings to the specified range of TCP or UDP
port numbers
dst port <Port_Number> Restricts packet recording from the specified destination TCP or
UDP port numbers
src port <Port_Number> Restricts packet recording to the specified source TCP and UDP
port number
tcp Restricts packet recordings to only TCP packets
udp Restricts packet recordings to only UDP packets
arp Restricts packet recordings to only the ARP packets
icmp Restricts packet recordings to only the ICMP packets
Network Traff|c Oapture us|ng NSTRAOE.SH
Network traffic can be captured using the nstrace.sh script and the nstcpdump.sh script on the
NetScaler system.
The nstrace.sh script is used for troubleshooting, and provides extended data for analysis. Filters
can be set on the nstrace.sh script to capture a trace with the front-end (client to vServer) or the
back-end (NetScaler system to server) or both. To limit the file size, the nstrace.sh script should run
for the minimum amount of time needed to gather the appropriate information.
The nstrace.sh script provides:
- Packet capture in the native NetScaler trace format, which provides NIC device information
and packet transmission data
- Connection link information, which allows for the identification of links between client and
virtual server, and SNIP/MIP to server TCP connections
- The ability to create multiple files based on a set amount of time and number of files per cycle
using the -nf and -time options
- The ability to create separate trace files per NIC using the -nic option
- Packet capture in tcpdump format, if desired
NSTRAOE Syntax
The nstrace.sh script is run at the shell prompt by using the following syntax:
nstrace -sz [postiveInteger] -tcpdump [ ENABLED | DISABLED ]
Replace postiveInteger with a value between 0 and 100 to specify the file size, where
0=unlimited and 100=max file size.
NSTRAOE Opt|ons
The nstrace.sh script supports the use of options to allow you to capture specific data.
-mode [mode] Identifies the capturing mode for the trace
-mode [mode] Mode values include:
-mode [mode] TX - transmitted packets
TXB - packets buffered for transmission
RX - received packets before NIC pipelining
IPV6 - translated IPv6 packets
NEW_RX - received packets after NIC pipelining
-name Specifies the name of the trace file
-filter Specifies the filter expression for trace filtering
-id Specifies a unique ID for the trace file name, and should only be
used with the -name filter
F||ter Express|ons
Filter expressions are supported by nstrace.sh and consist of qualifiers and operators. The value of
the qualifiers is based on the operator used in the filter expression.
IP-based filtering, which
- destip <ipaddress>: Restricts packet recording based on the
uses the operators: ==,
specified destination IP address
eq, != and neq
- ip <ipaddress>: Restricts packet recordings based on the
specified IP address(es)
- sourceip <ipaddress>: Restricts packet recordings based on the
specified source IP address(es)
Port-based filtering, which
- sourceport <Port_Number>: Restricts packet recordings based
use the operators: ==,
the the specified TCP or UDP port numbers
eq, !=, neq, >, gt, <, >=, ge,
- destport <Port_Number>: Restricts packet recording based on
<=, le, BETWEEN
the specified destination TCP or UDP port numbers
Service and Server name-
- svcname <name>: Restricts packet recordings based on the
based filtering, which used
specified service name
the operators: ==, eq, !=,
- vsvrname <name>: Restricts packet recordings based on the
neq
specified virtual server name
TCP state-based filtering,
- state <state>: Restricts packet recordings to the specified TCP
which used the operators
state
==, eq, != , neq
- TCP state-based filtering uses the following qualifier values:
CLOSE_WAIT, CLOSED, CLOSING, ESTABLISHED,
FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, LISTEN,
SYN_RECEIVED, SYN_SENT, and TIME_WAIT
Connection ID-based connid: Restricts packet recordings based on the connection ID
filtering
Rev|ew
1. Which entity is a type of authentication that allows access to managed devices:
a. Trap
b. Agent
c. MIB
d. Community string
2. Which port does syslog use by default:
a. TCP port 80
b. UDP port 443
c. TCP port 22
d. UDP port 314
3. How often is newnslog rotated:
a. Every day
b. Every two days
c. Every week
d. Every two weeks
4. What is the maximum number of SNMP managers that you can configure on a NetScaler
system:
a. 10
b. 30
c. 100
d. 1000
Append|x A
Rev|ew Quest|ons and
Answers
Rev|ew Answers: lntroduc|ng and Dep|oy|ng
O|tr|x NetSca|er
1. A client, such as a web browser, attempts to resolve a host name prior to accessing a resource.
Which NetScaler feature determines the site most available and best able to respond, and
returns the IP address of the site to the client:
a. Cache redirection
c. Global server load balancing
d. TCP buffering
Answer: C
2. Where is the NetScaler configuration file stored:
a. Flash memory
b. Hard disk
c. RAM drive
d. SATA drive
Answer: A
3. Which feature maximizes server efficiency by consolidating application-level requests and
reducing the number of server-side connections:
a. Link aggregation
b. TCP buffering
c. TCP multiplexing
d. SSL offload
Answer: C
Copyr|ght 2011 C|tr|x Systems, lnc. Append|x A: Rev|ew Quest|ons and Answers 371
Rev|ew Answers: Network|ng
1. When USIP mode is enabled for server communication, which address is used instead of a
MIP or SNIP address:
a. Client IP address
b. Virtual IP address
c. SNIP address
d. Server IP address
Answer: A
2. Determine if the following statement is true or false. 'By default, the NetScaler system operates
in layer-3 mode, which provides a higher level of security than layer-2 mode.'
a. True
b. False
Answer: A
3. Which of the following statements regarding Link Aggregation Control Protocol (LACP) is
true:
a. When the speed of one interface is more than adequate for the traffic flow that is
managed by the NetScaler system, LACP is used.
b. When interfaces on a NetScaler system are combined, the aggregate link speed is the
total speed of the bound physical interfaces.
c. Up to five physical interfaces can be bound to a single link aggregation channel.
d. When the physical interfaces are added to a channel and are of differing speeds, they
operate at the highest common speed when aggregated.
Answer: B
372 Append|x A: Rev|ew Quest|ons and Answers Copyr|ght 2011 C|tr|x Systems, lnc.
Rev|ew Answers: Oonf|gur|ng H|gh
Ava||ab|||ty
1. Determine if the statement is true or false. 'In a high-availability pair, when the primary node
experiences a failure and attempts to failover to a secondary system that is not healthy, the
primary node stays as the primary.'
a. True
b. False
Answer: B
2. Which two IP address types have the option to enable management access: (Choose two.)
a. NSIP address
b. MIP address
c. VIP address
d. USIP address
e. SNIP address
Answers: B, E
3. Before two nodes are able to function in a high-availability pair, how are they made aware of
each other in the command-line interface:
a. By issuing the sync command from the primary system
b. By issuing the sync command from the secondary system
c. By issuing the add node command on each node of the pair
d. By issuing the set node command on each node of the pair
Answer: C
4. Which statement refers to a default high-availability setting:
a. In a high-availability pair, management access and communication are secured
through SSL.
b. Synchronization between the systems in a high-availability pair has to be enabled after
the nodes are connected.
c. In a high-availability pair, both the primary and the secondary NetScaler systems
actively accept connections and manage servers.
d. When the nodes of a high-availability pair are running different versions of the system
software, the node running the newest version goes into listen mode.
Answer: D
Rev|ew Answers: Secur|ng the NetSca|er
System
1. Which port is commonly used for the HA heartbeat:
a. 162
b. 443
c. 3003
d. 3009
Answer: C
2. Which two statements apply to ACL precedence: (Choose two.)
a. The destination takes priority over the source when there is no priority assigned.
b. The most specific ACL takes priority despite the assigned priority.
c. The first ACL that matches determines how the packet is processed.
d. The packet is affected by multiple ACLs if there is no match.
Answers: A, C
Rev|ew Answers: Oonf|gur|ng |oad
Ba|anc|ng
1. An administrator created a server entity with a name of serverA and an IP address of
123.43.67.89. He now wants to create an HTTP service entity with the name of serviceA on
port 80 that is associated with serverA. Which command results in a successful service entity
creation:
a. add service serviceA serverA HTTP 80
b. add service serviceA:80:HTTP
c. add service serviceA 123.43.67.89
d. add service serviceA 123.43.67.89:80 HTTP
Answer: D
2. Which type of monitor is used to analyze live client traffic to verify the health of an HTTP
service:
a. HTTP
b. HTTP-INLINE
c. HTTP-ECV
d. TCP-ECV
Answer: B
3. Which parameters specifies the number of consecutive health check probe failures after the
system marks the service as DOWN:
a. Reverse
b. Down time
c. Retries
d. Response time
Answer: C
4. Which hashing type includes the NetScaler system choosing a service based on the hashed
value of the client IP address in the HTTP header:
a. Source IP
b. URL
c. Destination IP
d. Domain name
Answer: A
Rev|ew Answers: Oonf|gur|ng SS|
1. Which two options are valid means of obtaining a server certificate for use in a production
environment: (Choose two.)
a. Request a certificate from a trusted certificate authority.
b. Generate a self-signed certificate on the NetScaler system.
c. Use an existing certificate from a back-end web server.
d. Install a standard server certificate issued with most web browsers.
Answers: A, C
2. Which two NetScaler protocols would you use to terminate SSL sessions: (Choose two.)
a. SSL
b. SSL_TCP
c. SSL_HTTP
d. SSL_BRIDGE
Answers: A, B
3. Which benefit results from terminating SSL transactions on the NetScaler system rather than
on the server: (Choose two.)
a. The server is freed from CPU-intensive SSL processing.
b. SSL encryption can be passed to the back-end server.
c. A NetScaler system can be deployed without changes to the server configuration.
d. SSL transactions terminated on a NetScaler are less able to be compromised than those
terminated on a server.
Answers: A, C
Rev|ew Answers: GS|B
1. Which statement in NOT true about the GSLB function:
a. GSLB distributes Internet traffic across multiple sites.
b. GSLB relies on DNS for directing client requests.
c. GSLB reduces application latency.
d. GSLB distributes the server load across multiple sites.
Answer: A
2. Which feature applies when a NetScaler system is in an authoritative configuration:
a. Support for zone transfers and recursive query
b. Configuration for a maximum of 30 records
c. Participation of only one NetScaler system to be authoritative
d. Configuration that is local for Start of Authority
Answer: D
3. Which metric exchanges GSLB-site information every five seconds:
a. Network
b. Persistence
c. Server
d. Site
Answer: B
4. Which traditional load-balancing method does not require MEP to be enabled if explicit
monitoring is configured:
a. Source-IP-address hash
b. Least connections
c. Least packets
d. Proximity-based
Answer: A
3. Which consideration applies when using site affinity:
a. Site affinity evaluates attributes of incoming client LDNS responses.
b. Site affinity designates the target site before the action.
c. Site affinity requires content filtering be enabled.
d. Site affinity has a limit of 63 policies.
Answer: C
Rev|ew Answers: s|ng AppExpert O|ass|c to
Opt|m|ze Traff|c
1. Which option describes the EXISTS operator:
a. This operator performs checks against the specified qualifier to determine if the
specified string is not contained in the qualifier.
b. This operator checks if the qualifier exists and if it has contents.
c. This operator checks if the particular qualifier does not exist.
d. This operator checks for the existence of a particular qualifier.
Answer: D
2. Determine if the statement is true or false. A classic policy consists of two parts: an expression
and a request.
a. True
b. False
Answer: B
3. Which statement describes the purpose of a Host header in an HTTP request:
a. Defines the client method and the version of HTTP that is being used.
b. Defines the server to which the request is sent.
c. Defines information about the client software making the request.
Answer: B
4. Which action is used to send a request to close a client connection:
a. DROP
b. RESET
Answer: B
3. Content filtering can be configured in the Configuration Utility in the __________________
node.
a. System features
c. Protection features
d. Load balancing
Answer: C
Rev|ew Answers: s|ng AppExpert for
Responder, Rewr|te and R| Transformat|on
1. What are the three valid reasons for removing an HTTP header: (Choose three.)
a. Removing the server header in the response to hide the type of web server in use
b. Removing a cache control header in a response
c. Removing the server header in the response to show the client the type of web server
in use
d. Preventing an action on the server, such as removing the accept-encoding header to
prevent compression
Answers: A, B, D
2. Which description best describes the globally bound policy type of Response Default:
a. Policies bound to this bind point constitute the default request processing behavior.
b. Policies bound to this bind point are only evaluated for responses.
c. Policies bound to this bind point constitute the default response processing behavior.
d. Policies bound to this bind point are only evaluated for requests.
Answer: C
3. What information completes the following sentence: Two major differences between the URL
transformation feature and the rewrite feature is that __________ and __________. (Choose
two.)
a. Rewrite can handle chunked data.
b. Rewrite can handle character encoding.
c. URL transformation can handle chunked data.
d. URL transformation can handle character encoding.
Answers: C, D
Rev|ew Answers: s|ng AppExpert for
Oontent Sw|tch|ng
1. True or False: When switching content to different servers, an administrator only needs to
configure one load-balancing virtual server for both types of requests.
a. True
b. False
Answer: B
2. Content switching for HTTPS transactions requires that ________________ and
________________. (Choose two.)
a. SSL offloading be enabled
b. SSL offloading be disabled
c. SSL transactions are not switched in a method that is transparent to the client
d. the traffic type of the content-switching virtual server be set to SSL
Answers: A, D
3. Which statement concerning how a content-switching virtual server differs from a load-
balancing virtual server is true:
a. A content-switching virtual server is available only for HTTP/HTTPS traffic and is not
implemented for any other protocol.
b. If the traffic does not match any content-switching policy, the virtual server will send
the traffic to a default load-balancing server if one is defined.
c. A content-switching server references actual services.
d. A content-switching virtual server can be configured using both classic and advanced
policies.
Answer: B
Rev|ew Answers: s|ng AppExpert Advance
to Opt|m|ze Traff|c
1. Which one of the following parameters cannot be used to configure policy based routing:
a. VLAN
b. HTTP URL
c. Source Port
d. MAC Address
Answer: B
2. What outcome is a result of a policy that evaluates as not applicable to the current request:
a. DEF
b. TRUE
c. FALSE
d. UNDEF
Answer: C
3. Which two of the following is a source for new application templates:
a. Another NetScaler system
b. The NetScaler community web site
c. The NetScaler CD
d. NetScaler updates
Answer: B
4. What top-level object provides operations on system wide data:
a. CLIENT
b. HTTP
c. SERVER
d. SYSTEM
Answer: D
Rev|ew Answers: Management
1. Which entity is a type of authentication that allows access to managed devices:
a. Trap
b. Agent
c. MIB
d. Community string
Answer: D
2. Which port does syslog use by default:
a. TCP port 80
b. UDP port 443
c. TCP port 22
d. UDP port 314
Answer: D
3. How often is newnslog rotated:
a. Every day
b. Every two days
c. Every week
d. Every two weeks
Answer: B
4. What is the maximum number of SNMP managers that an administrator can configure on a
NetScaler system:
a. 10
b. 30
c. 100
d. 1000
Answer: C
G|ossary
access control list (ACL)
A set of data associated with a file, directory or other network resource that defines the permissions
that users, groups, processes or devices have for accessing it.
Access Gateway Enterprise Edition
An appliance built on the NetScaler system that provides secure access to private networks, such as
company LANs, using SSL VPN and IPSEC.
Active Directory
A technology created by Microsoft that provides LDAP-like directory services.
address resolution protocol (ARP)
A network layer protocol used to convert an IP address into a physical address. A host that requires
a physical address broadcasts an ARP request onto the TCP/IP network. The host at the IP address
in the request then replies with its physical hardware address.
agent
The software process that provides communication to a SNMP manager. A network device that
uses SNMP must be running an agent. See Simple Network Management Protocol (SNMP).
alarm
An SNMP notification sent to a designated server in response to certain system and firewall events.
AppExpert Rate Controls
A NetScaler feature that enables NetScaler policies to be triggered based upon data rates either
coming from or going to a given resource.
AppExpert Service Callouts
A NetScaler feature that is used by an administrator to obtain information from external
applications. The callout policy sends an HTTP request to an external application. An agent
deployed in front of the application formats the request for the application. When the application
returns a response, the agent formats the response for the NetScaler system, and the callout policy
extracts data of interest from the response.
AppExpert Templates
A NetScaler feature that encapsulates the entire NetScaler configuration for a specific application
into a logical view. Ongoing changes to configuration and policies can also be made from this view.
AppExpert Templates can be imported and exported, enabling complete NetScaler configurations to
be loaded for the optimization of specific applications.
AppExpert Visual Policy Builder
Keeps policy development simple and policies supportable by eliminating complex scripts or
programs from all NetScaler policies.
Copyr|ght 2011 C|tr|x Systems, lnc. G|ossary 385
AppExpert Visualizer
A NetScaler feature that provides a graphical, tree-based, hierarchical view of the entities, such as
load-balancing virtual servers, content-switching virtual servers, service pools, individual services
and health checks.
Application Switch
An appliance that provides web application acceleration and advanced layer 4-7 traffic
management.
authentication
The process of determining whether someone or something is who or what it is declared to be.
Authentication is commonly accomplished using a logon password.
authentication type
The mechanism used to perform authentication, such as RADIUS, LDAP, and SafeWord.
authorization
The process of providing someone permission to access resources on a system or in a network.
Badstore
A website that emulates a vulnerable online store. The site is an educational tool that allows clients
to execute hacking attempts to demonstrate vulnerabilities.
binding
An assigned relationship between two objects in the NetScaler operating system. For example, a
policy must be bound to a profile in order to take effect, and a certificate must be bound to an SSL
virtual server in order to secure traffic.
bridge tables
A method for storing MAC addresses and their interfaces on a NetScaler. When a new frame
arrives, the system refers to the bridge table and determines whether it needs to filter or bridge the
frame.
buffer overflow
An anomaly where a process stores data in a buffer outside the memory the programmer set aside
for it. Buffer overflows can be triggered by inputs that are designed to execute code, or alter the
way the program operates. They are thus the basis of many software vulnerabilities and can be
maliciously exploited.
cache redirection
Transparently redirects inbound cacheable HTTP requests to a cache, while redirecting non-
cacheable or dynamic HTTP requests to the origin server.
caching
386 G|ossary Copyr|ght 2011 C|tr|x Systems, lnc.
See integrated caching.
certificate authority (CA)
An entity that issues certificates after verifying the identify of a server. See Secure Sockets Layer
(SSL).
certificate revocation list (CRL)
A file sent to a certificate authority that requests that the certificate authority sign the public key of
the requesting server with the private key of the certificate authority and provide a new SSL
certificate. See Secure Sockets Layer (SSL).
certificate signing request (CSR)
A file sent to a certificate authority that requests that the certificate authority sign the public key of
the requesting server with the private key of the certificate authority and provide a new SSL
certificate. See Secure Sockets Layer (SSL).
Citrix EdgeSight for NetScaler
Allows for web application performance monitoring. EdgeSight for NetScaler monitors web
applications from the perspective of the client, providing real-time and historic visibility into web
application performance.
Citrix WANScaler appliance
A Citrix device that, when used with either another WANScaler appliance or a WANScaler Client,
creates accelerated connections that cause WANs to behave like LANs.
Citrix XenApp
A Windows application delivery system that manages applications in the datacenter and delivers
them as an on-demand service to users anywhere using any device.
client certificate
An optional security component that contains information about a user and the SSL client. See
Secure Sockets Layer (SSL).
client device
Any hardware device used to access corporate resources.
command-line interface (CLI)
The character-based interface to the NetScaler system. The NetScaler operating system is built on
the FreeBSD platform, and the command-line interface is built upon the FreeBSD-based shell.
command policies
Rules that control which NetScaler systems users may access and administer.
community string
An authentication and authorization method in SNMP version 1. When a manager attempts a
connection with an agent, it passes a community string, which determines if the agent replies to the
query. See Simple Network Management Protocol (SNMP).
compound expression
A type of expression that is made up of logical combinations of existing simple and compound
expressions. Compound expressions compare the results of the separate expressions with logical
operators to determine if the whole compound expression is true or false.
compression
Allows for the reduction in size of HTTP responses to compression-aware browsers. Reducing the
size of HTTP responses can improve the performance of network-based applications.
Configuration Utility
The web-based graphical user interface (GUI) used to configure and administer the NetScaler
system.
content filtering
Offers protection for web sites from malicious attacks at the content level. When this feature is
enabled, the NetScaler system inspects every incoming request with the configured rules based on
the HTTP URLs or headers.
content switching
Directs requests to specific servers based on the type of content requested.
cookie
A piece of data that a web server sends to a web browser, to be stored in RAM memory or the hard
disk of the local computer, and sent back to the web server with every request to that web
application. Web servers use cookies to track user sessions, to identify users who have previously
visited the site, and to store user information about registered users.
cookie insert persistence
A type of session persistence in which the NetScaler system inserts an HTTP cookie in the client
response that is then used to direct subsequent requests from the client to the same physical server
that handled the initial request.
cross-site scripting
A type of computer security vulnerability typically found in web applications which allow code
injection by malicious web users into the web pages viewed by other users.
custom load
A load balancing method that distributes traffic based on the load calculations made by load
monitors.
custom server ID persistence
A persistence method in which the NetScaler system looks for an embedded server ID in a client
request and then redirects the request to the physical server that corresponds to the ID.
Dashboard
A Java-based, browser-accessible application that allows administrators to monitor the performance
of the NetScaler appliance based on statistical counters. These counters are also displayed
graphically as charts and tables.
DEFLATE
An algorithm to compress data.
denial of service (DoS)
A general term for any one of the many attacks that are used in an attempt to prevent a server
from performing properly.
DESTIP persistence
A persistence method used with link load balancing.
dialog box
A small, standalone window in the Configuration Utility that asks the administrator a question or
prompts the administrator to fill in certain information. Most configuration tasks in the
Configuration Utility are performed through various dialog boxes.
digital certificate
A small file that contains public keys and that verifies the identify of the holder. Certificates are
issued by a certificate authority (CA).
direct server return (DSR) mode
A NetScaler deployment scenario in which the server responds to clients directly, using a return
path that does not flow through the NetScaler.
distinguished encoding rules (DER)
A method to encode a data object, such as a certificate, so that it is digitally signed or its signature
is verified.
distributed denial of service (DDoS)
A denial of service (DoS) attack that makes use of multiple computers to perform a DoS attack. See
denial of service (DoS).
DNS monitor
A type of monitor that performs health checks on services by testing the success of DNS queries.
expression
An operation that evaluates a request or response in order to determine what to do with that
request or response.
extended content verification (ECV) monitor
A type of monitor that marks a service as UP based upon whether the TCP connection is accepted
and the expected reply string is received.
failover
An event in which the primary node in a high-availability pair becomes the secondary node, and
the secondary node becomes the primary node as a result of a failure of the primary node.
Federal Information Processing Standards (FIPS)
A US Government standard for hardware protection of SSL certificates and keys required for many
government customers. Special models of the Access Gateway and NetScaler support FIPS
management of SSL certificates and keys.
file transfer protocol (FTP)
A protocol used to transfer data from one computer to another over a TCP/IP-based network.
Commonly used to download programs and other files to your computer from other servers.
flash memory
Mounted on the NetScaler system as /flash. When a save config command is executed, the running
configuration is saved to this drive.
forced failover
An administratively initiated failover on a node within a high availability pair. A forced failover is
desired if an administrator wants to test that a high-availability pair configuration is performing
correctly or if an administrator needs to replace or upgrade the primary node. See high availability.
forceful browsing
An attack that attempts to enumerate and access resources that are not referenced by the
application, but are still accessible.
FreeBSD
A UNIX operating system on which the NetScaler operating system runs.
global server load balancing (GSLB)
A DNS-based feature that ensures client requests are directed to a best performing site available in
a global enterprise and distributed Internet environment.
GSLB site IP address
Used by the sites participating in GSLB to communicate information about the health of the site so
an appropriate load balancing decision can be made. See global server load balancing (GSLB).
GZIP
An algorithm to compress data.
hard disk
Used to store log data, core files and unused builds, on the NetScaler system. The /var directory
represents the physical hard disk.
hashing
A load balancing method that uses a hash value calculated based on a particular aspect of the client
request to determine where to forward traffic. See load balancing.
health check
A probe in which the state of the services on a NetScaler system is periodically checked. See load
balancing.
high availability
A deployment scenario in which two Citrix NetScaler systems are configured to operate as a unit,
with one appliance actively accepting and processing traffic while the other monitors the first
appliance. If the first appliance quits accepting and processing traffic, then the second appliance
takes over.
high availability (HA) monitor
An entity that monitors an interface. When it is enabled on one of the interfaces and the status of
the interface is DOWN, the state of the node becomes NOT UP.
host file
The hosts file is a computer file used by an operating system to map hostnames to IP addresses.
HTTP compression
Implements lossless compression that can be interpreted by popular browsers. The compression
feature is implemented at origin sites that have HTML or other compressible content that is either
statically or dynamically generated. See compression and Hypertext Transfer Protocol (HTTP).
HTTP content filtering
Inspects the HTTP headers of each incoming request according to user-configured policies and
performs the specified action when a request matches a policy. Actions include resetting the
connection, dropping the request or sending an error message to the user. See content filtering.
HTTP data
The part of an HTTP request containing the information that the user typed into a web form, or
the part of an HTTP response that contains the web content the user requested. See Hypertext
Transfer Protocol (HTTP).
HTTP header
The part of an HTTP connection that contains information about the web server or user's browser
and is intended to assist the web server or browser in handling the connection. HTTP headers are
the metadata portion of an HTTP request or response. See Hypertext Transfer Protocol (HTTP).
HTTP monitor
A type of monitor used to verify the health of an HTTP service. See Hypertext Transfer Protocol
(HTTP).
HTTP request
A request from a user to a Web server, requesting content from the Web server using the HTTP
protocol. See Hypertext Transfer Protocol (HTTP).
HTTP response
A response from a web server to a user, sending requested information to that user. See Hypertext
HTTP traffic
Any HTTP connection, either from a user to a web server or from a web server to a user. See
Hypertext Transfer Protocol (HTTP).
Hypertext Transfer Protocol (HTTP)
A protocol for sending requests and responses between a user's browser and a web server.
Hypertext Transfer Protocol Secure (HTTPS)
A protocol for sending HTTP requests and responses securely between a user's web browser and a
web server so that packets are encrypted and cannot be read if intercepted. See Hypertext Transfer
Protocol (HTTP) and Secure Sockets Layer (SSL).
inline mode
See two-arm mode.
integrated caching
Rule-based caching allowing compressed content to be cached and served to all compression-aware
clients without reperforming the compression every time.
intermediate certificate
A subordinate certificate issued by a trusted certificate authority and used to create server
certificates in a certificate chain. See Secure Sockets Layer (SSL).
IP Security (IPSEC)
A protocol used for negotiating encryption and authentication at the IP level. IPSEC allows
administrators to ensure that all packets between two hosts are encrypted, regardless of packet type
or protocol used in transmission.
Java
An Object Oriented Programming (OOP) language created Sun Microsystems.
Javascript
A distant cousin of Java created by Netscape. It is also an OOP language. However, JavaScript
contains a much smaller and simpler set of commands than does Java.
key
A string of bits used to encrypt and decrypt messages. See Secure Sockets Layer (SSL).
layers 1-7
See network layers.
Layer 2 mode
A mode that controls the Layer 2 forwarding (bridging) function. This mode enables a NetScaler to
bridge or process the packets that are not destined for its MAC address.
Layer 3 mode
A mode that controls the Layer 3 forwarding function. This mode enables a NetScaler to perform a
route table lookup and forward the packets that are not destined for NetScaler-owned IP addresses.
least bandwidth
A load balancing method that distributes traffic based on the amount of bandwidth being directed
to each service. See load balancing.
least connections
A load balancing method that distributes traffic based on the number of connections to a service.
See load balancing.
least packets
A load balancing method that distributes traffic based on the rate of packet traffic to a service. See
load balancing.
least response time
A load balancing method that distributes traffic based on the average response time of each service.
See load balancing.
license
The contractual agreement between a company and Citrix Systems that specifies which features can
be used on a Citrix NetScaler system.
license key file
A file provided by Citrix Systems that an administrator must upload to the NetScaler system to
enable it and all licensed features.
lightweight directory access protocol (LDAP)
An application protocol to access information directories and to query and modify directory
services running over TCP/IP.
link aggregation
Combines or aggregates the data coming from multiple ports into a single high-speed link. Link
aggregation increases the capacity and availability of the communications channel between the
NetScaler system and other connected devices.
load balancing
Balances network traffic between separate managed servers that serve the same applications or host
the same data.
load monitor
A type of monitor used to perform custom load balancing based on server parameters, such as CPU
usage or memory. See load balancing.
Local Area Network (LAN)
The network behind the firewall or router of a company, where web servers, mail servers and other
protected resources belonging to the company are located.
log
One of a collection of text files maintained by the NetScaler operating system that consists of
information about various activities and events that occur on that device. Log files usually contain a
single line of text per logged event or activity.
MAC-based forwarding (MBF)
This mode enables the system to process traffic more efficiently and avoid multiple-route or ARP
lookups when forwarding packets, because the NetScaler remembers the MAC address of the
source.
managed devices
Network nodes that reside in a managed network. Managed devices collect and store management
information and make this information available to the network management system (NMS) using
SNMP. See Simple Network Management Protocol (SNMP).
management information base (MIB)
A collection of objects in a database used to manage entities in a network. The NetScaler system
provides a list of over a thousand variables in a MIB file. See Simple Network Management
Protocol (SNMP).
manager
Devices that poll agents for SNMP information. Managers can perform passive statistics-gathering,
or they can attempt to manage the network actively by setting new values in read-write variables on
some hosts. See Simple Network Management Protocol (SNMP).
mapped IP (MIP) address
An IP address assigned to a NetScaler system so that it can refer to the servers it protects.
monitor
Used by the NetScaler system to check periodically the health of a service in order to determine its
state and to mark it as UP or DOWN accordingly.
MySQL
A multi threaded, multi user SQL database management system (DBMS). The basic program runs
as a server providing multi user access to a number of databases.
NetScaler IP (NSIP) address
The management IP address assigned to a NetScaler system and used by administrators to connect
to the appliance when configuring or managing it.
NetScaler operating system (NetScaler OS)
The FreeBSD-based operating system that runs on all appliances in the Citrix NetScaler Application
Delivery product line.
network interface controller
A hardware device that handles an interface to a computer network and allows a network-capable
device to access that network.
network layers
Categories that define the protocols and types of traffic that a network device handles. For example,
a layer-3 device handles IP traffic sent using either TCP or the UDP. A layer-2 device handles MAC
address traffic.
network news transfer protocol (NNTP)
An Internet application protocol used primarily to read and post netnews articles and transfer news
among news servers.
network tracing
A debuging technique that provides access to information about method invocations and network
traffic generated by a managed application.
node
A single server, appliance, or device within a network.
node property
An attribute of a node, such as its IP address, hostname or domain.
nslog
A propriety binary format that the NetScaler system uses to record system events in more detail
than in the syslog format. See syslog.
nsroot
The root user with full administrative privileges on the NetScaler system.
Object Identifier (OID)
The name of an object in a MIB database. See SNMP.
one-arm mode
A NetScaler deployment scenario in which two appliances are installed on a single subnet
environment. In this type of deployment, the client must access the servers through a VIP address
configured on the appliance. See virtual IP address (VIP).
operator
The portion of an expression that specifies exactly what part of the qualifier an expression should
examine and what type of information for which it should look. See expression.
packet
The basic unit of data routed between an origin and a destination on a TCP/IP or other packet-
switching network. A packet contains part of a larger message and the destination address. On
TCP/IP networks, packets are often called datagrams.
packet switching
A process for transmitting a message from one server to another on a network by dividing the
message into smaller units, or packets, before sending them.
Paros
A network tracing tool used to evaluate the security of web applications.
Perl Compatible Regular Expressions (PCRE)
A set of functions that implement regular expression pattern matching using the same syntax and
semantics as Perl 3. The PCRE library is free, even for building commercial software.
persistence groups
An aggregate of vservers. When persistence is set on the group of vservers, client requests are
directed to the same selected server, regardless of which vserver in the group receives the client
request.
ping
A network tool used to test whether a particular host is reachable using an IP address. The source
host sends echo request packets to the target host and listens for echo response replies. Ping
estimates the round-trip time, usually in milliseconds, records any packet loss, and prints a
statistical summary when finished.
policy
A set of parameters created by the system administrator when configuring NetScaler traffic
management features.
port
In reference to hardware, an interface on a server that connects to another server or network
device. In reference to software, a number representing a virtual input location where a server
program listens for connections.
post office protocol version 3 (POP3)
A client/server protocol that enables an Internet server to receive e-mail and store it. Provides for
periodically checking mail boxes on the server and downloading any mail.
predefined roles
A set of preconfigured command polices. These command policies can be bound without any need
for additional configuration.
priority queuing
Uses set policies to prioritize users and tasks so that the NetScaler system can give priority access to
the most urgent tasks.
protocol
A specific type of communication between a server and client or two servers on the internet.
public-key encryption
A method of encrypting messages that pairs a public key and a private key. Messages encrypted
with the public key can be decrypted only using the private key. In turn, messages encrypted with
the private key can be decrypted only using the public key.
public-private
A NetScaler deployment scenario in which the IP addresses of the servers managed by the
NetScaler system are hidden. This scenario is accomplished by placing the servers on non-routable
IP subnets.
public-public
A NetScaler deployment scenario in which the servers managed by the NetScaler system are on a
publicly routable IP subnet.
qualifier
The portion of an expression that specifies what is to be examined.
RAM drive
Location on the NetScaler system from which binaries are executed. The RAM drive is mounted on
the root or / file system. The running configuration files for BSD-level tools are used from the /etc
filesystem residing on the RAM drive.
read-only
A default role that allows read-only access to all show commands except for the system command
group and ns.conf show commands.
regular expression
An expression that describes a set of strings. They are usually used to give a concise description of a
set, without having to list all elements. Also called a pattern.
Remote Authentication Dial In User Service (RADIUS)
A networking protocol that provides centralized Authentication, Authorization, and Accounting
(AAA) management for computers to connect and use a network service.
remote procedure call (RPC)
A technology that allows one program to cause a subroutine or procedure to execute in a different
address space within a network without understanding network details.
request
An inbound connection from a user to a web server.
response
An outbound connection from a web server to a user in response to a request sent by that user.
reverse NAT (RNAT)
A method that a NetScaler uses to translate network addresses by replacing the source IP addresses
of packets generated by the servers and replacing them with NAT IP addresses. The NAT IP
addresses is a public IP addresses.
rewrite
Allows general purpose HTTP header modification. When configured, the rewrite feature modifies
the header and body sections of an HTTP request or response.
root certificate
An unsigned public key certificate, or a self-signed certificate, that is part of a public key
infrastructure scheme. See Secure Sockets Layer (SSL).
round robin
A load-balancing method that distributes traffic based on a server rotation system, regardless of
load. See load balancing.
rule-based persistence
A persistence method in which the NetScaler system evaluates a client request against a configured
rule and creates a persistent session if the request is matched.
Secure Shell (SSH)
A protocol that allows a user to establish an encrypted, secure connection to a server through port
22.
Secure Sockets Layer (SSL)
A standards-based security protocol for encryption, authentication, and message integrity. It is used
to secure the communications between two systems across a public network, authenticate the two
systems to each other based on a separate trusted authority, and ensure that communications are
not tampered with. SSL supports a wide range of ciphersuites. The most recent version of SSL is
Transport Layer Security (TLS).
Secure Sockets Layer Virtual Private Network (SSL VPN)
A virtual private network that operates through an SSL web link.
security model
The underlying reasoning used to protect the security of a server or any other computer or
appliance on a network.
server
A Web server managed by a NetScaler.
server/application state protocol (SASP)
Provides a mechanism for load balancers and workload management systems to communicate in
better ways of distributing the existing workload to the group members. This memo provides
information for the Internet community.
server certificate
A copy of the server public key, signed by the private key of the certificate authority, containing
information about the server that allows a client to identify the server before sharing sensitive
information. A server certificate is unique to a particular server FQDN. See Secure Sockets Layer
(SSL).
service
A system entity representing the type of traffic being routed to a server.
service weight
Allows administrators to manage more closely load balancing decisions. See load balancing.
session
A single set of connections between a web site and a specific user, including both requests from the
user to the web site and responses by the web site to the user.
session initiation protocol (SIP)
An application-layer signaling protocol that is used to establish, modify, and terminate sessions
with one or more participants in a network.
session timeout
The maximum period of inactivity before the Application Firewall stops tracking a user's session.
The user must then establish a new session with the protected site by accessing a start URL before
continuing the activity.
simple expression
A type of expression that consists of a single, logical comparison.
Simple Network Management Protocol (SNMP)
A standard means of receiving important information from a network device by either polling
variables-(called object identifiers (OIDs))-(or receiving alerts-called traps).
simple network time protocol (SNTP)
An adaptation of the Network Time Protocol (NTP) that is used to synchronize computer clocks on
the Internet when the ultimate performance of the complete NTP implementation described in RFC
1303 is not needed or justified.
Simple Object Access Protocol (SOAP)
An XML-based syntax for exchanging messages. Using SOAP, web services on different platforms
using normally incompatible technologies can exchange information.
source IP address persistence
A type of session persistence in which the NetScaler system routes a client request based on the
configured load-balancing method and then directs all subsequent requests from the same IP
address to the physical server that handled the initial request.
spillover
Occurs when a virtual server exceeds a set threshold value, and new connection requests are
diverted to a backup virtual server.
SQL injection
A code injection technique that exploits a security vulnerability occurring in the database layer of
an application.
SRCIPDESTIP persistence
A type of session persistence used with IDS load balancing. See load balancing.
SSL client certificate verification
Verifies the authenticity of the user requesting a web object or a resource. Web access can be
logged and billed on a per user basis. See Secure Sockets Layer (SSL).
SSL offload
Transfers SSL encryption and decryption tasks from the managed servers to the NetScaler system.
See Secure Sockets Layer (SSL).
SSL session ID persistence
A type of persistence in which requests containing the same SSL session ID are directed to the
physical server that processed the initial request. See Secure Sockets Layer (SSL).
Statistical Utility
A Java-based, browser-accessible application that allows administrators to monitor the performance
of a NetScaler system based on statistical counters. These counters are displayed graphically as
charts and tables.
Structured Query Language (SQL)
A database computer language designed for managing data in relational database management
systems (RDBMS).
subnet IP (SNIP) address
An IP address on the NetScaler used to originate traffic to services, perform NAT, and provide
management access.
superuser
A default role that grants full system privileges, which are exactly the same privileges that belong to
the nsroot user.
SureConnect
Provides users with real-time estimates of Internet response times, interactive priority queuing and
guaranteed content delivery.
surge protection
Regulates the opening of new connections to servers and controls the number of clients that can
simultaneously access the resources on those servers. It queues any additional requests once the
servers have reached their capacity.
surge queue
A temporary placeholder for HTTP requests before the NetScaler transmits them to a server.
syslog
A format for logging system events.
threshold
The absolute number of times a behavior occurs on a protected site, and the percentage of total
Web site connections that exhibit this behavior, before the Adaptive Learning feature learns a
particular pattern or rule.
TCP buffering
Breaks the dependencies between the client and server connections, increasing transaction
management performance. Because the server-side network has better bandwidth and less packet
loss than the client network, the NetScaler system can process the entire response faster than the
client. The system buffers the server response and delivers it to the client at the client's speed. The
server is offloaded faster from having to serve slower client connections. TCP buffering is disabled
by default.
transmission control protocol (TCP)
A core Internet protocol that provides reliable, in-order delivery of a stream of bytes, and makes it
suitable for applications like file transfer and e-mail.
TCP optimization
Transfers certain TCP protocol overhead from the managed servers to the NetScaler system,
reducing CPU load on managed servers and improving performance. Part of the TCP optimization
on a NetScaler system includes TCP multiplexing. TCP multiplexing maximizes server efficiency by
consolidating application level requests, reducing the number of times that server connections are
made.
token
A load-balancing method that distributes traffic based on the value of a token extracted from a
client request. See load balancing.
Transport Layer Security (TLS)
See Secure Sockets Layer (SSL).
trap
An alert sent by an SNMP agent to the manager. A trap is the only type of communication initiated
by an agent.
two-arm mode
A NetScaler deployment scenario in which two appliances are installed in a two-arm configuration
on a single subnet. The appliances are in a high-availability setup and are placed between two layer-
2 switches.
Uniform Resource Locator (URL)
A standard address for an HTML page or other resource on the web.
URLPassive persistence
A type of persistence in which the NetScaler extracts the server ID from the server response and
embeds it in the URL query of the client request. The NetScaler extracts the Server ID from
subsequent client requests and uses it to select a server.
use subnet IP (USNIP) mode
A mode that allows a NetScaler to use an appropriate subnet IP address as the source IP address for
all packets originating from the system.
user datagram protocol (UDP)
A protocol used by application programs to send messages to other programs with a minimum of
protocol overhead. The protocol is transaction oriented, and delivery and duplicate protection are
not guaranteed.
value
The field within an expression that specifies with what the qualifier is compared.
virtual IP (VIP) address
IP address associated with a virtual server.
virtual LANs (VLANs)
A group of hosts with a common set of requirements that communicate as if they were attached to
the same LAN, regardless of their physical location.
virtual MAC (VMAC)
A floating entity that is shared by the primary and secondary nodes in a high availability setup.
virtual private network (VPN)
A method of tunneling secure communication through the Internet or a different network.
virtual server
An aggregated system entity that usually comprises multiple servers and services. Rather than being
routed directly to servers, traffic is sent to a virtual server that then makes the decision about which
server to forward the traffic based on the services bound to the virtual server.
web application
An application that is accessed with a web browser over a network, such as the Internet or an
intranet.
web server
A system that delivers web pages to browsers and other files to applications using HyperText
web service
Web-based content that employs one or more of three technologies-SOAP, WSDL and UDDI-to
offer structured content to users through the web.
Web Services Definition Language (WSDL)
An XML-based language for defining web services and explaining how to access those services.
web site
A collection of content hosted on a single web server and accessed through a single hostname.
wide area network (WAN)
The network 'outside' a company's firewall or router, which covers a large area and from which
users access a company's resources. WANs are used to connect local area networks (LANs) and
other types of networks together, so that users and computers in one location can communicate
with users and computers in other locations.
wildcard
The character used within an expression to match the string within the specified qualifier.
XML
A text markup language that supports interchange of structured data, a subset of SGML. The
Application Firewall protects a subset of XML-based web content called web services.
zombie cleanup process
A NetScaler process responsible for closing down idle connections.
831 West Cypress Creek Road Fort Lauderdale, FL 33309 USA (934) 267 3000 www.citrix.com
Rheinweg 9 8200 Schaffhausen Switzerland +41 (0) 32 63377 00 www.citrix.com
Copyright 2011 Citrix Systems, Inc. All rights reserved.

Basic Administration For NetScaler 9.2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Basic Administration For NetScaler 9.2

Hochgeladen von

Copyright:

Verfügbare Formate

Bas|c Adm|n|strat|on for O|tr|x

Das könnte Ihnen auch gefallen