Learning IOS and JUNOS

算一算時間，距離上次Riverbed通知我寄送證書的時間還不到一週，今天就收到了國際快遞，這一張是我的第一張Riverbed證書(希望不需再考第二張)，不過我才只上了一門Riverbed課程而己呢，所以其實說實話對於Riverbed產品線的掌控程度還是很心虛地…希望能夠儘快去把其他的Riverbed課程上完，加強一下自己對Riverbed產品的了解及不同架構的各種可行解決方案。 不過說實話這份證書上沒有任何的序號或認證編號，其實很容易就可以偽造的說...

看了這麼久的TCP Windows Size相關的文章，終於搞懂為何可以突破TCP Windows Size的最大值(2^16 = 0~65535 bytes)。之前我一直被TCP header長度的問題困擾，因為Windows Size欄位就只有16 bits，那麼要如何才能紀錄使用超過TCP Windows 65535 bytes長度的資料呢? 不過說也奇怪，明明是一個很簡單的理論，但是找來找去總是找不到一份很簡單的文章來說明為什麼? 透過一些相關文章的佐證，我就在這邊用比較淺顯易懂的文字來表達。 我們先來看看TCP Header的樣子： 我們可以看到在TCP header中共有20 bytes，其中包含了16 bits的Windows Size。因為原有的TCP Windows Size最大值無法超過65536 bytes，所以後來在IETF RFC 1323 中定義了TCP Windows scale option的功能，讓我們可以使用TCP options欄位(共32 bits)中的14 bits當成是延伸的Windows Size。因此我們現在的TCP Windows Size最大長度可以達到2^(16+14) = 1GB(1,073,741,824 bytes) 以下是摘錄自WiKi上的相關資料： TCP window scale option From Wikipedia, the free encyclopedia The TCP window scale option is an option to increase the TCP receive window size above its maximum value of 65,535 bytes. This TCP option, along with several others, is defined in IETF RFC 1323 which deals with Long-Fat Networks , or LFN. In fact, the throughput of a communication is limited by two windows: congestion window and receive window. The first one tries ...

With 5.0, we have SSL auto-discovery so that administrators can whitelist or blacklist peers very easily and the peers are automatically discovered upon the first SSL connection and appear in the self-signed peer gray list. You simply mark them as trusted. The connections are not optimized until after you move the peers to the trusted whitelist . Both the client-side and server-side Steelhead appliances must use RiOS 5.0 or later. • SSL Certificates and private keys copied to server-side Steelhead appliance (no certificate faking in branch offices) • Auto-discovery of SSL Steelhead peers with gray-list capability • Automatic optimization of SSL traffic • Support for certificate domain wildcards

Topology 如下： Client Client Steelhead(CSH) Server Steelhead(SSH) Server Correct Addressing This is how our product works today and is the safest and most scalable mode. Traffic on the WAN is between the Steelhead appliances on port 7800. We have thousands of customers using Steelhead appliances and we believe this will continue to be the most used mode going forward. 這是Riverbed預設模式，在這個模式中，Client與CSH以及Server與SSH之間使用Client & Server Source IP&Port，在CSH與SSH之間則是使用CSH&SSH的Source IP&Port。(Destination Port為7800) TCP Options使用0x4c(76) Correct Addressing & Port Visibility Traffic on the WAN is still between the Steelhead appliances, but we preserve the port information. 在這個模式中，除了CSH與SSH之間的Port改用Client與Server之間的Destination Port之外，其它部份跟Correct Addressing模式相同。 (RiOS 5.0+才有支援) TCP Options使用0x4c(76) Full IP & Port Transparency Traffic on the WAN preserves the IP addresses and port numbers of the end stations. 在這個模式中，CSH與SSH之間的Inner Connection全部改用Client與Server之間的Source IP...

Standard probe: 0x4c = Riverbed Probe Option 0x0e = Length (14 bytes) 0x11 = Type/Version 0x11 = Current TTL/Max TTL 0x0a – 0xed = Client SH in-path IP (10.0.103.237) 0x0a – 0xee = Server SH in-path IP (10.0.103.238) 0x1e – 0x78 = In-path port number (7800) Note: Port 7800 for internal channel Port 7801 for out-of-path channel Additional probe: 0x4c = Riverbed Probe Option 0x04 = Length (4 bytes) 0x0e = Version/Type 0x01 = Info field indicating server SH connected to server already (This value will be 0x0d in 5.x which also indicates the server SH supports transparency mode)

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