Learning IOS and JUNOS

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

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.

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}

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.

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.

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)

NetFlow 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). • Ser

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,

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

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.

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 .

Authentication 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 • RADIUS • TACACS+ 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.

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.

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.

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. HASH 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 de

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. • Either The either value uses L2 first—if Layer 2 is not supported, GRE is used. This is the default setting.

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: • HERE_I_AM Sent by Steelhead appliances to announce themselves. • I_SEE_YOU Sent by WCCP enabled routers to respond to announcements. • REDIRECT_ASSIGN Sent by the designated Steelhead appliance to determine flow distribution. • REMOVAL_QUERY Sent by router to check a Steelhead appliance after missed HERE_I_AM messages.