Aug 5, 2009

Riverbed Steelhead Management Console (GUI)

Home Page

§Enter the URL for the Management Console in the location box of your Web browser:
http://host.domain or https://host.domain
§Logging in
In the Account (Username) text box, type admin
In the Password text box, type the password you were assigned (default is password)
Click Log In button to display the Home page
§Console requirements
The Management Console has been tested with Mozilla Firefox version 1.5.x and 2.0, and Microsoft Internet Explorer version 6.x and 7.0
Note: JavaScript and cookies must be enabled in your Web browser
Note: If you want to encrypt your communication, you must have an SSL capable browser

Riverbed Steelhead Mobile Configuration Steps

1. Create MSI package and Endpoint and Acceleration policies on the Steelhead Mobile Controller
2. The MSI software package is pushed to the Steelhead Mobile Client(the endpoint) and installed.
3. Once connected, the Steelhead Mobile Controller utilizes the Deployment ID(DID) to link the Endpoint and Acceleration policies to the Mobile Client.
4. The Assignment occurs when an Endpoint or Acceleration policy is matched to a DID.

Aug 3, 2009

RCSP Study Guide - System Dumps

System Dumps

A system dump file contains data that can help Riverbed Technical Support diagnose problems.
From the CLI:
debug generate dump

To view system dump files
show files debug-dump

To update the file to a remote host:
file debug-dump upload {filename} {URL}

RCSP Study Guide - Asymmetric Route Passthrough

Asymmetric route passthrough allows connections to be passed through and an entry to be placed into the AR table. The entry is placed in the table for a default of 24 hours.

For SYN retransmissions AR will be placed in AR table at first for 10 seconds. If AR is confirmed, the timeout is increased to the default (24 hours) with a reason code updated to SYN Rexmit (confirmed AR).

If a SYN/ACK is received after we stop probing then it is placed in the table for 5 minutes with a reason code of probe filtered (not AR). If AR passthrough is disabled and we detect AR, we will not pass through the connection. A warning message is still placed in the log.

However, the alarm is not raised and no email notifications are sent. Normal functionality would be to send a probe each time. However, adding a passthough rule for 24 hours is a better approach. Sending a probe out again will save on overhead of re-transmitting the probe.

RCSP Study Guide - IPSec

You configure IPSec encryption to allow data to be communicated securely between peer Steelhead appliances. Enabling IPSec encryption makes it difficult for a third party to view your data or pose as a machine you expect to receive data from.

To enable IPSec, you must specify at least one encryption (DES or NULL) and authentication algorithm (MD5 or SHA-1). Only optimized data is protected, passthrough traffic is not.

RCSP Study Guide - NetFlow Timers

Adjusting NetFlow Timers

By default, the Steelhead appliance will export active flows every 30 minutes and inactive flows every 15 seconds. An inactive flow is defined as a flow where no traffic has been sent in the last 15 seconds.

Terminated flows (either with a FIN or RST packet) will be exported immediately. Some NetFlow collectors provide real-time reporting and the 30 minutes export may be too long. In this case, you can use the CLI command to change the timeout.

ip flow-setting active_to (seconds)
ip flow-setting inactive_to (seconds)

RCSP Study Guide - NetFlow Operation and Implementation

Operation and Implementation

Similar to configuring NetFlow on the routers, NetFlow statistics are collected on the ingress interfaces of the Steelhead appliance. Therefore, to see a complete flow or conversation between the server and client, it is necessary to configure NetFlow on both the client-side Steelhead appliance as well as the server-side Steelhead appliance, For example, to determine the amount of CIFS traffic on the LAN between a server and client, configure NetFlow to collect on the following interfaces:
• Client-side Steelhead LAN interface (this will show pre-optimized traffic going from client to server).
• Server-side Steelhead LAN interface (this will show pre-optimized traffic going from server to client).

Similarly, to determine the amount of CIFS traffic on the WAN between a server and client, configure NetFlow to collect on the following interfaces:
• Client-side Steelhead WAN interface (this will show optimized traffic going from server to client).
• Server-side Steelhead WAN interface (this will show optimized traffic going from client to server).

