Name: SG

Text: Volume 6: Advanced Networking

Contact Information
Blue Coat Systems Inc.
420 North Mary Ave
Sunnyvale, CA 94085-4121
http://www.bluecoat.com/support/contact.html
[email protected]
http://www.bluecoat.com
For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means
nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other
means without the written consent of Blue Coat Systems, Inc. All right, title and interest in and to the Software and documentation are
and shall remain the exclusive property of Blue Coat Systems, Inc. and its licensors. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware
Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®,
Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate
Internet Sharing Solution®, Permeo®, Permeo Technologies, Inc.®, and the Permeo logo are registered trademarks of Blue Coat Systems,
Inc. All other trademarks contained in this document and in the Software are the property of their respective owners.
BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED,
STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT
LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR
ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS,
INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Document Number: 231-02842
Document Revision: SGOS 5.1.x 03/2007

ii

Contents
Contact Information

Chapter 1: About Advanced Networking
About This Book ..................................................................................................................................................9
Document Conventions......................................................................................................................................9
Chapter 2: Configuring an Application Delivery Network
In this Chapter ...................................................................................................................................................12
Section A: About the Blue Coat Implementation for WAN Optimization
Components .......................................................................................................................................................13
ADN Manager and Backup Manager .....................................................................................................13
ADN Nodes.................................................................................................................................................14
SG Client Manager .....................................................................................................................................14
Optimizing the Network ..................................................................................................................................14
Transparent Connections ..........................................................................................................................15
Explicit Connections ..................................................................................................................................16
Combination of Transparent/Explicit Connections .............................................................................16
Choosing Which Traffic to Optimize ......................................................................................................17
ADN Security.....................................................................................................................................................17
Authenticating and Authorizing ADN Nodes ......................................................................................17
Securing ADN Connections......................................................................................................................18
Section B: Basic ADN Setup
Defining the ADN Manager ............................................................................................................................19
Section C: Transparent and Explicit Connection Deployments
Configuring a Transparent Deployment .......................................................................................................21
Transparent Deployment Notes...............................................................................................................21
Transparent Load Balancing.....................................................................................................................22
Configuring an Explicit Deployment .............................................................................................................24
Managing Server Subnets and Enabling an Internet Gateway ...........................................................24
Preserving the Destination Port ...............................................................................................................26
Explicit Load Balancing.............................................................................................................................27
Configuring a Combined (Transparent and Explicit) Deployment ...........................................................30
Section D: Securing the ADN Network
Configuring ADN Security Settings ...............................................................................................................31
Setting Device Security..............................................................................................................................31
Securing Connections ................................................................................................................................33
Authorizing Devices to Join the Network ..............................................................................................35
Approved/Pending Notes ...............................................................................................................................37

iii

Volume 6: Advanced Networking

Section E: ADN Network History, Statistics, and Health Metrics
Reviewing ADN History.................................................................................................................................. 38
Reviewing Byte-Caching Statistics ................................................................................................................. 38
Reviewing ADN Health Metrics..................................................................................................................... 39
Section F: Advanced Tunnel Optimization
Setting Advanced Tunneling Parameters...................................................................................................... 41
Section G: Manually Re-Sizing a Byte-Cache Dictionary
Section H: Related CLI Syntax to Configure an ADN Network
Section I: Policy
Chapter 3: Attack Detection
Configuring Attack-Detection Mode for the Client ..................................................................................... 51
Changing Global Settings ......................................................................................................................... 51
Configuring Attack-Detection Mode for a Server or Server Group .......................................................... 55
Chapter 4: Bandwidth Management
Bandwidth Management Overview............................................................................................................... 57
Allocating Bandwidth ............................................................................................................................... 58
Flow Classification..................................................................................................................................... 61
Configuring Bandwidth Allocation................................................................................................................ 61
Enabling Bandwidth Management ......................................................................................................... 62
Creating, Editing, and Deleting Bandwidth Classes ............................................................................ 62
Bandwidth Management Statistics ................................................................................................................. 64
Current Class Statistics Tab...................................................................................................................... 64
Total Class Statistics Tab........................................................................................................................... 65
Bandwidth Management Statistics in the CLI ....................................................................................... 66
Using Policy to Manage Bandwidth............................................................................................................... 67
CPL Support for Bandwidth Management ............................................................................................ 67
VPM Support for Bandwidth Management........................................................................................... 68
Bandwidth Allocation and VPM Examples ........................................................................................... 68
Policy Examples: CPL................................................................................................................................ 75
Chapter 5: Authenticating an SG Appliance
Introduction ....................................................................................................................................................... 77
SG Appliance Overview................................................................................................................................... 77
Appliance Certificates and Device Authentication Profiles ....................................................................... 78
About SG Appliance Certificates............................................................................................................. 78
About Device Authentication Profiles .................................................................................................... 78
Obtaining an SG Appliance Certificate.......................................................................................................... 79
Automatically Obtaining an Appliance Certificate .............................................................................. 80
Manually Obtaining an Appliance Certificate....................................................................................... 80

iv

Contents

Obtaining a Non Blue Coat Appliance Certificate ....................................................................................... 83
Creating an Authentication Profile................................................................................................................. 83
Related CLI Syntax to Manage Device Authentication ............................................................................... 85
Chapter 6: Configuring Failover
About Failover................................................................................................................................................... 87
Configuring Failover ........................................................................................................................................ 88
Viewing Failover Statistics............................................................................................................................... 89
Chapter 7: Configuring the Upstream Networking Environment
Section A: Understanding Forwarding
Understanding Load Balancing ............................................................................................................... 92
Understanding Host Affinity ................................................................................................................... 93
Using Load Balancing and Host Affinity Together .............................................................................. 93
Section B: Configuring Forwarding through the CLI
Creating Forwarding Hosts and Groups................................................................................................ 94
Editing a Forwarding Host....................................................................................................................... 97
Editing a Forwarding Group.................................................................................................................... 99
Configuring Load Balancing .................................................................................................................... 99
Configuring Host Affinity ...................................................................................................................... 100
Creating a Default Sequence .................................................................................................................. 102
Section C: Using Forwarding Directives to Create an Installable List
Section D: TCP Connection Forwarding
The TCP Connection Forwarding Solution ................................................................................................. 111
About Bidirectional Asymmetric Routing ........................................................................................... 112
About Dynamic Load Balancing............................................................................................................ 113
About ADN Transparent Tunnel Load Balancing .............................................................................. 113
TCP Configuration Forwarding Deployment Notes .......................................................................... 115
Configuring TCP Connection Forwarding .......................................................................................... 115
Chapter 8: Health Checks
About General Health Checks....................................................................................................................... 119
Configuring Service-Specific Health Checks .............................................................................................. 120
About Global Forwarding and SOCKS Gateway Health Checks ............................................................ 123
Configuring Global Health Checks .............................................................................................................. 123
Pausing or Resuming Global Health Checking .......................................................................................... 124
Chapter 9: Internet Caching Protocol (ICP) Configuration
Configuring ICP .............................................................................................................................................. 127
Using ICP Configuration Directives to Create an Installable List .................................................... 127
Naming the IP Hosts ............................................................................................................................... 129
Restricting Access .................................................................................................................................... 129
Connecting to Other ICP Hosts ............................................................................................................. 131

v

Volume 6: Advanced Networking

Creating an ICP Installable List ............................................................................................................. 131
Enabling ICP ............................................................................................................................................. 132
Chapter 10: Using RIP
Installing RIP Configuration Files ................................................................................................................ 133
Configuring Advertising Default Routes .................................................................................................... 134
RIP Commands................................................................................................................................................ 135
net............................................................................................................................................................... 135
host............................................................................................................................................................. 135
RIP Parameters ................................................................................................................................................ 136
SG-Specific RIP Parameters ........................................................................................................................... 137
Using Passwords with RIP ............................................................................................................................ 137
Chapter 11: Configuring the SG Appliance as a Session Monitor
Configuring the Session Monitor.................................................................................................................. 139
Configuring the RADIUS Accounting Protocol Parameters ............................................................. 139
Configuring a Session Monitor Cluster ................................................................................................ 140
Configuring the Session Monitor .......................................................................................................... 141
Creating the CPL ............................................................................................................................................. 142
Notes .......................................................................................................................................................... 142
Chapter 12: Configuring and Using the SG Client
Overview .......................................................................................................................................................... 146
Understanding the Terminology ........................................................................................................... 146
SG Client Features and Benefits............................................................................................................. 147
Understanding SG Client Deployment................................................................................................. 148
Software and Hardware Requirements ................................................................................................ 149
Understanding ADN Details......................................................................................................................... 149
General ADN Feature Support .............................................................................................................. 149
Configuring Plain Connections ............................................................................................................. 150
About Internet Gateways........................................................................................................................ 150
Configuring Client Settings ........................................................................................................................... 151
Configuring General Client Settings ..................................................................................................... 151
Configuring Client CIFS Settings .......................................................................................................... 153
Configuring Client ADN Settings ......................................................................................................... 154
Configuring the Client Manager................................................................................................................... 156
Uploading the SG Client Software to the Client Manager................................................................. 158
Configuring from the Command Line ......................................................................................................... 159
Making the SG Client Software Available to Users ................................................................................... 161
Setting Up Interactive Installations ....................................................................................................... 161
Setting Up Silent Installations and Uninstallations ............................................................................ 165
Using Group Policy Object Distribution .............................................................................................. 170

vi

Contents

Using the SG Client......................................................................................................................................... 171
Viewing Statistics and ADN Tunnels ................................................................................................... 172
Enabling and Disabling the SG Client .................................................................................................. 174
Troubleshooting the SG Client............................................................................................................... 175
Uninstalling the SG Client Software ..................................................................................................... 179
Troubleshooting Tips for Administrators ................................................................................................... 180
SG Client Logging.................................................................................................................................... 180
About Browser Proxies ........................................................................................................................... 181
ADN Tunnels............................................................................................................................................ 181
Clearing the Object Cache ...................................................................................................................... 181
Client Manager Logging ......................................................................................................................... 182
Licensing........................................................................................................................................................... 182
Chapter 13: SOCKS Gateway Configuration
Using SOCKS Gateways ................................................................................................................................ 183
Using the CLI to Create SOCKS Gateways Settings ........................................................................... 183
Editing a SOCKS Gateways Host .......................................................................................................... 184
Creating a Default Sequence .................................................................................................................. 185
Using SOCKS Gateways Configuration Directives With Installable Lists ............................................. 186
Creating a SOCKS Gateway Installable List ............................................................................................... 188
Tip for SOCKS Configuration ................................................................................................................ 189
Chapter 14: TCP/IP Configuration
RFC-1323........................................................................................................................................................... 191
TCP NewReno ................................................................................................................................................. 192
ICMP Broadcast Echo Support...................................................................................................................... 192
ICMP Timestamp Echo Support ................................................................................................................... 192
TCP Window Size ........................................................................................................................................... 193
PMTU Discovery ............................................................................................................................................. 193
TCP Time Wait ................................................................................................................................................ 193
TCP Loss Recovery Mode .............................................................................................................................. 194
Viewing the TCP/IP Configuration ............................................................................................................. 194
Chapter 15: Virtual IP Addresses
Chapter 16: WCCP Settings
Appendix A: Glossary
Appendix B: Using Policy to Manage Forwarding

vii

Volume 6: Advanced Networking

Appendix C: Using WCCP
Overview .......................................................................................................................................................... 211
Using WCCP and Transparent Redirection ......................................................................................... 211
WCCP Version 1....................................................................................................................................... 211
WCCP Version 2....................................................................................................................................... 212
Quick Start........................................................................................................................................................ 213
Configuring a WCCP Version 2 Service on the Router ............................................................................. 214
Setting up a Service Group..................................................................................................................... 214
Configuring the Internet-Connected Interface .................................................................................... 217
Saving and Viewing Changes ................................................................................................................ 219
Creating an SG Appliance WCCP Configuration File............................................................................... 220
Understanding Packet Forwarding....................................................................................................... 220
Understanding Cache Load Balancing ................................................................................................. 221
Creating a Configuration File................................................................................................................. 222
Creating a Configuration File using a Text File .................................................................................. 226
Examples .......................................................................................................................................................... 226
Displaying the Router’s Known Caches............................................................................................... 227
Standard HTTP Redirection .................................................................................................................. 227
Standard HTTP Redirection and a Multicast Address....................................................................... 228
Standard HTTP Redirection Using a Security Password .................................................................. 228
Standard Transparent FTP ..................................................................................................................... 229
Reverse Proxy Service Group................................................................................................................. 229
Service Group with Alternate Hashing ................................................................................................ 230
Troubleshooting: Home Router .................................................................................................................... 231
Identifying a Home Router/Router ID Mismatch .............................................................................. 231
Correcting a Home Router Mismatch................................................................................................... 233
Tips.................................................................................................................................................................... 234
Index

viii

Chapter 1: About Advanced Networking

Volume 6: Advanced Networking discusses networking tasks that are not required in
every environment, such as:


TCP/IP settings.



WAN Optimization, which enables you to optimize environments with application
delivery networks (ADNs).



Forwarding, which allows you to define the hosts and groups of hosts to which
client requests can be redirected.



Health Checks, which reports on the health of upstream hosts.

About This Book
This book discusses the following topics:


Chapter 2: "Configuring an Application Delivery Network" on page 11



Chapter 3: "Attack Detection" on page 51



Chapter 4: "Bandwidth Management" on page 57



Chapter 6: "Configuring Failover" on page 87



Chapter 7: "Configuring the Upstream Networking Environment" on page 91



Chapter 8: "Health Checks" on page 119



Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 127



Chapter 10: "Using RIP" on page 133



Chapter 11: "Configuring the SG Appliance as a Session Monitor" on page 139



Chapter 13: "SOCKS Gateway Configuration" on page 183



Chapter 14: "TCP/IP Configuration" on page 191



Chapter 15: "Virtual IP Addresses" on page 195



Chapter 16: "WCCP Settings" on page 197



Appendix A: "Glossary" on page 199



Appendix B: "Using Policy to Manage Forwarding" on page 207



Appendix C: "Using WCCP" on page 211

Document Conventions
The following section lists the typographical and Command Line Interface (CLI) syntax
conventions used in this manual.
Table 1-1. Document Conventions
Conventions

Definition

9

Volume 6: Advanced Networking

Table 1-1. Document Conventions (Continued)
Italics

The first use of a new or Blue Coat-proprietary term.

Courier font

Command line text that appears on your administrator workstation.

Courier Italics

A command line variable that is to be substituted with a literal name or
value pertaining to the appropriate facet of your network system.

Courier Boldface

A Blue Coat literal to be entered as shown.

{}

One of the parameters enclosed within the braces must be supplied

[]

An optional parameter or parameters.

|

Either the parameter before or after the pipe character can or must be
selected, but not both.

10

Volume 6: Advanced Networking

In this Chapter
The following topics are discussed in this chapter:


Section A: "About the Blue Coat Implementation for WAN Optimization" on page 13.



Section B: "Basic ADN Setup" on page 19.



Section C: "Transparent and Explicit Connection Deployments" on page 21.



Section D: "Securing the ADN Network" on page 31.



Section E: "ADN Network History, Statistics, and Health Metrics" on page 38.



Section F: "Advanced Tunnel Optimization" on page 41.



Section G: "Manually Re-Sizing a Byte-Cache Dictionary" on page 44.



Section H: "Related CLI Syntax to Configure an ADN Network" on page 47.



Section I: "Policy" on page 49.

12

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization

Section A: About the Blue Coat Implementation for WAN Optimization
This section provides conceptual information regarding various deployments that employ
WAN optimization.
An ADN network is composed of an ADN manager and backup ADN manager, ADN
nodes, and a network configuration that matches the environment.
Blue Coat recommends that you review this section for a high-level overview of the Blue
Coat ADN implementation.
This section contains discussions on:


“Components” , below.



“Optimizing the Network” on page 14.



“ADN Security” on page 17.

Components
The components of the Blue Coat ADN implementation are:


ADN manager and backup ADN manager to provide routing information and control
access to the ADN network.



ADN nodes in both branch offices and data centers that can be authenticated (identity
verified) and authorized (permitted to join the network).



(Optional) An SG Client manager if you have mobile users or users in small branch
offices, where it might not be cost-justifiable to deploy an acceleration gateway.

ADN Manager and Backup Manager
The ADN manager keeps track of and advertises the routes of the appliances it knows
about. The ADN manager must be one of the peers in the ADN optimization network.
Note: Peer refers to any ADN system, manager refers to the ADN system that
broadcasts route information to all ADN peers and controls peer access to the ADN
network, and node refers to all non-manager ADN peers. ADN managers can also act
as nodes on the network.

A backup ADN manager (optional, but recommended) can also be configured. The ADN
managers and the registered nodes periodically send keep-alive messages to each other. If
a node detects the primary ADN manager is not responding, the node automatically fails
over to the back-up ADN manager. The node repeatedly attempts to restore its connection
with the primary manager. After the primary ADN manager is responding to the node
again, the active routing connection of this node switches back to the primary manager.
If the ADN manager detects a node is not responding, the ADN manager removes the
node from the database and notifies all other nodes in the network to do the same.
If both the ADN manager and the backup ADN manager are unavailable, no further
routing advertisements are broadcast. In this case, routes already known by the peers
continue to be remembered and used.

13

Volume 6: Advanced Networking
Section A: About the Blue Coat Implementation for WAN Optimization
You also can use the ADN manager and backup manager to authorize which peers are
allowed to advertise or retrieve route information to and from the ADN manager, and
whether plain connection requests to the ADN manager are accepted.
Connections to the ADN manager and backup manager are made at startup and kept
open as long as ADN is enabled. These connections are referred to as routing connections,
and are used to advertise configured server subnets and to receive routing table updates
from the ADN manager.
Note: Even if you use a transparent tunnel deployment where ADN nodes do not
require routing information, you must configure each ADN node and register it with
the ADN manager. If you secure the network (highly recommended), the ADN
manager is used to authorize ADN peers before they join the network.

Whenever the ADN manager receives a new advertisement from a node that is joining the
network, a route update is sent to all the appliances in the ADN optimization network
that have already established a routing connection; in addition, the current routing table is
updated. The ADN manager and backup manager can each listen on two ports: one
accepting the default plain (unsecured) routing connection requests and another
accepting secure routing connection requests. The plain listener can be shut down if
routing connections from all ADN nodes are secured.
To configure the ADN manager and backup ADN manager, see Section B: "Basic ADN
Setup" on page 19.

ADN Nodes
An ADN node is any SG appliance that is configured for ADN optimization and sends
routing information to the ADN manager and backup ADN manager. A node excludes
those appliances that are acting as ADN managers and backup ADN managers, although
the manager and backup manager can also participate as nodes in the network.

SG Client Manager
The SG Client typically connects to an SG appliance typically located in a data center. That
SG appliance provides the SG Client software to users, and maintains the software and the
client configuration on all clients in the ADN network. Only one SG Client Manager can
be used in the ADN network.
For information on using the SG Client and SG Manager, see Chapter 12: "Configuring
and Using the SG Client" on page 145.

Optimizing the Network
You must decide on whether the network should use explicit tunnel connections,
transparent connections, or a combination of both. Note that ADN peers always intercept
incoming transparent connections if ADN is enabled.


Transparent: The branch SG appliance connects to the original server destination
address and port. If an upstream proxy is capable of transparent tunneling, the
downstream proxy transfers data over the ADN tunnel. The destination port is
preserved and is not affected by security being enabled. Skip to “Transparent
Connections” for more information.

14

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization


Explicit: The branch SG appliance connection is established to the ADN peer
discovered from the routing lookup table. The connection is established to the tunnel
listening port by default or, if you are preserving the destination port, to the port
number the application specifies. Skip to “Explicit Connections” on page 16 for more
information.



Combination: In some circumstances, some ADN nodes can connect transparently,
while other nodes require explicit routing. Skip to “Combination of Transparent/
Explicit Connections” on page 16.

Transparent Connections
Transparent connections are used when the network is required to see the original
destination IP addresses and ports. This requires that each node be configured as an ADN
node and deployed in in-line mode or virtual in-line mode.
Note: Beyond setting up an ADN node in an in-line network and configuring the
ADN node to point to the ADN manager and backup manager, no additional effort is
required for transparent connections. If you use explicit connections, those
connections must be explicitly configured.

Transparent connections take advantage of ADN tunnels that maintain layer-4
information from the original application connections. Layer-4 information provides an
administrator more granular control of the ADN network and allows the enforcement of
network policy.
In a transparent connection deployment, connections are not established to a particular
peer in the ADN, as they are in an explicit deployment. An ADN node can establish
connections to its peers automatically in the absence of any ADN routing information.
The reject-inbound per interface setting is honored for transparent tunnel interception,
while the allow-intercept setting is ignored for transparent tunnel interception.
Internet-bound traffic is automatically accelerated in a transparent deployment if a
transparent ADN peer is installed at the internet access point and Internet traffic is routed
correctly.

Transparent Deployment Load Balancing Scenarios
In transparent load balancing, routes are not advertised, and configuration of load
balancing must be done on each node in the ADN cluster.
If you are using a transparent deployment, you have two options for load balancing.


A dedicated SG appliance as a load balancer; that system makes the decision about
which node receives which traffic.



A WCCP router or other external load balancer, where the individual nodes in the
ADN cluster make the informed load balancing decision.

15

Volume 6: Advanced Networking
Section A: About the Blue Coat Implementation for WAN Optimization

Explicit Connections
Explicit connections are used when maximum network control and granularity is needed.
Blue Coat supports two explicit connections deployments: explicit or explicit but
preserving the destination port. In the latter case, the destination port used is the original
destination port from the client’s request, such as port 80 for HTTP. The destination port is
not affected by the connection setting.
In both explicit deployments, the server subnets that are fronted by each peer must be
explicitly configured; the server subnets are then advertised to each ADN node.
To accelerate Internet traffic in an explicit ADN network, set up a specific ADN peer as the
Internet gateway. Typically, the Internet gateway is an ADN peer close to the enterprise’s
Internet access point.

Note:

If multiple Internet gateways are available, each peer has its own preferred
Internet gateway to route all Internet subnets.
When an ADN peer is configured as an Internet gateway, all other ADN peers forward the
Internet traffic to this peer. The following logic is used by an ADN peer to determine if the
connection is destined to the Internet:


If the destination address matches an advertised subnet from any of the ADN peers,
the connection is forwarded to that peer over the ADN tunnel.



If the destination address matches one of the exempted subnets, the connection is not
forwarded over the ADN tunnel.



If the destination address does not match an advertised subnet or an exempted
subnet, the connection is forwarded to an ADN peer that is designated as an Internet
gateway.

Explicit Deployment Load Balancing Scenarios
If you use explicit network connections, you have two options when configuring load
balancing:


A server subnet, where the branch SG appliance makes the decision about the node
receiving specific traffic for a destination subnet. This is the easiest and more
preferred method. For more information, see“Using a Server Subnet” on page 27.



An external load balancer, where that system makes the informed decision about
which node in the ADN cluster receives specific traffic. For more information, see
“Using an External Load Balancer” on page 28.

Combination of Transparent/Explicit Connections
In some circumstances, it necessary to use explicit connections in addition to the much
easier and preferred transparent connection deployment. A transparent network that can
advertise explicit routing connections is supported. This configuration is useful:


When a small branch office is using the SG Client, which allows SGOS functionality
when a SG appliance is not on site.



If some nodes are not in an in-line configuration or are incapable of initiating
transparent connections.

16

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization
By default, if an ADN node is advertising routes, explicit connections are made. If no
explicit routes are found and there is an upstream proxy in the path capable of transparent
tunneling, the connection is intercepted. This preference is configurable.

Choosing Which Traffic to Optimize
When you configure proxy services to manage TCP traffic through the ADN network, you
can set various attributes that can optimize the traffic for the network. A specific attribute,
use ADN, allows you to disable ADN for a given service.
For information on using proxy services, including the services available, refer to Volume
3: Proxies and Proxy Services.

ADN Security
ADN networks can and should be secured. You can limit access by:


Authenticating and authorizing the ADN nodes that are allowed on the network and
prevent unauthorized nodes from participating.



Securing ADN connections.

Authenticating and Authorizing ADN Nodes
By default, authentication and authorization are disabled.

ADN Node Authentication
Secure ADN requires an appliance certificate for each ADN peer, including the ADN
manager and backup manager for identification. You can provide your own device
appliance certificates or obtain Blue Coat-issued appliance certificates from the Blue Coat
CA server. For the most secure environment, Blue Coat-issued appliance certificates are
recommended.
To enable secure ADN, you must enable the appliance authentication profile for the ADN
network to use before configuring any other security parameters.
In secure ADN mode, full mutual authentication can be supported between the ADN
manager and the ADN nodes and among ADN communicating peers. If authorization is
enabled on the ADN manager, the peer proxy is authorized through an approval
mechanism by the ADN manager before joining the network. For more information on
managing appliance certificates, see Chapter 5: "Authenticating an SG Appliance".

ADN Node Authorization
Authorization occurs when the ADN manager gives approval for the device to join the
network.
If the profile, authentication, and authorization are configured on each peer, and the
Pending Peers option is enabled on both the ADN manager and the backup ADN manager
(if one is configured), the following behavior takes place automatically:


When an ADN node comes up, it contacts the ADN manager for routing information.



The ADN manager extracts the device ID from the connecting ADN node's appliance
certificate and looks for the device ID in its approved list of ADN nodes.


If the device is on the approved list, a REQUEST-APPROVED response is sent,
followed by the route information, and the node joins the network.

17

Volume 6: Advanced Networking
Section A: About the Blue Coat Implementation for WAN Optimization


If the device is not on the approved list, the ADN manager adds the connecting
node's device ID to a pending-peers list and sends a REQUEST-PENDING response.
After the peer is moved to the Approved list by the administrator, a REQUESTAPPROVED response is sent, followed by the route information, and the node joins
the network.



If the Pending Peers option is not enabled and a peer is not on the approved list,
the ADN manager sends a REQUEST-DENIED response and closes the connection.
The connecting node closes the connection and updates its connection status.



If a peer is deleted from the approved list, the ADN manager broadcasts a
REJECT-PEER to all nodes to delete this node and terminate any existing ADN

connections to it. No new connections are routed through the deleted ADN node.
For information on configuring authentication and authorization on each ADN node, see
“Configuring ADN Security Settings” on page 31.

Securing ADN Connections
By default, ADN routing and tunnel connection requests are unauthenticated and all
ADN protocol messaging and compressed application data are transferred in plaintext.
For maximum security, you can configure the ADN network to secure ADN routing and
tunnel connections using standard SSL protocol, which provides authentication, message
privacy, and message authenticity security services, regardless of the application traffic
that is being accelerated or tunneled.
In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode
to listen for routing and tunnel requests.
When secure ADN is enabled, any existing plain outbound connections are dynamically
secured by activating SSL according to the secure-outbound setting.
For information on optimizing and securing ADN tunnels, see Section D: "Securing the
ADN Network" on page 31 and Section F: "Advanced Tunnel Optimization" on page 41.

18

Chapter 2: Configuring an Application Delivery Network

Section B: Basic ADN Setup

Section B: Basic ADN Setup
Basic ADN setup includes:


Configuring each node in an in-line deployment; if you are configuring an explicit
deployment, you do not need to configure the network in an in-line deployment.



Plugging each node in.



Enabling the ADN manager and backup manager on each node, starting with the
ADN manager and backup manager themselves.

If you are using a transparent connection deployment without load balancing, ADN
configuration is complete at this point.
If you are using an explicit connection deployment, a transparent connection deployment
with load balancing, or if you are securing the ADN network (highly recommended), after
finishing this section you must continue with:


“Explicit Load Balancing” on page 27, for explicit deployment.



“Transparent Load Balancing” on page 22, for transparent deployment.



Section D: "Securing the ADN Network" on page 31.

Defining the ADN Manager
When an SG appliance connects to the primary ADN manager, subnet information is sent
to the manager, including:


Peer ID: The serial number of the device. This is a globally unique identifier for the
peer SG appliance that is used as a key to select the dictionary of tokens to use.



Data IP Address and Port: The destination IP address and port number that a branch
proxy should use when establishing an explicit (non preserve-dest-port) tunnel
connection.



Server Subnet Advertisements: The list of server subnets the SG appliance contains
are sent to the ADN manager.

The first step in configuring an ADN network is to define the primary ADN manager.
Blue Coat also recommends deploying a backup ADN manager to prevent loss of routing
information should the primary ADN manager become unavailable for any reason. The
ADN manager and backup ADN manager must be configured on each peer that is joining
the ADN network.
To enable ADN optimization and define the primary/backup ADN managers:
Note:

1.

Fill in all fields on this pane before clicking Apply.

Select Configuration > App. Delivery Network > General.

19

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments

Section C: Transparent and Explicit Connection Deployments
If you are configuring a transparent connection deployment without load balancing,
remember that ADN peers always intercept incoming transparent connections if ADN is
enabled. No special configuration is required after basic ADN configuration is completed
unless you use transparent connection load balancing or if you need to configure a
combined (explicit and transparent) connection network.
The basic steps for configuring a combined transparent/explicit deployment or a pure
explicit deployment are:


Connect the nodes in in-line mode or virtual in-line mode only for those nodes that
are using transparent connections.



(Optional) Secure the ADN network:





Configure the ADN nodes for ADN authentication and authorization for
maximum security (see “Configuring ADN Security Settings” on page 31). The
settings on each system should be identical.



Configure secure tunnels (see Section F: "Advanced Tunnel Optimization" on
page 41).

(Optional) Configure the load balancing parameters for each node to be used in load
balancing (see “Explicit Load Balancing” on page 27 or “Transparent Load Balancing”
on page 22).

To configure transparent connections, including transparent connection load balancing,
continue with the next section.
To configure explicit connections, including explicit connection load balancing, see
“Configuring an Explicit Deployment” on page 24.
To configure a combined connection deployment, skip to “Configuring a Combined
(Transparent and Explicit) Deployment” on page 30 .

Configuring a Transparent Deployment
After you have completed basic ADN configuration, transparent connections are made
automatically. No further configuration is required, unless you need to configure
transparent load balancing.

Transparent Deployment Notes


The first proxy in the chain that supports transparent tunnels and is on the same ADN
network intercepts ADN transparent tunnel connections.



In transparent load balancing, routes are not advertised, and configuration of load
balancing must be done on each node in the ADN cluster.



Transparent load balancing relies on connection forwarding clusters for proper
operation. All nodes in an ADN load balancing group must be part of the same
connection forwarding cluster.



If connection forwarding is not set up correctly, load balancing will fail. For
information on connection forwarding, see Section D: "TCP Connection Forwarding"
on page 111.

21

Volume 6: Advanced Networking
Section C: Transparent and Explicit Connection Deployments
To configure transparent load balancing with the nodes in the ADN cluster as the decision
makers:


Enable load balancing on all nodes by going to Configuration > App. Delivery Network >
Tunneling > Load Balancing, and selecting the Enable Load Balancing checkbox.



(Optional) Set the same group name on all of the nodes in the cluster.



Put all ADN nodes into a forwarding connection cluster. For more information, see
Section D: "TCP Connection Forwarding" on page 111.



Configure WCCP settings on all nodes. For more information, see Chapter 16:
"WCCP Settings" on page 197.



Configure WCCP router settings. Review the vendor’s documentation for
information.
Note: Note: If client IP spoofing is desired, you must configure WCCP so that both
traffic from the Branch Appliance to the Origin Content Server and traffic from the
Origin Content Server to the Branch Appliance is redirected through WCCP. This
requires configuring WCCP on multiple interfaces on your router, or configuring "in/
out" rules. If specific ports are desired (rather than all ports), you must configure both
source-port and destination-port rules in two different service groups.

Configuring an Explicit Deployment
Complete the following steps to configure an explicit deployment:


Configure server subnets on each peer and enable an Internet gateway (see
“Managing Server Subnets and Enabling an Internet Gateway” ).



(Optional) Preserve the destination port (see “Preserving the Destination Port” on
page 26).



Configure explicit load balancing (see “Explicit Load Balancing” on page 27)

Managing Server Subnets and Enabling an Internet Gateway
The server subnets you create here are advertised by this peer upon joining the explicit
ADN network. You can also enable the peer as an Internet gateway. In addition, subnets
not intended to go over ADN tunnels or to be routed to Internet gateways can be
configured as exempt subnets.
Note: You can also configure the exempt subnet capability through policy that
allows you to disable ADN tunnel for specific connections. For more information,
refer to Volume 11: Content Policy Language Guide.

To create server subnets for this peer:
1.

Select Configuration > App. Delivery Network > Routing.

24

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network

Section D: Securing the ADN Network
Depending on your environment, you might need to secure your ADN network to
provide the following services:


Host validation: Securing the ADN network allows you to be sure that the ADN peers
are talking to the right devices and that the peer is authorized to join the ADN
network.



Privacy: Privacy can be an issue, especially for tunnels that carry application data.
You can configure the ADN network to secure ADN routing and tunnel connections
using standard SSL protocol. SSL tunnels provide authentication, message privacy,
and message authenticity security services, regardless of the application traffic that is
being accelerated or tunneled.



Message authenticity: Ensure that messages sent over ADN connections are not
altered. Messages include the route information sent over the routing connections and
compressed application data sent over the tunnel connections.

Secure ADN implementation includes:


Device authentication, managed through the device authentication profile.



Securing the device, including device authentication profile selection and device IDbased peer authorization.



Securing the connections, both inbound and outbound connection security control.



Configuring the SSL proxy.
Note: If you only want secure routing connections to the ADN manager, an SSL
license is not required. Secure tunnel connections for applications such as CIFS,
MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL license.

Configuring ADN Security Settings
For information on setting device security, continue with the next section. For information
on setting connection security, continue with “Securing Connections” on page 33.

Setting Device Security
For maximum security, configure the ADN network for both device authentication and
device authorization. Device authentication must be configured first.
Note: If the device being configured for authentication has Internet access,
acquisition of the SG appliance certificate is automatic. If you use your own appliance
certificates and profile, or if the affected device does not have Internet access, manual
device authentication is required.

For information on configuring device authentication, see Chapter 5: "Authenticating an
SG Appliance" on page 77.
After the device authentication has been set up, point the ADN manager and ADN
backup manager to the profile that is being used for authentication. Then enable
authorization for maximum security.

31

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network

Securing Connections
Use the Connection Security tab to set:


Manager and Tunnel Listening Mode.



Secure Outbound Connections.

Listening Mode Options
In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode
to listen for routing and tunnel requests. By default, ADN routing and tunnel connection
requests are unauthenticated and all ADN protocol messaging and compressed
application data are transferred in plain text.
You must enable the device authentication profile before setting any other security
parameters.
After the profile is configured, the following security modes are automatically set:


Secure-outbound: (Secure Proxies) Both outbound routing and secure proxy

connections are secured. You can also select the radio button to:


Not secure ADN connections.



Secure only ADN routing connections.



Secure all ADN and routing connections.

Note:




The secure-outbound feature is dependent upon an SSL license.

Manager-listening-mode: (Both) Listen for requests on two ports: plain and secure. If
your deployment requires a different ADN manager listening mode, you must
explicitly configure it. Other options available are:



Secure Only.



Plain Only.



Plain Read-Only. This mode is recommended if your network uses SG clients.

Tunnel-listening-mode: (Both) Listen for requests on two ports: plain and secure. Other

options are:


Secure Only (Note that tunnel listening mode cannot be set to secure-only if SG
Clients exist on the ADN network).



Plain Only.

Secure Outbound Connections
When secure ADN is enabled, any existing plain outbound connections are dynamically
secured by activating SSL according to the secure-outbound setting. Determine which
outbound ADN connections are secured by changing the secure-outbound parameter. If
you select:


None: Neither routing nor tunnel connections are secured. Secure proxy connections

bypass ADN connections and go directly to the origin content sever.


Routing-only: Only routing connections are secured. Secure proxy connections bypass

ADN connections and go directly to the origin content sever.

33

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network
3.

To configure tunnel listening mode and ports:


To change the tunnel listening mode, go to Configuration > App. Delivery Network >
General > Connection Security. The default is Plain-only before the device
authentication profile is selected. After the device authentication profile is
selected, the manager listening mode switches to Both by default.



To change tunnel listening ports, go to Configuration > App. Delivery Network >
Tunneling > Connection. The default is plain port 3035 and secure port 3037.
The tunnel listening port is used only if there are explicit tunnel connections to
this ADN node using the non-preserve-dest-port mode.

4.

Select Apply to commit the changes to the SG appliance.

Authorizing Devices to Join the Network
After a node is configured for authentication (device security) and peer validation is
enabled on the ADN manager, the node must be accepted by the ADN manager and the
backup ADN manager, if configured, before the device is allowed to join the network
(authorization).


When an ADN node comes up, it contacts the ADN manager for routing information.



If secure-outbound is None on the ADN node and the ADN manager's listening mode
is not secure-only, the ADN node connects to the plain manager listening port and
immediately joins the ADN network.



If the ADN node connects to the secure manager listening port, the ADN manager
extracts the device ID from connecting ADN node's appliance certificate and looks for
the device ID in its approved list of ADN nodes.


If the device is on the approved list, a REQUEST-APPROVED response is sent,
followed by the route information, and the node joins the network.



If the device is not on the approved list, the ADN manager adds the connecting
node's device ID to the pending-peers list and sends a REQUEST-PENDING
response. After the peer is moved to the Approved list by the administrator, a
REQUEST-APPROVED response is sent, followed by the route information, and the
node joins the network.



If the Pending Peers option is not enabled and a peer is not on the approved list,
the ADN manager sends a REQUEST-DENIED response and closes the connection.
The connecting node closes the connection and updates its connection status.



If a peer is deleted from the approved list, the ADN manager broadcasts a
REJECT-PEER to all nodes to delete this node and terminate any existing ADN

