Posts

Showing posts from July 19, 2009

Riverbed Steelhead Password Recovery

To reset your password, you must have access to the serial console or monitor and be able to see the entire boot process to perform these steps: 1. Start, or reboot the appliance. 2. Once you see the "Press any key to continue" message, press a key. 3. Immediately press E. You should see a GNU GRUB menu. For a Steelhead upgraded to 4.0 from 2.0 or 3.0, the menu prompts you to select the Riverbed Steelhead, diagnostics, or a restore/recovery image. Select Riverbed Steelhead and skip to Step 5. For a Steelhead manufactured with 4.0 (that has not had previous versions), the menu prompts you to select the disk image to use. Continue with Step 4. For software versions prior to 4.0, the menu displays root and kernel parameters. Skip to Step 6. 4. Press V or ^ to select the disk image to boot. 5. Press E. Another GRUB menu appears, with options similar to these: ------------------ 0: root (hd0,1) 1: kernel /vmlinuz ro root=/dev/sda5 console=tty0 console=ttyS0,9600n8 ----

Riverbed gets Websense

Image
Riverbed’s Saldich hopes the firm’s tie-up with Websense will mark its solution out as market leading in its comprehensiveness and flexibility. Network infrastructure outfit Riverbed has joined forces with internet security firm Websense to offer web security with its WAN optimisation solutions. Riverbed’s Services Platform (RSP), which is a virtualised data services platform integrated into its Steelhead appliance, will now come equipped with Websense Web Security. Both vendors have also stated they are planning to extent the relationship further in the future with the addition of Websense’s Hosted Web Security to Riverbed’s product range in an attempt to provide the most “comprehensive, flexible and up-to-date” security solutions on the market. The manufacturer points out that by installing Websense Web Security software on Riverbed’s Steelhead appliances, organisations can consolidate WAN and Web security deployments, to further secure and boost their IT infrastructure. “Through our

Tabular Data Stream (TDS)

From Wikipedia, the free encyclopedia Tabular Data Stream (TDS) is an application layer protocol, used to transfer data between a database server and a client. Initially designed and developed by Sybase Inc. for their Sybase SQL Server relational database engine in 1984, and later by Microsoft in Microsoft SQL Server. Background During the early development of Sybase SQL Server, the developers at Sybase realized that there was no commonly accepted application-level protocol to transfer data between a database server and its client. To encourage the use of their products, Sybase came up with a solution through the use of a flexible pair of libraries called netlib, and db-lib to implement standard SQL. A further library was included to implement "Bulk Copy" called blk. While netlib's job is to ferry data between the two computers through the underlying network protocol, db-lib provides an API to the client program, and communicates with the server via netlib. db-lib sends t

Opportunistic Locking (OpLocks)

In the SMB protocol, Opportunistic Locking (also referred to as OpLocks) is a file locking mechanism designed to improve performance by controlling caching of files on the client. Contrary to traditional locking, OpLocks are not used in order to provide mutual exclusion, rather the main goal of OpLocks is to provide synchronization for caching. Locking types In the SMB protocol there are 3 types of Opportunistic Locks: Batch Locks Batch OpLocks were created originally to support a particular behavior of MS-DOS batch file execution operation in which the file is opened and closed many times in a short period. This is an obvious performance problem. To solve this, a client may ask for a Batch type OpLock. In this case, the client delays sending the close request and if a subsequent open request is given, the two requests cancel each other. Exclusive Locks When a client opens a file hosted on an SMB server which is not opened by any other process (or other clients) the client rec

Bandwidth-Delay Product(BDP) 頻寬-延遲乘積

From Wikipedia, the free encyclopedia In data communications , bandwidth-delay product refers to the product of a data link's capacity (in bits per second ) and its end-to-end delay (in seconds). The result, an amount of data measured in bits (or bytes ), is equivalent to the maximum amount of data on the network circuit at any given time, i.e. data that has been transmitted but not yet received. Sometimes it is calculated as the data link's capacity times its round trip time [ 1 ] . Obviously, the bandwidth-delay product is higher for faster circuits with long-delay links such as GEO satellite connections. The product is particularly important for protocols such as TCP that guarantee reliable delivery, as it describes the amount of yet-unacknowledged data that the sender has to duplicate in a buffer memory in case the client requires it to re-transmit a garbled or lost packet. [ 2 ] A network with a large bandwidth-delay product is commonly known as a long fat network (sh

SFQ vs FIFO vs MXTCP Queue in Riverbed Steelhead

Queuing is a method for prioritizing traffic. The following queuing mechanisms are supported in Riverbed Steelhead Appliance: SFQ(Stochastic Fairness Queuing)  SFQ is the default queue for all classes. SFQ services all flows in a round-robin fashion, reducing the latency for competing flows. SFQ ensures that each flow has fair access to network resources and prevents a bursty flow from consuming more than its fair share of output bandwidth. FIFO  Transmits all flows in the order that they are received (first in, first out). Bursty sources can cause long delays in delivering time-sensitive application traffic and potentially to network control and signaling messages. MX-TCP  MX-TCP, which stands for "Maximum Speed TCP", is an optional acceleration mode that allows Steelhead appliances to achieve maximum throughput for environments where it is a challenge to fill the pipe. Optimizes high-loss links where regular TCP would cause under utilization. With MX-TCP, the TCP conges

Flat QoS vs Hierarchical QoS(H-QoS)

Flat QoS: In flat QoS, all classes are created at the same level. When all classes are on the same level, the types of QoS policies that can be represented are limited. For example, suppose you want to create a hub with two classes to represent remote offices for San Francisco and New York, then apply a QoS policy to segregate traffic flow within the San Francisco office. Because you cannot define a subclass within the San Francisco spoke, the traffic flow is difficult to segregate. The following figure illustrates a flat QoS structure. H-QoS: H-QoS provides a way to create a hierarchical QoS structure that supports parent and child classes. You can use a parent and child structure to segregate traffic for remote offices based on flow source or destination. This is a way to effectively manage and support remote sites with different bandwidth characteristics. For example, a QoS hierarchy can represent a hub site that uses parent classes for the two spoke offices of San Francisco and New