RCSP Study Guide - QoS Class Priorities

There are five QoS priorities for Steelhead appliances. You assign a class priority when you create a QoS class. Once you have created a QoS class, you can modify its class priority. In descending order, class priorities are:
• Realtime
• Interactive
• Business Critical
• Normal Priority
• Low Priority

Enforcing QoS for Active/Passive FTP
Active/Passive FTP Operation
To configure optimization policies for the FTP data channel, define an in-path rule with the destination port 20 and set its optimization policy. Setting QoS for destination port 20 on the client-side Steelhead appliance affects passive FTP, while setting the QoS for destination port 20 on the server-side Steelhead appliance affects active FTP.

In the case of an active FTP session, data connections originate on a server sourced on port 20 and destined to a random port specified by the client. As such, specifying a QoS rule on the server-side Steelhead with a destination port of 20 is appropriate. With passive FTP however, data connections initiate on the client from a random port, and are destined to a server on a random port; as such, there is no seemingly simple way to apply a QoS rule based on the Layer 4 port information.

To help solve this problem, the Steelhead allows you to define a client-side QoS rule with a destination port of 20 to tell it that you would like to apply this QoS rule to a passive FTP data connection. The Steelhead will intelligently identify the actual ports used for the passive FTP data transfer, and apply the QoS logic set forth by the class where the rule has been applied.

RCSP Study Guide - BDP Calculations and Buffer Adjustments

BDP Calculations and Buffer Adjustments

In order to achieve the maximum throughput possible for a given link with TCP, it is important to set the send and receive buffers to a proper size. Using buffers that are too small may not allow the Cwnd to fully open, while using buffers that are too large may overrun the receiver and break the flow control process. When configuring the send and receive WAN buffers on a Steelhead, it is recommended that they be set to two times the Bandwidth Delay Product.

As an example, a 45Mb/s point to point connection with 100ms of latency, should have a buffer size of 1,125,000 bytes set on the WAN send (for the sending Steelhead), and the same number on the receive for the WAN interface on the receiving Steelhead ((45,000,000bits/8*.1s) *2).

For a point-to-point connection such as this one, the send and receive buffers would typically be the same value. Additionally, it is recommended that buffers on WAN routers be set to accommodate the packet influx by allocating at least one times the BDP worth of packets. As an example, considering the case of the 45Mb/s connection above with 100ms of latency, and given that a packet is 1500 bytes in size, we realize that we need to back that buffer 375 packets deep [(45,000,000/8*.1)/1500].

RCSP Study Guide - Interceptor Appliance

In-Path Rules

When the Interceptor appliance intercepts a SYN request to a server, the in-path rules you configure determine the subnets and ports for traffic that will be optimized. You can specify inpath rules to pass-through, discard, or deny traffic; or to redirect and optimize it.

Link State Detection and Link State Propagation
The Interceptor appliance monitors the link state of devices in its path, including routers, switches, interfaces, and In-path interfaces. When the link state changes (for example, the link goes down or it resumes), the Interceptor appliance propagates the change to the dynamic routing table. Link state propagation ensures accurate and timely triggers for failover or redundancy scenarios.

RCSP Study Guide - Steelhead Mobile Solution

Firewall Requirements

If you deploy the Mobile Controller in the DMZ next to a VPN concentrator with firewalls on each side, the client-side network firewall must have port 7801 available. The server-side firewall must have ports 22, 80, 443, 7800, and 7870 open. If you are using application control, you need to allow rbtdebug.exe, rbtmon.exe, rbtsport.exe, and shmobile.exe.

RCSP Study Guide - Authentication and Authorization

The Steelhead appliance can use a RADIUS or TACACS+ authentication system for logging in administrative and monitor users. The following methods for user authentication are provided with the Steelhead appliance:
• Local

When configuring the authentication server, it is important to specify the service rbt-exec along with the appropriate custom attributes for authorization. Authorization can be based on either the admin account or the monitor user account by using local-user-name=admin or local-username=monitor, respectively.

RCSP Study Guide - Data Store Synchronization