connections to it. No new connections are routed through the deleted ADN node.
To have the denied peer rejoin the ADN network, go to ADN > Config > General >
Reconnect to Managers.
To approve a device to join the network:
Note: Device security must be enabled on all ADN peers you want to join the
network before you complete this procedure on the ADN manager and backup ADN
manager. For more information, see “Setting Device Security” on page 31.

35

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network
2.

Select the Allow Pending Peers checkbox.

3.

To manage pending peers:

4.



Highlight a peer and click Accept or Reject; alternatively, you can select or reject
all peers in the list by clicking Accept All or Reject All. If accepted, the peer moves
to the Approved list; if not, it is dropped from the Pending Peers list.



You can also leave peers in the pending list by not selecting them or selecting
them and clicking Leave Pending.

Select Apply to commit the changes to the SG appliance.

Approved/Pending Notes


Approved lists on the primary and backup ADN managers are not automatically kept
in sync. You must approve peers on both the primary and backup ADN managers.

37

Chapter 2: Configuring an Application Delivery Network

Section E: ADN Network History, Statistics, and Health Metrics


Bytes sent to the application: The total bytes sent to the client/server/application
proxy.



Bytes received from the peer SG appliance: The bytes received on the ADN tunnel
connection from the peer at the other end of the WAN link. (This is compressed unless
byte caching is disabled).



Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel connection to
the peer at the other end of the WAN Link. (This is compressed unless byte caching is
disabled).



Duration: The lifetime of this connection.

Reviewing ADN Health Metrics
You can see the state of the ADN network, specifically the ADN node, by checking the
Statistics > Health > General tab.
The status can have the values as shown in the following table. The information is meant
for diagnostic and debugging purposes.

39

Volume 6: Advanced Networking
Section E: ADN Network History, Statistics, and Health Metrics
Table 2-2. Connectivity to ADN Routing Manager Health Metric
Status

Message

Description

State

ADN Health Status

Connected

The ADN node is connected to the ADN
manager, ready to receive any route/peer
updates.

OK

If a backup manager exists, this state
indicates the node is connected to both
Managers.
Functionality
Disabled

ADN functionality is not enabled.

OK

Not operational

ADN functionality is not operational yet —
components are starting up or shutting
down.

OK

Connection
Approved

The ADN node has been approved to
connect to the ADN manager.

OK

Connecting

The ADN node is in process of connecting
to ADN manager.

OK

Partially Connected

The ADN node is connected to one ADN
manager but not the other.

Warning

Mismatching
Approval Status

The ADN node is approved by the current
active ADN manager but is rejected by the
backup manager. This warning only exists
if a backup ADN manager is configured.

Warning

Approval Pending

The ADN node is awaiting a decision from
the active ADN manager for the node’s
request to join the ADN network.

Warning

Disconnected

The ADN node is not connected to the
ADN manager and cannot receive route/
peer information.

Critical

If a backup manager is configured, this
state indicates the node is disconnected
from both manager nodes.

ADN Manager Status

Connection Denied

The ADN node is rejected by the ADN
managers in the node's request to join the
ADN network.

Critical

Not an ADN
manager

The ADN node is not an ADN manager.

OK

No Approvals
Pending

All ADN nodes that are requesting to join
the network are already on the approved
list.

OK

Approvals Pending

ADN nodes are requesting to join the
network. The approvals are made by the
administrator.

Warning

40

Chapter 2: Configuring an Application Delivery Network

Section F: Advanced Tunnel Optimization

Section F: Advanced Tunnel Optimization
Tunnel connections are between the branch and concentrator proxies and are made on
demand. To reduce connection startup latency, tunnel connections are pooled and reused.
If a route is present, proxies that support ADN optimization use an ADN tunnel
connection. Data traveling over the tunnel connection is subject to byte caching,
compression, and encryption, per the defined policies.
The tunnel connection occurs independently of the ADN optimization options chosen for
that connection. These options can be configured for specific services and can also be
modified in policy.
Note:

Encryption options cannot be set through policy.

Optimization options include byte caching and gzip compression; byte caching and gzip
compression can be controlled separately for inbound and outbound traffic on the WAN.
By default, ADN routing and tunnel connection requests are unauthenticated and all
ADN protocol messaging and compressed application data are transferred in plaintext.
For maximum security, you can configure the ADN network to secure ADN routing and
tunnel connections using standard SSL protocol, which provides authentication, message
privacy, and message authenticity security services, regardless of the application traffic
that is being accelerated or tunneled.
For information on securing the network, see Section D: "Securing the ADN Network" on
page 31.

Setting Advanced Tunneling Parameters
The tunneling parameters you set determine the behavior when you have special
environmental needs where the default parameters are not adequate. These parameters
generally do not need to be changed. Parameters that can be changed include:


Connection Settings (see “To configure ADN manager and tunnel listening mode and
ports:” on page 34).



Network Settings (see “To configure network tunneling settings:” ).



Load Balancing Settings (see “Transparent Load Balancing” on page 22 and “Explicit
Load Balancing” on page 27).



Proxy Processing Settings (see “To change parameters for proxy processing:” on page
42).

To configure network tunneling settings:
1.

Select Configuration > App. Delivery Network > Tunneling > Network.

41

Chapter 2: Configuring an Application Delivery Network

Section F: Advanced Tunnel Optimization
2.

(Optional) If the concentrator is required to perform HTTP proxy processing on
requests arriving over an ADN tunnel, select HTTP. For most deployments, this is not
needed. All proxy processing always happens at the branch proxy; generally
speaking, the concentrator proxy just compresses and decompresses bytes and
forwards them to and from the server. If this setting is enabled, proxy processing
happens at both the branch and concentrator.
Note: If you enable this setting, do not duplicate any of the policy that exists at
the branch, since the branch settings still apply. Depending on the policy
involved, doing the processing twice can cause problems (such as doing URL
rewrite multiple times) or it might just be unnecessary, taking up valuable
resources.

3.

Select Apply to commit the changes to the SG appliance.

43

Volume 6: Advanced Networking
Section G: Manually Re-Sizing a Byte-Cache Dictionary

Section G: Manually Re-Sizing a Byte-Cache Dictionary
The size of a byte-cache dictionary is dynamically based on the amount of traffic between
two peers. Generally, the dynamic settings are acceptable; you do not need to change the
dictionary size. Only if you determine that the algorithm performance does not guarantee
a sufficient dictionary size for a specific peer should you manually set the dictionary size.
The byte cache itself, consisting of all data seen on the network, is stored on disk.
However, byte caching stores index data in RAM. You cannot change the amount of
memory allocated for a peer, but you can manually set the amount of disk space to be set
aside. The amount of memory set aside is based on the disk space.
A table of peer rankings and dictionary sizes is created and maintained by the SG
appliance. Peers are allocated dictionary space in order starting with the highest ranking
peer in the table until each peer has been allocated resources, or maximum available
amount of byte cache memory is reached.

Note:

The rank table can track peers that are using SGOS 5.1.3, but these peers
cannot dynamically re-size or delete their dictionary.
After the maximum available resources are reached, any peers that have not been
allocated a dictionary cannot use byte caching. If those peers have existing dictionaries,
the tunnels are downgraded to gzip compression only and the existing dictionary is
deleted.
A node can re-negotiate a new shared dictionary size with one of its peers, and the
dictionaries grow or shrink to their new resource levels. The final shared dictionary sizes
between two peers is the minimum dictionary size that each peer tries to negotiate. To
guarantee a minimum dictionary size, the value should be set on both peers. (See “To
manually resize byte cache dictionaries from the Statistics tab:” on page 45.)
When a peer joins the network, it is added to the peer ranking table. How much dictionary
space it is allocated depends:


If the maximum amount of resources have already been reached, the new peer can do
gzip compression only.



If the maximum amount of resources have not been reached:


If no history exists for this peer, then the peer negotiates a default dictionary size
based on its maximum memory and maximum disk space.



If history does exist for the peer and the peer's rank guarantees the peer a
dictionary, the peer is allocated a dictionary based on that history.

The peer ranking table is persistent across system reboots; the dictionaries themselves are
re-sized upon any of the following conditions:


System restart.



A full dictionary.



If the dictionary size is set manually.

The re-ranking allows potentially unused dictionaries to be identified and removed,
freeing resources.

44

Chapter 2: Configuring an Application Delivery Network

Section H: Related CLI Syntax to Configure an ADN Network

Section H: Related CLI Syntax to Configure an ADN Network


To enter configuration mode:
SGOS#(config) adn
SGOS#(config adn)
Note:

For detailed information on using these commands, refer to Volume 12:
Command Line Reference.


The following subcommands are available:
SGOS#(config adn) {enable | disable}
SGOS#(config adn) exit
SGOS#(config adn) byte-cache
SGOS#(config adn byte-cache) peer-size peer-id {size_in_megabytes |
auto}
SGOS#(config adn byte-cache) exit
SGOS#(config adn byte-cache) view
SGOS#(config adn) load-balancing
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
disable}
SGOS#(config
SGOS#(config

adn
adn
adn
adn
adn

load-balancing)
load-balancing)
load-balancing)
load-balancing)
load-balancing)

{enable | disable}
exit
external-vip IP_address
group group_name
load-balance-only {enable |

adn load-balancing) no {external-vip | group}
adn load-balancing) view

SGOS#(config adn) manager
SGOS#(config adn manager) backup-manager {IP_address [ID] | self}
SGOS#(config adn manager) exit
SGOS#(config adn manager) no {backup-manager | primary-manager}
SGOS#(config adn manager) port port_number
SGOS#(config adn manager) primary-manager {IP_address [ID] | self}
SGOS#(config adn manager) secure-port secure_port_number
SGOS#(config adn manager) view [approved-peers | backup-manager-id
| pending-peers | primary-manager-id]
SGOS#(config adn manager) approved-peers
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

adn
adn
adn
adn

approved-peers)
approved-peers)
approved-peers)
approved-peers)

add peer-device-ID
exit
remove peer-device-ID
view

SGOS#(config adn manager) pending-peers
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

adn
adn
adn
adn

pending-peers)
pending-peers)
pending-peers)
pending-peers)

{accept | reject}
{enable | disable}
exit
view

SGOS#(config adn) routing
SGOS#(config adn routing) exit
SGOS#(config adn routing) prefer-transparent {enable | disable}
SGOS#(config adn routing) view
SGOS#(config adn routing) advertise-internet-gateway

47

Volume 6: Advanced Networking
Section H: Related CLI Syntax to Configure an ADN Network
SGOS#(config adn routing advertise-internet-gateway) {disable |
enable}
SGOS#(config adn routing advertise-internet-gateway) exemptsubnet {add {subnet_prefix[/prefix_length]} clear-all | remove
{subnet_prefix[/prefix_length]} | view}
SGOS#(config adn routing advertise-internet-gateway) exit
SGOS#(config adn routing advertise-internet-gateway) view
SGOS#(config adn routing) server-subnets
SGOS#(config adn
prefix length]
SGOS#(config adn
SGOS#(config adn
prefix length]
SGOS#(config adn
SGOS#(config adn

routing server-subnets) add subnet_prefix [/
routing server-subnets) clear-all
routing server-subnets) remove subnet_prefix [/
routing server-subnets) exit
routing server-subnets) view

SGOS#(config adn) security
SGOS#(config adn security) authorization {enable | disable}
SGOS#(config adn security) device-auth-profile profile_name [noauthorization]
SGOS#(config adn security) exit
SGOS#(config adn security) manager-listening-mode {plain-only |
plain-read-only | secure-only| both}
SGOS#(config adn security) no device-auth-profile
SGOS#(config adn security) secure-outbound {none | routing-only|
secure-proxies | all}
SGOS#(config adn security) tunnel-listening-mode {plain-only |
secure-only | both}
SGOS#(config adn security) view
SGOS#(config adn) tunnel
SGOS#(config adn
SGOS#(config adn
SGOS#(config adn
SGOS#(config adn
SGOS#(config adn
SGOS#(config adn
use-local-ip)
SGOS#(config adn
SGOS#(config adn
SGOS#(config adn

tunnel)
tunnel)
tunnel)
tunnel)
tunnel)
tunnel)

connect-transparent {enable | disable}
exit
preserve-dest-port {enable | disable}
port port_number
proxy-processing http {enable | disable}
reflect-client-ip (deny | allow |

tunnel) secure-port secure_port_number
tunnel) tcp-window-size window_size
tunnel) view

48

Chapter 2: Configuring an Application Delivery Network

Section I: Policy

Section I: Policy
The following gestures can be used for WAN optimization from either the VPM or CPL.
Note:

For more information on using the VPM or CPL to configure policy, refer to
Volume 7: VPM and Advanced Policy or Volume 11: Content Policy Language Guide.


adn.server(yes | no) (Note that this property overrides all other routing and
intercept decisions made by ADN based on configuration and routing information.)



adn.server.optimize(yes | no)



adn.server.optimize.inbound(yes | no)



adn.server.optimize.outbound(yes | no)



adn.server.optimize.byte-cache(yes | no)



adn.server.optimize.inbound.byte-cache(yes | no)



adn.server.optimize.outbound.byte-cache(yes | no)



adn.server.optimize.compress(yes | no)



adn.server.optimize.inbound.compress(yes | no)



adn.server.optimize.outbound.compress(yes | no)

49

Volume 6: Advanced Networking

50

Chapter 3: Attack Detection

The SGOS software can reduce the effects of distributed denial of service (DDoS)
attacks and port scanning, two of the most common virus infections.
A DDoS attack occurs when a pool of machines that have been infected with a DDoStype of virus attack a specific Web site. As the attack progresses, the target host shows
decreased responsiveness and often stops responding. Legitimate HTTP traffic is
unable to proceed because the infected system is waiting for a response from the target
host.
Port scanning involves viruses attempting to self-propagate to other machines by
arbitrarily attempting to connect to other hosts on the Internet. If the randomly selected
host is unavailable or behind a firewall or does not exist, the infected system continues
to wait for a response, thus denying legitimate HTTP traffic.
The SG appliance prevents attacks by limiting the number of simultaneous TCP
connections from each client IP address and either does not respond to connection
attempts from a client already at this limit or resets the connection. It also limits
connections to servers known to be overloaded.
You can configure attack detection for both clients and servers or server groups, such as
http://www.bluecoat.com. The client attack-detection configuration is used to control the
behavior of virus-infected machines behind the SG appliance. The server attackdetection configuration is used when an administrator knows ahead of time that a
virus is set to attack a specific host.
This feature is only available through the CLI. You cannot use the Management
Console to enable attack detection.
This section discusses:


“Configuring Attack-Detection Mode for the Client” on page 51



“Configuring Attack-Detection Mode for a Server or Server Group” on page 55

Configuring Attack-Detection Mode for the Client
To enter attack-detection mode for the client:
From the (config) prompt, enter the following commands:
SGOS#(config) attack-detection
SGOS#(config attack-detection) client

The prompt changes to:
SGOS#(config client)

Changing Global Settings
The following defaults are global settings, used if a client does not have specific limits
set. They do not need to be changed for each IP address/subnet if they already suit
your environment:


client limits enabled: true



client interval: 20 minutes

51

Volume 6: Advanced Networking



block-action: drop (for each client)



connection-limit: 100 (for each client)



failure-limit: 50 (for each client)



unblock-time: unlimited



warning-limit: 10 (for each client)

To change the global defaults:
Remember that enable/disable limits and interval affect all clients. The values cannot be
changed for individual clients. Other limits can be modified on a per-client basis.
Note: If you edit an existing client’s limits to a smaller value, the new value only applies

to new connections to that client. For example, if the old value was 10 simultaneous
connections and the new value is 5, existing connections above 5 are not dropped.
SGOS#(config client) enable-limits | disable-limits
SGOS#(config client) interval minutes
SGOS#(config client) block ip_address [minutes] | unblock ip_address
SGOS#(config client) default block-action drop | send-tcp-rst
SGOS#(config client) default connection-limit
integer_between_1_and_65535
SGOS#(config client) default failure-limit integer_between_1_and_500
SGOS#(config client) default unblock-time minutes_between_10_and_1440
SGOS#(config client) default warning-limit integer_between_1_and_100
:

Table 3-1. Changing Global Defaults
Toggles between enabled and disabled. The default is disabled.
This is a global setting and cannot be modified for individual
clients.

enable-limits |
disable-limits

interval

integer

Indicates the amount of time, in multiples of 10 minutes, that
client activity is monitored. The default is 20. This is a global
setting and cannot be modified for individual clients.

block | unblock

ip_address
[minutes]

Blocks a specific IP address for the number of minutes listed. If
the optional minutes argument is omitted, the client is blocked
until explicitly unblocked. Unblock releases a specific IP address.

default blockaction

drop | sendtcp-rst

Indicates the behavior when clients are at the maximum number
of connections or exceed the warning limit: drop the connections
that are over the limit or send TCP RST for connections over the
limit. The default is drop. This limit can be modified on a perclient basis.

default
connection-limit

integer

Indicates the number of simultaneous connections between 1 and
65535. The default is 100. This limit can be modified on a perclient basis.

default failurelimit

integer

Indicates the maximum number of failed requests a client is
allowed before the proxy starts issuing warnings. Default is 50.
This limit can be modified on a per-client basis.

52

Chapter 3: Attack Detection

Table 3-1. Changing Global Defaults (Continued)
default unblocktime

minutes

Indicates the amount of time a client is blocked at the network
level when the client-warning-limit is exceeded. Time must be a
multiple of 10 minutes, up to a maximum of 1440. By default, the
client is blocked until explicitly unblocked. This limit can be
modified on a per-client basis.

default warninglimit

integer

Indicates the number of warnings sent to the client before the
client is blocked at the network level and the administrator is
notified. The default is 10; the maximum is 100. This limit can be
modified on a per-client basis.

To create and edit a client IP address:
Client attack-detection configuration is used to control the behavior of virus-infected
machines behind the SG appliance.
1.

Verify the system is in the attack-detection client submode.
SGOS#(config) attack-detection
SGOS#(config attack-detection) client
SGOS#(config client)

2.

Create a client.
SGOS#(config client) create client ip_address or ip_and_length

3.

Move to edit client submode.
SGOS#(config client) edit client_ip_address

The prompt changes to:
SGOS#(config client ip_address)

4.

Change the client limits as necessary.
SGOS#(config client ip_address)
SGOS#(config client ip_address)
integer_between_1_and_65535
SGOS#(config client ip_address)
integer_between_1_and_65535
SGOS#(config client ip_address)
SGOS#(config client ip_address)
integer_between_1_and_65535

block-action drop | send-tcp-rst
connection-limit
failure-limit
unblock-time minutes
warning-limit

:b

Table 3-2. Changing the Client Limits
block-action

drop | send-tcp-rst

Indicates the behavior when the client is at the maximum
number of connections: drop the connections that are over the
limit or send TCP RST for the connection over the limit. The
default is drop.

connection-limit

integer

Indicates the number of simultaneous connections between 1
and 65535. The default is 100.

failure-limit

integer

Indicates the behavior when the specified client is at the
maximum number of connections: drop the connections that
are over the limit or send TCP RST for the connection over the
limit. The default is 50.

53

Volume 6: Advanced Networking

Table 3-2. Changing the Client Limits (Continued)
unblock-time

minutes

Indicates the amount of time a client is locked out at the
network level when the client-warning-limit is exceeded. Time
must be a multiple of 10 minutes, up to a maximum of 1440. By
default, the client is blocked until explicitly unblocked. .

warning-limit

integer

Indicates the number of warnings sent to the client before the
client is locked out at the network level and the administrator
is notified. The default is 10; the maximum is 100.

To view the specified client configuration:
Enter the following command from the edit client submode:
SGOS#(config client ip_address)
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

view
700
50
10
Drop
unlimited

To view the configuration for all clients:
1.

Exit from the edit client submode:
SGOS#(config client ip_address) exit

2.

Use the following syntax to view the client configuration:
view { | blocked | connections | statistics}

To view all settings:
SGOS#(config client) view
Client limits enabled:
true
Client interval:
20 minutes
Default client limits:
Client connection limit:
100
Client failure limit:
50
Client warning limit:
10
Blocked client action:
Drop
Client connection unblock time:
unlimited
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

700
50
10
Drop
unlimited

To view the number of simultaneous connections to the SG appliance:
SGOS#(config client) view connections
Client IP
Connection Count
127.0.0.1
1
10.9.16.112
1
10.2.11.133
1

54

Chapter 3: Attack Detection

To view the number of blocked clients:
SGOS#(config client) view blocked
Client
Unblock time
10.11.12.13
2004-07-09 22:03:06+00:00UTC
10.9.44.73
Never

To view client statistics:
SGOS#(config client) view statistics
Client IP
Failure Count
10.9.44.72
1

Warning Count
0

To disable attack-detection mode for all clients:
SGOS#(config client) disable-limits

Configuring Attack-Detection Mode for a Server or Server Group
Server attack-detection configuration is used when an administrator knows ahead of time
that a virus is set to attack a specific host.
You can create, edit, or delete a server. A server must be created before it can be edited.
You can treat the server as an individual host or you can add other servers, creating a
server group. All servers in the group have the same attack-detection parameters,
meaning that if any server in the group gets the maximum number of simultaneous
requests, all servers in the group are blocked.
You must create a server group before you can make changes to the configuration.
To create a server or server group:
1.

At the (config) prompt:
SGOS#(config) attack-detection
SGOS#(config attack-detection) server

The prompt changes to:
SGOS#(config server)

2.

Create the first host in a server group, using the fully qualified domain name:
SGOS#(config server) create hostname

To edit a server or server group:
At the (config server) prompt:
SGOS#(config server) edit hostname

The prompt changes to (config server hostname).
SGOS#(config server hostname) {add | remove} hostname
SGOS#(config server hostname) request-limit integer_from_1_to_65535

where:
:e

The name of a previously created server or server group.
When adding a hostname to the group, the hostname does
not have to be created. The host that was added when
creating the group cannot be removed.

hostname

add | remove

hostname

Adds or removes a server from this server group.

55

Volume 6: Advanced Networking

request-limit

integer

Indicates the number of simultaneous requests allowed from
this server or server group. The default is 1000.

To view the server or server group configuration:
SGOS#(config server hostname) view
Server limits for hostname:
Request limit:
1500

56

Chapter 4: Bandwidth Management

Bandwidth management (BWM) allows you to classify, control, and limit the amount of
bandwidth used by different classes of network traffic flowing into or out of the SG
appliance. Network resource sharing (or link sharing) is accomplished by using a
bandwidth-management hierarchy where multiple traffic classes share available
bandwidth in a controlled manner.
Note: The SG appliance does not attempt to reserve any bandwidth on the network
links that it is attached to or otherwise guarantee that the available bandwidth on the
network can sustain any of the bandwidth limits which have been configured on it. The
SG appliance can only shape the various traffic flows passing through it, and prioritize
some flows over others according to its configuration.

By managing the bandwidth of specified classes of network traffic, you can accomplish
the following:


Guarantee that certain traffic classes receive a specified minimum amount of
available bandwidth.



Limit certain traffic classes to a specified maximum amount of bandwidth.



Prioritize certain traffic classes to determine which classes have priority over
available bandwidth.

Bandwidth Management Overview
To manage the bandwidth of different types of traffic that flow into, out of, or through
the SG appliance, you must do the following:


Determine how many bandwidth classes you need and how to configure them to
accomplish your bandwidth management goals. This includes determining the
structure of one or more bandwidth hierarchies if you want to use priority levels to
manage bandwidth.



Create and configure bandwidth classes accordingly.



Create policy rules using those bandwidth classes to identify and classify the traffic
in the SG appliance.



Enable bandwidth management.

Bandwidth management configuration consists of two areas:


Bandwidth allocation
This is the process of creating and configuring bandwidth classes and placing them
into a bandwidth class hierarchy. This process can be done using either the
Management Console or the CLI.

57

Volume 6: Advanced Networking



Flow classification
This is the process of classifying traffic flows into bandwidth management classes
using policy rules. Policy rules can classify flows based on any criteria testable by
policy. You can create policy rules using either the Visual Policy Manager (VPM),
which is accessible through the Management Console, or by composing Content
Policy Language (CPL).

Note: For more information about using VPM to create policy rules, refer to Volume 7:
VPM and Advanced Policy. For information about composing CPL, refer to Volume 11:
Content Policy Language Guide.

Allocating Bandwidth
The process of defining bandwidth classes and grouping them into a bandwidth class
hierarchy is called bandwidth allocation. Bandwidth allocation is based on:


the placement of classes in a hierarchy (the parent/child relationships).



the priority level of classes in the same hierarchy.



the minimum and/or maximum bandwidth setting of each class.

For example deployment scenarios, see “Bandwidth Allocation and VPM Examples” on
page 68.

Bandwidth Classes
To define a bandwidth class, you create the class, giving it a name meaningful to the
purpose for which you are creating it. You can configure the class as you create it or edit it
later. The available configuration settings are:


Parent: Used to create a bandwidth-management hierarchy.



Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this
class.



Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this
class.



Priority: Relative priority level among classes in the same hierarchy.

Parent Class
A parent class is a class that has children. When you create or configure a bandwidth class,
you can specify another class to be its parent (the parent class must already exist). Both
classes are now part of the same bandwidth-class hierarchy, and so are subject to the
hierarchy rules (see “Class Hierarchy Rules and Restrictions” on page 60).
Minimum Bandwidth
Setting a minimum for a bandwidth class guarantees that class receives at least that
amount of bandwidth, if the bandwidth is available. If multiple hierarchies are competing
for the same available bandwidth, or if the available bandwidth is not enough to cover the
minimum, bandwidth management is not be able to guarantee the minimums defined for
each class.

58

Chapter 4: Bandwidth Management

Note: The SG appliance does not attempt to reserve any bandwidth on the network links
that it is attached to or otherwise guarantee that the available bandwidth on the network
can be used to satisfy bandwidth class minimums. The SG appliance can only shape the
various traffic flows passing through it, and prioritize some flows over others according
to its configuration.

Maximum Bandwidth
Setting a maximum for a bandwidth class puts a limit on how much bandwidth is
available to that class. It does not matter how much bandwidth is available; a class can
never receive more bandwidth than its maximum.
To prevent a bandwidth class from using more than its maximum, the SG appliance inserts
delays before sending packets associated with that class until the bandwidth used is no
more than the specified maximum. This results in queues of packets (one per class)
waiting to be sent. These queues allow the SG appliance to use priority settings to
determine which packet is sent next. If no maximum bandwidth is set, every packet is sent
as soon as it arrives, so no queue is built and nothing can be prioritized.
Unlike minimums and priority levels, the maximum-bandwidth setting can purposely
slow down traffic. Unused bandwidth can go to waste with the maximum-bandwidth
setting, while the minimum-bandwidth settings and priority levels always distributes any
unused bandwidth as long as classes request it. However, priority levels are not
meaningful without a maximum somewhere in the hierarchy. If a hierarchy has no
maximums, any class in the hierarchy can request and receive any amount of bandwidth
regardless of its priority level.
Priority
When sharing excess bandwidth with classes in the same hierarchy, the class with the
highest priority gets the first opportunity to use excess bandwidth. When the highpriority class uses all the bandwidth it needs or is allowed, the next class gets to use the
bandwidth, if any remains. If two classes in the same hierarchy have the same priority,
then excess bandwidth is shared in proportion to their maximum bandwidth setting.

Class Hierarchies
Bandwidth classes can be grouped together to form a class hierarchy. Creating a
bandwidth class allows you to allocate a certain portion of the available bandwidth to a
particular type of traffic. Putting that class into a bandwidth-class hierarchy with other
bandwidth classes allows you to specify the relationship among various bandwidth
classes for sharing available (unused) bandwidth.
The way bandwidth classes are grouped into the bandwidth hierarchy determines how
they share available bandwidth among themselves. You create a hierarchy so that a set of
traffic classes can share unused bandwidth. The hierarchy starts with a bandwidth class
you create to be the top-level parent. Then you can create other bandwidth classes to be
the children of the parent class, and those children can have children of their own.
To manage the bandwidth for any of these classes, some parent in the hierarchy must have
a maximum bandwidth setting. The classes below that parent can then be configured with
minimums and priority levels to determine how unused bandwidth is shared among
them. If none of the higher level classes have a maximum bandwidth value set, then
bandwidth flows from the parent to the child classes without limit. In that case,
minimums and priority levels are meaningless, because all classes get all the bandwidth
they need at all times. The bandwidth, in other words, is not being managed.

59

Volume 6: Advanced Networking

Class Hierarchy Rules and Restrictions
Certain rules and restrictions must be followed to create a valid BWM class hierarchy:


Each traffic flow can only belong to one bandwidth management class.
You can classify multiple flows into the same bandwidth class, but any given flow is
always counted as belonging to a single class. If multiple policy rules match a single
flow and attempt to classify it into multiple bandwidth classes, the last classification
done by policy applies.



When a flow is classified as belonging to a bandwidth class, all packets belonging to
that flow are counted against that bandwidth class.



If a minimum bandwidth is configured for a parent class, it must be greater than or
equal to the sum of the minimum bandwidths of its children.



If a maximum bandwidth is configured for a parent class, it must be greater than or
equal to the largest maximum bandwidth set on any of its children. It must also be
greater than the sum of the minimum bandwidths of all of its children.



The minimum bandwidth available to traffic directly classified to a parent class is
equal to its assigned minimum bandwidth minus the minimum bandwidths of its
children. For example, if a parent class has a minimum bandwidth of 600 kbps and
each of its two children have minimums of 300 kbps, the minimum bandwidth
available to traffic directly classified into the parent class is 0.

Relationship among Minimum, Maximum, and Priority Values
Maximum values can be used to manage bandwidth for classes whether or not they are
placed into a hierarchy. This is not true for minimums and priorities, which can only
manage bandwidth for classes that are placed into a hierarchy. Additionally, a hierarchy
must have a maximum configured on a high-level parent class for the minimums and
priorities to manage bandwidth.
This is because, without a maximum, bandwidth goes to classes without limit and there is
no point to setting priorities or minimum guarantees. Bandwidth cannot be managed
unless a maximum limit is set somewhere in the hierarchy.
When a hierarchy has a maximum on the top-level parent and minimums, maximums and
priorities placed on the classes related to that parent, the following conditions apply:


If classes in a hierarchy have minimums, the first thing that happens with available
bandwidth is that all the minimum requests are satisfied. If the amount requested is
less than the minimum for any class, it receives the entire amount, and its priority level
does not matter.
Even though a minimum is considered to be a guaranteed amount of bandwidth,
satisfying minimums is dependent on the parent being able to receive its own
maximum, which is not guaranteed.



When all of the classes in a hierarchy have had their minimums satisfied, any
additional requests for bandwidth must be obtained. When a class requests more than
its minimum, it must obtain bandwidth from its parent or one of its siblings. If,
however, a class requests more than its maximum, that request is denied—no class
with a specified maximum is ever allowed more than that amount.



If a class does not have a minimum specified, it must obtain all of the bandwidth it
requests from its parents or siblings, and it cannot receive any bandwidth unless all of
the minimums specified in the other classes in its hierarchy are satisfied.

60

Volume 6: Advanced Networking

Viewing Bandwidth Management Configurations
You can view the following bandwidth class configurations:


Level in the hierarchy (parent/child relationships)



Priority level



Maximum bandwidth value



Minimum bandwidth value

To view BWM configuration:
1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.
On this tab, you can view a class’s minimum, maximum and priority value. Top level
classes are visible—classes with children have a folder icon on the left.

2.

To view the configurations of the child class(es) of a class, double-click the folder icon.
The child classes become visible. A second double-click closes the folder.

Related CLI Syntax to Configure Bandwidth Management


To enter configuration mode:
SGOS#(config) bandwidth-management



The following subcommands are available:
SGOS#(config bandwidth-management) enable | disable
SGOS#(config bandwidth-management) create | delete bwm_class



To enter edit mode:
SGOS#(config bandwidth-management) edit bwm_class



The following subcommands are available:
SGOS#(config bw-class bwm_class) min-bandwidth minimum_in_kbps
SGOS#(config bw-class bwm_class) max-bandwidth maximum_in_kbps
SGOS#(config bw-class bwm_class) priority value_from_0_to_7
bandwidth-management bwm_class) no {min-bandwidth | max-bandwidth}
SGOS#(config bandwidth-management bwm_class) parent parent_class_name
-orSGOS#(config bandwidth-management bwm_class) no parent
SGOS#(config bandwidth-management bwm_class) view

Bandwidth Management Statistics
The bandwidth management statistics tabs (Current Class Statistics and Total Class
Statistics) display the current packet rate and total number of packets served, the current
bandwidth rate, and the total number of bytes served and packets dropped.

Current Class Statistics Tab
The Current Class Statistics tab displays the following information for each bandwidth
class:


Current Packet Rate: current packets-per-second (pps) value.



Current Bandwidth: current bandwidth in kilobits per second (Kbps).

64

Chapter 4: Bandwidth Management

Total Bytes

The total number of bytes served.

Total Packets

The total number of packets served.

Dropped Packets

Total number of packets dropped (packets in the queue that are
dropped because the queue length is reached).

Current Bandwidth

Current bandwidth value (in kilobits per second).

Current Packet Rate

Current packets-per-second value.

Queue Length

Maximum length allowed for the queue of packets that lack
available bandwidth but are waiting for bandwidth to become
available.

To clear bandwidth management statistics:
1.

To clear bandwidth management statistics for all bandwidth management classes,
enter the following command at the prompt:
SGOS# clear-statistics bandwidth-management

2.

To clear bandwidth management statistics for a particular class, enter the following
command at the prompt:
SGOS# clear-statistics bandwidth-management class bandwidth_class_name

Using Policy to Manage Bandwidth
After creating and configuring bandwidth management classes, create policy rules to
classify traffic flows using those classes. Each policy rule can only apply to one of four
traffic flow types:


Client inbound



Client outbound



Server inbound



Server outbound

You can use the same bandwidth management classes in different policy rules; one class
can manage bandwidth for several types of flows based on different criteria. However,
any given flow is always be counted as belonging to a single class. If multiple policy rules
match a flow and try to classify it into multiple bandwidth classes, the last classification
done by policy applies.
To manage the bandwidth classes you have created, you can either compose CPL (see
“CPL Support for Bandwidth Management” on page 67 below) or you can use VPM (see
“VPM Support for Bandwidth Management” on page 68). To see examples of policy using
these methods, see “Bandwidth Allocation and VPM Examples” on page 68 or “Policy
Examples: CPL” on page 75.

CPL Support for Bandwidth Management
You must use policy to classify traffic flows to different bandwidth classes. Refer to
Volume 11: Content Policy Language Guide for more information about writing and
managing policy.

67

Volume 6: Advanced Networking

CPL Triggers
You can use all of the CPL triggers for BWM classification (refer to Volume 11: Content
Policy Language Guide for information about using CPL triggers). Basing a bandwidth
decision on a trigger means that the decision does not take effect until after the
information needed to make that decision becomes available. For example, if you set the
CPL to trigger on the MIME type of the HTTP response, then the HTTP headers must be
retrieved from the OCS before a classification can occur. The decision to retrieve those
headers occurs too late to count any of the request bytes from the client or the bytes in the
HTTP response headers. However, the decision affects the bytes in the body of the HTTP
response and any bytes sent back to the client.

Supported CPL
Bandwidth class can be set with policy on each of these four traffic flows:


limit_bandwidth.client.inbound(none | bwm_class)



limit_bandwidth.client.outbound(none | bwm_class)



limit_bandwidth.server.inbound(none | bwm_class)



limit_bandwidth.server.outbound(none | bwm_class)

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed.

VPM Support for Bandwidth Management
You can manage bandwidth using VPM in the Action column of four policy layers: Web
Access, DNS Access, Web Content, and Forwarding Layers. For more information about
using VPM to manage bandwidth, refer to Volume 7: VPM and Advanced Policy. For
examples of bandwidth management scenarios using VPM, see "Bandwidth Allocation
and VPM Examples" below.

Bandwidth Allocation and VPM Examples
This section illustrates how to use the VPM to allocate bandwidth, arrange hierarchies,
and create policy. It describes an example deployment scenario and the tasks an
administrator must accomplish to manage the bandwidth for this deployment. For
specific instructions about allocating bandwidth, see “Configuring Bandwidth
Allocation” on page 61. For examples of CPL bandwidth management tasks, see “Policy
Examples: CPL” on page 75.
Task One: Bandwidth Allocation
The administrator is responsible for managing the bandwidth of three branch offices. He
was told to ensure that each office uses no more than half of its total link bandwidth for
Web and FTP traffic. The total link bandwidth of each office is as follows:


Office A: 1.5 Mb



Office B: 1 Mb



Office C: 2 Mb

He creates one bandwidth class for each of the three offices and configures the maximum
bandwidth to an amount equal to half of the total link bandwidth of each, as shown
below. He also creates policy rules for each class, as described below in "Task One: VPM".

68

Chapter 4: Bandwidth Management

Task Five: Bandwidth Allocation
The CEO makes another request, this time for the main office, the one the administrator
himself works from. This office uses the content filtering feature of the SG appliance to
control the types of Web sites that employees are allowed to view. Although the office uses
content filtering, access to sports sites is not restricted because the CEO is a big fan.
The administrator creates a bandwidth management class called Sports with a maximum
bandwidth of 500 kbps and launches VPM to create policy for this class as described
below.
Task Five: VPM
To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access
Layer, and sets the Destination column to the Category object that includes sports viewing
(content filtering is already set up in VPM). He sets the Action column to the Manage
Bandwidth object, selecting Server side/Inbound and the Sports bandwidth class he created.
After installing the policy and verifying that bandwidth management is enabled, he is
finished.

Policy Examples: CPL
The examples below are complete in themselves. The administrator uses CLI to create and
configure bandwidth management classes and writes CPL to classify traffic flow for these
classes. These examples do not make use of a bandwidth class hierarchy. For examples of
hierarchies, see “Bandwidth Allocation and VPM Examples” on page 68.
Example One: CPL
In this example, the administrator of a college is asked to prevent college students from
downloading MP3 files during peak hours, while still allowing the music department to
download MP3 files at any time. The CPL triggers used are authentication and/or source
subnet and MIME type. The action taken is to limit the total amount of bandwidth
consumed by students to 40 kbps.
CLI commands:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create mp3
SGOS#(config bandwidth-management) edit mp3
SGOS#(config bw-class mp3) max-bandwidth 40

