The Riverbed SteelHeads (SH) is a platform that, simply said, speeds up connections across the wide-area network (WAN). Riverbed solutions improve network performance and thus user satisfaction and productivity, enable storage and server consolidation into the data center by making application performance across the WAN feel like the server or storage is still local in the remote office, and provide a visualization platform for applications needing to remain in the remote office while still being managed centrally, all while lowering ongoing operating expenses by avoiding bandwidth upgrades and requiring fewer managed devices.
One Riverbed customer had a question about how they could integrate two Riverbed optimized networks; one they control (A&B) and another, the do not (C&D). They desired to keep the Riverbeds from each set of networks separate. My response was posted to a technical forum but I also include it here since I found it very interesting. It assumes technical proficiency with the Riverbed SteelHead platform, so unfortunately it will not be appropriate read for those not familiar with the workings of the product.
Using their diagram, let’s take a look at some of the technical requirement around how this would work:
In this scenario, networks A and B are optimizing via auto-discovery by Riverbed A and Riverbed D. Networks C and D are being optimized by a fixed-target rule on Riverbed C pointing to the out-of-path Riverbed B. The question was asked, if we don’t control networks C and D, what needs to be done to ensure that Riverbed A does not participate in optimization between network C and D.
If optimization is indeed occurring between clients on network D and servers on network C via a fixed target rule on Riverbed C pointing to Riverbed B, no peering rule is necessary on Riverbed A to avoid participation in optimization since peering rules are not invoked unless an auto-discovery probe is received. Fixed-Target rules do not initiate such an auto-discovery probe since fixed-target rules hard code the Riverbed to peer with. Furthermore, the optimized connection created by that fixed target rule from Riverbed C to Riverbed B is made on TCP port 7810 which is included in the default pass-through rules on Riverbed A for Riverbed protocols.
However, if we want to make sure that Riverbed C never peers with Riverbed A (due to sizing constraints for example), since both are in-path and may auto-discover each other, we will need both a peering rule and an in-path rule on Riverbed A. Riverbed C may be configured not to perform auto-discovery, but unless we have visibility into its configuration, you can’t be sure.
To handle inbound connections from network D to network C, we would put a peering rule on Riverbed A, matching Riverbed C’s in-path IP address. This ensures that a connection coming from a client on network D to a server on networks B or C would not be optimized. In essence, the peering rule on Riverbed A says to not respond to auto-discovery probes from Riverbed C for any networks behind it. We can also be more selective in the peering rule by using networks’ subnets instead of a peer IP. For example, we could allow connections from clients on network D to be optimized (by Riverbed C and Riverbed A auto-peering) for network B but not network C. We can think of a peering rule as answering the question, “what do I do when I receive an auto-discovery probe from another Riverbed?” If we don’t want optimization from network D to network C, but we do want optimization from network A to network C, the peering rule on Riverbed A would be specific to a peer IP address of Riverbed C. If we don’t want anyone auto-peering with Riverbed A when going to network C, the peering rule would use a destination subnet of network C.
Now, for outbound connections being initiated by clients on network C, due to the way server-side out-of-path works, outbound connections from network C will never be seen by Riverbed B. However, they will be seen by the in-path Riverbed A and thus will receive an auto-discovery probe. Other Riverbeds will respond to that probe and thus cause those connections to be optimized. So, for a connection being initiated on network C going to network D, a probe would be generated by Riverbed A and that probe would then be seen by Riverbed C and they would optimize that connection. Thus, if we don’t want Riverbed A and Riverbed C peering up for connections from network C to network D, we must put an in-path rule on Riverbed A to pass-through connections from network C to network D. If we don’t want Riverbed A optimizing any outbound connections from network C, that in-path rule would just match the source address of network C.
In summary, if we are just trying to keep Riverbed A from peering with Riverbed C, all we need is:
- An in-path rule on Riverbed A passing though connections to network D.
- A peering rule on Riverbed A passing probes from the peer-IP of Riverbed C.
This scenario still allows optimized connections from network A to network C or from network D to network A.
If we are instead trying to prohibit all optimization when networks A or B communicate with networks C or D, it is a little more complex. To do that we need:
- An in-path rule on both Riverbed A and Riverbed D passing through connections to network D
- An in-path rule on Riverbed D passing through connections to network C.
- A peering rule on both Riverbed A and Riverbed D passing through probes from network D.
- A peering rules on Riverbed D passing through probes from network C.