In a serial failover scenario the data stores are not synchronized by default. When the master Steelhead appliance fails, the backup Steelhead appliance will take over but users will experience cold performance again. Data store synchronization can be turned on to exchange data store content. This can either be done via the Primary or the AUX interface.

The synchronization process runs on port 7744, the reconnect timer is set to 30 seconds.(keepalive 10 seconds)

Data store synchronization can only occur between the same Steelhead appliance models and can only be used in pairs of two.

RCSP Study Guide - Connection Forwarding

In WCCP deployments, Connection Forwarding can also be used to prevent outages whenever the cluster and the redirection table changes.

Default behavior of Connection Forwarding is that when a neighbor is lost, the Steelhead appliance that lost the neighbor also will pass through the connection since it is assuming asymmetric routing of traffic. In WCCP deployments this is not the case and this behavior has to be avoided.

The command

in-path neighbor allow-failure

overrides the default behavior and allows the Steelhead appliances to continue optimizing. Understanding the implication of applying this command prior to configuring it in a production environment is recommended.

RCSP Study Guide - WCCP Assignment and Redirection Methods

Assignment and Redirection Methods
The assignment method refers to how a router chooses which Steelhead appliance in a WCCP service group to redirect packets to. There are two assignment methods: the Hash assignment method and the Mask assignment method. Steelhead appliances support both the Hash assignment and Mask assignment methods.

Redirection using Hash assignment is a two-stage process. In the first stage a primary key is formed from the packet which is defined by the Service Group and is hashed to yield an index. This index number will then be placed into a Redirection Hash Table.

In the Redirection Hash Table a packet has either an unflagged web-cache, unassigned bucket, or a flagged packet. In the event the packet has an unflagged web-cache, the packet is redirected to that web-cache. If the bucket is unassigned the packet is forwarded normally. However, if the bucket is flagged indicating a secondary hash then a secondary key is formed (as defined by the Service Group description). This key is hashed to yield an index number which in turn is placed into the Redirection Hash Table. If this secondary entry contains a web-cache index then the packet is directed to that web-cache. If the entry is unassigned the packet is forwarded normally.

The first phase of Mask assignment is defining the mask itself. The mask can be up to seven bits and can be applied to the SRC TCP port, DST TCP port, source IP address or DST IP address or a combination of the four attributes but may not exceed seven bits. Depending on the amount of bits selected different number of buckets are created and assigned to the different Steelhead appliances in the service group. As traffic traverses the router a bitwise AND operation is performed between the mask and the IP address/TCP port depending on the mask defined. The traffic is assigned to the different buckets based on the results of the AND operation.

Mask IP address/TCP port pairs are processed in an order they are received and in turn are compared to the seven bits.

RCSP Study Guide - WCCP Redirection

By default, all TCP traffic is redirected, optionally a redirect-list can be defined where only the contents of the redirect-list are redirected. A redirect-list in a WCCP configuration refers to an ACL that is configured on the router to select the traffic that will be redirected.
Traffic is redirected using one of the following schemes:

• GRE (Generic Routing Encapsulation)
Each data packet is encapsulated in a GRE packet with the Steelhead appliance IP address configured as the destination. This scheme is applicable to any network.

• L2 (Layer 2)
Each packet MAC address is rewritten with a Steelhead appliance MAC address. This scheme is possible only if the Steelhead appliance is connected to a router at Layer 2.

The either value uses L2 first—if Layer 2 is not supported, GRE is used. This is the default setting.

RCSP Study Guide - WCCP Deployments

The WCCP protocol is a stateful language that the router and Steelhead appliance can use to redirect traffic to the Steelhead appliance in order for it to optimize. Several functions will have to be covered to make it stateful and scalable. Failover, load distribution, and negotiation of connection parameters will all have to be communicated throughout the cluster that the Steelhead appliance and router form upon successful negotiation. The protocol has four messages to encompass all of the above functions:

Sent by Steelhead appliances to announce themselves.

Sent by WCCP enabled routers to respond to announcements.

Sent by the designated Steelhead appliance to determine flow distribution.

Sent by router to check a Steelhead appliance after missed HERE_I_AM messages.