CPL:
define condition student_mp3_weekday
client_address=student_subnet response_header.Content-Type="audio/
mpeg" \
weekday=1..5 hour=9..16
end condition

condition=student_mp3_weekday limit_bandwidth.server.inbound(mp3)

Example Two: CPL
In this example, an administrator must restrict the amount of bandwidth used by HTTP
POST requests for file uploads from clients to 2 Mbps. The CPL trigger used is request
method, and the action taken is to throttle (limit) the amount of bandwidth used by client
side posts by limiting inbound client side flows.
CLI:

75

Volume 6: Advanced Networking

SGOS#(config) bandwidth-management
bandwidth-management) create http_post
SGOS#(config bandwidth-management) edit http_post
SGOS#(config bw-class http_post) max-bandwidth 2000

CPL:
define condition http_posts
http.method=POST
end condition

condition=http_posts limit_bandwidth.client.inbound(http_post)

Example Three: CPL
In this example, the administrator of a remote site wants to limit the amount of bandwidth
used to pre-populate the content from headquarters to 50 kbps during work hours. The
CPL triggers used are current-time and pre-population transactions. The action taken is to
limit the total amount of bandwidth consumed by pre-pop flows.
CLI:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create pre-pop
SGOS#(config bandwidth-management) edit pre-pop
SGOS#(config bw-class pre-pop) max-bandwidth 50

CPL:
define condition prepop_weekday
content_management=yes weekday=1..5 hour=9..16
end condition

condition=prepop_weekday limit_bandwidth.server.inbound(pre-pop)

76

Chapter 5: Authenticating an SG Appliance

This chapter discusses device authentication, which is a mechanism that allows devices
to verify each others’ identity; devices that are authenticated can be configured to trust
only other authenticated devices.
Note:

SG appliance authentication is always used in association with other SGOS
features. For example, you can use appliance authentication with the ADN
implementation of secure tunnels. The secure tunnels feature uses authentication,
the process of verifying a device’s identity, with authorization, the process of
verifying the permissions that a device has. For information on secure tunnels and
appliance authentication, see Section D: "Securing the ADN Network" on page 31.

Introduction
Device authentication is important in several situations:


Securing the network. Devices that are authenticated have exchanged certification
information, verified each others’ identity and know which devices are trusted.



Securing protocols. Many protocols require authentication at each end of the
connection before they are considered secure.

This chapter discusses the following topics:


“SG Appliance Overview”.



“Appliance Certificates and Device Authentication Profiles” on page 78.



“Creating an Authentication Profile” on page 83.



“Related CLI Syntax to Manage Device Authentication” on page 85.



“Obtaining a Non Blue Coat Appliance Certificate” on page 83.



“Related CLI Syntax to Manage Device Authentication” on page 85.

SG Appliance Overview
The Blue Coat implementation allows devices to be authenticated without sending
passwords over the network. Instead, a device is authenticated through certificates and
profiles that reference the certificates. Both the profile and the referenced certificate are
required for device authentication.


Certificates: Certificates contain information about a specific device. Blue Coat runs
an Internet-accessible Certificate Authority (CA) for the purpose of issuing
appliance certificates to SGOS devices. You can also create your own appliance
certificates.



Profiles: A profile is a collection of information used for device-to-device
authentication, including if the device has a certificate and if the certificates of other
devices should be verified. The built-in profile is called bluecoat-appliance-certificate
and references the appliance certificate on your SG appliance; you can create
additional profiles.

77

Volume 6: Advanced Networking

Note:

Authenticating the SG appliance and authenticating the SG appliance server
name are two different procedures that require two different certificates. For
information on authenticating server names, refer to Volume 5: Securing the Blue Coat
SG Appliance.

Appliance Certificates and Device Authentication Profiles
In the Blue Coat implementation of device authentication, both an appliance certificate
and a device authentication profile that references the appliance certificate keyring are
required for device authentication to be successful. Each device to be authenticated must
have an appliance certificate and a profile that references that certificate.
Note that device authentication does not take effect unless the profile is enabled; for
example, if you use WAN optimization, you enable the profile on the Configuration > App.
Delivery Network > General > Device Security tab.

About SG Appliance Certificates
SG appliances come with a cryptographic key that allows the system to be authenticated
as an SG appliance when an appliance certificate is obtained.
An appliance certificate is an X.509 certificate that contains the hardware serial number of
a specific SG device as the CommonName (CN) in the subject field. This certificate then
can be used to authenticate the SG appliance whose hardware serial number is listed in
the certificate. Information from the presented certificate is extracted and used as the
device ID.
Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance certificates.
The root certificate for the Blue Coat CA is automatically trusted by SGOS for device
authentication. These Blue Coat-signed certificates contain no authorization information
and are valid for five years.
You can provide your own device authentication certificates for the SG appliances on your
network if you prefer not to use the Blue Coat CA.

About Device Authentication Profiles
A device authentication profile contains the information related to device authentication:


The name of the keyring that contains the private key and certificate this device uses to
authenticate itself. The default is appliance-key. (For information on private and
public keys, refer to Volume 5: Securing the Blue Coat SG Appliance.)



The name of the CA Certificate List (CCL) that contains the names of certificates of
CAs trusted by this profile. If another device offers a valid certificate signed by an
authority in this list, the certificate is accepted. The default is appliance-ccl.



Verification of the peer certificate.
When the SG appliance is participating in device authentication as an SSL client, the
peer certificate verification option controls whether the server certificate is validated
against the CCL. If verification is disabled, the CCL is ignored.
When the SG appliance is participating in device authentication as an SSL server, the
peer certificate verification option controls whether to require a client certificate. If
verification is disabled, no client certificate is obtained during the SSL handshake. The
default is verify-peer-certificate enabled.

78

Chapter 5: Authenticating an SG Appliance



Specification of how the device ID authorization data is extracted from the certificate.
The default is $(subject.CN).



SSL cipher settings. The default is AES256-SHA.

Each Blue Coat appliance has an automatically-constructed profile called bluecoatappliance-certificate that can be used for device-to-device authentication. This profile
cannot be deleted or edited.
If you cannot use the built-in profile because, for example, you require a different cipher
suite or you are using your own appliance certificates, you must create a different profile,
and have that profile reference the keyring that contains your certificate.
Note: If you do not want to use peer verification, you can use the built-in passiveattack-detection-only profile in place of the bluecoat-appliance-certificate profile.

This profile uses a self-signed certificate and disables the verify-peer option, so that
no authentication is done on the endpoints of the connection. The traffic is encrypted,
but is vulnerable to active attacks.
This profile can be used only when there is no threat of an active man-in-the-middle
attack. Like the bluecoat-appliance certificate profile, the passive-attack-detection-only
profile cannot be edited or deleted.
If you create your own profile, it must contain the same kind of information that is
contained in the Blue Coat profile. To create your own profile, skip to “Creating an
Authentication Profile” on page 83.

Obtaining an SG Appliance Certificate
In many cases, if you have Internet connectivity, an appliance certificate is automatically
fetched by the SG appliance, and no human intervention is required. In other cases, if the
Internet connection is delayed or if you do not have Internet access, you might have to
manually initiate the process of obtaining an appliance certificate.
How you obtain an appliance certificate depends upon your environment:


If the device to be authenticated has Internet connectivity and can reach the Blue Coat
CA server, continue with “Automatically Obtaining an Appliance Certificate” on page
80.



If the device to be authenticated cannot reach the Blue Coat CA server, you must
acquire the certificate manually; continue with “Manually Obtaining an Appliance
Certificate” on page 80.

After the certificate is obtained, you must configure the device to use the profile you
choose to use. For information on configuring the device to use the profile, see Chapter 2:
"Configuring an Application Delivery Network".
If you are configuring device authorization as well as authentication, configure device
authentication before authorization. For more information on device authorization, see
Chapter 2: "Configuring an Application Delivery Network".

79

Volume 6: Advanced Networking

Important:

Only the following SG platforms support appliance certificates:



SG200 (manufactured after August 1, 2006)



SG510



SG810



SG8100

If you attempt to obtain an appliance certificate for other platforms (through
Configuration > SSL > Appliance Certificates > Request appliance certificate), the request
fails with the following error message:


Request failed: Signing server reported error: No such serial number serial number.

If you receive this message, you cannot use Blue Coat appliance certificates, but you can
create your own appliance certificates for use in a secure network. For more
information, see “Obtaining a Non Blue Coat Appliance Certificate” on page 83.

Automatically Obtaining an Appliance Certificate
The appliance attempts to get the certificate completely automatically (with no user
intervention) if it can connect to the Blue Coat CA server at boot time or within about five
minutes of being booted. If the appliance does not have a certificate (for example, it had
one until you did a restore-defaults factory-defaults command) it attempts to get
one on every boot. Once the appliance gets a certificate, that certificate is used until
another restore-defaults factory-defaults command is issued.
If Internet connectivity is established more than five minutes after the system is booted,
you might need to complete the following steps.
To automatically obtain an appliance certificate:
1.

Select Configuration > SSL > Appliance Certificates > Request Certificate.

2.

Click Request appliance certificate.
The Blue Coat CA server does validation checks and signs the certificate. The
certificate is automatically placed in the appliance-key keyring. Note that the
appliance-key keyring cannot be backed up. The keyring is re-created if it is missing
at boot time.

Manually Obtaining an Appliance Certificate
Complete the following steps to obtain an appliance certificate manually. The overview of
the procedure is to:


Generate a appliance certificate signing request and send it to the Blue Coat CA server
for verification and signature.



Import the signed certificate into the SG appliance.

To generate a CSR:
1.

Select Configuration > SSL > Appliance Certificates > Request Certificate.

2.

Select Create CSR.

80

Volume 6: Advanced Networking

7.

Click Generate Cert.
The signed certificate displays, and can be pasted into the appliance-key keyring.
-----BEGIN CERTIFICATE----MIIF/jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV
BAoTF0JsdWUgQ29hdCBTeXN0ZW1zLCBJbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs
IEFCUkNBMRswGQYDVQQDExJhYnJjYS5ibHVlY29hdC5jb20xJDAiBgkqhkiG9w0B
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMjkyMDM5NDdaFw0xMjAx
MjkyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcT
CVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd
BgNVBAsTFkJsdWUgQ29hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTCjA1MDUwNjAw
OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG
DNLCvf7SyKK5+SBCJU2iKwP5+EfiQ5JsScWJghtIo94EhdSC2zvBPQqWbZAJXN74
k/yM4w9ufjfo+G7xPYcMrGmwVBGnXbEhQkagc1FH2orINNY8SVDYVL1V4dRM+0at
YpEiBmSxipmRSMZL4kqtAgMBAAGjggLGMIICwjAJBgNVHRMEAjAAMAsGA1UdDwQE
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr
BgEEAfElAQECAQYLKwYBBAHxJQEBAgIGCysGAQQB8SUBAQIDMB0GA1UdDgQWBBSF
NqC2ubTI7OT5j+KqCPGlSDO7DzCB6wYDVR0jBIHjMIHggBSwEYwcq1N6G1ZhpcXn
OTIu8fNe1aGBvKSBuTCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExEjAQBgNVBAcTCVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3Rl
bXMsIEluYy4xGTAXBgNVBAsTEEJsdWUgQ29hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi
cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AYmx1ZWNv
YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB
hj1odHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9jZ2ktYmluL2RldmljZS1hdXRo
ZW50aWNhdGlvbi9vY3NwMEIGCCsGAQUFBzAChjZodHRwOi8vYWJyY2EuYmx1ZWNv
YXQuY29tL2RldmljZS1hdXRoZW50aWNhdGlvbi9jYS5jZ2kwSAYDVR0fBEEwPzA9
oDugOYY3aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vQ1JMLmNybDBfBgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRjBEBggrBgEF
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X
d2/Qw7NiVsnqOlAy913QZlieFfVATJnCeSrH+M9B/2XtnRxVT0/ZWrf4GbsdYqTF
hc9jR/IwKu6kZq32Dqo8qFU5OzbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK
OeB2bYcjWtMvTvr50iDOV69BEQz+VXos8QiZmRHLVnebQSjl3bi1w3VjBw31tCmc
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq
r23/+BsZlYKAeVMq3PEmxaA2zLzO+jf79a8ZvIKrF27nNuTN7NhFL/V6pWNE1o9A
rbs=
-----END CERTIFICATE-----

To import a certificate onto the SG appliance:
1.

Copy the certificate to your clipboard. Be sure to include the “Begin Certificate” and
“End Certificate” statements.

2.

Select Configuration > SSL > Keyrings.

3.

Select the keyring that is used for device authentication. The keyring used by the
bluecoat-appliance-certificate profile is the appliance-key keyring.

4.

Click Edit/View in the Keyrings tab.

82

Chapter 5: Authenticating an SG Appliance

5.

In the Certificate panel, click Import.

6.

Paste the certificate you copied into the dialog box. Click OK.
The certificate should display in the SSL Certificates Pane, associated with the keyring
you selected earlier.

Obtaining a Non Blue Coat Appliance Certificate
If you run your own certificate signing authority for device authentication, complete the
following steps:
1.

Create a keyring for the appliance's certificate. For information on creating a keyring,
refer to Volume 5: Securing the Blue Coat SG Appliance.

2.

Generate the certificate signing request and get it signed. For information on creating
a CSR, refer to Volume 5: Securing the Blue Coat SG Appliance.
Note:

You cannot put a Blue Coat appliance certificate into a keyring you create
yourself.
3.

Create a CA certificate list.For information on creating a CCL, refer to Volume 5:
Securing the Blue Coat SG Appliance
a.

Import the CA's root certificate.

b.

Add the certificate to the CCL.

4.

Create a device authentication profile. (To create a profile, see “Appliance Certificates
and Device Authentication Profiles” on page 78.)

5.

Associate the profile with the keyring and CCL. The keyring and CCL must already
exist.
Adjust other parameters, including authorization data extractor (if the certificate is to
be used for authorization), as needed.

Configure each application that uses device authentication to reference the newly created
profile, and set up its whitelist. To associate the device with the profile, see Chapter 2:
"Configuring an Application Delivery Network".

Creating an Authentication Profile
An authentication profile only needs to be created if you cannot use the built-in bluecoatappliance-certificate profile without modification; note that the bluecoat-appliancecertificate profile cannot be deleted or edited.
Additional profiles with different settings can be created; for example, if you require a
different cipher setting than what the bluecoat-appliance-certificate profile uses, you can
create a profile with the different cipher suite.
To create a new authentication profile:
1.

Select Configuration > SSL > Device Authentication > Profiles.

2.

Click New.

83

Volume 6: Advanced Networking

86

Chapter 6: Configuring Failover

Using IP address failover, you can create a redundant network for any explicit proxy
configuration. If you require transparent proxy configuration, you can create software
bridges to use failover. For information on creating software bridges, refer to Volume 2:
Getting Started.
Note: If you use the Pass-Through adapter for transparent proxy, you must create a
software bridge rather than configuring failover. For information on using the PassThrough adapter, refer to Volume 2: Getting Started.

Using a pool of IP addresses to provide redundancy and load balancing, Blue Coat
migrates these IP addresses among a group of machines.
This section discusses:


“About Failover” .



“Configuring Failover” on page 88.

About Failover
Failover allows a second machine to take over if a first machine fails, providing
redundancy to the network through a master/slave relationship. In normal operations,
the master (the machine whose IP address matches the group name) owns the address.
The master sends keepalive messages (advertisements) to the slaves. If the slaves do not
receive advertisements at the specified interval, the slave with the highest configured
priority takes over for the master. When the master comes back online, the master takes
over from the slave again.
The Blue Coat failover implementation resembles the Virtual Router Redundancy
Protocol (VRRP) with the following exceptions:


A configurable IP multicast address is the destination of the advertisements.



The advertisement interval is included in protocol messages and is learned by the
slaves.



A virtual router identifier (VRID) is not used.



Virtual MAC addresses are not used.



MD5 is used for authentication at the application level.

Masters are elected, based on the following factors:


If the failover mechanism is configured for a physical IP address, the machine
owning the physical address have the highest priority. This is not configurable.



If a machine is configured as a master using a virtual IP address, the master has a
priority that is higher than the slaves.

When a slave takes over because the master fails, an event is logged in the event log.
No e-mail notification is sent.

87

Chapter 6: Configuring Failover

Note: Class D IP addresses (224 to 239) are reserved for multicast. A Class D IP
address has a first bit value of 1, second bit value of 1, third bit value of 1, and
fourth bit value of 0. The other 28 bits identify the group of computers that
receive the multicast message.

c.

Relative Priority refers to a range from 1-255 that is assigned to systems in the

group. 255 is reserved for the system whose failover group ID equals the real
IP address. (Optional) Master identifies the system with the highest priority
(the priority value is greyed out).

4.

d.

(Optional) Advertisement Interval refers to the length of time between
advertisements sent by the group master. The default is 40 seconds. If the
group master fails, the slave with the highest priority takes over (after
approximately three times the interval value). The failover time of the group
is controlled by setting this value.

e.

(Optional, but recommended) Group Secret refers to a password shared only
with the group.

f.

Select enabled.

g.

Click OK.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Failover


To enter configuration mode:
SGOS#(config) failover



The following subcommands are available:
SGOS#(config failover) create group_address
SGOS#(config failover) edit group_address
SGOS#(config failover group_address) multicast-address
multicast_address
SGOS#(config failover group_address) master
SGOS#(config failover group_address) priority number
SGOS#(config failover group_address) interval seconds
SGOS#(config failover group_address) secret secret
-orSGOS#(config failover group_address) encrypted-secret encrypted_secret
SGOS#(config failover group_address) enable

Viewing Failover Statistics
At any time, you can view statistics for any failover group you have configured on your
system.
To view failover status:
1.

Select Statistics > System > Failover.

89

Chapter 7: Configuring the Upstream Networking
Environment

To fill requests, the SG appliance must interact not only with the local network, but
with the upstream network environment. To control upstream interaction, various
options are supported, such as forwarding, SOCKS gateways, ICP (Internet Caching
Protocol), and WCCP (Web Cache Control Protocol).


The SG appliance forwarding system—Allows you to define the hosts and groups
of hosts to which client requests can be redirected. Those hosts can be servers or
proxies, including additional appliances. Rules to redirect requests are set up in
policy.



SOCKS gateways—SOCKS servers provide application level firewall protection for
an enterprise. The SOCKS protocol provides a generic way to proxy HTTP and
other protocols. For information on configuring SOCKS gateways, see Chapter 13:
"SOCKS Gateway Configuration" on page 183.



ICP—Internet Caching Protocol (ICP) is a service to handle ICP queries from other
caching devices looking for cached data. The devices that can access this service can
be controlled. ICP can also be used by the SG appliance to locate cached data in
other systems. For information on configuring ICP, see Chapter 9: "Internet
Caching Protocol (ICP) Configuration" on page 127.



WCCP—WCCP is a Cisco®-developed protocol that allows you to establish
redirection of the traffic that flows through routers.

This chapter contains the following topics:


Section A: "Understanding Forwarding" on page 92



Section B: "Configuring Forwarding through the CLI" on page 94



Section C: "Using Forwarding Directives to Create an Installable List" on page 104



Section D: "TCP Connection Forwarding" on page 111
Note: Forwarding (TCP Connection Forwarding excluded) is configured through
the CLI or through installable lists using directives. The CLI and the directives have
been designed to be as similar as possible; the functionality is identical.

91

Volume 6: Advanced Networking
Section A: Understanding Forwarding

Section A: Understanding Forwarding
The SG appliance forwarding system allows you to represent what the upstream network
looks like to the appliance at the level of the Web addresses (URLs). Forwarding is not
concerned with the packet addressing associated with networking equipment, such as
switches, routers, and hubs. Forwarding allows you to send Web requests to something
other than the IP address specified in the URL and organize how the Web traffic flows
around the network.
The SG appliance forwarding system encompasses the use of forwarding, upstream
SOCKS gateways, load balancing, host affinity, health checks, and ICP. The SG appliance
forwarding system determines the upstream address a request is sent to and is
fundamentally tied in with all of the protocol agents, including HTTP, HTTPS, streaming,
and FTP, and the network configuration. The combination of forwarding with the policy
engine allows extremely flexible configuration and traffic management.
Note: The SG appliance forwarding system is available for HTTP, HTTPS, FTP, Windows
Media, RTSP, Telnet, and TCP tunnels.

Understanding Load Balancing
Load balancing is a way to share traffic requests among multiple upstream systems or
multiple IP addresses on a single host. Technologies used include round robin, which
selects the next system in the list, or least-connections, which selects the system with the
least number of connections among the selected group.
You can configure load balancing several ways:


For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that
host's load balancing method (round-robin, least connections, or none) is applied to
those IP addresses. The method is either explicitly set for that host or taken from the
configurable global default settings.



For groups, two load balancing choices are available:


Apply a load-balancing method to a group. The hashing option must be
specifically disabled (it is enabled by default) before you can apply the load
balancing method to a group. Without using a hash, all the IP addresses of all the
members of the group are gathered together, and the group's method is applied
across that entire set of IP addresses.



Use a hash. If you use a hash, load balancing is a two-step process:


Step one: Apply a hash, either to the domain name or the full URL. This hash
value is used to select one member of the group.



Step two: The selected host is treated just as an individual host is treated; the
only difference is that the load-balancing method configured for the group is
used for the selected host.

For more information, see “Configuring Load Balancing” on page 99.

92

Chapter 7: Configuring the Upstream Networking Environment

Section A: Understanding Forwarding

Understanding Host Affinity
Host affinity is the attempt to direct multiple connections by a single user to the same
group member. For example, a Web site uses shopping carts to allow customers to purchase
items. The site might use load balancing with a group of Web servers working in parallel,
but only one server in the group has state on a single user. If the user connections are sent
to a different server, the server has no previous state on the user and might start over.
Host affinity forces the user’s connections to return to the same server until the user is idle
for a configurable period of time. After a configurable period of inactivity, the host affinity
times out and the fact that multiple connections belong to a single user is lost.
Host affinity allows you to use any of the following options:


Use the client IP address to determine which group member was last used. When the
same client IP sends another request, the connection is made to that recorded group
member.



Place a cookie in the response to the client. When further requests are sent from the
client with the cookie, the data in the cookie is used to determine which group member
the client last used. The connection is made to that recorded group member.



For HTTPS, extract the SSL session ID name from the connection information. The
session ID is used in place of a cookie to determine which group member was last
used. The connection is made to that recorded group member.

For more information on host affinity, see “Configuring Host Affinity” on page 100.

Using Load Balancing and Host Affinity Together
By default, if you use load balancing, each connection is treated independently. That
connection is made to whichever member of the load-balancing group that the loadbalancing algorithm selects. The load balancing responsibility is to spread the connections
around as much as possible so the load is shared among group members.
If host affinity is configured, it is checked first to see if the request comes from a known
client. If this is a first connection, the load-balancing algorithm selects the group member
to target. The result of the load balancing is recorded by host affinity in its tables for use if
that client connects again.
Host affinity does not make a connection to a host that health checks report is down;
instead, if host affinity breaks, the load-balancing algorithm selects a group member that
is healthy, and affinity is re-established on that working group member.
For information on configuring host affinity, see “Configuring Host Affinity” on page 100;
for information on configuring load balancing, see “Configuring Load Balancing” on page
99.

93

Volume 6: Advanced Networking
Section B: Configuring Forwarding through the CLI

Section B: Configuring Forwarding through the CLI
Forwarding is configured through the CLI or through installable lists using directives. The
CLI and the directives have been designed to be as similar as possible; the functionality is
identical. To use installable lists to configure forwarding, see Section C: "Using
Forwarding Directives to Create an Installable List" on page 104.
High level steps to configure forwarding are:


Create the forwarding hosts and groups, including parameters such as protocol agent
and port



Edit these hosts and groups; you can create settings that override the global defaults



Create Load Balancing and Host Affinity values

Creating Forwarding Hosts and Groups
You can create a maximum of 32 groups, and each group can contain a maximum of 512
hosts. You can create 512 individual hosts that do not belong to any group. (You might
want to create individual hosts as a way of managing traffic inside an enterprise, for
example.)
The only required entries under the create command (for a host) are the host_alias,
hostname, a protocol, and a port number. The port number can be defined explicitly (such
as http=8080), or it can take on the default port value of the protocol, if one exists (such as
http, and the default port value of 80 is entered automatically).
Note: The host/group aliases cannot be CPL keywords, such as no, default, or
forward.

To create a host group, you must also include the group=group_name option. If this is the
first mention of the group, group_name, then that group is automatically created with this
host as its first member. Do not use this command when creating an independent host.
Because the functionality of the CLI and the directives is so similar, detailed instructions
are provided only for the CLI. For the list of available directives, see “Using Forwarding
Directives to Create an Installable List” on page 104.
To create the host or group:
1.

At the (config) command prompt, create a forwarding host:
SGOS#(config) forwarding
SGOS#(config forwarding) create host_alias hostname [default-schemes]
[http[=port | =no]] [https[=port | =no]] [ftp[=port | =no]] [mms[=port
| =no]] [rtsp[=port | =no]] [tcp=port] [telnet[=port | =no]] [sslverify-server[=yes | =no]] [group=group_name] [server | proxy] [loadbalance={no | round-robin | least-connections}] [host-affinity={no |
client-ip-address | accelerator-cookie}] [host-affinity-ssl={no |
client-ip-address | accelerator-cookie | ssl-session-id}]

94

Chapter 7: Configuring the Upstream Networking Environment

Section B: Configuring Forwarding through the CLI
:

Table 7-1. Commands used to Create a Forwarding Host
Command

Suboption

Description

host_alias

This is the alias for use in policy. Define a meaningful
name.

host_name

The name of the host domain, such www.bluecoat.com,
or its IP address.

default-schemes

If you select default-schemes, all protocols, along with
their default ports, are used. This directive is only
available for proxy hosts.

http

=port | =no

https
ftp

You must choose at least one protocol where port=1 to
65535. If only one protocol is configured, the SG
configures the default port for that protocol.
You can use default-schemes and then eliminate
protocols by selecting the protocol you do not want; for
example, http=no. If you do not want to use the default
ports for the protocols, you must also specify them here.

mms
rtsp
telnet

HTTPS or Telnet protocols are not allowed if the host is a
proxy.
tcp

=port

If you choose to add a TCP protocol, a TCP port must be
specified.
TCP protocols are not allowed if the host is a proxy.

ssl-verify-server

=yes | =no

You can set SSL to specify that the SG appliance checks the
CA certificate of the upstream server.
The default for ssl-verify-server is yes. To disable
this feature, you must specify ssl-verify-server=no
in the installable list or CLI.
Note that the CPL property
server.certificate.validate, if configured,
overrides this setting,

group

=group_name

Group specifies the group to which this host belongs. If
this is the first mention of the group group_name then
that group is automatically created with this host as its
first member.
The SG appliance uses load balancing to evenly distribute
forwarding requests to the origin servers or group of
proxies. Do not use the group= option when creating
independent hosts.

server | proxy

Server specifies to use the relative path for URLs in the
HTTP header because the next hop is a Web server, not a
proxy server. The default is proxy.

load-balance

no | round-robin | leastconnections

Specifies the load-balancing method: round robin or least
connections. No disables load balancing.

host-affinity

accelerator-cookie | clientip-address | no

Specifies which non-SSL host-affinity method to use
(accelerator cookie or client-ip-address) or
you can use no to disable non-SSL host affinity.

95

Volume 6: Advanced Networking
Section B: Configuring Forwarding through the CLI
Table 7-1. Commands used to Create a Forwarding Host (Continued)
Command

Suboption

Description

host-affinity-ssl

accelerator-cookie | clientip-address | ssl-session-id |
no

Specifies which SSL host-affinity method to use
(accelerator cookie, client-ip-address, or sslsession-id) or you can use no to disable SSL host
affinity.

2.
3.

Repeat Step 1 to create additional forwarding hosts or host groups.
Complete the configuration by entering the following commands as necessary:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
host_alias}
SGOS#(config
SGOS#(config

forwarding)
forwarding)
forwarding)
forwarding)

download-via-forwarding disable | enable
failure-mode closed | open
integrated-host-timeout minutes
delete {all | group group_name | host

forwarding) path url
forwarding) no path

:

Table 7-2. Commands used to Configure a Forwarding Host
Command

Suboption

Description

download-via-forwarding

enable | disable

Specifies whether forwarding (and SOCKS gateways) are to
be used or ignored when trying to download or upload
documents, including installable lists and policy files.

failure-mode

closed | open

Failing open or closed applies to forwarding hosts and
groups. Fail Open/Closed applies when the health checks
are showing sick for each forwarding target in the applicable
fail-over sequence. If no systems are healthy, the SG
appliance fails open or closed, depending on the
configuration. If closed, the connection attempt simply fails.
If open, an attempt is made to connect without using any
forwarding target. Fail open is usually a security risk; fail
closed is the default if no setting is specified.
This setting can be overridden by policy, (using the
forward.fail_open(yes|no) property).

integrated-host-timeout

minutes

An integrated host is an Origin Content Server (OCS) that
has been added to the health check list. The host, added
through the integrate_new_hosts property, ages out
after being idle for the specified time. The default is 60
minutes.

delete

all | group
group_name | host
host_alias

Deletes all forwarding hosts and groups (delete all) or a
specific forwarding group (delete group group_name)
or host (delete host host_alias).

path

url

(Optional) Path specifies the download path to use if you
download installable lists.

no

path

No clears the network path URL to download forwarding
settings.

96

Chapter 7: Configuring the Upstream Networking Environment

Section B: Configuring Forwarding through the CLI

Editing a Forwarding Host
After you create a forwarding host, you can edit its configuration.
Note: If you edit a group, you can only modify its load balancing and host affinity
settings. For information on editing a group, see “Editing a Forwarding Group” on page
99.

To edit the settings of a forwarding host:
1.

At the (config) command prompt, enter the following commands to configure the
settings of a forwarding host:
SGOS#(config) forwarding
SGOS#(config forwarding) edit host_alias
SGOS#(config forwarding host_alias) {ftp | http | https | mms | rtsp |
telnet} [port]
SGOS#(config forwarding host_alias) group group_name
SGOS#(config forwarding host_alias) host hostname
SGOS#(config forwarding host_alias) host-affinity {method
{accelerator-cookie | client-ip-address | default} | ssl-method
{accelerator-cookie | client-ip-address | ssl-session-id | default}
SGOS#(config forwarding host_alias) load-balance method {leastconnections | default | round-robin}
SGOS#(config forwarding host_alias) proxy | server
SGOS#(config forwarding host_alias) ssl-verify-server
SGOS#(config forwarding host_alias) tcp port

:

Table 7-3. Commands Used to Edit a Forwarding Host
Command

Suboption

Description

ftp | http |
https | mms |
rtsp | telnet

[port]

Adds the protocol and optional port for this host if it
was not set previously or changes the port number for
the specified protocol if it was. If you do not enter a port
number, the default port number is used.
HTTPS or Telnet protocols are not allowed if the host is
a proxy.

tcp

port

Changes the port number for the TCP protocol for this
host. You must enter a port number if you use the TCP
protocol.
TCP protocols are not allowed if the host is a proxy.

group

group_name

Changes the group membership for this host.

host

host_name

Changes this host’s name.

host-affinity

method (acceleratorcookie | client-ipaddress | default)

Sets which non-SSL host-affinity method to use
(accelerator cookie or client-ip-address) or
you can use default to specify the global method.

ssl-method (acceleratorcookie | client-ipaddress | ssl-session-id
| default}

Sets which SSL host-affinity method to use
(accelerator cookie, client-ip-address, or
ssl-session-id) or you can use default to specify
the global method.

97

Volume 6: Advanced Networking
Section B: Configuring Forwarding through the CLI
Table 7-3. Commands Used to Edit a Forwarding Host (Continued)
Command

Suboption

Description

load-balance
method

least-connections |
round-robin | default

Allows you to select the round-robin method or the
least-connections method, or specify default to
specify the global method.

proxy

Defines this host as a proxy instead of a server; any
HTTPS, Telnet, or TCP port is deleted.

server

Defines this host as a server instead of a proxy.

ssl-verify-server

Sets SSL to specify that the SG appliance checks the CA
certificate of the upstream server for this host.

2.

(Optional) Enter the following commands to negate or disable settings for this host
(only one setting can be negated at a time):
SGOS#(config forwarding
| tcp | telnet}
-orSGOS#(config forwarding
-orSGOS#(config forwarding
method}
-orSGOS#(config forwarding
-orSGOS#(config forwarding

host_alias) no {ftp | http | https | mms | rtsp

host_alias) no group
host_alias) no host-affinity (method | ssl-

host_alias) no load-balance method
host_alias) no ssl-verify-server

:

Table 7-4. Commands to Negate Forwarding Host Settings
Command

Suboption

Description

no {ftp | http | https | mms |
rtsp | tcp | telnet}

Clears the specified protocol and port
from this host.

no group

Removes this host from any and all
groups.

no host-affinity

method | ssl-method

Clears the specified method from this
host.

no load-balance

method

Clears the method from this host.

no ssl-verify-server

Disables SSL verification for this host.

Example
SGOS#(config) forwarding
SGOS#(config forwarding) edit testhost
SGOS#(config forwarding testhost) server
ok
SGOS#(config forwarding testhost) no ftp
ok
SGOS#(config forwarding testhost) exit
SGOS#(config forwarding) exit
SGOS#(config)

98

Chapter 7: Configuring the Upstream Networking Environment

Section B: Configuring Forwarding through the CLI

Editing a Forwarding Group
When you edit a group, you can change the load-balance and host-affinity settings.
To edit a group:
At the (config) command prompt, enter the following commands to configure the
settings of a forwarding host:
SGOS#(config) forwarding
SGOS#(config forwarding) edit group_alias
SGOS#(config forwarding group_alias) host-affinity {method
{accelerator-cookie | client-ip-address | default} | ssl-method
{accelerator-cookie | client-ip-address | ssl-session-id | default}
SGOS#(config forwarding group_alias) load-balance hash {domain | no |
url}
SGOS#(config forwarding group_alias) load-balance method {leastconnections | default | round-robin}
:

Table 7-5. Commands to Edit a Forwarding Group
Command

Suboption

Description

host-affinity

method (accelerator-cookie |
client-ip-address | default)

Sets which non-SSL host-affinity method to use
(accelerator cookie or client-ipaddress) or you can use default to specify
the global method.

ssl-method (acceleratorcookie | client-ip-address |
ssl-session-id | default}

Sets which SSL host-affinity method to use
(accelerator cookie, client-ipaddress, or ssl-session-id) or you can use
default to specify the global method.

hash {domain | default |
url}

If you use the hash for load balancing, you can
choose to hash the domain or the full URL or you
can use default to disable hashing, and the
load balancing method applies across a group.
Hash is enabled by default.

method {least-connections |
round-robin | default}

If you use method for load balancing, you can
select the round-robin method or the leastconnections method, or specify default to specify
the global method.

load-balance

Configuring Load Balancing
Load balancing settings can be configured globally (for all forwarding hosts and groups),
or load balancing can be configured to a host or group’s private values. These private
values override the global default settings. (For an overview of load balancing, see
“Understanding Load Balancing” on page 92.)
To set load balancing global default settings:
SGOS#(config) forwarding
SGOS#(config forwarding) load-balance hash {domain | no | url}
SGOS#(config forwarding) load-balance method {least-connections | no |
round-robin}

99

Volume 6: Advanced Networking
Section B: Configuring Forwarding through the CLI
:

Table 7-6. Commands to Set Load Balancing Global Default Settings
Command

Suboption

Description

hash

{domain | no | url}

If you use the hash for load balancing, you can choose to hash the
domain or the full URL or no to disable hashing, and the load
balancing method applies across a group. Hash is enabled by default.

method

{least-connections | no
| round-robin}

If you use method for load balancing, you can select the round-robin
method or the least-connections method, or specify no to disable load
balancing.

Note: Remember that a group must have a hash setting of no in order for the method to

apply across the entire group.
To set load balancing private values:
SGOS#(config) forwarding
SGOS#(config forwarding) load-balance hash {default | domain | no |
url} group_alias
SGOS#(config forwarding) load-balance method {default | leastconnections | no | round-robin} host_or_group_alias
:

Table 7-7. Commands to Set Load Balancing Private Values
Command

Suboption

Description

hash

{default | domain | no | url}
group_alias

You can specify a group to apply the load-balancing hash
setting to only that group. Hashing is enabled by default.

method

{default | least-connections |
no | round-robin}
host_or_group_alias

You can specify a host or group to apply the loadbalancing method to only that host or group.

Example
SGOS#(config forwarding) load-balance method least-connections testhost-name
ok

Configuring Host Affinity
Host affinity settings can be configured globally (for all forwarding hosts and groups), or
the settings can be configured fort a host or group’s private values. These private values
override the global default settings. (For an overview of host affinity, see “Understanding
Host Affinity” on page 93.)
The non-SSL host affinity methods are implemented for HTTP only; SSL host affinity
methods are implemented for HTTPS only.

100

Chapter 7: Configuring the Upstream Networking Environment

Section B: Configuring Forwarding through the CLI
To configure global default host affinity settings:
SGOS#(config) forwarding
SGOS#(config forwarding) host-affinity method {accelerator-cookie |
client-ip-address | no}
-orSGOS#(config forwarding) host-affinity ssl-method {accelerator-cookie
| client-ip-address | ssl-session-id | no}
SGOS#(config forwarding) host-affinity timeout minutes

where:
method

{accelerator-cookie |
client-ip-address | no}

Sets which non-SSL host-affinity
method to use (accelerator cookie
or client-ip-address) or you can
use no to disable non-SSL host affinity.

ssl-method

{accelerator-cookie |
client-ip-address | sslsession-id | no}

Sets which SSL host-affinity method to
use (accelerator cookie, clientip-address, or ssl-session-id) or
you can use no to disable SSL host
affinity.

timeout

minutes

Determines how long a user's IP
address, SSL ID, or cookie remains
valid.

To configure host- or group-specific host affinity settings:
SGOS#(config) forwarding
SGOS#(config forwarding) host-affinity method {accelerator-cookie |
client-ip-address | default | no} host_or_group_alias
-orSGOS#(config forwarding) host-affinity ssl-method {accelerator-cookie
|
client-ip-address | default | no} host_or_group_alias
:

Table 7-8. Commands to Configure Host- or Group-Specific Host Affinity Settings
Command

Suboptions

Description

method

{accelerator-cookie |
client-ip-address |
default | no}
host_or_group_alias

You can choose which non-SSL host-affinity method to use
(accelerator cookie or client-ip-address) for a
specific host or group, or you can use no to disable non-SSL
host affinity for a specific host or group. You can also apply
the global non-SSL host-affinity method to a specific host or
group.

ssl_method

{accelerator-cookie |
client-ip-address |
default | no | sslsession-id}
host_or_group_alias

You can choose which SSL host-affinity method to use
(accelerator cookie, client-ip-address, or sslsession-id) for a specific host or group, or you can use no
to disable SSL host affinity for a specific host or group. You
can also apply the global SSL host-affinity method to a
specific host or group (use the default command).

101

Volume 6: Advanced Networking
Section B: Configuring Forwarding through the CLI
Example
SGOS#(config forwarding) host-affinity method client-ip-address
ok
SGOS#(config forwarding) host-affinity ssl-method no test-group-name
ok
SGOS#(config forwarding) host-affinity timeout 45
ok

Creating a Default Sequence
The default sequence defines the order in which forwarding hosts are used in case of
failover and which host to use first (only one default sequence is allowed). If you create a
default sequence, forwarding is applied, by default, to all requests. All members must be
pre-existing hosts and groups, and no member can be in the group more than once.
Note: Creating a default sequence through the CLI is a legacy feature. Creating a default

sequence can be done much more efficiently through policy—VPM or CPL—than it can
through the CLI. The default sequence (if present) is applied only if no applicable
forwarding gesture is in policy.
For information on using VPM, refer to Volume 7: VPM and Advanced Policy; for
information on using CPL, refer to Volume 11: Content Policy Language Guide. For
information on using forwarding with policy, see Appendix B: "Using Policy to Manage
Forwarding" on page 207.
A default failover sequence (and any sequence specified in policy) works by allowing
healthy hosts to take over for an unhealthy host (one that is failing its DNS Resolution or
its health check). The sequence specifies the order of failover, with the second host taking
over for the first host, the third taking over for the second, and so on.
Note: In normal circumstances, only the first member of the sequence is ever used.

If all hosts are unhealthy, the operation fails either open or closed, depending upon your
settings.
This configuration is generally created and managed through policy. If no forwarding
policy applies, you can create a default sequence through the CLI. This single default
sequence consists of a single default host (or group) plus one or more hosts to use if the
preceding ones are unhealthy.
To create a default sequence:
From the (config) prompt, enter the following commands:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

forwarding)
forwarding)
forwarding)
forwarding)
forwarding)

sequence
sequence
sequence
sequence
sequence

add alias_name
clear
demote alias_name
promote alias_name
remove alias_name

:

Table 7-9. Commands to Create a Default Sequence
Command

Suboptions

Description

add

alias_name

Adds an alias to the end of the default failover sequence.

102

Chapter 7: Configuring the Upstream Networking Environment

Section B: Configuring Forwarding through the CLI
Table 7-9. Commands to Create a Default Sequence (Continued)
Command

Suboptions

Description
Clears the default failover sequence.

clear
demote

alias_name

Moves an alias one place towards the end of the default failover
sequence.

promote

alias_name

Moves an alias one place towards the start of the default failover
sequence.

remove

alias_name

Removes an alias from the default failover sequence.

Example
SGOS#(config forwarding) sequence clear
ok
Note: Any host or group in the default sequence is considered in use by policy. As a
result, if you try to delete a host or group while it is in the default sequence, you receive an
error message. You must remove the host/group from the sequence first, then delete.

103

Volume 6: Advanced Networking
Section C: Using Forwarding Directives to Create an Installable List

Section C: Using Forwarding Directives to Create an Installable List
You can use either directives or the CLI #inline forwarding command to create and
configure forwarding hosts. To use the CLI to configure forwarding hosts, see Section A:
"Understanding Forwarding" on page 92.
The forwarding configuration includes directives that:


Create the forwarding hosts and groups



Provide load balancing and host affinity

Table 7-10. Forwarding Directives
Directive

Meaning

See

fwd_fail

Determines whether the forwarding host
should fail open or fail closed if an operation
does not succeed. Fail open is a security risk.

“Setting Fail Open/Closed and
Host Timeout Values” on page
106.

fwd_host

Create a forwarding host and set
configuration parameters for it, including
protocols and ports.

“Creating Forwarding Host and
Group Directives” on page 104.

host_affinity

The attempt to direct multiple connections by
a single user to the same group member.

“Configuring Host Affinity
Directives” on page 107.

integrated_host_
timeout

An origin content server that has been added
to the health check list is called an integrated
host. The host ages out after being idle for the
specified time.

“Setting Fail Open/Closed and
Host Timeout Values” on page
106.

load_balance

The attempt to manage the load among
forwarding hosts in a group, or among
multiple IP addresses of a host.

“Configuring Load Balancing
Directives” on page 107.

sequence alias_list

where alias_list is a space separated list
of one or more forwarding host and group
aliases.

“Creating a Default Sequence” on
page 108.

Creating Forwarding Host and Group Directives
You can add directives into the forwarding installable list that allows you to create and
delete the forwarding host and associate protocols and ports with the host.
You can create a maximum of 32 groups, and each group can contain a maximum of 512
hosts. You can create 512 individual hosts that do not belong to any group.
To create a forwarding host, choose the protocols you want to use, or optionally add the
forwarding host to a group, enter the following into your installable list. Create a
fwd_host directive for each forwarding host you want to create.
fwd_host host_alias hostname [default-schemes] [http[=port | =no]]
[https[=port | =no]] [ftp[=port | =no]] [mms[=port | =no]] [rtsp[=port
| =no]] [tcp=port] [telnet[=port | =no]] [ssl-verify-server[=yes |
=no]] [group=group_name] [server | proxy] [load-balance={no | roundrobin | least-connections}] [host-affinity={no | client-ip-address |
accelerator-cookie}] [host-affinity-ssl={no | client-ip-address |
accelerator-cookie | ssl-session-id}]

104

Chapter 7: Configuring the Upstream Networking Environment

Section C: Using Forwarding Directives to Create an Installable List
:

Table 7-11. Commands to Create Forwarding Host and Group Directives
host_alias

This is the alias for use in policy. Define a name meaningful to
you.

host_name

The name of the host domain, such www.bluecoat.com, or its
IP address.

default-schemes

If you use default-schemes in the directive, all protocols, along
with their default ports are selected. This directive is only
available for proxy hosts.

http

=port | =no

https
ftp
mms

No protocol is selected by default if the forwarding host is a
server. You must choose at least one protocol where port=0 to
65535. If only one protocol is configured, the SG configures the
default port for that protocol.
You can use default-schemes and then eliminate protocols
by selecting the protocol you do not want; for example,
http=no. If you do not want to use the default ports for the
protocols, you must also specify them here.

rtsp
telnet

HTTPS protocols are not allowed if the host is a proxy.
tcp

=port

If you choose to add a TCP protocol, a TCP port must be
specified.
TCP protocols are not allowed if the host is a proxy.

ssl-verifyserver

=yes | =no

Sets SSL to specify that the SG appliance checks the CA
certificate of the upstream server.
The default for ssl-verify-server is yes. To disable this
feature, you must specify ssl-verify-server=no in the
installable list or CLI. In other words, you can configure sslverify-server=yes in three ways: do nothing (yes is the
default), specify ssl-verify-server, or specify sslverify-server=yes.

group

=group_name

Specifies the group (or server farm or group of proxies) to
which this host belongs. If this is the first mention of the group
group_name then that group is automatically created with this
host as its first member.
The SG appliance uses load balancing to evenly distribute
forwarding requests to the origin servers or group of proxies.
Do not use the group= option when creating independent
hosts.

server | proxy

server specifies to use the relative path for URLs in the HTTP
header because the next hop is a Web server, not a proxy server.
The default is proxy.

105

Volume 6: Advanced Networking
Section C: Using Forwarding Directives to Create an Installable List
Table 7-11. Commands to Create Forwarding Host and Group Directives (Continued)
load-balance

=no | =round-robin |
=least-connections

Specifies either the least-connections or round-robin method of
load balancing. Select no to disable load balancing for this
forwarding host or host group.
If these settings are not specified for a particular host or host
group, then the global default settings are used. To configure
the settings for a specific host or host group, use the edit
host_alias or edit group_alias commands (see “Editing
a Forwarding Host” on page 97 or “Editing a Forwarding
Host” on page 97).

host-affinity

=no | =client-ipaddress |
=accelerator-cookie

Specifies non-SSL host affinity via either a client IP address or
an accelerator cookie. Select no to disable non-SSL host affinity
for this forwarding host or host group.
If these settings are not specified for a particular host or host
group, then the global default settings are used. To configure
the settings for a specific host or host group, use the edit
host_alias or edit group_alias commands (see “Editing
a Forwarding Host” on page 97 or “Editing a Forwarding
Group” on page 99).

host-affinityssl

=no | =client-ipaddress |
=accelerator-cookie
| =ssl-session-id

Specifies SSL host affinity via a client IP address, an accelerator
cookie, or an SSL session ID. Select no to disable SSL host
affinity for this forwarding host or host group.
If these settings are not specified for a particular host or host
group, then the global default settings are used. To configure
the settings for a specific host or host group, use the edit
host_alias or edit group_alias commands (see “Editing
a Forwarding Host” on page 97 or “Editing a Forwarding
Group” on page 99).

Example
fwd_host www.bluecoat1.com 10.25.36.48 default-schemes ssl-verifyserver=no group=bluecoat

Setting Fail Open/Closed and Host Timeout Values
Using directives, you can determine if the forwarding host fails open or closed, if an
operation does not succeed, and the interval it takes for integrated hosts to be aged out.
An integrated host is an Origin Content Server (OCS) that has been added to the health
check list. If the policy property integrate_new_hosts applies to a forwarding request,
the SG appliance makes a note of each OCS and starts health checking to help future
accesses to those systems. If the host is idle for the interval you specify, it is aged out. Sixty
minutes is the default.
The syntax is:
fwd_fail {open | closed}
integrated_host_timeout minutes

106

Chapter 7: Configuring the Upstream Networking Environment

Section C: Using Forwarding Directives to Create an Installable List
Table 7-12. Commands to Set Fail Open/Closed and Host Timeout Values
fwd_fail

{open |
closed}

Determines whether the forwarding host should fail open
or fail closed if an operation does not succeed. Fail open is a
security risk, and fail closed is the default if no setting is
specified.
This setting can be overridden by policy, (using the
forward.fail_open(yes|no) property).

integrated_host_timeout

minutes

An OCS that has been added to the health check list is called
an integrated host. The host ages out after being idle for the
specified time.

Examples
fwd_fail open
integrated_host_timeout 90

Configuring Load Balancing Directives
Load balancing shares the load among a set of IP addresses, whether a group or a host
with multiple IPs.
The syntax is:
load_balance hash {domain | no | url} [group_alias]
load_balance method {least-connections | round-robin | no}
[host_or_group_alias]
Table 7-13.

Load Balancing Directives

Command

Suboptions

Description

hash

{domain | no | url}
[group_alias]

If you use the hash for load balancing, you can hash the domain
or the full URL, or you can enter no to disable hashing and the
load-balancing method applies across a group. If you do not
specify a group, the settings apply as the default for all groups.

method

{least-connections | no |
round-robin}
[host_or_group_alias]

If you use method for load balancing, you can select the
least-connections method or the round-robin method,
or you can specify no to disable load balancing (hashing still
occurs if it is set). If you do not specify a host or group, the
settings apply as the default for all hosts or groups.

Example
load_balance method least_connections

Configuring Host Affinity Directives
Host affinity is the attempt to direct multiple connections by a single user to the same
group member.
The syntax is:
host_affinity method {accelerator-cookie | client-ip-address | no}
[host_or_group_alias]
host_affinity ssl_method {accelerator-cookie | client-ip-address | no
| ssl-session-id} [host_or_group_alias] host_affinity timeout seconds

107

Volume 6: Advanced Networking
Section C: Using Forwarding Directives to Create an Installable List

Table 7-14. Commands to Configure Host Affinity Directives
Command

Suboption

Description

method

{accelerator-cookie |
client-ip-address | no}
[host_or_group_alias]

Determines which non-SSL host-affinity method to use
(accelerator cookie or client-ip-address), or you
can use no to disable non-SSL host affinity. If you do not
specify a host or group, the settings apply as the default for all
hosts or groups.

ssl_method

{accelerator-cookie |
client-ip-address | no |
ssl-session-id}
[host_or_group_alias]

Determines which SSL host-affinity method to use
(accelerator cookie, client-ip-address, or sslsession-id), or you can use no to disable SSL host affinity. If
you do not specify a host or group, the settings apply as the
default for all hosts or groups.

timeout

minutes

Determines how long a user's IP address, SSL ID, or cookie
remains valid.

Example
host_affinity ssl_method 10.25.36.48
host_affinity timeout 5

Creating a Default Sequence
A default sequence defines the order in which forwarding hosts are used. Only one
default sequence is allowed. All members must be pre-existing hosts and groups, and no
member can be in the group more than once.
Note: The default sequence is completely overridden by policy.

A default failover sequence works by allowing healthy hosts to take over for an unhealthy
host (one that is failing its DNS Resolution or its health check). The sequence specifies the
order of failover, with the second host taking over for the first host, the third taking over
for the second, and so on).
If all hosts are unhealthy, the operation fails either open or closed, depending upon your
settings.
This configuration is generally created and managed through policy. If no forwarding
policy applies, you can create a default sequence through the CLI. This single default
sequence consists of a single default host (or group) plus one or more hosts to use if the
preceding ones are unhealthy.
The syntax is:
sequence alias_list alias_list

where alias_list is a space-separated list of one or more forwarding host and group
aliases.

Example
sequence bluecoat

108

Chapter 7: Configuring the Upstream Networking Environment

Section C: Using Forwarding Directives to Create an Installable List

Creating a Forwarding Installable List
You can create and install the forwarding installable list using one of the following
methods:


Text Editor, which allows you to enter the installable list of directives (or copy and
paste the contents of an already-created file) directly onto the appliance.



A local file, created on your system; the SG appliance can browse to the file and install
it.



A remote URL, where you placed an already-created file on an FTP or HTTP server to
be downloaded to the SG appliance.



CLI inline command.

When the Forwarding Installable List is installed, it updates the forwarding directives on
the SG appliance. The directives remain in effect until they are overwritten by another
installable list; the list can be modified or overwritten using CLI commands.
Note: During the time that a forwarding installable list is being compiled and installed,
forwarding is not available. Any transactions that come into the SG appliance during this
time are not forwarded properly and are denied.

Installation of forwarding installable lists should be done outside peak traffic times.
To create a forwarding installable list:
1.

Select Configuration > Forwarding > Forwarding Hosts.

2.

From the drop-down list, select the method to use to install the forwarding installable
list; click Install.
Note: A message is written to the event log when you install a list through the SGOS
software.



Remote URL:
Enter the fully-qualified URL, including the filename, where the installable list is
located. To view the file before installing it, click View. Click Install. Examine the
installation status that displays; click OK.



Local File:
Click Browse to display the Local File Browse window. Browse for the installable
list file on the local system. Open it and click Install. When the installation is
complete, a results window opens. View the results, close the window, click Close.



Text Editor:

The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the installation is
complete, a results window opens. View the results, close the window, click Close.
Note: The Management Console text editor is a way to enter an installable list

for forwarding. It is not a way to enter CLI commands. The directives are
understood only by the installable list parser for forwarding.

109

Volume 6: Advanced Networking
Section C: Using Forwarding Directives to Create an Installable List
3.

Click Apply.

Note: You can create forward settings using the CLI #inline forwarding command.

You can use any of the forwarding directives, but host affinity and load balancing are
mutually exclusive.
For more information on using inline commands, refer toVolume 12: Command Line
Reference: “Chapter 2: Standard and Privileged Commands”.
To delete forwarding settings on the SG appliance:
From the (config) prompt, enter the following commands to delete a host, a group, or
all hosts and groups from the forwarding configuration:
SGOS#(config) forwarding
SGOS#(config forwarding) delete {all | group group_name | host
host_alias}
Note: Any host or group in the default sequence is considered in use by policy. As a
result, if you try to delete a host or group while it is in the default sequence, you receive an
error message. You must remove the host/group from the sequence first, then delete.

110

Chapter 7: Configuring the Upstream Networking Environment

Section D: TCP Connection Forwarding

TCP Configuration Forwarding Deployment Notes
When configuring your network for TCP connection forwarding, consider the following:


Peers can be added to clusters at any time without affecting the performance of the
other peers. An SG appliance that joins a peer cluster immediately contacts every other
peer in the cluster. Likewise, a peer can leave a cluster at anytime. This might be a
manual drop or a forced drop because of a hardware or software failure. If this
happens, the other peers in the cluster continue to process connection forwarding
requests.



Connections between peers are not encrypted and not authenticated. If you do not
assign the correct local IP address on an SG appliance with multiple IP addresses,
traffic sent peer to peer might be routed through the Internet, not the intranet,
exposing your company-sensitive data.



The peering port—the connection between SG appliance connection forwarding
peers—cannot be configured with bypass services. This means an SG appliance cannot
be deployed in transparent mode between two SG appliances that are peers.



SG does not enforce a maximum number of appliances a peer cluster supports, but
currently the deployment is designed to function with up to 20 SG appliances.



Because TCP connection forwarding must function across different network segments,
employing multicasting, even among SG appliance peers on the same network, is not
supported.



There might be a slight overall performance impact from enabling TCP connection
forwarding, especially in deployments where traffic is largely already being routed to
the correct SG appliance. If a substantial amount of traffic requires forwarding, the
performance hit is equitable to processing the same amount of bridging traffic.

Configuring TCP Connection Forwarding
As described in the previous concept sections, enabling TCP connection forwarding
provides one component to a larger deployment solution. After you have deployed Blue
Coat appliances into the network topography that best fits your enterprise requirements,
enable TCP connection forwarding on each Blue Coat appliance that is to belong to the
peering cluster, and add the IP address of the other peers. The peer lists on all of the
cluster members must be the same, and an SG appliance cannot have a different local peer
IP address than what is listed in another peers list. A peer list can contain only one local IP
address.
To enable TCP Connection Forwarding:
1.

Select Configuration > Network > Advanced > Connection Forwarding.

115

Chapter 7: Configuring the Upstream Networking Environment

Section D: TCP Connection Forwarding

Removing a Peer
A network change or other event might require you to remove a peer from the cluster.
Highlight a peer IP address and click Remove. The peer connection is terminated and all
connections associated with the peer are removed from the local system.
Note: A CLI command is available that allows you to disable a peer, which terminates
the communication with other peers, but does not remove the peer from the cluster. See
the next section.

Related CLI Syntax to Configure TCP Connection Forwarding


To enter configuration mode:
SGOS# (config) connection-forwarding



The following subcommands are available:
SGOS#
SGOS#
SGOS#
SGOS#
SGOS#



(config
(config
(config
(config
(config

connection
connection
connection
connection
connection

forwarding)
forwarding)
forwarding)
forwarding)
forwarding)

add ip_address
port number
[enable | disable]
[clear | remove ip_address]
[view | exit]

The following configuration and statistics commands are available:
SGOS# show connection-forwarding configuration
SGOS# show connection-forwarding statistics

117

Volume 6: Advanced Networking

118

Chapter 8: Health Checks

This chapter discusses health checks for services and hosts and describes how to
configure the SG appliance.

About General Health Checks
The SG appliance can perform health checks on a forwarding host or external server
that is providing a service. The supported server types are HTTP, HTTPS, ICAP,
Websense (off-box), and SOCKS gateways, Layer-3, and Layer 4 forwarding hosts.
When a health check reports a target as sick, this allows a much quicker failure for a
connection attempt than might otherwise occur. The health check also drives the failover mechanisms in the forwarding groups, external service groups, and forwarding
policy sequences.
Based on the health check type, the SG appliance periodically verifies the health status,
and thus the availability, of the host. The time interval between checks is configurable.
If the health check is successful, the appliance considers the host available. If the initial
health check is not successful for a host, the SG appliance retries, using the number of
consecutive successes or failures meet the configured thresholds to trigger a change of
health check state.
If the health check is not successful for every server in a domain, stale content might be
served, depending on the SG configuration.
The following table describes the types of health checks.
Table 8-1. Health Check Types
Health Check Type

Description

HTTP

Use this type to confirm that the host can fulfill a content
request over HTTP by the SG appliance. The appliance
accepts only a 200 OK as a healthy response.

Criterion for success

The SG appliance fetches the object.

Criterion for failure

The SG appliance cannot fetch the object.

HTTPS

Use this type to confirm that the host can fulfill a content
request over HTTPS by the SG appliance. The appliance
accepts only a 200 OK as a healthy response.

Criterion for success

The SG appliance fetches the object.

Criterion for failure

The SG appliance cannot fetch the object.

Layer-3 health check

Use this type to confirm the basic connection between the SG
appliance and the origin server. The server must recognize
ICMP echoing. The SG appliance sends a ping (three Internet
Control Message Protocol [ICMP] echo requests) to the host.

Criterion for success

The SG appliance receives at least one ICMP echo reply.

Criterion for failure

The SG appliance does not receive a single ICMP echo reply.

119

Volume 6: Advanced Networking

Table 8-1. Health Check Types (Continued)
Health Check Type

Description

Layer-4 health check

Use this type to confirm that the SG appliance can connect to
the host HTTP and FTP ports. The SG appliance attempts to
establish a TCP connection to an HTTP port or FTP port on
the host.

Criterion for success

The SG appliance establishes the connection to the defined
port (of any type), then closes it. For global forwarding
checks, the first defined port in the forwarding host port list
is used for the attempt (except for SOCKS gateways, in
which the SOCKS port is used).

Criterion for failure

The SG appliance cannot establish the connection.

ICAP health check and
Websense 4 off-box

Requests are not sent to sick services. If a health check
determines the service is healthy, requests resume.

Configuring Service-Specific Health Checks
This section describes how to create a health check service for a specific host (for example,
an ICAP server). A failed health check results in administrator notification; however, no
action is taken to control any traffic.
To configure health checks:
Part 1: General Tasks
This part of the procedures is the same for all health check types.
1.

Select Configuration > Health Checks > General.

2.

Click New.

3.

In the Add Health Check dialog, specify a name for the health check service; click OK.

4.

In the Health Check list, select the newly created service and click Edit.

120

Volume 6: Advanced Networking

2.

Configure the options:
a.

3.

Select the health check type:


Forwarding—HTTP, HTTPS, Layer-3, or Layer-4.



SOCKS Gateway—Layer-3 or Layer-4.

b.

(HTTP/HTTPS option only) Object name—Enter a relative URL (path) to test a
server or enter a full URL, (including scheme and hostname) to test a proxy.
A full URL scheme must match the HTTP or HTTPS test to be accepted. If the
test is performed on a mix of servers and proxies, the health check attempts to
make up a full URL out of the path and make a path out of the full URL, as
required. For a proxy, enter the full URL of the upstream target. If you have a
mixture of servers and proxies, the full URL to work for them and the path of
the URL to still be reasonable for the servers.

c.

Specify the interval, in seconds, between health checks. The default is 60.

d.

Specify the failure count, which specifies the number of sequential failures
before the host is considered down. The default is 5.

Select Apply to commit the changes to the SG appliance.

Pausing or Resuming Global Health Checking
You can temporarily halt global health checks and resume when ready. This is helpful if
the SG appliance must be temporarily taken out of service.
Note: If the health check is paused, the state remains paused until the resume option is
invoked. The paused state remains even after a reboot.

To pause or resume health checking:
1.

Select Configuration > Health Checks > Forwarding or SOCKS Gateway.

2.

Click Pause.

3.

To resume health checks, click Resume.

Related CLI Syntax to Manage Health Checks


To enter configuration mode:
SGOS#(config) health-check
SGOS#(config health-check)



The following subcommands are available:
SGOS#(config health-check) forwarding type {http | https | layer-3 |
layer-4}
SGOS#(config health-check) forwarding interval seconds
SGOS#(config health-check) forwarding failcount count
SGOS#(config health-check) socks-gateways type {layer-3 | layer-4}
SGOS#(config health-check) socks-gateways interval seconds
SGOS#(config) health-check) socks-gateways failcount count
SGOS#(config) health-check) {forwarding | socks-gateway} {pause |
resume}
SGOS#(config health-check) create name
SGOS#(config health-check) edit name

124

Chapter 8: Health Checks

SGOS#(config health-check name) type {layer-3 | layer-4 | http | https
| icap | websense-offbox}
SGOS#(config health-check name) type parameter
SGOS#(config) health-check name) perform-health-check

125

Volume 6: Advanced Networking

126

Chapter 9: Internet Caching Protocol (ICP) Configuration

ICP is a communication protocol for caches. It allows a cache (not necessarily a SG
appliance) to query other caches for an object, without actually requesting the object. By
using ICP, the cache can determine if the object is available from a neighboring cache,
and which cache provides the fastest response.
Note: The SG appliance (assuming ICP is configured) does ICP queries only if no
forwarding host or SOCKS gateway is identified as an upstream target. If ICP is used by
the appliance, it prompts other cache devices for the item, and upon a positive response
re-directs the upstream request to that cache device instead of the content origin server.

Only use ICP if you have ICP hosts available or to have the SG appliance support
requests from other ICP hosts.
By default, the ICP protocol requires the requesting host to wait up to two seconds for
all ICP hosts to respond to the request for an object (the time is configurable).
If the ICP service is configured and running, the service is used if no forwarding or
SOCKS gateway target was specified. In other words, the policy rule icp(yes) is the
default, assuming that the ICP service is available. You can disable ICP with the policy
rule icp(no) to control ICP queries for requests.

Configuring ICP
An ICP hierarchy is comprised of a group of caches, with defined parent and sibling
relationships. A cache parent is one that can return the object if it is in the cache, or
request the object from the source on behalf of the requester if the object is not in the
cache. A cache sibling is a device that can only return the object if it is in the cache. One
cache acting as a parent can also act as a sibling to other cache devices.


When an object is not cached, the cache device sends an ICP query to its neighbors
(parents and siblings) to see if any of its peers holds the object.



Each neighbor that holds the requested object returns an ICP_HIT reply.



Each neighbor that does not hold the object returns an ICP_MISS reply.

Based on the responses, the cache can determine where to request the object: from one
of its neighbors or from the source. If an ICP_HIT reply is received, the request is sent to
the host that returned the first reply. If no ICP_HIT reply is received, the request is
forwarded to the first parent that replied. If no parents respond or are configured, the
request is made directly to the source.

Using ICP Configuration Directives to Create an Installable List
To configure ICP you must create an installable list and load it on the SG appliance. The
ICP protocol contains a number of directives, commands used to create a list that can be
installed on the SG appliance.
For information on installing the file itself, see “Creating an ICP Installable List” on
page 81.
The ICP configuration includes directives that:

127

Volume 6: Advanced Networking



Name the ICP hosts



Restrict ICP access to only these hosts

Available directives are listed in Table 9-1.
Table 9-1. ICP Directives
Directive

Meaning

Where used

icp_host

The icp_host directive describes cache peers in the
hierarchy. There should be one entry for each SG
appliance you want to use.

“Naming the IP Hosts” on
page 129.

icp_access_ domain

The icp_access_domain directive is used to control
which ICP queries are accepted. The
icp_access_domain directive requires a reverse DNS
lookup of each ICP query to validate the IP address.

Names the ICP hosts. See

Restricts access. See

“Restricting Access” on
page 129.

The icp_access_ip directive works like the
icp_access_domain command, except that you can
specify an IP address and subnet mask rather than a
domain.

See “Restricting Access” on
page 129.

icp_port

The icp_port directive sets the port the SG appliance
uses to listen for ICP requests. The default port is 3130.
If you set the port to 0, ICP is disabled.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

neighbor_timeout

The neighbor_timeout directive sets the number of
seconds the SG appliance waits for ICP replies. When
the cache device sends an ICP request, it waits for all
hosts to reply or for the neighbor_timeout to expire.
The default timeout is two seconds.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

icp_failcount

The icp_failcount directive sets the number of
consecutive failures the cache device can receive before
considering the ICP host as failed. By default, the ICP
failure count is set to 20. Each time a request fails, the
failure count is incremented. When a request succeeds,
the failure count is reset to zero.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

http_failcount

The http_failcount directive sets the number of
consecutive failures the cache device can receive before
considering the HTTP host as failed. By default, the
HTTP failure count is set to five. The failure count
increments each time a request fails. When a request
succeeds, the failure count is reset to zero. When an
HTTP host fails, the cache device waits five minutes
before attempting to use it again as a forwarding target.
If the next request fails, the cache device continues to
wait five minutes between attempts until the cache
becomes available.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

host_fail_notify

The host_fail_notify directive tells the cache
device to send event notification e-mail when a connect
fails persistently.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

host_recover_
notify

The host_recover_notify directive tells the cache
device to send event notification e-mail when a failed
host recovers.

Connects to other ICP hosts.
See “Connecting to Other
ICP Hosts” on page 131.

icp_access_ip

Restricts access.

128

Chapter 9: Internet Caching Protocol (ICP) Configuration

Naming the IP Hosts
The icp_host directive describes peers in the hierarchy. One entry is required for each SG
appliance you want to use.
icp_host hostname peertype HTTPport ICPport [default | backup |
feeder]
Table 9-2. ICP_host Directive
Command

Suboptions

The host name of the SG appliance.

hostname
peertype

Description

{parent |
sibling}

Relationship of the SG appliance to the cache device you are configuring.

HTTPport

TCP port where the SG appliance accepts HTTP requests. The common HTTP
port is 80 or 8080.

ICPport

UDP port where the SG appliance accepts ICP requests. The common ICP port
is 3130.

default

If specified, designates a SG host parent to be the default ICP parent. If no ICP
reply is received, all requests are forwarded to the default parent.

backup

If specified, designates the cache device host parent to be the backup default
ICP parent. If the default parent is not available, the cache device uses the
backup default parent.

feeder

If specified, designates the SG host sibling as a feeder-type host, using ICP
request loops to populate the appliance.

The following are sample icp_host directives that can be entered into the ICP
configuration:
; Define
icp_host
icp_host
icp_host
icp_host
icp_host

ICP parent and sibling hosts.
cm1.bluecoat.com parent 8080 3130 default
cm2.bluecoat.com sibling 8080 3130
cm3.bluecoat.com sibling 8080 3130
cm4.bluecoat.com sibling 8080 3130
cm5.bluecoat.com parent 8080 3130

Restricting Access
You can restrict access to SG appliances acting as caches by other ICP hosts using the
icp_access_domain and icp_access_ip directives. By default, when ICP is configured,
all ICP hosts are allowed access. You should deny access to all domains other than the ICP
hosts you want to use.

icp_access_domain Directive
The icp_access_domain directive defines which hosts can request objects from the Web
cache using ICP. The default action is to allow all requests. When you use
icp_access_domain, each ICP query requires a reverse DNS lookup to validate the IP
address. Depending on the number of ICP requests, these lookups can consume SG
appliance resources.
icp_access_domain {allow | deny} domain

129

Volume 6: Advanced Networking

Table 9-3. ICP_Access_Domain Directive
Directive Option

Description

allow | deny

Allows or denies ICP queries from neighbors that match the domain
specification.

domain

The domain to match. All ICP queries from neighbors that match the
specified domain are handled by the host. The special domain of all
defines the default action when there is no domain match.

The following are sample icp_access_domain directives to be entered into the
ICP configuration:
; allow ICP access to this Blue Coat Systems ProxySG Appliance from
the
; bluecoat.com domain
icp_access_domain allow bluecoat.com
icp_access_domain deny all
; the deny all option should always be specified to deny all other
; domains

icp_access_ip Directive
The icp_access_ip directive works like the icp_access_domain command, except that
you can specify an IP address and subnet mask rather than a domain. The following
describes the parameters for the icp_access_ip command:
icp_access_ip {allow | deny} subnet mask
Table 9-4. ICAP_Access_IP Directive
Directive Option

Description

allow | deny

Allow or deny ICP queries from neighbors that match the address
specification.

address/subnet mask

The address and subnet mask to match. All ICP queries that match
the specified address are handled by the ICP host. The special
address of 0.0.0.0 defines the default action when there is no
address match.

The following are sample icp_access_ip directives to be entered into the ICP
configuration:
; allow ICP access to this Blue Coat Systems ProxySG Appliance from
the local subnet
icp_access_ip allow 192.168.10.0/255.255.255.0
icp_access_ip deny 10.25.36.47
; the deny all option should always be specified to deny all other
domains

130

Chapter 9: Internet Caching Protocol (ICP) Configuration

Connecting to Other ICP Hosts
In addition to the ICP directives described in the sections above, you can specify the
following directives in the ICP configuration:
icp_port 0
neighbor_timeout 2
icp_failcount 20
http_failcount 5
host_fail_notify on
host_recover_notify on
Table 9-5. Connecting to Other ICP Hosts
Directive

Description

icp_port

The default port is 3130. If you set the port to 0, ICP is disabled.

neighbor_timeout

When the cache device sends an ICP request, it waits for all hosts to
reply or for the neighbor_timeout to expire. The default timeout is
two seconds.

http_failcount

By default, the HTTP failure count is set to five. The failure count
increments each time a request fails. When a request succeeds, the
failure count resets to zero. When an HTTP host fails, the cache device
waits five minutes before attempting to use it again as a forwarding
target.

icp_failcount

By default, the ICP failure count is set to 20. Each time a request fails,
the failure count is incremented. When a request succeeds, the failure
count is reset to zero.

host_fail_notify

on tells the cache to send event notification e-mail when a connect fails
persistently; off disables this setting.

host_recover_
notify

on tells the cache to send event notification e-mail when a failed host
recovers; off disables this setting.

Creating an ICP Installable List
You can create the ICP installable list using one of the following methods:


Text Editor, which allows you to enter directives (or copy and paste the contents of an
already-created file) directly onto the SG appliance.



Local file, installed on your system; the SG appliance can browse to the file and install
it.



A remote URL, where you place an already-created file on an FTP or HTTP server to be
downloaded to the SG appliance.



The CLI inline command.

When the ICP installable list is created and installed, it overwrites any ICP settings on the
SG appliance.
To create an ICP installable list:
1.

Select Configuration > Forwarding > ICP.

2.

From the drop-down list, select the method you want to use to install the ICP
configuration; then click Install.

131

Volume 6: Advanced Networking



Remote URL:
Enter the fully-qualified URL, including the filename, where the configuration is
located. To view the file before installing it, click View. Click Install. Examine the
installation status that displays; click OK.



Local File:
Click Browse to bring up the Local File Browse window. Browse for the file on the
local system. Click Install. When the installation is complete, a results window
opens. View the results, close the window, click Close.



Text Editor:

The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the installation is
complete, a results window opens. View the results, close the window, click Close.
3.

Select Apply to commit the changes to the SG appliance.

Note: You can create ICP settings using the CLI inline commands.

For more information on using inline commands, refer to Volume 12: Command Line
Reference.

Enabling ICP
Before ICP can be used in the SG environment:


ICP must be running



At least one forwarding host must be configured

ICP can be enabled or disabled through the policy rule icp.The default is icp(yes). You
can disable ICP with the policy rule icp(no) to control ICP queries for requests.

132

Chapter 10: Using RIP

The Routing Information Protocol (RIP) is designed to select the fastest route to a
destination. RIP support is built into the SG appliance, and is configured by created and
installing an RIP configuration text file onto the device.
The Blue Coat RIP implementation also supports advertising default gateways. Default
routes added by RIP are treated the same as the static default routes; that is, the default
route load balancing schemes apply to the default routes from RIP as well.
This chapter discusses:


“Installing RIP Configuration Files” on page 133



“Configuring Advertising Default Routes” on page 134



“RIP Commands” on page 135



“RIP Parameters” on page 136



“SG-Specific RIP Parameters” on page 137



“Using Passwords with RIP” on page 137

Installing RIP Configuration Files
No RIP configuration file is shipped with the appliance. For commands that can be
entered into the RIP configuration file, see “RIP Commands” on page 135.
After creating an RIP configuration file, install it using one of the following methods:


Using the Text Editor, which allows you to enter settings (or copy and paste the
contents of an already-created file) directly onto the appliance.



Creating a local file on your local system; the SG appliance can browse to the file and
install it.



Using a remote URL, where you place an already-created file on an FTP or HTTP
server to be downloaded to the SG appliance.



Using the CLI inline rip-settings command, which allows you to paste the RIP
settings into the CLI.



Using the CLI rip commands, which require that you place an already-created file
on an FTP or HTTP server and enter the URL into the CLI. You can also enable or
disable RIP with these commands.

To install an RIP configuration file:
Note: When entering RIP settings that affect current settings (for example, when
switching from ripv1 to ripv2), disable RIP before you change the settings; re-enable
RIP when you have finished.

1.

Select Configuration > Network > Routing > RIP.

2.

To display the current RIP settings, routes, or source, click one or all of the View RIP
buttons.

133

Volume 6: Advanced Networking

3.

In the Install RIP Setting from the drop-down list, select the method used to install the
routing table; click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the routing table is
located. To view the file before installing it, click View. Click Install. To view the
installation results, click Results; close the window when you are finished. Click
OK.



Local File:
Click Browse to display the Local File Browse window. Browse for the file on the
local system. Open it and click Install. When the installation is complete, a results
window opens. View the results and close the window.



Text Editor:
The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the installation is
complete, a results window opens. View the results, close the window, and click
OK.

4.

Select Apply to commit the changes to the SG appliance.

5.

Select Enable RIP.

6.

Click Apply.

Related CLI Syntax to Configure RIP
SGOS#(config) rip {disable | enable}


To enter a path to a remote URL where you have placed an already-created RIP
configuration file, enter the following commands at the (config) command prompt:
SGOS#(config) rip path url
SGOS#(config) load rip-settings



To paste an RIP configuration directly into the CLI, enter the following command at
the (config) command prompt:
SGOS#(config) inline rip-settings end-of-file_marker

Configuring Advertising Default Routes
Default routes advertisements are treated the same as the static default routes; that is, the
default route load balancing schemes also apply to the default routes from RIP.
By default, RIP ignores the default routes advertisement. You can change the default from
disable to enable and set the preference group and weight through the CLI only.
To enable and configure advertising default gateway routes:
1.

At the (config) command prompt:
SGOS#(config) rip default-route enable
SGOS#(config) rip default-route group group_number
SGOS#(config) rip default-route weight weight_number

Where group_number defaults to 1, and weight_number defaults to 100, the same
as the static default route set by the ip-default-gateway command.

134

Chapter 10: Using RIP

2.

(Optional) To view the default advertising routes, enter:
SGOS#(config) show rip default-route
RIP default route settings:
Enabled:
Yes
Preference group:
3
Weight:
30

RIP Commands
You can place any of the commands below into a Routing Information Protocol (RIP)
configuration text file. You cannot edit a RIP file through the command line, but you can
overwrite a RIP file using the inline rip-settings command.
Once the file is complete, place it on an HTTP or FTP server accessible to the SG appliance
and download it.

net
net Nname[/mask] gateway Gname metric Value {passive | active |
external}
Table 10-1. net Commands
Parameters

Description

Nname

Name of the destination network. It can be a symbolic network
name, or an Internet address specified in dot notation.

/mask

Optional number between 1 and 32 indicating the netmask
associated with Nname.

Gname

Name or address of the gateway to which RIP responses should be
forwarded.

Value

The hop count to the destination host or network. A net Nname/32
specification is equivalent to the host Hname command.

passive | active |
external

Specifies whether the gateway is treated as passive or active, or
whether the gateway is external to the scope of the RIP protocol.

host
host Hname gateway Gname metric Value {passive | active | external}
Table 10-2. host Commands
Parameters

Description

Hname

Name of the destination network. It can be a symbolic network
name, or an Internet address specified in dot notation.

Gname

Name or address of the gateway to which RIP responses should be
forwarded. It can be a symbolic network name, or an Internet
address specified in dot notation.

Value

The hop count to the destination host or network. A net Nname/32
specification is equivalent to the host Hname command.

passive | active |
external

Specifies whether the gateway is treated as passive or active, or
whether the gateway is external to the scope of the RIP protocol.

135

Volume 6: Advanced Networking

RIP Parameters
Lines that do not start with net or host commands must consist of one or more of the
following parameter settings, separated by commas or blank spaces:
Table 10-3. RIP Parameters
Parameters

Description

if=[0|1|2|3]

Specifies that the other parameters on the line apply to the interface numbered 0,1,2,
or 3 in SGOS terms.

passwd=XXX

Specifies an RIPv2 password included on all RIPv2 responses sent and checked on all
RIPv2 responses received. The password must not contain any blanks, tab characters,
commas or ‘#’ characters.

no_ag

Turns off aggregation of subnets in RIPv1 and RIPv2 responses.

no_super_ag

Turns off aggregation of networks into supernets in RIPv2 responses.

passive

Marks the interface to not be advertised in updates sent through other interfaces, and
turns off all RIP and router discovery through the interface.

no_rip

Disables all RIP processing on the specified interface.

no_ripv1_in

Causes RIPv1 received responses to be ignored.

no_ripv2_in

Causes RIPv2 received responses to be ignored.

ripv2_out

Turns off RIPv1 output and causes RIPv2 advertisements to be multicast when
possible.

ripv2

Is equivalent to no_ripv1_in and no_ripv1_out. This parameter is set by default.

no_rdisc

Disables the Internet Router Discovery Protocol. This parameter is set by default.

no_solicit

Disables the transmission of Router Discovery Solicitations.

send_solicit

Specifies that Router Discovery solicitations should be sent, even on point-to-point
links, which by default only listen to Router Discovery messages.

no_rdisc_adv

Disables the transmission of Router Discovery Advertisements.

rdisc_adv

Specifies that Router Discovery Advertisements should be sent, even on point-topoint links, which by default only listen to Router Discovery messages.

bcast_rdisc

Specifies that Router Discovery packets should be broadcast instead of multicast.

rdisc_pref=N

Sets the preference in Router Discovery Advertisements to the integer N.

rdisc_interval=N

Sets the nominal interval with which Router Discovery Advertisements are
transmitted to N seconds and their lifetime to 3*N.

trust_gateway=rname

Causes RIP packets from that router and other routers named in other trust_gateway
keywords to be accept, and packets from other routers to be ignored.

redirect_ok

Causes RIP to allow ICMP Redirect messages when the system is acting as a router
and forwarding packets. Otherwise, ICMP Redirect messages are overridden.

136

Chapter 10: Using RIP

SG-Specific RIP Parameters
The following RIP parameters are unique to SG configurations:
Table 10-4. SG-Specific RIP Parameters
Parameters

Description

supply_routing_info

-s option:
Supplying this option forces routers to supply routing
information whether it is acting as an Internetwork router or not.
This is the default if multiple network interfaces are present or if a
point-to-point link is in use.

-oradvertise_routes

-g option:
This flag is used on Internetwork routers to offer a route to the
`default' destination. This is typically used on a gateway to the
Internet, or on a gateway that uses another routing protocol
whose routes are not reported to other local routers.
-h option:
Suppress_extra_host_routes advertise_host_route
-m option:
Advertise_host_route on multi-homed hosts
-A option:
Ignore_authentication //
no_supply_
routing_info

-q option:
opposite of -s.

no_rip_out

Disables the transmission of all RIP packets. This setting is the
default.

no_ripv1_out

Disables the transmission of RIPv1 packets.

no_ripv2_out

Disables the transmission of RIPv2 packets.

rip_out

Enables the transmission of RIPv1 packets.

ripv1_out

Enables the transmission of RIPv1 packets.

rdisc

Enables the transmission of Router Discovery Advertisements.

ripv1

Causes RIPv1 packets to be sent.

ripv1_in

Causes RIPv1 received responses to be handled.

Using Passwords with RIP
The first password specified for an interface is used for output. All passwords pertaining
to an interface are accepted on input. For example, with the following settings:
if=0 passwd=aaa
if=1 passwd=bbb
passwd=ccc

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. Interface 1
accepts passwords bbb and ccc, and transmits using password bbb. The other interfaces
accept and transmit the password ccc.

137

Volume 6: Advanced Networking

138

Chapter 11: Configuring the SG Appliance as a Session
Monitor

You can configure the SGOS software to monitor RADIUS accounting messages and to
maintain a session table based on the information in these messages. The session table
can then be used for logging or authentication.
You can also, optionally, configure multiple appliances to act as a session monitor
cluster. The session table is then replicated to all members of the cluster.
Once configured and enabled, the session monitor maintains a session table that
records which sessions are currently active and the user identity for each session.

Configuring the Session Monitor
Three steps are required to configure the session monitor:


Configure the RADIUS accounting protocol parameters for the session monitor.



(Optional) Configure the session monitor cluster.



Configure the session monitor parameters.

Configuring the RADIUS Accounting Protocol Parameters
The configuration commands to create the RADIUS accounting protocol parameters
can only be done through the CLI. If you are using session-monitor clustering, the
commands must be invoked on each system in an already-existing failover group. (For
information on configuring a failover group, see Chapter 6: "Configuring Failover"on
page 87.)
To configure the RADIUS accounting protocol parameters:


To enter configuration mode:
SGOS#(config) session-monitor



The following subcommands are available:
SGOS#(config session-monitor) radius acct-listen-port port_number
SGOS#(config session-monitor) radius authentication {enable |
disable}
SGOS#(config session-monitor) radius encrypted-shared-secret
encrypted_secret
SGOS#(config session-monitor) radius no encrypted-shared-secret
SGOS#(config session-monitor) radius response {enable | disable}
SGOS#(config session-monitor) radius shared-secret plaintext_secret

139

Volume 6: Advanced Networking

t

Table 11-1. Session Monitor Accounting Command Descriptions
Command

Option

Description

radius acct-listen-port

port_number

The port number where the SG appliance listens for
accounting messages

radius authentication

enable | disable

Enable or disable (the default) the authentication of
RADIUS messages using the shared secret. Note
that the shared secret must be configured before
authentication is enabled.

radius encrypted-sharedsecret

encrypted_shared_
secret

Specify the shared secret (in encrypted form) used
for RADIUS protocol authentication. The secret is
decrypted using the configuration-passwords-key.
Clears the shared secret used for RADIUS protocol
authentication.

radius no shared-secret

radius response

enable | disable

Enable (the default) or disable generation of
RADIUS responses.

radius shared-secret

plaintext_secret

Specify the shared secret used for RAIDUS protocol
in plaintext.

Configuring a Session Monitor Cluster
Configuring a session monitor cluster is optional. When a session monitor cluster is
enabled, the session table is replicated to all members of the cluster. The cluster members
are the SG appliances that are configured as part of the failover group referenced in the
session monitor cluster configuration. The failover group must be configured before the
session monitor cluster. (For information on configuring a failover group, see Chapter 6:
"Configuring Failover"on page 87.)
To replicate the session table to all the members of a failover group, you can use the
following commands.
Note: When using a session monitor cluster, the RADIUS client must be configured to
send the RADIUS accounting messages to the failover group's virtual IP address.

Proxy traffic can be routed to any of the machines in the cluster.
Note: Each member of the failover group must configured with the cluster commands to
maintain the session table for RADIUS accounting messages.

To configure session monitor cluster parameters:
SGOS#(config) session-monitor


The following subcommands are available:
SGOS#(config session-monitor) cluster {enable | disable}
SGOS#(config session-monitor) cluster group-address IP_address
SGOS#(config session-monitor) cluster port port_number
SGOS#(config session-monitor) cluster grace-period seconds
SGOS#(config session-monitor) cluster synchronization-delay seconds

140

Chapter 11: Configuring the SG Appliance as a Session Monitor

Table 11-2. Session Monitor Cluster Command Descriptions
Command

Option

Description

cluster

enable |
disable

Enable or disable (the default) clustering on a failover group.
The group address must be set before the cluster can be
enabled.

cluster group-address
| no group-address

IP_address

Set or clear (the default) the failover group IP address. This
must be an existing failover group address.

cluster port

port_number

Set the TCP/IP port for the session replication control. The
default is 55555.

cluster
synchronization-delay

seconds

Set the maximum time to wait for session table
synchronization. The default is zero; the range is from 0 to 2
^31 -1 seconds. During this time evaluation of
$(session.username) is delayed, so proxy traffic might
also be delayed.

cluster grace-period

seconds

Set the time to keep session transactions in memory while
waiting for slave logins. This can be set to allow session table
synchronization to occur after the synchronization-delay has
expired. The default is 30 seconds; the range is 0 to 2^31-1
seconds.

Configuring the Session Monitor
The session monitor commands set up session monitoring behavior. If using sessionmonitor clustering, these commands must be invoked on all systems in the failover group.
To configure the session monitor:
1.

At the (config) prompt:
SGOS#(config) session-monitor
SGOS#(config session-monitor) disable | enable
SGOS#(config session-monitor) max-entries integer
SGOS#(config session-monitor) timeout minutes

Table 11-3. Session Monitor Configuration Command Descriptions
Command

Option

Description
Enable or disable (the default) session monitoring

enable | disable
max_entries

integer

The maximum number of entries in the session table.
The default is 500,000; the range is from 1 to 2,000,000.
If the table reaches the maximum, additional START
messages are ignored.

timeout

minutes

The amount of time before a session table entry
assumes a STOP message has been sent. The default is
120 minutes; the range is from 0 to 65535 minutes. Zero
indicates no timeout.

141

Volume 6: Advanced Networking

2.

(Optional) To view the session-monitor configuration, you can either use the
session-monitor view command or the config show session-monitor command.
SGOS#(config) show session-monitor
General:
Status: enabled
Entry timeout: 120 minutes
Maximum entries: 500000
Cluster support: enabled
Cluster port: 55555
Cluster group address: 10.9.17.159
Synchronization delay: 0
Synchronization grace period: 30
Accounting protocol: radius
Radius accounting:
Listen ports:
Accounting: 1813
Responses: Enabled
Authentication: Enabled
Shared secret: ************

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication policy.
By themselves, they are not adequate.
Note: Refer to Volume 11: Content Policy Language Guide for details about CPL and how
transactions trigger the evaluation of policy file layers.


In this example, the SG appliance is using the session table maintained by the session
monitor for authentication.

allow authenticate(session)

where session is a policy substitution realm that uses $(session.username) in
building the username. (For information on creating a Policy Substitution realm, refer
to Volume 5: Securing the Blue Coat SG Appliance.)

Notes


The session table is stored entirely in memory. The amount of memory needed is
roughly 40MB for 500,000 users.



The session table is kept in memory. If the system goes down, the contents of the
session table are lost. However, if the system is a member of a failover cluster, the
current contents of the session table can be obtained from another machine in the
cluster. The only situation in which the session table is entirely lost is if all machines in
the cluster go down at the same time.



The session replication protocol replicates session information only; configuration
information is not exchanged. That means that each SG appliance must be properly
configured for session monitoring.



The session replication protocol is not secured. The failover group should be on a
physically secure network to communicate with each other.

142

Chapter 11: Configuring the SG Appliance as a Session Monitor



The session monitor requires sufficient memory and at least 100Mb-per-second
network links among the cluster to manage large numbers of active sessions.



The username in the session table is obtained from the Calling-Station-ID attribute in
the RADIUS accounting message and can be a maximum of 19 bytes.

143

Volume 6: Advanced Networking

144

Chapter 12: Configuring and Using the SG Client

The Blue Coat SG Client enables users to benefit from accelerated application delivery
directly to their desktops. This allows mobile users or users in small branch offices—
where it might not be cost-justifiable to deploy an acceleration gateway—to enjoy
improved networked application access.
For more information about the SG Client, see one of the following sections:


“Overview” on page 146



“Software and Hardware Requirements” on page 149



“Understanding ADN Details” on page 149



“Configuring Client Settings” on page 151



“Configuring the Client Manager” on page 156



“Configuring from the Command Line” on page 159



“Making the SG Client Software Available to Users” on page 161



“Using the SG Client” on page 171



“Troubleshooting Tips for Administrators” on page 180



“Licensing” on page 182

145

Chapter 12: Configuring and Using the SG Client



ADN manager and backup manager (not shown in the preceding figure)
Every ADN network must have an ADN manager, which is responsible for publishing
the routing table to SG Clients (and to other SG appliances). Although not required,
Blue Coat recommends configuring an ADN backup manager, which takes over for the
ADN manager in the event it becomes unavailable.
Note:

The Client Manager can be any appliance in the ADN network, including a
concentrator, the ADN manager, or backup manager. For example, the Client
Manager could also be the ADN manager but that is not a requirement.
To configure an ADN manager and backup manager, see “Defining the ADN
Manager” on page 19.

SG Client Features and Benefits
The following table discusses features and benefits of the SG Client:
Table 12-1. SG Client Features and Benefits
Feature

Benefit

Common Internet File System (CIFS)
acceleration

The SG Client significantly enhances Wide Area
Network (WAN) file service delivery, improving user
productivity by implementing the following:
• Client object caching, which enables clients to get
previously-obtained data from cache rather than
across the WAN.
• CIFS protocol optimization, which improves
performance by consolidating data forwarded across
the WAN.

Connect from anywhere

The SG Client enables any user to remotely connect to
an ADN network.

ADN optimization

Uses gzip compression to improve bandwidth
utilization for TCP applications.

Centralized management and
distribution

Administrators use a particular SG appliance
designated as the Client Manager to download to
clients SG Client software and configuration updates.

Load balancing and failover

Enables you to efficiently use your ADN network as a
robust infrastructure for clients.

Client statistics

Provides users with real-time performance data.

147

Volume 6: Advanced Networking

Understanding SG Client Deployment
The SG Client software is deployed in two basic steps: the administrator configures the
Client Manager to install and configure the client, then the user (or administrator) installs
the client. After installation, the client connects to an appliance in the ADN network. The
following sections discuss this process in more detail.

Administrator Configuration Tasks
The administrator configures the following:
1.

Sets up an ADN manager, backup manager, and configures the ADN network as
discussed elsewhere in this book.

2.

Configures an SG appliance as the Client Manager as discussed in “Configuring the
Client Manager” on page 156.
The Client Manager must be licensed as discussed in “Licensing” on page 182.
The Client Manager is the location from which users download the SG Client
software, software updates, and configuration updates.

3.

Sets up the SG Client configuration (such as CIFS and ADN) as discussed in
“Configuring Client Settings” on page 151.

4.

Provisions the SG Client software to users in one of the ways discussed in this chapter.
For more information, see “Making the SG Client Software Available to Users” on
page 161.

Client Installation Tasks
The SG Client deployment process can be summarized as follows:
1.

A user obtains the SG Client software, either from the Client Manager or pre-installed
by an administrator some other way.
Note:

Installation methods are discussed in “Making the SG Client Software
Available to Users” on page 161.
To download the SG Client software from the Client Manager, the user must go to a
URL provided by the administrator.
When the user connects to the Client Manager using the URL, the user runs a setup
application (SGClientSetup.exe) that in turn downloads and starts a Microsoft
Installer (SGClientSetup.msi).
Note:

To run SGClientSetup.exe and SGClientSetup.msi, the user must be in the
Administrators group on the machine.

148

Chapter 12: Configuring and Using the SG Client

2.

After installing the SG Client software, the user must reboot the machine to use the
software.

3.

Periodically, the SG Client polls the Client Manager for changes to the SG Client
software and configuration.
Note:

Every software or configuration update requires the client to reboot their
machine for the update to take effect.

Software and Hardware Requirements
The SG Client currently requires Microsoft Windows XP Professional or Home Edition,
Service Pack 2 or later (32-bit version only; the 64-bit operating system is not supported).
Note:

Blue Coat highly recommends users apply all the latest hot fixes available
from Microsoft Windows Update.
The SG Client requires a machine with:


Hard drive with 5MB available for SG Client software installation, up to 40MB for
logging, and an additional 1.5GB available space (minimum) for CIFS object caching,
5GB or more available recommended.
The CIFS object cache is stored on the system root volume. If there is 1GB or less
available space for the cache, the client will not cache CIFS objects, such as directory
listings and file contents.



Processor—Minimum, 500 megahertz (MHz) processor, such as the Intel family, AMD
family, or compatible processor.
Recommended, 750MHz or faster processor.



RAM—256MB minimum, 512MB or more recommended.

Understanding ADN Details
This section discusses the ADN features supported by the SG Client in this release.

General ADN Feature Support
The SG Client supports the following ADN features:


Gzip compression, which improves bandwidth utilization.



CIFS protocol optimization and CIFS caching on the client.



Load balancing and failover
The SG Client makes two types of connections in the ADN network: the routing
connection and the ADN tunneling connection. The routing connection obtains the
routing table from the ADN manager or backup manager, and the tunneling connection
transfers data to the ADN network.
The SG Client first attempts to connect to the primary ADN manager to get routing
information; if it is not available, the client attempts to connect to the backup ADN
manager. If the backup ADN manager is also not available, the connection goes
directly to its destination as a result of fail open, which is discussed next.

149

Volume 6: Advanced Networking

Assuming there is more than one active SG appliance in the ADN network, the SG
Client randomly picks an appliance from the list of appliances in the routing table and
iterates through the list until it finds an active appliance.
Randomly choosing an appliance—assuming there is more than one—achieves
simple load balancing. Iterating through the list of appliances achieves failover. If no
appliance is active, the connection goes directly to its destination as a result of fail
open, which is discussed next.


Fail open, which means that if all client connections to concentrators fail for any
reason, the client opens a connection directly to a destination, such as a CIFS server.
Client connections that do not go through a concentrator are not accelerated and
remain unaccelerated as long as the connection is open (that is, until the connection is
closed by the application).
After a concentrator becomes available, new connections are accelerated.

Configuring Plain Connections
To use the SG Client in your ADN network, the ADN manager’s listening mode must be
configured for Plain Only, Plain Read-Only, or Both, as discussed in “Securing Connections”
on page 33.


Use the following guidelines to configure the Manager Listening Mode:


Choose Plain Read-Only if all SG appliances in the ADN network use SGOS
version 5.1.4—where all appliances support secure routing, and you have chosen
to utilize secure routing on those SG appliances.
This setting means that users who connect to the plain port are not allowed to
advertise routes to the ADN network.





Choose either Plain Only or Both as appropriate if you have some SG appliances
that are not using secure routing (for example, SG appliances running SGOS
5.1.3).

Use the following guidelines to set Tunnel Listening mode on all SG appliances in the
ADN network:


Choose Plain to enable the SG Client to connect to the appliance in cases where
you do not secure any ADN connections between SG appliances.



Choose Both to enable the SG Client to connect to the appliance in cases where
you do use secure connections for some or all SG appliances.

Note:

The Secure Outbound Mode options have no impact on the SG Client.

About Internet Gateways
The SG Client ignores Internet Gateway settings; however, if you want to route all SG
Client traffic through a concentrator, you can configure the concentrator to publish all
addresses as discussed in “Managing Server Subnets and Enabling an Internet Gateway”
on page 24.

150

Chapter 12: Configuring and Using the SG Client

Configuring Client Settings
This section discusses how to configure the settings that affect SG Client configuration.
Available settings follow:


General settings—Software update interval, TCP window size, and maximum
percentage of client disk space to allocate for object caching. See “Configuring General
Client Settings” on page 151.



CIFS settings—Disabling CIFS or enabling CIFS with options for write-back and
directory cache time. See “Configuring Client CIFS Settings” on page 153.



ADN settings—Primary and backup ADN manager IP addresses and port, excluded
subnets, and included or excluded ports. See “Configuring Client ADN Settings” on
page 154.
Important: Changes you make to the client configuration are sent to clients at the next
software update interval. After a configuration change, the user is required to reboot the
client machine for the change to take effect.

Configuring General Client Settings
This section discusses how to configure the following client settings:


SG Client software update interval



TCP window size
If you know the bandwidth and round-trip delay, the TCP window size you should
use is approximately 2 * bandwidth * delay. For example, if the bandwidth of the
link is 8 Mbits/sec and the round-trip delay is 0.75 seconds:
TCP window size = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes
The setting in this example would be 1572864 bytes. This number goes up as either
bandwidth or delay increases, and goes down as they decrease. Because the
bandwidth and delay for SG Client users can vary, Blue Coat recommends you test SG
Client performance in a controlled environment before deciding on a TCP window
size value to use in production.



Maximum percentage of client disk space to use for object caching. Regions of files
that are read or written by the client are placed in the cache. Object caching applies to
both read and write file activities. Also, the caching process respects file locking.
Note:

In this release, the object cache is not encrypted.

You can set the maximum percentage of total disk space (as opposed to available disk
space) the SG Client allocates to the object cache. The SG Client always leaves at least
1GB of available disk space on the client machine’s system root volume.
Following is a summary of how object caching works on the client:
a.

The SG Client starts.

b.

The user requests a cacheable object, such as a file.

c.

The SG Client allocates sufficient disk space on the system root volume to
cache the object—up to the limit set by the administrator.
In other words, if the client machine’s system root volume has 100GB of total
space and the administrator configures the object cache to use a maximum of 10%,
the SG Client allocates up to 10GB for the object cache.

151

Volume 6: Advanced Networking

However, if the maximum cache size leaves less than 1GB of available disk space,
the cache size is further limited. Continuing this example, if the client has only
9GB of available space, the maximum cache size is 8GB instead of 10GB.
d. If any single object (such as a file) exceeds the maximum cache size, that
object is not cached.
To continue the preceding example, if the maximum size of the object cache is
10GB, and the client requests a file that is 11GB in size, that file is not cached.
e.

If the object cache is full, objects are expired from the cache based on a
number of criteria, such as unopened files and oldest objects first.

To configure general client settings:
1.

Log in to the Management Console as an administrator.

2.

In the left pane, click SG Client > Client Configuration.

3.

In the right pane, click the General tab.

4.

On the General tab page, enter the following information:

Table 12-2. Configuring General Client Settings
Field

Description

Update interval

Enter the frequency, in minutes, for clients to check the
Client Manager for updated SG Client software or
configuration updates.
Default is 120. Valid values are between 10—432000 (that
is, 300 days).
Note: Updating SG Client software or configuration
requires the client to reboot the machine.

TCP window size

Enter the number of bytes allowed before
acknowledgement (the value must be between 8192 and
4194304). Default is 65536.

Maximum percentage of disk
space to use for object caching

Maximum percentage of client disk space to use for
caching objects, such as CIFS objects. Valid values are 1—
90; default is 10.
Note: The cache leaves at least 1GB available space on the
system root volume. For more information, see
“Configuring General Client Settings” on page 151.

5.

Select Apply to commit the changes to the SG appliance.

152

Chapter 12: Configuring and Using the SG Client

Configuring Client CIFS Settings
This section discusses how to configure the following:


Enable or disable CIFS acceleration



Enable or disable write-back



Set the directory cache time

To configure CIFS settings:
1.

Log in to the Management Console as an administrator.

2.

In the left pane, click SG Client > Client Configuration.

3.

In the right pane, click the CIFS tab.

4.

On the CIFS tab page, enter the following information:

Table 12-3. Configuring Client Settings for CIFS
Item

Description

Enable CIFS acceleration check
box

• Select the check box to enable CIFS acceleration for clients.
• Clear the check box to disable CIFS acceleration. If you clear the check box,
the other options on this tab page are unavailable.
For more information about CIFS acceleration, see “SG Client Features and

Benefits” on page 147.
Determines whether or not users can continue sending data to the appliance
while the appliance is writing data on the back end.

Write back

• Click Full to enable write-back, which in turn makes the local SG Client
proxy appear to the user as a file server; in other words, the local SG Client
proxy constantly sends approval to the client and allows the client to send
data while the back end takes advantage of the compressed TCP connection.
• Click None to disable write-back. Disabling write-back can introduce
substantial latency while clients send data to the appliance and wait for
acknowledgement before sending more data.
One reason to set this option to None is the risk of data loss if the link from
the branch to the core server fails. There is no way to recover queued data if
such a link failure occurs.
Directory cache time field

5.

Number of seconds for directory listings to remain in the client’s cache.

Select Apply to commit the changes to the SG appliance.

153

Volume 6: Advanced Networking

Configuring Client ADN Settings
This section discusses how to configure the following:




ADN manager settings:


Primary and backup ADN manager IP addresses



ADN manager port

ADN rules settings:


Excluded subnets
Adds or removes subnets from the list of subnets not included in ADN tunnels.
Assuming SG Clients can connect to an SG appliance that can optimize traffic to
the destination address, this is the list of IP addresses and subnets that bypass
ADN tunneling on the way to the destination.



Include and exclude ports
Includes or excludes TCP ports in ADN tunnels. Assuming SG Clients can
connect to an SG appliance that can optimize traffic to the destination address,
this setting determines ports accelerated (or not accelerated) for clients. You can
use either the excluded ports list or included ports list, but not both.
The include and exclude ports list are advanced settings that limit the traffic that
is accelerated by the ADN network. Because the ADN manager sets options for
both its peers in the ADN network and for SG Clients, you can use the include or
exclude ports list to fine-tune the way SG appliances interact with the SG Client.
For example, if you know that SG Client traffic over particular ports is not
compressible, you can put those ports in the exclude ports list. Blue Coat strongly
recommends you test the include/exclude ports settings in a controlled
environment before using them in production because improper settings can have
an adverse impact on performance.

Configuring Client ADN Manager Settings
To configure client ADN Manager settings:
1.

Log in to the Management Console as an administrator.

2.

In the left pane, click SG Client > Client Configuration.

3.

In the right pane, click the ADN Manager tab.

4.

On the ADN Manager tab page, enter the following information:

Table 12-4. Configuring Client Settings for ADN Manager
Field

Description

ADN Manager

Enter the primary ADN manager’s IP address. The ADN
manager tracks and advertises the routes to the
appliances it knows about.
The SG Client obtains the routing table from the ADN
manager.

154

Chapter 12: Configuring and Using the SG Client

Table 12-4. Configuring Client Settings for ADN Manager (Continued)
Field

Description

Backup Manager

Enter the backup ADN manager’s IP address.
Configuring a backup ADN manager is optional but
recommended.
If the ADN manager becomes unavailable for any reason,
the backup ADN manager takes over the task of
advertising routes to all ADN nodes—including SG
Clients.
Enter the ADN managers’ plain listen port.

Port

5.

Select Apply to commit the changes to the SG appliance.

Configuring Client ADN Rules Settings
To configure client ADN Manager settings:
1.

Log in to the Management Console as an administrator.

2.

In the left pane, click SG Client > Client Configuration.

3.

In the right pane, click the ADN Rules tab.

4.

On the ADN Rules tab page, in the Excluded Subnets section, do one of the following:


To add excluded subnets (in other words, to cause SG Client traffic from these
subnets to bypass the ADN tunnel), click Add.
In the Add IP/Subnet dialog box, enter the following information and click OK
when you’re done:


IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet
in Classless Inter-Domain Routing (CIDR) notation (for example,
192.168.0.1/16).



Subnet Mask field: Use this field only if you entered an IP address in the

preceding field (in other words, if you used CIDR notation in the preceding
field, you do not need to enter a value in this field).

5.



To remove excluded subnets, click the subnets you want to remove and click
Remove. You are required to confirm the action.



To clear all excluded subnets (in other words, to cause SG Client traffic from all IP
addresses and subnets to be tunneled), click Clear all. You are required to confirm
the action.

On the ADN Rules tab page, in the Ports section, enter the following information:

Table 12-5. Configuring Included or Excluded Ports
Item

Description

Exclude

Client traffic from specified ports is not routed through
the ADN tunnel. All other traffic is accelerated.
Valid values: Comma-separated list of ports and port
ranges (no spaces, separated by a dash character).
Example: 22,88,443,993,995,1352,1494,1677,
3389,5900

155

Volume 6: Advanced Networking

Table 12-5. Configuring Included or Excluded Ports (Continued)
Item

Description

Include

Client traffic from specified ports is routed through the
ADN tunnel and therefore accelerated. All other traffic
bypasses the tunnel and is therefore not accelerated.
Valid values: Comma-separated list of ports and port
ranges (no spaces, separated by a dash character).
Example: 80,139,445,8080-8088

Note: The include and exclude ports lists are advanced settings that limit the traffic
that is accelerated by the ADN network. For more information, see “Configuring
Client ADN Rules Settings” on page 155.

To cause all traffic to be accelerated by the ADN network, click either option and
delete all the ports in the list.
6.

Select Apply to commit the changes to the SG appliance.

Configuring the Client Manager
You must configure one SG appliance in your ADN network as the Client Manager,
meaning it is responsible for provisioning the SG Client software, software updates, and
client configuration to SG Clients. The Client Manager must be licensed as discussed in
“Licensing” on page 182.
Note: The Client Manager can be a different appliance than the ADN manager or the
backup ADN manager. In other words, you can configure the ADN manager or the
backup ADN manager as the Client Manager, but it’s not required.

Setting an Appliance as the Client Manager
To set an SG appliance as the Client Manager:
1.

Log in to the Management Console as an administrator.

2.

In the left pane, click SG Client > Client Manager.

3.

In the right pane, click the Client Manager tab.

4.

Select the Enable Client Manager checkbox.

5.

In the Client Manager section in the right pane, enter or edit the following
information:
Note:



Before you can enable an appliance to be the Client Manager, you must
configure the ADN manager SG Clients will use. If you enable the Client
Manager before you configure an ADN manager for clients, the following
error displays when you attempt to apply the change: The ADN primary
manager must be set prior to enabling the SG Client Manager. To
configure the clients’ ADN manager, see “Configuring Client ADN Manager
Settings” on page 154.



License information displays below the check box. For more information, see
“Licensing” on page 182.

156

Chapter 12: Configuring and Using the SG Client

Table 12-6. Client Manager Section
Item

Description

Host

Specify the host from which users get the SG Client software, configuration, and updates as
one of the following:
• Use host from initial client request: (Recommended.) Click this option if you want
clients to download the SG Client software, configuration, and updates from the host
from which the clients originally obtained the software and configuration.
• Use host: Click this option only if you want to change the host from which clients
download the SG Client software, configuration, and updates. Enter a fully-qualified
host name or IP address only; do not preface it with http:// or https://or
downloads will fail.
In other words, this option enables you to change the host from which currentlyinstalled clients obtain future software and configuration updates. Use caution when
selecting this option because if clients are unable to connect to the host you enter in the
adjacent field, new installations from the Client Manager and updates to existing
installations fail.
Note: Blue Coat recommends you enter a fully-qualified host name. If you enter either
an unqualified host name or IP address and change the IP address later, connections to
all currently-connected clients are dropped.

Port field

Enter the port on which the Client Manager listens for requests from clients. Default is 8084.

Keyring list

Click the keyring you want to use when clients connect to the Client Manager.

6.

Select Apply to commit the changes to the SG appliance.
After you apply the changes, the Client Components section displays a summary of
the information you selected, as follows:

Table 12-7. Client Components section
Item

Description

Client setup

Displays the URL from which users will download the SG
Client setup application. The setup application
(SGClientSetup.exe) downloads the Microsoft Installer
(MSI)—named SGClientSetup.msi—to the client.
If you want users to install the SG Client software from the
Client Manager, provide this URL to them. To install the
software this way, the user must have administrative
privileges on the client machine.

Client install MSI

Displays the URL from which SGClientSetup.exe
downloads SGClientSetup.msi.
If you want to install the SG Client software on client
machines silently or using Group Policy Objects (GPO), use
SGClientSetup.msi.

Client configuration

Displays the URL from which the SG Client installer will
download the client configuration file
(SGClientConfig.xml).

Client configuration last
modified

Displays the most recent date and time
SGClientConfig.xml was updated on the Client
Manager.

157

Volume 6: Advanced Networking

Uploading the SG Client Software to the Client Manager
This section discusses how to upload updated SG Client software to the Client Manager
so it can make the latest SG Client software available to install or to update on client
machines.
Important: After you update the Client Manager’s SG Client software, whenever users
connect using the SG Client, they must update their SG Client software. As a result, users
must reboot their machines to use the updated software.

To upload the SG Client software to the Client Manager:
1.

If necessary, copy the SG Client .car file to a location that is accessible from the
machine on which you’re running the Management Console.
That is, if you want to upload the SG Client software from your local file system or
from a network share drive (as opposed to uploading it from a remote URL), you
must copy the SG Client .car file to an accessible location.

2.

Log in to the Management Console as an administrator.

3.

In the left pane, click SG Client > Client Manager.

4.

In the right pane, click the Client Software tab.
On the Client Software tab page, the Current SG Client Software section displays
information about the SG Client software this Client Manager is currently using.

5.

In the Install SG Software section, from the Install SG Client software from list, click one
of the following:


Remote URL: Upload the SG Client .car file from a location specified by a URL
in the following format:
https://host:port/sgclient/SGClient_timestamp.car

For example,
http://mysg.example.com:8004/sgclient/SGClient_timestamp.car

Follow the prompts on your screen to complete the upload.


6.

Local file: Upload the SG Client software from a location accessible by the
machine on which you’re running the Management Console. Follow the prompts
on your screen to complete the task.

Click Install.
You are required to confirm the action. Remember that any software or configuration
updates require SG Client users to download the updates the next time they connect
to the ADN network. Any configuration or software update requires the user to
reboot their machine for the update to take effect.

7.

Follow the prompts on your screen to complete the download.
Note: A compatibility check is performed on the SG Client version you just
uploaded. If the upload fails, you must upgrade your SGOS version before you can
upload the SG Client .car file.

158

Chapter 12: Configuring and Using the SG Client

Configuring from the Command Line
Configuring General Client Settings
To configure general client settings:
1.
2.

At the #(config) command prompt, enter sg-client.
Configure general client settings:
#(config
#(config
#(config
#(config
#(config

sg-client)
sg-client)
sg-client)
sg-client)
sg-client)

max-cache-disk-percent percentage
software-upgrade-path url
tcp-window-size bytes
update-interval minutes
view

Configuring CIFS Client Settings
To configure CIFS client settings:
1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter cifs.

3.

Configure CIFS settings:
#(config
#(config
#(config
#(config
#(config

sg-client
sg-client
sg-client
sg-client
sg-client

cifs)
cifs)
cifs)
cifs)
cifs)

directory-cache-time seconds
{disable | enable}
exit
write-back {full | none}
view

Configuring ADN Manager Settings
To configure ADN manager settings:
1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter adn.

3.

Configure ADN manager settings:
#(config sg-client adn) primary-manager ip-address
#(config sg-client adn) backup-manager ip-address
#(config sg-client adn) manager-port plain-port

159

Volume 6: Advanced Networking

Configuring ADN Rules Settings
To configure ADN rules settings:
1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter adn.

3.

Configure ADN manager settings:
#(config sg-client adn) port-list {exclude-ports | include-ports}
#(config sg-client adn) {exclude-ports | include-ports} {port-list |
port-range}
#(config sg-client adn) exclude-subnets
#(config sg-client adn exclude-subnets)
subnet_prefix[/prefix length]
#(config sg-client adn exclude-subnets)
#(config sg-client adn exclude-subnets)
#(config sg-client adn exclude-subnets)

{add | remove}
clear
exit
view

#(config sg-client adn) exit

Setting the Client Manager
To configure the Client Manager:
1.
2.

At the #(config) command prompt, enter sg-client.
Enable this appliance as the Client Manager:
#(config sg-client) enable
Note:

Before you can enable an appliance to be the Client Manager, you must
configure the ADN manager SG Clients will use. If you enable the Client Manager
before you configure an ADN manager for clients, the following error displays: The

ADN primary manager must be set prior to enabling the SG Client
Manager. To configure the clients’ ADN manager, see “Configuring Client ADN Rules

Settings” on page 155.
3.

Configure Client Manager settings:
#(config sg-client) client-manager host {from-client-address | }
#(config sg-client) client-manager install-port port
#(config sg-client) client-manager keyring keyring

Loading the Software
#(config sg-client) software-upgrade-path path-to-SGClient-car
#(config) load sg-client-software

160

Chapter 12: Configuring and Using the SG Client

Making the SG Client Software Available to Users
This section discusses how administrators can make the SG Client software available to
users in any of the following ways:


Interactive installations started from:


A command line on the user’s machine



The Client Manager

For more information, see “Setting Up Interactive Installations” on page 161


Silent installations
For more information, see “Setting Up Silent Installations and Uninstallations” on
page 165



Windows Group Policy Object distribution
For more information, see “Using Group Policy Object Distribution” on page 170
Note:

For the user to run SGClientSetup.exe or SGClientSetup.msi, the user
must be in the Administrators group on the client machine.

Important: Do not rename SGClientSetup.msi because doing so causes future
updates to fail.

Do not edit SGClientConfig.xml on the client machine because doing so causes
unpredictable results in future configuration updates.

Setting Up Interactive Installations
Users can install the SG Client software either by downloading SGClientSetup.exe from
the Client Manager, or manually by running SGClientSetup.msi from a command line,
as shown in the following table:
Table 12-8. SG Client Installation Options
Option

Description

Install from Client Manager

Provide users the URL to SGClientSetup.exe, which displays
on the Management Console’s SG Client > Client Manager,
Client Manager tab page.
SGClientSetup.exe downloads and runs
SGClientSetup.msi on the client machine. Users see the
installation in progress and have the option of canceling the
installation.
For more information about this installation method, see

“Interactive Installations From the Client Manager” on
page 162.

161

Volume 6: Advanced Networking

Interactive Manual Installations
To enable users to manually install the SG Client software:
Provide a location from which the user can download SGClientSetup.msi to the client
machine; for example, provide the user the URL to the Client Manager.
Important: Do not rename SGClientSetup.msi because doing so causes future
updates to fail.

Do not edit SGClientConfig.xml on the client machine because doing so causes
unpredictable results in future configuration updates.
For users to install the SG Client using this method:
1.

The user downloads SGClientSetup.msi to a location on the local file system.

2.

The user does either of the following:

3.



Clicks Start > Run, then enters the command shown in step 3.



Opens a DOS command prompt window and changes to the directory to which
they downloaded SGClientSetup.msi

The user enters the following command:
path\SGClientSetup.msi BCSI_UPDATEURL=url-to-config.xml

where path is the absolute file system path to SGClientSetup.msi (if necessary), urlto-config.xml is the URL to SGClientConfig.xml on the Client Manager.
This URL displays in the Management Console in SG Client > Client Manager, Client
Manager tab page as discussed in “Configuring the Client Manager” on page 156.
For example,
SGClientSetup.msi BCSI_UPDATEURL=http://mysg.example.com:8084/
sgclient/SGClientConfig.xml
Note:

Other command-line parameters are available. For a complete list, see
“Setting Up Silent Installations and Uninstallations” on page 165.
4.

The installation proceeds as discussed in steps 4 and following “Interactive
Installations From the Client Manager” on page 162.

164

Chapter 12: Configuring and Using the SG Client

Setting Up Silent Installations and Uninstallations
This section discusses how to silently install or uninstall the SG Client.
See one of the following sections:


“Parameters for Silent Installations” on page 165



“Command for Silent Uninstallations” on page 167



“Examples Installations and Uninstallations” on page 167

Important: Do not rename SGClientSetup.msi because doing so causes future
updates to fail.

Do not edit SGClientConfig.xml on the client machine because doing so causes
unpredictable results in future configuration updates.
For information about distributing the SG Client software using Group Object Policy, skip
this section and see “Using Group Policy Object Distribution” on page 170.

Parameters for Silent Installations
The following table shows command-line parameters to use with SGClientSetup.msi for
silent installations. For examples, see “Examples Installations and Uninstallations” on
page 167.
Silent Installation Usage
SGClientSetup.msi [/qr|/qn] BCSI_UPDATEURL=url REINSTALL=ALL
REINSTALLMODE=vamus [AUTOUPDATEDISABLED=0|1]
[AUTOUPDATEPROHIBITED=0|1] [FORCEREBOOT={yes|no} | {y|n}]
[REBOOTTIME=secs] [/l*v logfile]

Silent Installation Parameters
The following table shows the meanings of the parameters that can be used for silent
installations; for examples, see “Examples Installations and Uninstallations” on page 167:
Table 12-9. Parameters for Silent SG Client Installations
Parameter

Argument

/qr|/qn

Description
/qr (interactive, default) enables the user to see and interact
with the installer, and to cancel the installation.
/qn (totally silent) prevents the user from seeing or
interacting with the installer, and from canceling the
installation.
Note: Because this is an msiexec command, other options
are available. Enter msiexec at a command prompt for
more information about other options.

BCSI_UPDATEURL

url

URL to SGClientConfig.xml on the Client Manager,
which you can find as discussed in “Configuring the
Client Manager” on page 156, entered in the following
format:
https://client-manager-host:client-managerport/sgclient/SGClientConfig.xml

165

Volume 6: Advanced Networking

Table 12-9. Parameters for Silent SG Client Installations (Continued)
Parameter

Argument

Description

REINSTALL

ALL

Installs all SG Client components, whether they are already
installed or not.
ALL is the only supported parameter value in this release.

REINSTALLMODE

vamus

Blue Coat recommends using vamus as the parameter value.
Because this is an msiexec command, other options are
available. For more information, see the description of this
parameter at: http://msdn2.microsoft.com/en-us/
library/aa371182.aspx

AUTOUPDATEDISABLED

0|1

0 (default) means the SG Client automatically implements
software and configuration updates at the frequency the
administrator specified for software update interval in
“Configuring General Client Settings” on page 151.
1 means the SG Client checks for software and configuration
updates and does the following:
• Implements configuration updates when they are
available.
• Implements software updates only if the user manually
requests an update.
This setting enables you to test the SG Client installation
before deploying it in production.
In other words, before you deploy the SG Client in your
enterprise, you might want to test it in a controlled manner
with a small number of users. Doing so keeps clients from
requesting updates immediately after installation.
(Users can manually update the software and configuration
as discussed in “Updating the SG Client Software and
Configuration” on page 177. After the user manually
updates the software and configuration, the SG Client
software checks for updates at the interval you specified in
“Configuring General Client Settings” on page 151.)

AUTOUPDATEPROHIBITED

0|1

0 (default) means the SG Client automatically implements
software and configuration updates at the interval the
administrator specified for software update interval in
“Configuring General Client Settings” on page 151.
1 means only the SG Client configuration can be updated
(automatically or manually), but the SG Client software
cannot be updated. Use this setting if you want to distribute
software updates in some way other than the Client
Manager.
Note: AUTOUPDATEPROHIBITED=1 takes precedence over
AUTOUPDATEDISABLED=1.

166

Chapter 12: Configuring and Using the SG Client

Table 12-9. Parameters for Silent SG Client Installations (Continued)
Parameter

Argument

Description

FORCEREBOOT

yes|no

This setting controls whether or not Now or Later buttons
display on the post-installation reboot dialog box.

y|n

yes or y mean the dialog box displays without buttons.
(However, if REBOOTTIME=0, no dialog box displays.)
no or n (default) mean a dialog box displays with two
options: Now and Later, enabling the user to either reboot
immediately, wait for the timer to expire (see the next
parameter); or wait until a later time of their choosing.
secs

REBOOTTIME

Number of seconds after the SG Client installation
completes before the user’s machine is rebooted. A value of
0 means there is no timer; to the user, a value of 0 has
slightly different meanings, depending on the value of
FORCEREBOOT. For more information, see “Examples
Installations and Uninstallations” on page 167.
Default is 0.

/l*v

logfile

If you want the installation to be logged, enter the absolute
file system path and file name of the log file.

Command for Silent Uninstallations
To silently uninstall the SG Client software, use the following command:
msiexec /q /x {4214C5ED-CCED-4360-90C0-69764F3D0854}
Note: Users who have administrative privileges on their machines can also uninstall the

SG Client using the Windows Control Panel’s Add or Remove Programs application as
discussed in “Uninstalling the SG Client Software” on page 179.

Examples Installations and Uninstallations
This section shows the following examples:


“Example Installations” on page 167



“Example Uninstallation” on page 169

Important: Do not rename SGClientSetup.msi because doing so causes future
updates to fail.

Do not edit SGClientConfig.xml on the client machine because doing so causes
unpredictable results in future configuration updates.
Example Installations
Example 1: Automated, interactive installation with manual software updates possible:
SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
AUTOUPDATEDISABLED=1 FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration is downloaded from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and can
cancel it.

167

Volume 6: Advanced Networking

AUTOUPDATEDISABLED=1 means that the SG Client does not implement software

updates after the initial installation (it will, however, implement configuration
updates). This setting enables you to test the SG Client software on a small scale
without having to plan for client updates.
(To get software updates manually and thereafter enable automatic updates, click
Check for Updates on the Advanced tab page in the SG Client dialog box as discussed

in “Updating the SG Client Software and Configuration” on page 177.)
The REINSTALL and REINSTALLMODE parameters make sure that all SG Client
components install, which is useful in cases where you are recovering from an
incomplete or previously-unsuccessful installation.
After the installation is complete, the user has the following options:


Wait 30 seconds for the machine to reboot



Click Later on the dialog box to defer rebooting until a later time



Click Now on the dialog box to reboot immediately

Example 2: Automated, interactive installation with no automatic software updates
possible
SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
AUTOUPDATEPROHIBITED=1 FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration is downloaded from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and can
cancel it.
AUTOUPDATEPROHIBITED=1 means the SG Client cannot check for software updates
after the initial installation; however, it will check for and implement configuration
updates. Use this setting if you want to distribute software updates in some way other
than the Client Manager.

The REINSTALL and REINSTALLMODE parameters make sure that all SG Client
components install, which is useful in cases where you are recovering from an
incomplete or previously-unsuccessful installation.
After the installation is complete, the user has the following options:


Wait 30 seconds for the machine to reboot



Click Later on the dialog box to defer rebooting until a later time



Click Now on the dialog box to reboot immediately

168

Chapter 12: Configuring and Using the SG Client

Example 3: Automated, interactive installation
SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration is downloaded from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and can
cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all SG Client
components install, which is useful in cases where you are recovering from an
incomplete or previously-unsuccessful installation.
After the installation is complete, the user has the following options:


Wait 30 seconds for the machine to reboot



Click Later on the dialog box to defer rebooting until a later time



Click Now on the dialog box to reboot immediately

Example 4: Automated, interactive installation without a timer
SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=no REBOOTTIME=0

The SG Client configuration is downloaded from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and can
cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all SG Client
components install, which is useful in cases where you are recovering from an
incomplete or previously-unsuccessful installation.
After the installation is complete, the user has the following options:


Click Later on the dialog box to defer rebooting until a later time



Click Now on the dialog box to reboot immediately

Example 5: Totally silent installation, immediate reboot
SGClientSetup.msi /qn BCSI_UPDATEURL=https://mysg.example.com:8084/
sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=yes REBOOTTIME=0

The SG Client configuration is downloaded from the Client Manager specified at
https://mysg.example.com:8084. The user does not see the installation in progress
and cannot cancel it. The user’s machine is rebooted immediately after the installation
is complete. The REINSTALL and REINSTALLMODE parameters make sure that all SG
Client components install, which is useful in cases where you are recovering from an
incomplete or previously-unsuccessful installation.
Example Uninstallation
msiexec /q /x {4214C5ED-CCED-4360-90C0-69764F3D0854}

169

Volume 6: Advanced Networking

Using Group Policy Object Distribution
This section discusses how to distribute the SG Client software using Windows Group
Policy Object (GPO). Only an experienced Windows administrator should attempt to
complete the tasks discussed in this section.
To distribute the SG Client software using GPO:
1.

Get an .msi transform tool, such as the Orca database editor.
Orca is a table-editing tool available in the Windows Installer SDK that can be used to
edit your .msi files. You can also use similar tools available from other vendors.

Note: Blue Coat does not recommend a particular transform tool.

For more information about Orca, see:
http://support.microsoft.com/kb/255905/en-us

The remainder of this section assumes you use Orca. Consult the documentation
provided with the transform tool you’re using for vendor-specific instructions.
2.

Open SGClientSetup.msi.

3.

Right-click each of the following SG Client properties and change them as shown in
the following table:

Table 12-10. SG ClientSetup Transform Properties
Property

Action

Value

BCSI_UPDATEURL

Add row

URL to SGClientConfig.xml on the Client
Manager, which you can find as discussed in

“Configuring the Client Manager” on
page 156, entered in the following format:
https://client-managerhost:client-manager-port/sgclient/
SGClientConfig.xml
Edit value

FORCEREBOOT

y

Note:

Do not use any of the other parameters discussed in Table 12-9 on page 165—
in particular, REINSTALL and REINSTALLMODE. Using these parameters will cause
installations to fail.
4.

Generate the transformation.

170

Volume 6: Advanced Networking

Enabling and Disabling the SG Client
You can enable or disable the SG Client in any of the ways discussed in this section.

Enabling the SG Client
The SG Client is enabled when you boot your machine and remains enabled until you
disable it. If you don’t know whether or not it’s enabled because its icon is hidden, you
can use the following procedure to display the icon and make sure it’s enabled. Any
connections you make after enabling the SG Client are accelerated.
To enable the SG Client using its system tray icon:
1.

Right-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)

2.

From the pop-up menu, click Enable SG Client.

To enable the SG Client while you have the application open:
1.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

2.

Click the Advanced tab.

3.

On the Advanced tab page, verify the value of Client Status.

4.

If Client Status is Disabled, click the General tab.

5.

On the General tab page, click Enable SG Client.

Disabling the SG Client
You can disable the SG Client in the event of network problems or if instructed to do so by
your network administrator.
To disable the SG Client using its system tray icon:
1.

Right-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)

2.

From the pop-up menu, click Disable SG Client.

To disable the SG Client while you have the application open:
1.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

2.

Click the General tab.

3.

On the General tab page, click Disable SG Client.

174

Volume 6: Advanced Networking

Problem

Solution

Symptom: An automatic update fails.
Description: An SG Client update fails.
Try to manually update the client, as follows:
Double-click its icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start >
[All] Programs > Blue Coat > SG Client > SG Client.)
In the SG Client dialog box, click the Advanced tab.
On the Advanced tab page, click Check for Updates.
If the Check for Updates button is unavailable, the SG Client might be
disabled. To enable it, click the General tab and click Enable SG
Client.
If the manual update fails, send the following logs to your
administrator.
• Automatic update log, named sgautoupdate.log, located in the
SG Client installation folder, such as C:\Program Files\Blue
Coat\SG Client.
• SG Client application log, as discussed in “Viewing and Saving
the Log” on page 178.

Symptom: You don’t have enough available disk space.
Description: The SG Client always leaves a minimum of 1GB on your system
volume for your use. To free disk space, you can clear the SG Client cache at any time.
Clearing the cache might slow performance when you’re copying files but otherwise
has no effect.
Make sure the SG Client is enabled as discussed in “Enabling the SG

Client” on page 174.
Double-click its icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start >
[All] Programs > Blue Coat > SG Client > SG Client.)
In the SG Client dialog box, click the General tab.
On the General tab page, click Clear Cache.

176

Chapter 12: Configuring and Using the SG Client

Updating the SG Client Software and Configuration
The SG Client should automatically check for software and/or configuration updates at
the interval set by your administrator. However, you can check for updates anytime you
want (for example, if network problems have prevented you from checking for updates
earlier).
To update the SG Client software and configuration:
1.

Enable the SG Client as discussed in “Enabling the SG Client” on page 174.

2.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

3.

In the SG Client dialog box, click the Advanced tab.

4.

On the Advanced tab page, click Check for Updates.
A dialog box displays to notify you of the result of the update.
Note: If any software or configuration updates were applied, you must restart your
machine—or disable and then enable the SG Client—for the updates to take effect. For
more information, see “Enabling and Disabling the SG Client” on page 174.

If errors display instead, see “Troubleshooting the SG Client” on page 175.

Finding Information About The SG Client
To assist support personnel, it might be necessary for you to find version information
about SG Client components as discussed in this section.
To find information about the SG Client software:
1.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

2.

In the SG Client dialog box, click the About tab.
The version of SG Client software you’re running displays at the top of the About tab
page.

3.

On the About tab page, do any of the following as instructed by your support
personnel:


Click Copy to copy SG Client version information to the clipboard. You can then email the information to your support personnel.



Click System Info to display information about your machine.

177

Volume 6: Advanced Networking

SG Client Logging
The SG Client software maintains a diagnostic log that records the following:


Client installation (that is, timestamp of the initial installation and any updates,
including errors)



Activation of the driver and client service components every time those components
start



Configuration download events (that is, whenever a configuration download is
attempted and whether it succeed or failed)



Connection information between the client machine and the ADN manager



ADN tunnel creation and destruction



Activation/deactivation of the trace log, which is discussed in more detail in “Starting
the Trace Log” on page 179.



Various error conditions (for example, out of memory, out of disk space, and so on)

Log entries include the date and time of each event. The log file is a maximum of 20MB in
size, after which the oldest log entries are deleted as new entries are written.
Viewing and Saving the Log
This section discusses how to view the SG Client log file, copy it to the clipboard, or to
save it in a different location.
For information about the more detailed trace log, see “Starting the Trace Log” on page
179.
To view and save the SG Client log:
1.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

2.

In the SG Client dialog box, click the Advanced tab.

3.

On the Advanced tab page, click View Log.
The SG Client Log dialog box displays.

4.

You have the following options:

Table 12-13. Viewing the SG Client Log
To perform this task...

... Use these steps

To view the log

Click View Log. The log file displays in a dialog box
that enables you to read it, to copy it to the clipboard, or
to save it.

To copy the log to the clipboard

Click View Log, then click Copy to Clipboard.
Follow the directions from your network administrator
or technical support to paste the log into an e-mail or an
application like Notepad.

To save the log

Click View Log, then click Save Log.
Follow the directions from your network administrator
to e-mail the log.

178

Chapter 12: Configuring and Using the SG Client

5.

In the SG Client Log dialog box, click OK.

Starting the Trace Log
The trace log contains more detailed information about your client session than does the
client log. The trace log is not readable.
To start the trace log:
1.

Double-click the SG Client icon in the system tray.
(If the SG Client icon doesn’t display in your system tray, click Start > [All] Programs >
Blue Coat > SG Client > SG Client.)
The SG Client dialog box displays.

2.

In the SG Client dialog box, click the Advanced tab.

3.

On the Advanced tab page, click Start Trace.
A dialog box displays informing you the log was started.

4.

At the confirmation dialog box, click OK.

5.

Repeat the tasks that caused the problem for which you’re seeking assistance.

6.

After a sufficient length of time has passed, or when instructed to do so by your
network administrator or support personnel, click Stop Trace.
A dialog box displays informing you the log was stopped.
Note:

Before sending it to anyone, you must stop the trace log.

7.

At the confirmation dialog box, click OK.

8.

Click Open Trace Folder.

9.

Locate the trace log, named sgdebug.etl, and e-mail it to your administrator or
support.

Uninstalling the SG Client Software
To uninstall the SG Client software:
1.

Log in to your machine as a user who is a member of the Administrators group.
If you are not in the Administrators group on your machine, contact your network
administrator for alternate uninstallation methods.

2.

Click Start > Settings > Control Panel.

3.

In the Control Panel window, double-click Add or Remove Programs.

4.

Click Blue Coat SG Client.

5.

Click Remove.

6.

Follow the prompts on your screen to uninstall the software.

179

Volume 6: Advanced Networking

Troubleshooting Tips for Administrators
For administrators to assist SG Client users with diagnosing errors, you need to be
familiar with the topics discussed in this section:


“SG Client Logging” on page 180



“About Browser Proxies” on page 181



“ADN Tunnels” on page 181



“Clearing the Object Cache” on page 181



“Client Manager Logging” on page 182

SG Client Logging
The SG Client maintains the following logs in the user’s %TMP% folder:
Table 12-14. SG Client Log Files
File Name

Description

SGClientSetup.log

SGClientSetup.exe log; displays errors related to
downloading SGClientConfig.xml or running
SGClientSetup.exe.

SGClientSetup2.log

SGClientSetup.msi log; displays errors related to
installing the SG Client software.

The SG Client maintains the following logs in the user’s
%windir%\system32\sgclient\support folder:
Table 12-15. SG Client Log Files
File Name

Description

sglog.etl

SG Client application log. This file can reach a maximum of
20MB in size, after which the oldest log entries are deleted as
new entries are written.

sgdebug.etl

SG Client trace log. This file can reach a maximum of 20MB in
size, after which the oldest log entries are deleted as new
entries are written.
This log is in a compiled format that is readable only by Blue
Coat Engineering.

The SG Client maintains the following log in the SG Client installation folder (for
example, C:\Program Files\Blue Coat\SG Client):
Table 12-16. SG Client Log Files
File Name

Description

sgautoupdate.log

Logs software updates but not configuration updates.
Configuration update log messages are contained in
sglog.etl.

180

Chapter 12: Configuring and Using the SG Client

About Browser Proxies
For users to download SG Client software and configuration updates, you might need to
change proxy settings for SSL traffic. If you don’t use a proxy for SSL traffic, you can skip
this section.
The following options are available:


If users can connect directly to the Client Manager, change the browser’s proxy
settings to exclude the Client Manager from being proxied.



Change the proxy settings to allow connections to the Client Manager listen port (by
default, 8084). You chose the Client Manager listen port as discussed in “Configuring
the Client Manager” on page 156.
This method works for all users—even those who cannot connect directly to the Client
Manager.
Note:

The SG Client uses the Internet Explorer proxy settings to download software
and configuration updates, so make sure you change Explorer’s proxy settings.

ADN Tunnels
On the General tab page of the SG Client dialog box, clicking View ADN Tunnels displays
detailed information about available tunnels, including whether a tunnel is idle or
bypassed.
An Idle tunnel is one that is not currently being used but for which connection
information is preserved to decrease the amount of time required to use that connection
later, if necessary.
A Bypassed tunnel indicates an error with the connection to the indicated SG appliance.

Clearing the Object Cache
To free disk space on the user’s system root volume, the user can clear the object cache by
clicking Clear Cache on the SG Client dialog box’s General tab page. The object cache is
located in the user’s %windir%\system32\sgclient\cifs folder, which is a hidden
folder.
Clearing the cache affects the performance of file copies, listing directories, and opening
files in different applications. Also, clearing the cache while the client is running does not
delete files that are currently in use.

181

Volume 6: Advanced Networking

Client Manager Logging
The Client Manager logs success or failure events related to users downloading the SG
Client software and configuration. Each log should include timestamp, HTTP GET string
(including the HTTP return code), and client machine name).
To get Client Manager logs:
Enter the following URL in your browser’s location field:
https://host:port/sgclient/log

where host is the fully-qualified host name or IP address of the Client Manager, and
port is the SG appliance’s listen port.

Licensing


A new SG appliance has a 60-day trial license that permits you to use it with an
unlimited number of clients.



After the 60-day trial period, you are required to purchase a permanent license to
continue using the SG Client.
The license entitles you to support a certain number of clients in your enterprise;
however, the license does not limit the number of ADN tunnels to which clients can
have access.
Client machines do not require a license to use the SG Client software; only the Client
Manager appliance requires a license.



You can upgrade your license to larger user counts.

For information about applying a permanent Client Manager license, see the chapter on
licensing in Volume 2: Getting Started.

182

Chapter 13: SOCKS Gateway Configuration

The Blue Coat implementation of SOCKS includes the following:


A SOCKS proxy server that supports both SOCKSv4/4a and SOCKSv5, running on
the SG appliance.



Support for forwarding through SOCKS gateways.

To configure a SOCKS proxy server on the SG appliance, refer to Volume 3: Proxies and
Proxy Services. To use SOCKS gateways when forwarding, continue with the next
section.
Note: SOCKS gateway aliases cannot be CPL keywords, such as no, default, forward,
or socks_gateways.

Using SOCKS Gateways
SOCKS servers provide application level firewall protection for an enterprise. The
SOCKS protocol provides generic way to proxy HTTP.
SOCKS gateways, like ICP and forwarding, can use installable lists for configuration.
You can configure the installable list using directives. You can also use the CLI to create
a SOCKS gateways configuration.

Using the CLI to Create SOCKS Gateways Settings
If you prefer, you can use SOCKS gateways CLI commands instead of an installable list
to create SOCKS gateways settings. For information about using an installable list, see
“Using SOCKS Gateways Configuration Directives With Installable Lists” on page 186.
To create a SOCKS gateways host:
1.

At the (config) command prompt:
SGOS#(config) socks-gateways
SGOS#(config socks-gateways) create gateway_alias gateway_host
SOCKS_port [version {=4 | =5] [user=username password=password]

Table 13-1. Commands to Create a SOCKS Gateways Host
Command

Suboptions

Description

gateway_alias

A name, meaningful to you.

gateway_host

The IP address or the host name of the gateway where traffic is directed.
The host name must DNS resolve.

SOCKS_port

The port number of the SOCKS gateway.

version

=4 | =5

The version that SOCKS gateways can support. (SOCKS v5 is
recommended, if you have a choice). If no version is configured, the default
is version 4.

183

Volume 6: Advanced Networking

Table 13-1. Commands to Create a SOCKS Gateways Host (Continued)
Command

Suboptions

Description

user

=username

(Optional, and only if you use v5) The username of the user on the SOCKS
gateway. The username already must exist on the gateway. If you use
user=, you must also use password=.

password

=password

(Optional, and only if you use v5) The password of the user on the SOCKS
gateway. The password must match the gateway’s information. If you use
user=, you must also use password=.

2.

3.

Repeat for each gateway you want to create. The failure-mode command applies to
all SOCKS gateways configured on the system. The default failure mode can be
overridden using policy.
Complete the configuration by entering the following commands as necessary:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

socks-gateways)
socks-gateways)
socks-gateways)
socks-gateways)

failure-mode {open | closed}
delete {all | gateway gateway_alias}
path url
no path

Table 13-2. Commands to Complete SOCKS Gateways Configuration
failure-mode

open | closed

If the health checks fail, open specifies that the connection be
attempted without use of any SOCKS gateway (whether to an
origin content server or a forwarding target); closed
specifies that the connection be aborted.

delete

all | gateway
gateway_alias

Deletes all SOCKS gateways (delete all) or a specific
SOCKS gateway (delete gateway gateway_alias).

path

url

(Optional) Specifies the download path to use if you
download SOCKS-gateways settings through directives.

no

path

Clears the network path URL to download SOCKS gateway
settings.

4.

View the results.
SGOS#(config socks-gateways) view
SOCKS Gateways: (* = gateway unresolved)
Sec_App1
10.25.36.47 1080 V5

Editing a SOCKS Gateways Host
Once you have created a SOCKS gateways host, you can edit the settings.
To edit the settings of a SOCKS gateways host:
At the (config) command prompt:
SGOS#(config) socks-gateways
SGOS#(config socks-gateways) edit gateway_alias
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

socks-gateways
socks-gateways
socks-gateways
socks-gateways
socks-gateways
socks-gateways

gateway_alias)
gateway_alias)
gateway_alias)
gateway_alias)
gateway_alias)
gateway_alias)

host gateway_host
no password | user
password password
port socks_port
user username
version 4 | 5

184

Chapter 13: SOCKS Gateway Configuration

Table 13-3. Commands to Edit a SOCKS Gateways Host
Commands

Suboptions

Description

host

gateway_host

Changes the host name.

no

password | user

Optional, and only if you use version 5. Deletes the
version 5 password or username.

password

password

Optional, and only if you use version 5. Changes the
version 5 password.

port

socks_port

Changes the SOCKS port.

user

username

Optional, and only if you use version 5. Changes the
version 5 username.

version

4 | 5

Changes the SOCKS version.

Example
SGOS#(config) socks-gateways
SGOS#(config socks-gateways) edit testsocks
SGOS#(config socks-gateways testsocks) port 23
ok
SGOS#(config socks-gateways testsocks) version 5
ok
SGOS#(config socks-gateways testsocks) exit
SGOS#(config socks-gateways) exit
SGOS#(config)

Creating a Default Sequence
A default sequence defines the order in which SOCKS gateways hosts are used. Only one
default sequence is allowed. All members must be pre-existing hosts, and no member can
be in the group more than once.
Note: The default sequence (if present) is applied only if no applicable forwarding
gesture is in policy.

A default failover sequence allow healthy hosts to take over for an unhealthy host (one
that is failing its DNS Resolution or its health check). The sequence specifies the order of
failover, with the second host taking over for the first host, the third taking over for the
second, and so on.
If all hosts are unhealthy, the operation fails either open or closed, depending upon your
settings.
This configuration is usually created and managed through policy. If no SOCKS-gateways
policy applies, you can create a default sequence through the CLI. This single default
sequence consists of a single default host (or group) plus one or more hosts to use if the
preceding ones are unhealthy.
The syntax is
sequence alias_name alias_name

where alias_name is a space-separated list of one or more SOCKS gateways.

185

Volume 6: Advanced Networking

To create a default failover sequence, enter the following commands from the (config)
prompt:
SGOS#(config) socks-gateways
SGOS#(config socks-gateways) sequence add gateway-alias
SGOS#(config socks-gateways) sequence promote | demote gateway-alias
SGOS#(config socks-gateways) sequence clear | remove gateway-alias
Table 13-4. Commands to Create a Default Failover Sequence
Command

Suboptions

Description

sequence

add

Adds an alias to the end of the default fail-over sequence.

clear

Clears the default fail-over sequence.

demote

Demotes an alias one place towards the end of the default failover sequence.

promote

Promotes an alias one place towards the start of the default failover sequence.

remove

Removes an alias from the default fail-over sequence.

Using SOCKS Gateways Configuration Directives With Installable Lists
To configure a SOCKS gateway you must create an installable list and load it on the SG
appliance. Alternately, you can use the CLI to configure SOCKS gateways. To use the CLI,
see “Using the CLI to Create SOCKS Gateways Settings” on page 183.
For information on installing the file itself, see “Creating a SOCKS Gateway Installable
List” on page 188.
The SOCKS gateways configuration includes SOCKS directives that:


Names the SOCKS gateway hosts



Specifies the SOCKS version



(Optional, if using Version 5) Specifies user name and password

Available directives are described in the table below.
Table 13-5. SOCKS Gateway Directives
Directive

Meaning

gateway

Specifies the gateway alias and name, SOCKS port, version supported,
usernames and password.

socks_fail

In case connections cannot be made, specifies whether to abort the
connection attempt or to connect to the origin content server

sequence

Specifies the order in which hosts should be used for failover.

Syntax for the SOCKS directives are:
gateway gateway_alias gateway_host SOCKS_port [version={4 | 5]
[user=username password=password]
socks_fail {open | closed}
sequence gateway_name

186

Chapter 13: SOCKS Gateway Configuration

Table 13-6. SOCKS Directives Syntax
Command

Suboptions

Description
Configures the SOCKS gateway host.

gateway
gateway_alias

A meaningful name that is used for policy rules.

gateway_name

The IP address or host name of the gateway where traffic is directed.
The host name must DNS resolve.

SOCKS-port

The port number of the SOCKS gateway.

version={4 | 5}

The version that SOCKS gateways can support.

user=username

(Optional, if you use v5) The username of the user on the SOCKS
gateway. It already must exist on the gateway.

password=password

(Optional, if you use v5) The password of the user on the SOCKS
gateway. It must match the gateway’s information.

socks_fail

{open | closed}

If health checks fail, socks_gateway.fail_open specifies that the
connection be attempted without using a SOCKS gateway (for
example, go to the original server or forwarding target);
socks_gateway.fail_closed specifies that the connection be
aborted. The default is closed. Fail open is a security risk, and fail
closed is the default if no setting is specified. This setting can be
overridden by policy, (using the forward.fail_open(yes|no)
property).

sequence

gateway_name

Specifies the order in which hosts should be used for failover.

Example
gateway Sec_App1 10.25.36.47 1022 version=5 user=username
password=password
socks_gateway.fail_open no
Important: The username and password display in plaintext if you use the show
config command.

A default sequence defines the order in which forwarding hosts are used. Only one
default sequence is allowed. All members must be pre-existing hosts and groups, and no
member can be in the sequence more than once.
Note: The default sequence (if present) is applied only if no applicable forwarding
gesture is in policy.

A default failover sequence works by allowing healthy hosts to take over for an unhealthy
host (one that is failing its DNS Resolution or its health check). The sequence specifies the
order of failover, with the second host taking over for the first host, the third taking over
for the second, and so on).
If all hosts are unhealthy, the operation fails either open or closed, depending upon your
settings.

187

Volume 6: Advanced Networking

This configuration is generally created and managed through policy. If no SOCKSgateways policy applies, you can create a default sequence through the CLI. This single
default sequence consists of a single default host (or group) plus one or more hosts to use
if the preceding ones are unhealthy.
The syntax is
sequence gateway_name gateway_name

where gateway_name is a space-separated list of one or more SOCKS gateway aliases.
Example
sequence gateway_alias

Creating a SOCKS Gateway Installable List
You can create and install the SOCKS gateway installable list with the following methods:


Use the Text Editor, which allows you to enter directives (or copy and paste the
contents of an already-created file) directly onto the SG appliance.



Create a local file on your local system; the SG appliance can browse to the file and
install it.



Use a remote URL, where you place an already-created file on an FTP or HTTP server
to be downloaded to the SG appliance.

When the SOCKS gateway installable list is created, it overwrites any previous SOCKS
gateway configurations on the SG appliance. The installable list remains in effect until it is
overwritten by another installable list; it can be modified or overwritten using CLI
commands.
Note: During the time that a forwarding installable list is being compiled and installed,
forwarding is not available. Any transactions that come into the SG appliance during this
time are not forwarded properly and are denied.

Installation of SOCKS gateways installable-list configuration should be done outside peak
traffic times.
To create a SOCKS gateway installable list:
1.

Select Configuration > Forwarding > SOCKS Gateways.

2.

If you use a SOCKS gateway server for the primary or alternate forwarding gateway,
you must specify the ID for the Identification (Ident) protocol used by the SOCKS
gateway in SOCKS server handshakes. The default is BLUECOAT SYSTEMS.

3.

From the drop-down list, select the method used to install the SOCKS gateway
configuration; click Install.


Remote URL:

Enter the fully-qualified URL, including the filename, where the configuration is
located. To view the file before installing it, click View. Click Install. Examine the
installation status that displays; click OK.


Local File:

Click Browse to bring up the Local File Browse window. Browse for the file on the
local system. Click Install. When the installation is complete, a results window
opens. View the results, close the window, click Close.

188

Chapter 13: SOCKS Gateway Configuration



Text Editor:

The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the installation is
complete, a results window opens. View the results, close the window, click Close.
4.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to specify the SOCKS Gateway Machine ID
SGOS#(config) socks-machine-id machine_ID

Tip for SOCKS Configuration
By default, SOCKS treats all incoming requests destined to port 80 as HTTP, allowing the
usual HTTP policy to be performed on them, including ICAP scanning. If the SOCKS
connection is being made to a server on another port, write policy on the SG appliance to
match on the server host and port and specify that it is HTTP using SOCKS.

189

Volume 6: Advanced Networking

190

Chapter 14: TCP/IP Configuration

Use the TCP/IP configuration options to enhance the performance and security of the
SG appliance. Except for IP Forwarding (refer to Volume 3: Proxies and Proxy Services),
these commands are only available through the CLI.


RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and longdelay operation of the SG appliances over very high-speed paths, ideal for satellite
environments.



TCP NewReno: Enabling TCP NewReno support improves the fast recovery of the
appliances.



ICMP Broadcast Echo: Disabling the response to these messages can limit security
risks and prevent an attacker from creating a distributed denial of service (DDoS) to
legitimate traffic.



ICMP Timestamp Echo: Disabling the response to these messages can prevent an
attacker from being able to reverse engineer some details of your network
infrastructure.



TCP Window Size: Configures the amount of unacknowledged TCP data that the
SG appliance can receive before sending an acknowledgement.



PMTU Discovery: Enabling PMTU Discovery prevents packets from being unable
to reach their destination because they are too large.

To view the TCP/IP configuration, see “Viewing the TCP/IP Configuration” on page
194.
This section discusses


"RFC-1323" on page 191



"TCP NewReno" on page 192



"ICMP Broadcast Echo Support" on page 192



"ICMP Timestamp Echo Support" on page 192



"TCP Window Size" on page 193



"PMTU Discovery" on page 193



"TCP Time Wait" on page 193



“TCP Loss Recovery Mode” on page 194



"Viewing the TCP/IP Configuration" on page 194

RFC-1323
The RFC-1323 TCP/IP option enables the SG appliance to use a set of extensions to TCP
designed to provide efficient operation over large bandwidth-delay-product paths and
reliable operation over very high-speed paths, including satellite environments. RFC1323 support can be configured through the CLI and is enabled by default.

191

Volume 6: Advanced Networking
To enable or disable RFC-1323 support:
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip rfc-1323 {enable | disable}

TCP NewReno
NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP
performance during fast retransmit and fast recovery when multiple packets are dropped
from a single window of data. TCP NewReno support is enabled by default.
To enable or disable TCP NewReno support:
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip tcp-newreno {enable | disable}

ICMP Broadcast Echo Support
Disabling the ICMP broadcast echo command can prevent the SG appliance from
participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service (DoS) attack,
where the attacker sends an ICMP echo request packet to an IP broadcast address. This is
the same type of packet sent in the ping command, but the destination IP is broadcast
instead of unicast. If all the hosts on the network send echo reply packets to the ICMP
echo request packets that were sent to the broadcast address, the network is jammed with
ICMP echo reply packets, making the network unusable. By disabling ICMP broadcast
echo response, the SG appliance does not participate in the Smurf Attack.
This setting is disabled by default.
To enable or disable ICMP broadcast echo support:
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-bcast-echo {enable | disable}

For more information on preventing DDoS attacks, see Chapter 3: "Attack Detection" on
page 51.

ICMP Timestamp Echo Support
By disabling the ICMP timestamp echo commands, you can prevent an attacker from
being able to reverse engineer some details of your network infrastructure.
For example, disabling the ICMP timestamp echo commands prevents an attack that
occurs when the SG appliance responds to an ICMP timestamp request by accurately
determining the target's clock state, allowing an attacker to more effectively attack certain
time-based pseudo-random number generators (PRNGs) and the authentication systems
on which they rely.
This setting is disabled by default.
To enable or disable ICMP Timestamp echo support:
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-timestamp-echo {enable | disable}

192

Chapter 14: TCP/IP Configuration

TCP Window Size
Adjusting the TCP window-size regulates the amount of unacknowledged data that the
SG appliance receives before sending an acknowledgement.
To configure the TCP window size:
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip window-size window_size

where window_size indicates the number of bytes allowed before acknowledgement
(the value must be between 8192 and 4194304).

PMTU Discovery
PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the
largest packet size sent that is not fragmented anywhere along the path between two
communicating appliances that are not directly attached to the same link.
An SG appliance that is not running PMTU might send packets larger than that allowed by
the path, resulting in packet fragmentation at intermediate routers. Packet fragmentation
affects performance and can cause packet discards in routers that are temporarily
overtaxed.
An SG appliance doing PMTU sets the Do-Not-Fragment bit in the IP header when
transmitting packets. If fragmentation becomes necessary before the packets arrive at the
second SG appliance, a router along the path discards the packets and returns an ICMP
Host Unreachable error message, with the error condition of Needs-Fragmentation, to
the original SG appliance. The first SG appliance then reduces the PMTU size and retransmits the transmissions.
The discovery period temporarily ends when the SG appliance estimates the PMTU is low
enough that its packets can be delivered without fragmentation or when the SG appliance
stops setting the Do-Not-Fragment bit.
Following discovery and rediscovery, the size of the packets that are transferred between
the two communicating nodes dynamically adjust to a size allowable by the path, which
might contain multiple segments of various types of physical networks.
PMTU is disabled by default.
To configure PMTU discovery:
At the (config) command prompt:
SGOS#(config) tcp-ip pmtu-discovery enable | disable

TCP Time Wait
When a TCP connection is closed (such as when a user enters quit for an FTP session), the
TCP connection remains in the TIME_WAIT state for twice the Maximum Segment
Lifetime (MSL) before completely removing the connection control block.
The TIME_WAIT state allows an end point (one end of the connection) to remove remnant
packets from the old connection, eliminating the situation where packets from a previous
connection are accepted as valid packets in a new connection.
The MSL defines how long a packet can remain in transit in the network. The value of
MSL is not standardized; the default value is assigned according to the specific
implementation.

193

Volume 6: Advanced Networking

To change the MSL value, enter the following commands at the (config) command
prompt:
SGOS#(config) tcp-ip tcp-2msl seconds

where seconds is the length of time you chose for the 2MSL value. Valid values are 1
to 16380 inclusive.

TCP Loss Recovery Mode
A new TCP algorithm helps to recover throughput efficiently after packet losses occur and
also addresses performance problems due to a single packet loss during a large transfer
over long delay pipes. The feature is enhanced by default.
To enable the algorithm:
SGOS#(config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive}

To disable the algorithm:
SGOS#(config) tcp-ip tcp-loss-recovery-mode {normal}

Viewing the TCP/IP Configuration
To view the TCP/IP configuration:
SGOS#(config) show tcp-ip
RFC-1323 support:
TCP Newreno support:
IP forwarding:
ICMP bcast echo response:
ICMP timestamp echo response:
Path MTU Discovery:
TCP 2MSL timeout:
TCP window size:
TCP Loss Recovery Mode:

enabled
disabled
disabled
disabled
disabled
disabled
120 seconds
65535 bytes
Aggressive

194

Chapter 15: Virtual IP Addresses

Virtual IP (VIP) addresses are addresses assigned to a system (but not an interface) that
are recognized by other systems on the network. Up to 255 VIPs can be configured on
each SG appliance. They have several uses:


Assign multiple identities to a system on the same or different network, partitioning
the box in to separate logical entities for resource sharing or load sharing.



Create an HTTPS Console to allow multiple, simultaneous, secure connections to
the system.



Direct authentication challenges to different realms.



Set up failover among multiple SG appliances on the same subnet.

Note: For information on creating an HTTPS Console, refer to Volume 3: Proxies and
Proxy Services; for information on using VIPs with authentication realms, refer to
Volume 5: Securing the Blue Coat SG Appliance; to use VIPs with failover, see Chapter 6:
"Configuring Failover" on page 87.

To create a VIP:
1.

Select Configuration > Network > Advanced > VIPs.

2.

Click New.

3.

Enter the virtual IP address you want to use. It can be any IP address, except a
multicast address. (A multicast address is a group address, not an individual IP
address.)
Note: You cannot create a VIP address that is the IP address used by the origin
content server. You must assign a different address on the SG appliance, and use
DNS or forwarding to point to the origin content server's real IP address.

4.

Click OK.

5.

Select Apply to commit the changes to the SG appliance.

The VIP address can now be used.
Related CLI Syntax to manage a VIP
SGOS#(config) virtual address ip_address
SGOS#(config) virtual no address ip_address
SGOS#(config) virtual clear
SGOS#(config) show virtual

195

Volume 6: Advanced Networking

196

Chapter 16: WCCP Settings

The SGOS software can be configured to participate in a WCCP (Web Cache Control
Protocol) scheme, in which a WCCP-capable router collaborates with a set of WCCPconfigured SG appliances to service requests.
Note: Note: Bridge interfaces cannot be used in WCCP configurations. If the
configuration includes bridge interfaces, you will receive the following error if you
attempt to load the WCCP configuration file:

Interface 0:0 is member of a bridge.
Before you can install the WCCP configuration, you must create a WCCP configuration
file for the SG appliance. The appliance does not ship with a default WCCP
configuration file.
You can install the WCCP settings in several ways:


Text Editor, which allows you to enter settings (or copy and paste the contents of an
already-created file) directly onto the appliance.



Local file, installed on your system; the SG appliance can browse to the file and
install it.



A remote URL, where you place an already-created file on an FTP or HTTP server to
be downloaded to the SG appliance.



Using the CLI inline wccp-settings command, which allows you to paste the
WCCP settings into the CLI.



Using the CLI wccp command, which requires that you place an already-created file
on an FTP or HTTP server and enter the URL into the CLI.

For more information about WCCP, see Appendix C: "Using WCCP" on page 211.
To install WCCP settings:
1.
2.

Select Configuration > Network > Advanced > WCCP.
From the drop-down list, select the method used to install the WCCP settings; click
Install.



Remote URL:
Enter the fully-qualified URL, including the filename, where the WCCP file is
located. To view the file before installing it, click View. Click Install. View the
installation status that displays; click OK.



Local File:
Click Browse to display the Local File Browse window. Browse for the file on
the local system. Open it and click Install. When the installation is complete, a
results window opens. View the results, close the window, and click Close.

197

Volume 6: Advanced Networking



Text Editor:
The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the installation is
complete, a results window opens. View the results, close the window, and click
Close.

3.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Install WCCP Settings


To enter WCCP settings directly onto the SG appliance, enter the following commands
at the (config) command prompt:
SGOS#(config) inline wccp-settings end-of-file_marker
wccp enable
wccp version 2
service-group 9
priority 1
protocol 6
service-flags destination-ip-hash
service-flags ports-defined
ports 80 21 1755 554 80 80 80 80
interface 6
home-router 10.16.18.2
forwarding l2
eof



To enter a path to a remote URL where you have placed an already-created static route
table, enter the following commands at the #(config) command prompt:
SGOS#(config) wccp path url

where url is a fully qualified URL, including the filename, where the configuration
file is located.
SGOS#(config) load wccp-settings
SGOS#(config) wccp enable

198

Appendix A: Glossary

Term

Description

ADN Optimize Attribute

Controls whether to optimize bandwidth usage when connecting upstream using an
ADN tunnel.

Asynchronous Adaptive

This allows the ProxySG to keep cached objects as fresh as possible, thus reducing
response times. The AAR algorithm allows HTTP proxy to manage cached objects
based on their rate of change and popularity: an object that changes frequently and/
or is requested frequently is more eligible for asynchronous refresh compared to an
object with a lower rate of change and/or popularity.

Refresh (AAR)

Asynchronous Refresh
Activity

Refresh activity that does not wait for a request to occur, but that occurs
asynchronously from the request.

Attributes (Service)

The service attributes define the parameters, such as explicit or transparent,
cipher suite, and certificate verification, that the SG appliance uses for a
particular service. .

Authenticate-401 Attribute

All transparent and explicit requests received on the port always use transparent
authentication (cookie or IP, depending on the configuration). This is especially
useful to force transparent proxy authentication in some proxy-chaining scenarios

authentication

The process of identifying a specific user.

authorization

The permissions given to a specific user.

Bandwidth Gain

A measure of the difference in client-side and server-side Internet traffic expressed in
relation to server-side Internet traffic. It is managed in two ways: you can enable or
disable bandwidth gain mode or you can select the Bandwidth Gain profile (this also
enables bandwidth gain mode)..

Bandwidth Class

A defined unit of bandwidth allocation. An administrator uses bandwidth classes to
allocate bandwidth to a particular type of traffic flowing through the SG appliance.

Bandwidth Class Hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree
structure that specifies the relationship among different classes. You create a
hierarchy by creating at least one parent class and assigning other classes to be its
children.

Bandwidth Policy

The set of rules that you define in the policy layer to identify and classify the traffic in
the SG appliance, using the bandwidth classes that you create. You must use policy
(through either VPM or CPL) in order to manage bandwidth.

Bypass Lists

The bypass list allows you to exempt IP addresses from being proxied by the SG

appliance. The bypass list allows either or a specific IP prefix entry for
both the client and server columns. Both UDP and TCP traffic is
automatically exempted.

199

Volume 6: Advanced Networking

Term

Description

Byte-Range Support

The ability of the ProxySG to respond to byte-range requests (requests with a Range:
HTTP header).

Cache-hit

An object that is in the ProxySG and can be retrieved when an end user requests the
information.

Cache-miss

An object that can be stored but has never been requested before; it was not in the
ProxySG to start, so it must be brought in and stored there as a side effect of
processing the end-user's request. If the object is cacheable, it is stored and served the
next time it is requested.

Child Class (Bandwidth
Gain)

The child of a parent class is dependent upon that parent class for available
bandwidth (they share the bandwidth in proportion to their minimum/maximum
bandwidth values and priority levels). A child class with siblings (classes with the
same parent class) shares bandwidth with those siblings in the same manner.

Client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's
HTTPS request.

Compression

An algorithm that reduces a file’s size but does not lose any data. The ability to
compress or decompress objects in the cache is based on policies you create.
Compression can have a huge performance benefit, and it can be customized based
on the needs of your environment: Whether CPU is more expensive (the default
assumption), server-side bandwidth is more expensive, or whether client-side
bandwidth is more expensive.

Default Proxy Listener

See “ Proxy Service (Default)” .

Detect Protocol Attribute

Detects the protocol being used. Protocols that can be detected include:
HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

Directives

Directives are commands that can be used in installable lists to configure forwarding.
See also forwarding Configuration.

Display Filter

The display filter is a drop-down list at the top of the Proxy Services pane that allows
you to view the created proxy services by service name or action.

Early Intercept Attribute

Controls whether the proxy responds to client TCP connection requests before
connecting to the upstream server. When early intercept is disabled, the proxy delays
responding to the client until after it has attempted to contact the server.

Emulated Certificates

Certificates that are presented to the user by ProxySG when intercepting
HTTPS requests. Blue Coat emulates the certificate from the server and signs
it, copying the subjectName and expiration. The original certificate is used
between the ProxySG and the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

Encrypted Log

A log is encrypted using an external certificate associated with a private key.
Encrypted logs can only be decrypted by someone with access to the private key. The
private key is not accessible to the SG appliance.

200

Appendix A: Glossary

Term

Description

explicit proxy

A configuration in which the browser is explicitly configured to communicate with
the proxy server for access to content.
This is the default for the SG appliance, and requires configuration for both browser
and the interface card.

Fail Open/Closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways.
Fail Open/Closed applies when the health checks are showing sick for each
forwarding or SOCKS gateway target in the applicable fail-over sequence. If no
systems are healthy, the SG appliance fails open or closed, depending on the
configuration. If closed, the connection attempt simply fails.
If open, an attempt is made to connect without using any forwarding target (or
SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no
setting is specified.

Forwarding Configuration

Forwarding can be configured through the CLI or through adding directives to a text
file and installing it as an installable list. Each of these methods (the CLI or using
directives) is equal. You cannot use the Management Console to configure
forwarding.

Forwarding Host

Upstream Web servers or proxies.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A
forward proxy can be explicit or transparent.

Freshness

A percentage that reflects the objects in the ProxySG cache that are expected to be
fresh; that is, the content of those objects is expected to be identical to that on the OCS
(origin content server).

Gateway

A device that serves as entrance and exit into a communications network.

Global Default Settings

You can configure settings for all forwarding hosts and groups. These are called the
global defaults. You can also configure private settings for each individual
forwarding host or group. Individual settings override the global defaults.

FTP

See Native FTP; Web FTP.

Host Affinity

Host affinity is the attempt to direct multiple connections by a single user to the same
group member. Host affinity is closely tied to load balancing behavior; both should
configured if load balancing is important.

Host Affinity Timeout

The host affinity timeout determines how long a user remains idle before the
connection is closed. The timeout value checks the user's IP address, SSL ID, or
cookie in the host affinity table.

Inbound Traffic (Bandwidth
Gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of
the following:
• Server inbound: Packets originating at the origin content server (OCS) and sent to
the SG appliance to load a Web object.
• Client inbound: Packets originating at the client and sent to the SG

appliance for Web requests.

201

Volume 6: Advanced Networking

Term

Description

Installable Lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one
of several methods: through creating the list through the SG text editor, by placing
the list at an accessible URL, or by downloading the directives file from the local
system.

Integrated Host Timeout

An integrated host is an Origin Content Server (OCS) that has been added to the
health check list. The host, added through the integrate_new_hosts property,
ages out of the integrated host table after being idle for the specified time. The default
is 60 minutes.

IP Reflection

Determines how the client IP address is presented to the origin server for explicitly
proxied requests. All proxy services contain a reflect-ip attribute, which enables or
disables sending of client's IP address instead of the SG's IP address.

Issuer keyring

The keyring that is used by the SG appliance to sign emulated certificates. The
keyring is configured on the appliance and managed through policy.

Listener

The service that is listening on a specific port. A listener can be identified by any

destination IP/subnet and port range. Multiple listeners can be added to
each service.
Load Balancing

The ability to share traffic requests among multiple upstream targets. Two methods
can be used to balance the load among systems: least-connections or roundrobin.

Log Facility

A separate log that contains a single logical file and supports a single log format. It
also contains the file’s configuration and upload schedule information as well as
other configurable information such as how often to rotate (switch to a new log) the
logs at the destination, any passwords needed, and the point at which the facility can
be uploaded.

Log Format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or
Websense.
The proprietary log types each have a corresponding pre-defined log format that has
been set up to produce exactly that type of log (these logs cannot be edited). In
addition, a number of other ELFF type log formats are also pre-defined (im, main,
p2p, ssl, streaming). These can be edited, but they start out with a useful set of log
fields for logging particular protocols understood by the SG appliance. It is also
possible to create new log formats of type ELFF or Custom which can contain any
desired combination of log fields.

Log Tail:

The access log tail shows the log entries as they get logged. With high traffic on the
SG appliance, not all access log entries are necessarily displayed. However, you can
view all access log information after uploading the log.

Maximum Object Size

The maximum object size stored in the ProxySG. All objects retrieved that are greater
than the maximum size are delivered to the client but are not stored in the ProxySG.

NCSA common log format

A log type that contains only basic HTTP access information.

202

Appendix A: Glossary

Term

Description

Negative Responses

An error response received from the OCS when a page or image is requested. If the
ProxySG is configured to cache such negative responses, it returns that response in
subsequent requests for that page or image for the specified number of minutes. If it
is not configured, which is the default, the ProxySG attempts to retrieve the page or
image every time it is requested.

Native FTP

Native FTP involves the client connecting (either explicitly or transparently) using
the FTP protocol; the SG appliance then connects upstream through FTP (if
necessary).

Outbound Traffic
(Bandwidth Gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists
of the following:
• Client outbound: Packets sent to the client in response to a Web request.
• Server outbound: Packets sent to an OCS or upstream proxy to request a service.

Origin Content Server (OCS)
Parent Class (Bandwidth
Gain)

PASV

A class with at least one child. The parent class must share its bandwidth with its
child classes in proportion to the minimum/maximum bandwidth values or priority
levels.
Passive Mode Data Connections. Data connections initiated by an FTP client to

an FTP server.
proxy

Caches content, filters traffic, monitors Internet and intranet resource usage, blocks
specific Internet and intranet resources for individuals or groups, and enhances the
quality of Internet or intranet user experiences.
A proxy can also serve as an intermediary between a Web client and a Web server
and can require authentication to allow identity based policy and logging for the
client.
The rules used to authenticate a client are based on the policies you create on the SG
appliance, which can reference an existing security infrastructure—LDAP, RADIUS,
IWA, and the like.

Proxy Service

The proxy service defines the ports, as well as other attributes. that are used by the
proxies associated with the service.

Proxy Service (Default)

The default proxy service is a service that intercepts all traffic not otherwise
intercepted by other listeners. It only has one listener whose action can be set to
bypass or intercept. No new listeners can be added to the default proxy service, and
the default listener and service cannot be deleted. Service attributes can be changed.

realms

A realm is a named collection of information about users and groups. The name is
referenced in policy to control authentication and authorization of users for access to
Blue Coat Systems SG services. Multiple authentication realms can be used on a
single SG appliance. Realm services include IWA, LDAP, Local, and RADIUS.

Reflect Client IP Attribute

Enables the sending of the client's IP address instead of the SG's IP address to the
upstream server. If you are using an Application Delivery Network (ADN), this
setting is enforced on the concentrator proxy through the Configuration>App.
Delivery Network>Tunneling tab.

203

Volume 6: Advanced Networking

Term

Description

Refresh Bandwidth

The amount of bandwidth used to keep stored objects fresh. By default, the ProxySG
is set to manage refresh bandwidth automatically. You can configure refresh
bandwidth yourself, although Blue Coat does not recommend this.

reverse proxy

A proxy that acts as a front-end to a small number of pre-defined servers, typically to
improve performance. Many clients can use it to access the small number of
predefined servers.

rotate logs

When you rotate a log, the old log is no longer appended to the existing log, and a
new log is created. All the facility information (headers for passwords, access log
type, and so forth), is re-sent at the beginning of the new upload.
If you're using Reporter (or anything that doesn't understand the concept of "file,”
such as streaming) the upload connection is broken and then re-started, and, again,
the headers are re-sent.

serial console

A device that allows you to connect to the SG appliance when it is otherwise
unreachable, without using the network. It can be used to administer the SG
appliance through the CLI. You must use the CLI to use a serial console.
Anyone with access to the serial console can change the administrative access
controls, so physical security of the serial console is critical.

Server Certificate Categories

The hostname in a server certificate can be categorized by BCWF or another content
filtering vendor to fit into categories such as banking, finance, sports.

Sibling Class (Bandwidth
Gain)

A bandwidth class with the same parent class as another class.

SOCKS Proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both
SOCKSv4/4a and SOCKSv5; however, because of increased username and password
authentication capabilities and compression support, Blue Coat recommends that
you use SOCKS v5..

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter
tool.

Split proxy

Employs co-operative processing at the branch and the core to implement
functionality that is not possible in a standalone proxy. Examples of split
proxies include :
Mapi Proxy
SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics.

SSL

A standard protocol for secure communication over the network. Blue Coat
recommends using this protocol to protect sensitive information.

SSL Interception

Decrypting SSL connections.

SSL Proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or
reverse proxy mode.

204

Appendix A: Glossary

Term

Description

static routes

A manually-configured route that specifies the transmission path a packet must
follow, based on the packet’s destination address. A static route specifies a
transmission path to another network.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The
SurfControl log format includes fully-qualified usernames when an NTLM realm
provides authentication. The simple name is used for all other realm types.

Traffic Flow (Bandwidth
Gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection
that terminate at, originate at, or flow through the SG appliance. A single request
from a client involves two separate connections. One of them is from the client to the
SG appliance, and the other is from the SG appliance to the OCS. Within each of
these connections, traffic flows in two directions—in one direction, packets flow out
of the SG appliance (outbound traffic), and in the other direction, packets flow into
the SG (inbound traffic). Connections can come from the client or the server. Thus,
traffic can be classified into one of four types:
• Server inbound
• Server outbound
• Client inbound
• Client outbound
These four traffic flows represent each of the four combinations described above.
Each flow represents a single direction from a single connection.

transparent proxy

A configuration in which traffic is redirected to the SG appliance without the
knowledge of the client browser. No configuration is required on the browser, but
network configuration, such as an L4 switch or a WCCP-compliant router, is
required.

Variants

Objects that are stored in the cache in various forms: the original form, fetched from
the OCS; the transformed (compressed or uncompressed) form (if compression is
used). If a required compression variant is not available, then one might be created
upon a cache-hit. (Note: policy-based content transformations are not stored in the
ProxySG.)

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and
accesses an ftp:// URL. The SG appliance translates the HTTP request into
an FTP request for the OCS (if the content is not already cached), and then
translates the FTP response with the file contents into an HTTP response for
the client.

Websense log type

A proprietary log type that is compatible with the Websense reporter tool.

205

Volume 6: Advanced Networking

Term

Description

Wildcard Services

When multiple non-wildcard services are created on a port, all of them must be of the
same service type (a wildcard service is one that is listening for that port on all IP
addresses). If you have multiple IP addresses and you specify IP addresses for a port
service, you cannot specify a different protocol if you define the same port on another
IP address. For example, if you define HTTP port 80 on one IP address, you can only
use the HTTP protocol on port 80 for other IP addresses.
Also note that wildcard services and non-wildcard services cannot both exist at the
same time on a given port.
For all service types except HTTPS, a specific listener cannot be posted on a port if
the same port has a wildcard listener of any service type already present.

206

Appendix B: Using Policy to Manage Forwarding

After ICP, forwarding, and the SOCKS gateways are configured, use policy to create
and manage forwarding rules. Forwarding, ICP, and SOCKS gateway rules should go
in the layer of the Forwarding Policy file or the VPM Policy file (if you use
the VPM).
The separate layer is provided because the URL can undergo URL rewrites
before the request is fetched. This rewritten URL is accessed as a server_url and
decisions about upstream connections are based on the rewritten URL, requiring a
separate layer. All policy commands allowed in the layer are described
below.
Table B-1. Policy Commands Allowed in the Layer
Forwarding

Description

Conditions
client_address=

Tests the IP address of the client. Can also be used in
and layers.

client.host=

Tests the hostname of the client (obtained through RDNS). Can
also be used in , , and layers.

client.host.has_name=

Tests the status of the RDNS performed to determine
client.host. Can also be used in , , and
layers.

client.protocol=

Tests true if the client transport protocol matches the
specification. Can also be used in and
layers.

date[.utc]=

Tests true if the current time is within the startdate..enddate
range, inclusive. Can be used in all layers.

day=

Tests if the day of the month is in the specified range or an exact
match. Can be used in all layers.

has_client=

has_client= is used to test whether or not the current
transaction has a client. This can be used to guard triggers that
depend on client identity.

hour[.utc]=

Tests if the time of day is in the specified range or an exact match.
Can be used in all layers.

im.client=

Tests the type of IM client in use. Can also be used in ,
, and layers.

im.message.reflected=

Tests whether IM reflection occurred. Can also be used in
and layers.

minute[.utc]=month[.utc]=

Tests if the minute of the hour is in the specified range or an exact
match. Can be used in all layers.

207

Volume 6: Advanced Networking

Table B-1. Policy Commands Allowed in the Layer (Continued)
Forwarding

Description

proxy.address=

Tests the IP address of the network interface card (NIC) on which
the request arrives. Can also be used in and
layers.

proxy.card=

Tests the ordinal number of the network interface card (NIC)
used by a request. Can also be used in and
layers.

proxy.port=

Tests if the IP port used by a request is within the specified range
or an exact match. Can also be used in and
layers.

server_url[.case_sensitive|.no_
lookup]=

Tests if a portion of the requested URL exactly matches the
specified pattern.

server_url.address=

Tests if the host IP address of the requested URL matches the
specified IP address, IP subnet, or subnet definition.

server_url.domain[.case_sensitive]
[.no_lookup]=

Tests if the requested URL, including the domain-suffix portion,
matches the specified pattern.

server_url.extension[.case_
sensitive]=

Tests if the filename extension at the end of the path matches the
specified string.

server_url.host.has_name=

Tests whether the server URL has a resolved DNS hostname.

server_url.host[.exact|.substring|
.prefix|.suffix|.regex][.no_lookup
]=

Tests if the host component of the requested URL matches the IP
address or domain name.

server_url.host.is_numeric=

This is true if the URL host was specified as an IP address.

server_url.host.no_name=

This is true if no domain name can be found for the URL host.

server_url.host.regex=

Tests if the specified regular expression matches a substring of
the domain name component of the requested URL.

server_url.is_absolute=

Tests whether the server URL is expressed in absolute form.

server_url.path[.exact|.substring|
.prefix|.suffix|.regex]
[.case_sensitive]=

Tests if a prefix of the complete path component of the requested
URL, as well as any query component, matches the specified
string.

server_url.path.regex=

Tests if the regex matches a substring of the path component of
the request URL.

server_url.port=

Tests if the port number of the requested URL is within the
specified range or an exact match.

server_url.query.regex=

Tests if the regex matches a substring of the query string
component of the request URL.

server_url.regex=

Tests if the requested URL matches the specified pattern.

server_url.scheme=

Tests if the scheme of the requested URL matches the specified
string.

socks=

This condition is true whenever the session for the current
transaction involves SOCKS to the client.

208

Appendix B: Using Policy to Manage Forwarding

Table B-1. Policy Commands Allowed in the Layer (Continued)
Forwarding

Description

socks.version=

Switches between SOCKS 4/4a and 5. Can also be used in
and layers.

streaming.client=

yes | no. Tests the user agent of a Windows, Real Media, or
QuickTime player.

time[.utc]=

Tests if the time of day is in the specified range or an exact match.
Can be used in all layers.

tunneled=

yes | no. Tests TCP tunneled requests, HTTP CONNECT
requests, and unaccelerated SOCKS requests

weekday[.utc]=

Tests if the day of the week is in the specified range or an exact
match. Can be used in all layers.

year[.utc]=

Tests if the year is in the specified range or an exact match. Can
be used in all layers.

Properties
access_server()

Determines whether the client can receive streaming content
directly from the OCS. Set to no to serve only cached content.

ftp.transport()

Determines the upstream transport mechanism.
This setting is not definitive. It depends on the capabilities of the
selected forwarding host.

forward()

Determines forwarding behavior.
There is a box-wide configuration setting
(config>forwarding>failure-mode) for the forward
failure mode. The optional specific settings can be used to
override the default.

forward.fail_open()

Controls whether the SG appliance terminates or continues to
process the request if the specified forwarding host or any
designated backup or default cannot be contacted.

http.refresh.recv.timeout()

Sets the socket timeout for receiving bytes from the upstream
host when performing refreshes. Can also be used in
layers.

http.server.connect_attempts()

Sets the number of attempts to connect performed per-address
when connecting to the upstream host.

http.server.recv.timeout()

Sets the socket timeout for receiving bytes from the upstream
host. Can also be used in layers.

icp()

Determines when to consult ICP. The default is yes if ICP hosts
are configured and if no forwarding host or SOCKS gateway is
identified as an upstream target.

im.transport()

Sets the type of upstream connection to make for IM traffic.

integrate_new_hosts()

Determines whether to add new host addresses to health checks
and load balancing. The default is no. If it is set to yes, any new
host addresses encountered during DNS resolution of
forwarding hosts are added to health checks and load balancing.

209

Volume 6: Advanced Networking

Table B-1. Policy Commands Allowed in the Layer (Continued)
Forwarding

Description

reflect_ip()

Determines how the client IP address is presented to the origin
server for explicitly proxied requests. Can also be used in
layers.

socks_gateway()

The socks_gateway() property determines the gateway and
the behavior of the request if the gateway cannot be contacted.
There is a box-wide configuration setting for the SOCKS failure
mode. The optional specific settings can be used to override the
default.

socks_gateway.fail_open()

Controls whether the SG appliance terminates or continues to
process the request if the specified SOCKS gateway or any
designated backup or default cannot be contacted.

streaming.transport()

Determines the upstream transport mechanism. This setting is
not definitive. The ability to use streaming.transport()
depends on the capabilities of the selected forwarding host.

trace.request()

Determines whether detailed trace output is generated for the
current request. The default value is no, which produces no
output

trace.rules()

Determines whether trace output is generated that shows each
policy rule that fired. The default value of no suppresses output.

trace.destination()

Used to change the default path to the trace output file. By
default, policy evaluation trace output is written to an object in
the cache accessible using a console URL of the following form:
http://ProxySG_ip_address:8081/Policy/
Trace/path

Actions
notify_email()

Sends an e-mail notification to the list of recipients specified in
the Event Log mail configuration. Can be used in all layers.

notify_snmp()

The SNMP trap is sent when the transaction terminates. Can be
used in all layers.

log_message

Writes the specified string to the event log.

Definitions
define server_url.domain condition
name

Binds a user-defined label to a set of domain suffix patterns for
use in a condition= expression.

210

Appendix C: Using WCCP

This appendix discusses how to configure an SG appliance to participate in a Web Cache
Communication Protocol (WCCP) scheme, when a WCCP-capable router collaborates
with a set of WCCP-configured appliances to service requests. If you are already
familiar with WCCP version 2 and want to get your router and SG appliance up and
running right away, see the “Quick Start” on page 213.

Overview
WCCP is a Cisco®-developed protocol that allows you to establish redirection of the
traffic that flows through routers.
The main benefits of using WCCP are:


Scalability. With no reconfiguration overhead, redirected traffic can be
automatically distributed to up to 32 appliances.



Redirection safeguards. If no appliances are available, redirection stops and the
router forwards traffic to the original destination address.

WCCP has two versions, version 1 and version 2, both of which are supported by Blue
Coat. However, only one protocol version can be active on the SG appliance at a time.
The active WCCP protocol set up in the SG configuration must match the version
running on the WCCP router.

Using WCCP and Transparent Redirection
A WCCP-capable router operates in conjunction with the appliances to transparently
redirect traffic to a set of caches that participate in the specified WCCP protocol. IP
packets are redirected based on fields within each packet. For instance, WCCP version
1 only redirects destination TCP port 80 (default HTTP traffic) IP packets. WCCP
version 2 allows you to redirect traffic from other ports and protocols.
Load balancing is achieved through a redirection hash table to determine which SG
appliance receives the redirected packet.

WCCP Version 1
In WCCP version 1, the WCCP-configured home router transparently redirects TCP
port 80 packets to a maximum of 32 appliances. (An SG appliance is seen as a cache in
WCCP protocol.)
One of the caches participating in the WCCP service group is automatically elected to
configure the home router’s redirection tables. This way, caches can be transparently
added and removed from the WCCP service group without requiring operator
intervention. WCCP version 1 supports only a single service group.
Each applicable client IP packet received by the home router is transparently redirected
to a cache. An SG appliance from the group is selected to define the home router’s
redirection hash table for all caches. All caches periodically communicate with the
home router to verify WCCP protocol synchronization and SG availability within the
service group. In return, the home router responds to each cache with information as to
which appliances are available in the service group.

211

Volume 6: Advanced Networking
To create an SG appliance WCCP configuration file and enable WCCP:
1.

Create a WCCP configuration file through either the SG appliance’s CLI inline
commands or through a text editor. Make sure that the home router you enter here is
the home router that was named in the router’s configuration. If you do have a
mismatch, you must correct it before continuing. See “Identifying a Home Router/
Router ID Mismatch” on page 231.
For more information on creating a configuration file, see “Creating an SG Appliance
WCCP Configuration File” on page 220.
If you used the inline commands, you have completed WCCP configuration for both
the router and the SG appliance and you have enabled WCCP on the SG appliance. No
further steps are needed.

2.
3.

If you used a text editor, copy the file to an HTTP server accessible to the SG appliance.
Enable WCCP and download the configuration file to the SG appliance.
SGOS#(config) wccp enable
SGOS#(config) wccp path http://205.66.255.10/files/wccp.txt
SGOS#(config) load wccp-settings

Configuring a WCCP Version 2 Service on the Router
Configuring a router requires that you work with two different types of configuration
commands:


Creating a service group (which uses global settings).



Configuring the Internet-Connected Interface (which uses interface settings).

Define service group settings before defining adapter interface settings.

Setting up a Service Group
Services are of two types:


Well known services (web-cache for port 80—HTTP— redirection)



The web-cache service group is supported by both Cisco and Blue Coat.



Dynamic services (which can be used for other services, such as FTP, RTSP redirection,
and reverse proxy).



Dynamic service uses identifiers ranging from 0-99 to name the service group.

WCCP global settings allow you to name the service group and then define the
characteristics for that service group. Even if you use the pre-defined Web-cache service
group, you should:


configure a multicast group address



create and identify a redirection access list and associate it with a service group



create and identify a cache bypass list and associate it with a service group



create password authentication for messages sent by the service group to the router

Syntax for configuring a service group (global settings):
ip wccp {web-cache | service-number} [group-address group_address]
[redirect-list access-list] [group-list access-list] [password
password]

214

Appendix C: Using WCCP

where:
web-cache

Enables port 80 (HTTP) service.

service-number

The identification number of the cache service group being controlled by the router. Services
are identified using a value from 0 to 99. The reverse-proxy service is indicated using the
value 99, although any value can be used for reverse proxy.

group-address
groupaddress

(Optional) If no redirect list is defined (the default), all traffic is redirected. The group address
option directs the router to use a specified multicast IP address to coalesce the “I See You”
responses to the “Here I Am” messages that it has received on this address. The groupaddress argument requires a multicast address used by the router to determine which cache
engine receives redirected messages. The response is sent to the group address, as well. If no
group address is defined (the default), all “Here I Am” messages are responded to with a
unicast reply.

redirect-list
access-list

(Optional) Directs the router to use an access list to control traffic redirected to the defined
service group. The access-list parameter specifies either a number from 1 to 99 identifying a
predefined standard or extended access list number, or a name (up to 64 characters long)
identifying an existing standard or extended access list. The access list itself specifies which
traffic can be redirected.

group-list
access-list

(Optional) If no group list is defined (the default), all caches might participate in the service
group.
The group-list option directs the router to use an access list to determine which caches are
allowed to participate in the service group. The access-list parameter specifies either a
number from 1 to 99 identifying a predefined standard or extended access list number or a
name (up to 64 characters long) identifying an existing standard or extended access list. The
access list itself specifies which caches are permitted to participate in the service group.

password
password

(Optional) By default, password authentication is not configured and authentication is
disabled.
The password option increases authentication security to messages received from the service
group specified by the service-number. Messages that do not pass authentication are
discarded. The password can be up to eight characters long.
If you specify a password in the router configuration, you must also configure the same
password separately on each cache.

Naming a Service Group and Enabling WCCP
WCCP version 2 is enabled when you name a WCCP service group. (Version 1 requires a
specific enable command.) The service group can already exist, such as web-cache, or it
could be a new group, such as 36.
To name a service group and enable WCCP:
From the router (config) mode, enter the following command:
Router#(config) ip wccp web-cache
-orRouter#(config) ip wccp 36

Configuring a Global Multicast Group Address
Benefits of using a multicast address include reduced WCCP protocol traffic and the
ability to easily add and remove caches and routers from a service group without having
to reconfigure all service group members. Multicast addresses fall within the range of
224.0.0.0 to 239.255.255.255.

215

Volume 6: Advanced Networking

Use the following syntax to configure a global multicast group address for multicast cache
discovery.
ip wccp {web-cache | service-number} [group-address group_address]

To configure a multicast address:
From the router (config) mode, name the group that uses the multicast address, provide
the address, then tell the router which adapter interface is used:
Router(config)# ip wccp 36 group-address 225.1.1.1
Router(config)# interface ethernet 0
Router(config-if)# end

Creating a Redirection Access List and Associating it with a Service
Group
Redirection access lists can contain commands redirecting packets from one network or
cache to another. The lists also can be used to determine which caches participate in which
service groups.
The two lists, although similar, have different purposes, and are applied to the router
differently. The redirection lists are applied with the redirect-list option. The cache bypass
lists are applied with the group-list argument. Both lists can be identified with either a
name or a number.
Use the following syntax to create a redirection access list. This is partial syntax for this
command. Access lists are very complicated; refer to the Cisco Web site for complete
syntax.
access-list acl_ID [deny | permit] protocol {[source_addr source_mask]
| [local_addr local_mask]}

where:
acl_ID

Names the access list you are creating. You can use either a name or number.

deny

Indicates that you do not want to allow a packet to traverse the Cisco router. By default, the
router firewall denies all inbound or outbound packets unless you specifically permit access.

permit

Selects a packet to traverse the PIX firewall. By default, the router firewall denies all inbound
or outbound packets unless you specifically permit access.

protocol

Identifies, by name or number, an IP protocol. This parameter can be one of the keywords
icmp, ip, tcp, or udp, or an integer in the range 1 to 254 representing an IP protocol number.
To match any Internet protocol, including ICMP, TCP, and UDP, use the keyword ip.

source_addr

Indicates the address of the network or host from which the packet is being sent. Use the
keyword any as an abbreviation for an address of 0.0.0.0.

source_mask

Specifies the netmask bits (mask) to be applied to source_addr, if the source address is for a
network mask. Use the keyword any as an abbreviation for a mask of 0.0.0.0.

local_addr

Indicates the address of the network or host local to the PIX firewall. The local_addr is the
address after NAT has been performed. Use the keyword host, followed by address, as an
abbreviation for a mask of 255.255.255.255.

local_mask

Specifies the netmask bits (mask) to be applied to local_addr, if the local address is a
network mask. Use the keyword host followed by address as an abbreviation for a mask of
255.255.255.255.

216

Appendix C: Using WCCP

To create a redirection access list or a cache bypass list:
From the router (config) prompt, name an access list and assign rules to it.
Router(config)# access-list 100 deny ip any host 126.10.10.10
Router(config)# access-list 100 permit ip any any
Router#


The commands above gave the access list a name of 100.



Denied packets from any protocol to be sent from any host on the 126.10.10.10
network.



Permitted packets from any protocol to be sent from any other network.

To associate a redirection access list with a specific service group:
1.

Create a redirection access list.

2.

Associate the access list with a specified service group.
ip wccp {web-cache | service-number} [redirect-list access-list]
Router(config)# interface ethernet 0/0
Router(config-if)# ip wccp web-cache redirect-list 100
Router(config-if)# end
Router#

To associate a cache bypass access list with a specific service group:
1.

Create a redirection access list, using the syntax discussed above.

2.

Associate the access list with a specified service group.
ip wccp {web-cache | service-number} [group-list access-list]
Router(config)# interface ethernet 0
Router(config-if)# ip wccp web-cache group-list 120
Router(config-if)# end
Router#

Configuring the Internet-Connected Interface
WCCP interface settings allow you to configure the Internet-connected adapter interface
that redirects Web traffic to the content engine.
Using the interface commands allows you to:


Enable and prevent packet redirection



Enable reception of multicast packets for service group member routers

Syntax for configuring an Internet-connected adapter interface (interface settings):
ip wccp [{web-cache | service-number} redirect out | group-listen] |
redirect exclude in

where:
web-cache

Enables the Web cache service group.

service-number

The identification number of the cache service group being controlled by
the router. Services are identified using a value from 0 to 99. The reverseproxy service is indicated using the value 99.

redirect out

Enables packet redirection on an outbound (Internet facing) adapter
interface.

217

Appendix C: Using WCCP

Enabling Reception of Multicast Packets
Benefits of using a multicast address include reduced WCCP protocol traffic and the
ability to easily add and remove caches and routers from a service group without having
to reconfigure all service group members. You (optionally) set up a multicast group
address in "Configuring a Global Multicast Group Address". In the following procedure,
you enable the reception of the pre-defined IP multicast packets to routers that are
members of the group.
Multicast addresses fall within the range 224.0.0.0 to 239.255.255.255.
Use the following syntax to configure for multicast discovery of the cache(s).
ip wccp {web-cache | service-number} group-listen

The following example configures the router to use the WCCP 36 service group to redirect
port 80 destination traffic. WCCP protocol traffic uses multicast address 225.1.1.1.
Adapter interface “Ethernet 0” is used to receive the multicast WCCP traffic.
Router(config)# ip wccp 36 group-address 225.1.1.1
Router(config)# interface ethernet 0
Router(config-if)# ip wccp web-cache group-listen
Router(config-if)# end

Saving and Viewing Changes
Once you have made all the changes, you must permanently save them to disk. If not, the
changes are lost at the next reboot of the router.
To save router configuration:
Router# write memory

To display all current WCCP configuration settings:
Use the following syntax to verify the settings in the new router configuration and to
ensure that the appropriate cache engines are visible to the router.
show ip wccp {web-cache | service-number} [view | detail]

where
view

(Optional) Lists all members of the identified service group and whether they have
been detected.

detail

(Optional) Displays IP and protocol version information about the router. Displays IP,
protocol version, state, initial and assigned hash, hash allotment, redirected packet,
and connection time information about the associated cache engine (SG appliance).

For example:
Router# show ip wccp web-cache view
Global WCCP Information:
Service Name: web-cache:
Number of Cache Engines:1
Number of Routers:1
Total Packets Redirected:186
Redirect Access-list:120
Total Packets Denied Redirect:57
Total Packets Unassigned:-noneGroup Access-list:0
Total Messaged Denied to Group:0
Total Authentication Failures:0

219

Volume 6: Advanced Networking

WCCP Router Informed of:
86.135.77.10
186.135.77.20
WCCP Cache Engines Visible:
186.135.77.11
186.135.77.12
WCCP Cache Engines Not Visible:
-none-

Creating an SG Appliance WCCP Configuration File
Once you have the router global and adapter interface settings complete, you must create
a WCCP configuration file for the SG appliance. These configurations should include the
following:


Identify the service group.



Identify the queuing priorities for all defined service groups.



Identify the protocol.



Load balancing caches in a service group.



Identify ports.



Identify the home router as defined in the router configuration.



Identify the packet forwarding method.

Understanding Packet Forwarding
By default, Cisco’s GRE encapsulation (Generic Routing Encapsulation) is used to
forward packets from the WCCP router to the caches. If you have a version 2 WCCP
router, you can alternatively use Layer 2 (L2) rewrites to forward packets, which is faster
than GRE and saves network bandwidth.
Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header.
Using L2, redirected packets are not encapsulated; the MAC address of the target cache
replaces the packet’s destination MAC address. This different way of directing packets
saves you the overhead of creating the GRE packet at the router and decoding it at the
cache. Also, it saves network bandwidth that would otherwise be consumed by the GRE
header.
If you want to continue using GRE, you need not change any settings. To use L2 packet
redirection, you must add the forwarding option to the SG configuration file.
If WCCP version 2 is supported, the router sends out a list of forwarding mechanisms
supported by the router in the first WCCP2_I_SEE_YOU message. The cache responds with a
WCCP2_HERE_I_AM message. If the router does not send the list, the cache aborts its
attempt to join the WCCP service group. If the method of forwarding mechanism is not
supported by the router, the WCCP2 messages from the cache are ignored.
Caveats for using L2 redirection:


You must use WCCP version 2.



If a cache is not connected directly to a router, the router does allow the cache to
negotiate the rewrite method.

220

Volume 6: Advanced Networking

For instance, consider a configuration with five caches that use a primary-hash-weight
defined as {25, 200, 0, 50, 25}. The total requested weight value is 25+200+0+50+25=300
and, therefore, the proportion of the hash table assigned to each SG appliance is 25/300,
200/300, 0/300, 50/300, and 25/300.
Because one cache did not specify a non-zero primary-hash-weight, that cache is assigned
any elements within the redirection hash table and, therefore, does not receive any
redirected traffic. Also, the hash weight can be specified for each caching member within a
SG appliance. In Figure C-4, Cache 2 and Cache 3 can be assigned different weight values.

Alternate Hash Table
In some cases, a Web site becomes an Internet hot spot, receiving a disproportional number
of client traffic relative to other sites. This situation can cause a larger request load on a
specific SG appliance because the hash element associated with the popular site receives
more activity than other hash elements.
To balance the redirection traffic load among the caches, a service group can be configured
to use an alternate hash function when the number of GRE packets forwarded to the cache
exceeds a certain number. (If you use L2 forwarding, the SG appliance counts MAC
addresses.) Therefore, when a router receives an IP packet that hashes to an element
flagged as a hot spot, the alternate hash function is computed. The SG appliance specified
by the new index in the redirection hash table receives the redirected packet.
Each SG appliance can dynamically determine a hot spot within its assigned portion of the
redirection hash table.
Alternate hash tables are only used for dynamic service groups that specify alternate-hash
flags within their service-flags. The default Web-cache service group cannot use an
alternate hash table. Instead, a comparable dynamic service group must be created.
To use hot spot detection, the SG appliance’s WCCP configuration file must specify:
service-flags source-ip-hash
service-flags destination-port-alternate-hash

Creating a Configuration File
An example of a file using a dynamic service, as opposed to the default Web-cache service,
is shown below:
If using the default Web-cache service, the service group settings priority, protocol,
service flags, and ports are not used.
wccp enable
wccp version 2
service-group 9
forwarding-type L2
priority 1
protocol 6
service-flags destination-ip-hash
service-flags ports-defined
ports 80 21 1755 554 80 80 80 80
interface 6
home-router 10.16.18.2
end

You can create a configuration file customized for the environment two ways: CLI inline
commands or through a text file. In either case, the configuration file must include the
information required by the commands below.
Syntax to create a customized configuration file:

222

Appendix C: Using WCCP

service-group {web-cache | service-number}
[priority priority-number]
[protocol protocol-number]
[service-flags hash-bit-identifier]
[ports port1 … port8]
home-router [ip-address | domain-name]
interface [interface-number]
[password string]
[primary-hash-weight interface-number value]
forwarding-type [GRE | L2]

Using Optional Negation Syntax, you can create an alternative WCCP configuration file
using these negative commands; this is especially helpful when testing and debugging.
This functionality enables you to change some of the configuration settings without
altering or reloading the main configuration file.
[no] service-group {web-cache | service-number}
[priority priority-number]
[protocol protocol-number]
[no] service-flags hash-bit-identifier
[ports port1 …port8]
home-router [ip-address | domain-name]
[multicast-ttl [ttl_value]]
[no] interface [interface-number]
[password string | no password]
[primary-hash-weight interface-number value]

where:
web-cache

Enables the Web cache service group. If using the Web-cache service group for
WCCP, the dynamic service group settings (priority, protocol, service
flags, and ports) are not applicable.

service-number

The identification number of the dynamic service group being controlled by the
router. Services are identified using a value from 0 to 99. The reverse-proxy service
is indicated using the value 99.

priority-number

(Applies to a dynamic service group only. A dynamic service group is one
identified by a service number.) Establishes queuing priorities for all defined
service groups, based on a priority number from 0 through 255, inclusive.

protocol-number

(Applies to a dynamic service group only. A dynamic service group is one
identified by a service number.) Number of an Internet protocol. Protocolnumber must be an integer in the range 0 through 255, inclusive, representing an
IP protocol number.

hash-bit-identifier

(Applies to a dynamic service group only. A dynamic service group is one
identified by a service number.) Sets the hash index, for load balancing purposes.
The key associated with the hash-bit-identifier you specify is hashed to
produce the primary redirection hash table index. For instance, if only the
destination-ip-hash flag is set, then the packet destination IP address is used
to determine the index. The index is constructed by starting with an initial value of
zero and then computing an exclusive OR (XOR) of the fields specified in the hashbit identifier.
If alternative hashing has been enabled, any alternate hash flags are processed in
the same way and produce a secondary redirection hash table index. Alternate
hash flags end with the suffix “-alternate-hash.”
For more information using the hashing table, see “Understanding Cache Load

Balancing” on page 221.

223

Volume 6: Advanced Networking

source-ip-hash

Sets the source IP bit definition within the redirection hash table index.

(hash-bit-identifier)
destination-ip-hash

Sets the source IP bit definition within the redirection hash table index.

(hash-bit-identifier)
source-port-hash
(hash-bit-identifier)

Sets the source port bit definition within the redirection hash table index.

destination-port-hash
(hash-bit-identifier)

Sets the destination port bit definition within the redirection hash table index.

ports-defined
(hash-bit-identifier)

Sets the port bit definition within the redirection hash table index.

ports-source
(hash-bit-identifier)

Sets the source port bit definition within the redirection hash table index.

source-ip-alternatehash
(hash-bit-identifier)

Sets the alternate source IP bit definition within the redirection hash table index.

destination-ipalternate-hash

Sets the alternate destination IP bit definition within the redirection hash table
index.

(hash-bit-identifier)
source-portalternate-hash

The alternate source port bit definition within the redirection hash table index.

(hash-bit-identifier)
destination-portalternate-hash

Sets the alternate destination port bit definition within the redirection hash table
index.

(hash-bit-identifier)
multicast-ttl

Sets the multicast TTL value per WCCP service group. The value must be set
between 1 and 255.
If the multicast TTL value is not set, the default value is 1. If the home-router
address is not multicast, this command is non-operational.

port1…port8

(Applies to a dynamic service group only. A dynamic service group is one
identified by a service number.) A zero-terminated list of TCP port identifiers.
Note that this must be a list of exactly eight ports.
If the service-flags ports-defined flag is set, packets are matched against the set of
ports supplied. If the service-flags ports-source flag is set, the ports are
assumed to be source ports. Otherwise, the ports are assumed to be destination
ports.

ip-address

Indicates the IP address of your network's home router. For version 2, ipaddress can be a multicast address. (Multicast addresses are in the range
224.0.0.0 to 239.255.255.255, inclusive.)
In version 2, multiple IP addresses can be specified for unicast addressing. For
multicast addresses, only one IP address can be specified per service group.
If you choose to specify the home router IP address, it is important that the actual
home router IP address and the home router IP address specified in this SG
configuration file match. If you do not already know the IP address of the home
router, you can easily determine it from the router CLI by using the show ip
wccp command.

224

Appendix C: Using WCCP

domain-name

Specifies the domain name of your network's home router. Domain-name must be
a valid domain name string that successfully resolves on DNS lookup.

interface-number

Specifies the adapter interface number for the service group. You cannot use a
colon (0:0 or 0:1, for example).

string

(Applies to a dynamic service group only. A dynamic service group is one
identified by a service number.) String can be at least one, and not more than eight,
alphanumeric characters long.
The password string specified here must match the password string declared for
the router.

interface-number

(When used with the hash identifiers) Specifies the adapter interface to which the
weight factor is applied to alter the distribution of the primary hash table.

value

Specifies the weight factor value (0 through 255) that is applied to the adapter
interface specified to alter the distribution of the primary hash table.

forwarding-type
[GRE|L2]

Switches between GRE encapsulation (the default) and L2 MAC address rewrite
for forwarding packets. If this command is not present, GRE encapsulation is used.

You can create a configuration file customized for the environment through the CLI inline
commands or through a text file. The CLI inline commands enable WCCP on the SG
appliance immediately; the drawback is that if any information changes, you must recreate the whole file using the inline command. With a text file, if any information
changes, you can change the individual line; the drawback is that you must download the
file again from an HTTP server to the SG appliance.
To use CLI commands to create a configuration file, continue with the next procedure. To
use a text editor to create a configuration file, continue with “Creating a Configuration
File using a Text File” on page 226.

Creating a Configuration File using CLI Inline Commands
For examples of various types of WCCP configurations, see “Examples” on page 226.
If you choose to configure through the CLI and the inline command, refer to the example
below:
SGOS# configure terminal
SGOS#(config) inline wccp eof

where eof marks the beginning and end of the inline commands.
For example:
SGOS#(config) inline wccp eof
wccp enable
wccp version 2
service-group 9
forwarding-type L2
priority 1
protocol 6
service-flags destination-ip-hash
service-flags ports-defined
ports 80 21 1755 554 80 80 80 80
interface 6
home-router 10.16.18.2
end
eof

225

Volume 6: Advanced Networking

You created a WCCP configuration file and enabled WCCP on the SG appliance. WCCP
setup is complete.

Creating a Configuration File using a Text File
If you create a configuration file using a text editor, assign the file the extension .txt. The
following are SG configuration file rules:


Only one command (and any associated parameters) is permitted, per line.



Comments must begin with a semicolon (;) or a pound sign (#).



Comments can begin in any column; however, all characters from the beginning of the
comment to the end of the line are considered part of the comment and, therefore, are
ignored.

For examples of various types of WCCP configurations, see “Examples” on page 226.
To create a configuration file using a text editor and load the file on an SG
appliance:
1.

Open a text editor.

2.

Using the commands described in “Syntax to create a customized configuration file:”
on page 222, enter the arguments you need.

3.

Copy the configuration file to an HTTP server so that it can be downloaded to the SG
appliance.

4.

Enable WCCP and download the WCCP configuration file using the following syntax:
wccp {enable | disable | no} [path config-file-url] | [version versionnumber]

where:
enable

Enables WCCP on the SG appliance.

disable

Disables WCCP on the SG appliance.

no

Indicates that you want to clear the current WCCP configuration settings.

config-file-url

Specifies the SG WCCP configuration file or alternate configuration file.

version-number

Indicates the version of WCCP that your router is configured to use. If
version version-number is omitted, it is assumed to be 2.

For example:
SGOS#(config) wccp enable
SGOS#(config) wccp path http://205.66.255.10/files/wccp.txt
SGOS#(config) load wccp-settings

Examples
This section provides detailed examples of both the router and SG configurations for:


Standard HTTP redirection



Standard HTTP redirection and a multicast address



Standard HTTP redirection and a security password



Standard transparent FTP

226

Appendix C: Using WCCP



A service group and alternate hashing

For information and examples about using WCCP, refer to http://www.cisco.com/
univercd/cc/td/doc/product/software/ios121/121cgcr/fun_r/frprt3/frd3005.htm.

Displaying the Router’s Known Caches
Use the router show command to display information about the appliances that are known
to the router.
Router# show ip wccp web-caches
WCCP Web-Cache information:
IP Address:192.168.51.102
Protocol Version:0.3
State:Usable
Initial Hash
Info:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Assigned Hash:
Info:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment:256 (100.00%)
Packets Redirected:0
Connect Time:00:00:31
Router# exit

Standard HTTP Redirection
The web-cache service group enables HTTP traffic redirection on port 80.

Router Configuration
The following example enables standard HTTP traffic redirection on a WCCP version 2capable Cisco router.
Router(config)# ip wccp web-cache
Router(config)# interface ethernet 0/0
Router(config-if)# ip wccp web-cache redirect out
Router(config-if)# end

SG Configuration
To enable the Web-cache service group within the SG appliance, the following
configuration file could be loaded.
# Enable WCCP to allow WCCP protocol communication between
# the ProxySG Appliance and the home router.
wccp enable
# By default, the WCCP version 2 protocol is assumed. An
# explicit “wccp version 2" command could be specified here.
service-group web-cache
# Specify the address for the router.
home-router 90.0.0.90
# Network interface 0 will participate.
interface 0
end

227

Volume 6: Advanced Networking

Standard HTTP Redirection and a Multicast Address
Configuring a multicast address on a WCCP-capable router provides reduced WCCP
protocol traffic and the ability to easily add and remove caches and routers from a service
group without having to reconfigure all service group members.

Router Configuration
The following example enables the standard HTTP traffic redirection on a WCCP
version 2-capable Cisco router. In this case, WCCP protocol traffic is directed to the
multicast address 226.1.1.1.
Router(config)# ip wccp web-cache group-address 226.1.1.1
Router(config)# interface ethernet 0/0
Router(config-if)# ip wccp web-cache group-listen
Router(config-if)# ip wccp web-cache redirect out
Router(config-if)# end

SG Configuration
To enable the standard Web-cache service group within the SG appliance, the following
configuration file should be loaded. In this example, both network interfaces 0 and 1
participate within the service group. Both interfaces send and receive WCCP protocol
packets by way of the multicast address.
# Enable WCCP to allow WCCP protocol communication between
# the ProxySG Appliance and the home router.
wccp enable
# By default, the WCCP version 2 protocol is assumed. An
# explicit “wccp version 2" command could be specified here.
service-group web-cache
# Specify the multicast address.
home-router 239.192.5.3
# Network interface 0 will participate.
interface 0
# Network interface 1 will also participate.
interface 1
end

Standard HTTP Redirection Using a Security Password
A simple eight-character password is configured within the router. This password must
match the password configured within the SG appliance.

Router Configuration
The following example enables standard HTTP traffic redirection on a WCCP version 2capable Cisco router.
Router(config)# ip wccp web-cache password 29gy8c2
Router(config)# interface ethernet 0
Router(config-if)# ip wccp web-cache redirect out
Router(config-if)# end

SG Configuration
To enable the standard WCCP version 2 service group within the SG appliance, the
following configuration file could be loaded.

228

Appendix C: Using WCCP

# Enable WCCP to allow WCCP protocol communication between
# the ProxySG Appliance and the home router.
wccp enable
# By default, the WCCP version 2 protocol is assumed. An
# explicit “wccp version 2" command could be specified
# here.
service-group web-cache
# Specify the address for the router.
home-router 90.0.0.90
# Network interface 0 will participate.
interface 0
password 29gy8c2
end

Standard Transparent FTP
In WCCP version 1, only HTTP traffic on port 80 could be redirected. In WCCP version 2,
you can create a numbered service group that redirects other protocols on other ports.
You set the service group on the router, and tell the SG appliance which ports should be
redirected.

Router Configuration
In this configuration, you create a new service group that you are dedicating to FTP
redirects.
# Enables the service group that redirects ports besides 80.
Router(config)# ip wccp 10
# Enables a service group that allows user-defined
# ports to be redirected.
Router(config)# int e0
Router(config-if)# ip wccp 10 redirect out

SG Configuration
In this configuration, you take the service group created by the router and assign the
characteristics to the group.
SGOS#(config) inline wccp eof
wccp enable
service-group 10
interface 0
home-router 10.1.1.1
protocol 6
priority 1
service-flags ports-defined
service-flags destination-port-hash
ports 20 21 80 80 80 80 80 80
eof

Reverse Proxy Service Group
This service group redirects IP packets for TCP destination port 80 traffic by hashing the
source IP address.

Router Configuration
The following example enables the special SG service group on a WCCP-capable router.

229

Volume 6: Advanced Networking

Router(config)# ip wccp 99
Router(config)# interface ethernet 0/0
Router(config-if)# ip wccp 99 redirect out
Router(config-if)# end

SG Configuration
To configure the special SG service group on the appliance, a dynamic service group must
be created as illustrated by the following example.
# Enable WCCP to allow WCCP protocol communication between
# the ProxySG Appliance and the home router.
wccp enable
# By default, the WCCP version 2 protocol is assumed. An
# explicit “wccp version 2" command could be specified here.
# Service Group 99 is specially identified within the router
# as representing the ProxySG Appliance service.
service-group 99
# Specify the address for the router.
home-router 90.0.0.90
# Network interface 0 will participate.
interface 0
# Specify the TCP protocol.
protocol 6
# The hash should be based on the source IP address.
service-flags source-ip-hash
end

Service Group with Alternate Hashing
You can create a special service group on a WCCP-capable router that uses alternate
hashing when hot spots are detected. This service group redirects IP packets by hashing
the source IP address.

Router Configuration
In this configuration, you create a new service group that you are dedicating to Website
hot spots.
Router(config)# ip wccp 5
Router(config)# interface ethernet 0/0
Router(config-if)# ip wccp 5 redirect out
Router(config-if)# end

SG Configuration
To configure this special service group on the SG appliance, a dynamic service group must
be created.
# Enable WCCP to allow WCCP protocol communication between
# the ProxySG Appliance and the home router.
wccp enable
# By default, the WCCP version 2 protocol is assumed. An
# explicit “wccp version 2" command could be specified here.
# Service Group 5 is created to redirect standard HTTP
# traffic and use an alternate hash function based on the
# source IP address, if necessary.
service-group 5
# Specify the address for router 1.
home-router 90.0.0.90

230

Appendix C: Using WCCP

# Specify the address for router 2.
home-router 90.0.1.5
# Network interface 0 will participate.
interface 0
# Specify the TCP protocol.
protocol 6
# The following two flags specify that a hash function based
# on the destination IP address should be applied first. If
# a hot-spot is detected, then an alternate hash
# function using the source IP address should be used.
service-flags destination-ip-hash
service-flags source-ip-alternate-hash
end

Troubleshooting: Home Router
If you install WCCP settings and then later upgrade the Cisco IOS software or change
network configuration by adding a device with a higher IP address, the change might
result in a different home router IP assignment. WCCP might or might not work under
these conditions, and performance might decrease. If you upgrade the router software or
change the network configuration, verify that the actual home router IP address and home
router IP address in the WCCP configuration match.
To verify the home router IP address matches the home router IP address listed in
the WCCP configuration:
1.

From the router CLI, view the WCCP configuration:
Router#(config) show ip wccp

The home router information appears, similar to the example below:
Global WCCP information:
Router information:
Home router Identifier:195.200.10.230
Protocol Version:2.0

2.

From the Blue Coat SG appliance, verify that the home router IP address specified in
the SG WCCP configuration file is the same as the actual home router IP address
discovered through the router CLI command. The following is an SG WCCP
configuration file showing the same home router IP as in the example above:
SGOS# show wccp config
;WCCP Settings
;Version 1.3
wccp enable
wccp version 2
service-group web-cache
interface 1
home-router 195.200.10.230
end

In this case, the two home router identifiers match.

Identifying a Home Router/Router ID Mismatch
The following is some helpful information for resolving a home-router/Router ID mismatch that results in the router crashing the SG appliance. This situation can occur when
the router interface is set to a higher IP address than the home-router and WCCP
messages show w/bad rcv_id.

231

Volume 6: Advanced Networking

WCCP version 1 does not care what home router the cache had configured. So if you
upgrade from WCCP version 1 to WCCP version 2, the router might pick a different IP
address than was configured as a home router in the cache.
This means that a mismatch can occur after an upgrade.

SG Configuration
Use the show wccp statistics command to identify the configured home router and the
highest router IP.
SGOS#(config) show wccp statistics
Service Group ident.
:512,1,9, 1,6,18,
1755,554,20,21,80,80,80,80
Home Routers
:10.2.3.224 <<========Configured Home Router IP
Hotspots announced
:0
Assignment state
:idle
Designated Cache
:10.2.3.228 <<=======Blue Coat IP
Announcement key #
:2
Cache view change #
:13 <<==== # times cache view changed
Router View Changed
:0
Recent hit count
:0
Primary hit count
:0
Alternate hit count
:0
Instance IP address :10.2.3.228
<<=======Blue Coat IP
Sequence info
:10.2.3.231,636
Query response info:
Active
:1
Primary hash weight
:0
Hotspot information
:0,0,0,0
Total assign weight
:0
Router IP address
:10.2.3.231 <<=======Router ID/Highest IP on
Router
Receive #
:636
Change #
:4
Activation time
:Wed, Jan 30 2002 00:17:58 UTC
Last I-See-You time
:Wed, Jan 30 2002 01:08:58 UTC
Active caches
:10.2.3.228
Assignment key
:10.2.3.228,2
Router state
:active
Cache
:10.2.3.228,L,D
:1
Active

Notice that .231 is highest IP on router and is automatically selected as the home router,
even though .224 is the configured home router IP.
You can also use the show wccp configuration command if you already know the
highest IP and just want to know what the SG appliance identifies as the home-router.
SGOS#(config) show wccp configuration
;WCCP Settings
;Version 1.3
wccp enable
wccp version 2
service-group 9
interface 0
home-router 10.2.3.224

232

Appendix C: Using WCCP

protocol 6
priority 1
service-flags ports-defined
service-flags destination-ip-hash
ports 1755 554 20 21 80 80 80 80

Router Configuration
The configuration below reveals that two interfaces are active on the router, and that one
of the IP addresses is higher than the home router configured in the SG configuration file.
The higher IP address takes over duties as the home router, causing a mismatch between
the router and the SG appliance.
Router# show conf
Using 689 out of 129016 bytes
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname NachoL3
enable secret 5 $1$r6nJ$dr58AZ.ZDg6RKA6MYeGRb.
enable password nacho
ip subnet-zero
no ip routing
ip wccp 9
interface FastEthernet0/0
ip address 10.2.3.224 255.255.255.0
ip wccp 9 redirect out
no ip route-cache
no ip mroute-cache
speed 100
half-duplex
!
interface FastEthernet0/1
ip address 10.2.3.231 255.255.255.0
no ip route-cache
no ip mroute-cache
speed 100
half-duplex

Correcting a Home Router Mismatch
The home router must have the same IP address on both the router and the SG appliance.
Every time a higher IP address is introduced to the router, the higher address becomes the
home router.
On a WCCP router, the Router Identifier parameter is dynamically assigned. It cannot
be manually configured.
To set the correct home router IP address on the SG appliance:
You cannot edit a WCCP configuration file created by the SGOS inline commands. You
must recreate the configuration file. For more information on creating a WCCP
configuration file using CLI commands on an SG appliance, see “Creating a Configuration
File using CLI Inline Commands” on page 225.
If you created a text file and downloaded it, you can edit the file and then download it
again to the SG appliance. For more information for editing the WCCP text file and
downloading it, see “Creating a Configuration File using a Text File” on page 226.

233

Volume 6: Advanced Networking

Tips
If you use IP spoofing with WCCP, do the following for best results:


The ip wccp redirect exclude in command should be applied to the adapter to
which the SG appliance is attached.



For L2 forwarding, the SG appliance should be directly connected to the router
interface.

234

Index

A
access lists
cache bypass
associating with service group 217
creating 217
creating 216
redirection
associating with service group 217
creating 217
syntax 216
ADN manager, defining 19
alternate hash table, creating 222
alternate hashing
router example 230
SG example 230
Application Delivery Network (ADN)
ADN History, reviewing 38
ADN manager, defining 19
basic setup 19
byte-cache
dictionary, manually resizing 44
statistics, reviewing 38
CLI syntax 47
combined deployment, configuring 30
components 13
concepts 13
connections deployments 21
connections, securing 33
device security, setting 31
devices, authorizing 35
explicit deployment
configuring 24
destination port, preserving 26
load balancing 27
managing server subnets 24
health metrics, reviewing 39
History/Stats/Health Metrics 38
network
constructing 19
optimizing 14
securing 31
overview 11
policy gestures available for use with 49
Security 17

security settings, configuring 31
transparent deployment
configuring 21
load balancing 22
tunnel
optimization, understanding 41
parameters, setting 41
attack-detection
client
block-action, explained 53
connection-limit, explained 53
creating and editing 53
failure-limit, explained 53
global defaults 51
global defaults, changing 52
unblock-time, explained 54
warning-limit, explained 54
configuration, viewing 54
mode, entering 51
overview 51
server
add or remove server from group 55
configuration, viewing 56
configuring 55
creating 55
editing 55
hostname, explained 55
request-limit, explained 56
authentication, device. See device authentication. 78

B
bandwidth management
allocating bandwidth 58
allocation examples 68
class hierarchies 59
creating classes 62
deleting bandwidth-classes 63
editing classes 63
enabling or disabling 62
flow classification 61
maximum bandwidth 59
minimum bandwidth 58
overview 57
policy examples 68

235

Volume 6: Advanced Networking

priority levels 59
viewing configurations 64
Blue Coat SG
alternate hashing example 230
configuration file 225
configuration file, creating 222
configuration file, creating with text editor 226
configuration file, loading 226
configuration file, quick start 214
configuration file, syntax 222
FTP example 229
home router IP address, verifying 231
HTTP configuration example 227
HTTP redirection multicast address example 228
HTTP redirection with password example 228
load balancing 221
optional negation syntax, using 223
reverse proxy example 230
simultaneous connections to, viewing 54
WCCP configuration, creating 220
WCCP versions supported 211
WCCP-known caches, displaying 227
bluecoat profile, understanding 78
BWM, see bandwidth management
byte-cache dictionary, manually resizing 44

C
cache bypass list
associating with service group 217
creating 217
.car file, SG Client 158
CLI configuration file, creating for SG appliance 225
Client Manager, for SG Client 146
combined deployment
configuring for ADN 30
configuration file
creating with inline commands 225
creating with text editor 226
loading on SG appliance 226
connections, securing for ADN 33
CPL
enabling ICP 132
RADIUS policies, creating 142

D
D range multicast address, explained 88
device authentication
appliance certificates, about 78
cipher suites, changing 84

236

cipher suites, default 79
CLI syntax 85
device ID, setting 84
overview 78
platforms supported 80
profile, creating 83
profile, understanding 78
device security
ADN, setting for 31
devices
ADN authorization 35
document
conventions 9
Do-Not-Fragment, see PMTU

E
explicit deployment
ADN server subnets, managing. 24
ADN, configuring for 24
load balancing for ADN network 27

F
failover
configuring, overview 88
group secret 89
master, explained 87
multicast address, using 88
priority ranges 89
statistics page, viewing 89
VRRP, using with 87
failover group
configuring as session monitor 140
forwarding
default sequence, creating 102
editing a host 97
host affinity, configuring 100
hosts/host groups, creating 94
load balancing, configuring 99
policy commands in forward layer 207
policy, managing with 207
using forwarding directives to create an
installable list
fail open/closed 106
host timeout values 106
FTP
router configuration for 229
SG appliance, configuration for 229
WCCP example 229

Index

H

M

hash table, see redirection hash table
health check
creating forwarding 123
creating general 119
instant 122
home router
mismatch errors 231
SG IP address 231
troubleshooting 231
version 1 usage 211
version 2 configuration 212
WCCP IP address 231
hot spot, working with 222
HTTP redirection
multicast address example 228
multicast address router configuration 228
password example 228
router configuration example 227
router configuration for password 228
SG configuration 227
SG multicast address configuration 228
SG password example 228

multicast
D range address, explained 88
failover, using with 88
multicast address
configuring 215
router configuration 228
SG configuration 228
syntax 216
multicast packet reception, enabling 219

I
ICMP broadcast echo
configuring 192
ICMP error message
ICMP host unreachable 193
ICMP timestamp echo
configuring 192
ICP
creating an installable list for 127
enabling through CPL 132
hierarchy 127
icp_access_domain directive 129
icp_access_ip directive 130
installable list, creating through Management
Console 131
restricting access 129
identification (Ident) protocol 188
installable list
ICP 127
SOCKS 186

L
load balancing
assigning percentages 221
understanding 221

O
optional negation syntax, using 223

P
packet redirection
enabling 218
excluding 218
password
HTTP redirection example 228
with RIP 137
PMTU
enabled by default 193
overview 193
policy
bandwidth management examples 68
proxies
setting up 9

Q
quick start
SG, creating a WCCP configuration file 214
WCCP configuration 213

R
RADIUS
policies, creating 142
RADIUS session monitor
cluster, configuring 140
configuring 141
configuring failover group 140
redirection access list, creating 217
redirection hash table
alternate, creating 222
assigning percentages 221
hot spot 222
understanding 221

237

Volume 6: Advanced Networking

reverse proxy
router configuration for 229
SG, configuration for 230
WCCP example 229
RFC-1323
configuring 191
RIP
configuring 133
definition of 133
installing configuration file 133
parameters 136
SG-specific RIP parameters 137
using passwords with 137
routing information protocol, see RIP

S
SG Client
.car file 158
ADN features, about 149
ADN manager, about 147
ADN manager, setting 154
CIFS, enabling 153
Client Manager, about 146
Client Manager, setting 156
deployment overview 148
dialog box 172
enabling or disabling 174
icon, hiding or displaying 171
installing interactively 161
installing silently 165
Internet gateways 150
licensing 182
logging 178
logs 178, 180
object cache, about 151
plain connections 150
requirements 149
sgautoupdate.log 180
SGClientSetup.log 180
SGClientSetup2.log 180
sgdebug.etl 180
sglog.etl 180
TCP window size, about 151
terminology 146
troubleshooting 175
uninstalling 179
updating software and configuration 177

238

viewing statistics and ADN tunnels 172
sgautoupdate.log 180
SGClientSetup.exe 148
SGClientSetup.log 180
SGClientSetup.msi 148
SGClientSetup2.log 180
sgdebug.etl 180
sglog.etl 180
SOCKS
creating an installable list for 186
gateway configuration 183
SOCKS gateway
default sequence, creating 185
HTTP, using with SOCKS 189
statistics
failover page, viewing 89

T
TCP Connection Forwarding
about 111
CLI commands 117
configuring 115
deployment 115
TCP NewReno
configuring 192
TCP/IP
configuration, showing 194
ICMP broadcast echo 192
ICMP timestamp echo 192
overview 191
PMTU, configuring 193
RFC-1323 191
transparent deployment
ADN load balancing 22
ADN, configuring for 21
transparent redirection, using WCCP 211
troubleshooting
ICMP host unreachable error message 193
WCCP, home router mismatch 233

V
viewing WCCP changes 219
virtual IPs
creating 195
understanding 195
virus, preventing 51
VRRP, failover, using with 87

Index

W
WCCP
access lists, creating 216
alternate hash table, using 222
alternate hashing example 230
changes, viewing 219
definition of 211
examples 226
global settings, syntax 214
global settings, using 214
home router mismatch, troubleshooting 233
home router troubleshooting 231
hot spot, working with 222
HTTP redirection example 227
installing settings through CLI 198
installing settings through Management Console
197
interface commands, syntax 217
interface commands, using 217
known caches, displaying 227
load balancing, understanding 221

multicast address, configuring 215
multicast packet reception, enabling 219
optional negation syntax, explained 223
overview 211
packet redirection, enabling 218
packet redirection, excluding 218
quick start 213
router configuration, initial 213
saving changes 219
service group, naming 215
service group, setting up 214
settings 197
settings, understanding 197
SG configuration for 220
transparent redirection, using with 211
version 1 overview 211
version 1 rules 212
version 2 overview 212
version 2 router, configuring 214
version 2, enabling 215
Web Cache Control Protocol, see WCCP

239

Document Path: ["142-blue-coat-instruction-sg.pdf"]

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh