I used to deploy WAN acceleration devices for a hardware vendor about 6 years ago. Not much has really changed since then except I won't make hardware recommendations because of consolidation and changing product lines.
All of these devices use some combination of compression and caching to reduce the overall traffic to be transmitted, TCP pre ack'ing to ...
I can recommend Cisco WAAS (Wide Area Application Services), specificall WAVE (Wide Area Virtualization Engine).
We use it for
over satellite connections (VSAT) for cruise ships, with latency between 600 ms and 800 ms, depending on satellite and earth station (possible additional transatlantic latency). One central ...
I am by no means authoritative on this subject, however, in our environment we use Riverbeds for WAN optimization, and although we're not over satellite, we see a 68% improvement in speed for TCP communication as a minimum, and the Steelheads we have report an almost 3x bandwidth increase based on data it serves from its datastore vs. actually transferring ...
Assuming the servers can ping each other:
You need to check that the Optimization Service is enabled globally and for your inpath interface otherwise the Riverbed will not interact with network traffic at all.
As soon as Optimization is enabled you can check under "Reports / Connected Appliances" if the Riverbeds can see each other.
I would also recommend Cisco WAAS. It does perform well. My company did a decision paper and evaluated a few products. The WAAS came out on top. It was better able to handle variable speeds associated with different weather conditions. Form factor can be a problem also. WAAS can be accomplished using WAAS Express, modules, or full appliance. If power and ...
Yes, generally you need at least one WAE device for the head-end or Core. For a very simple point to point scenario it is possible to use two routers running Express, but the optimization will be relatively low since DRE won't be used.
As far as I recall the software version in the 1941 is only WAAS Express, which does not save the data to disk. This has ...
If there is a Riverbed device at both ends of your link, you will gain some optimisation regardless of the traffic that is being sent.
Now, it may not be optimised to it's fullest extent (aka, the Print Optimisation feature), but none the less the technology deployed by Riverbed (bit level blocks of data) will in fact decrease the amount of data sent over ...
For one year now, I have been using Riverbed Steelhead to perform traffic optimization over regular WAN connections. So far I am satisfied with the results.
Despite I have no experience with satellite links, Riverbed's website looks like they have optimization solutions for satellite links too: http://www.riverbed.com/products-solutions/solutions/...
I can confirm that the Steelheads will reduce printer traffic volume.
I have seen a consistent 90+% reduction in traffic volume for JetDirect (TCP/9100) and LDP (TCP/515) protocols on my network.
These protocols are highly used on my network and I am unaware of any issues that have occurred in about 18 months since we deployed the Steelheads.
I'm so glad you asked this! We have IBM 4230-5I3's and 4247's that communicate back to a UVX platform or a Windows Print Server platform. Our Steel heads have printer optimization and it works well for both the WAN (over MPLS) or LAN (within the building on a different subnet/VLAN), but we've noticed the biggest benefit is always out to and from the WAN.
Option 3 is your only real choice.
You are limited by physics. As you probably know, you are running into delay-bandwidth product limitations, so Option 1 --increasing your connection speed won't help.
Option 2 is great news for Juniper, but it will make absolutely no difference in performance.
You might consider adjusting the maximum TCP window size ...
Your question is indeed vague and since it will generate mostly opinions, is also probably off topic.
I did want to address one point. The "Traveling Salesman Problem" isn't really applicable to data center topologies, whether it's just a handful of racks or a Facebook-sized organization. Data doesn't need to pass through every node. It only has to get ...
The M in MTU stands for maximum (transmission unit), so there's no "max MTU".
When determining the MTU in a tunnel you need to know the expected overheads from the wrapping protocols:
PPPoE: 8 bytes
IPv4: 20 bytes
IPv6: 40 bytes
TCP: 20 bytes
UDP: 8 bytes
PPTP (GRE): 40 bytes
The MTU outside the tunnel minus the summed overhead is the MTU inside the ...
Have you already accounted for MTU issues?
Often, an IPSEC or other tunnel over the public Internet will result in a path MTU of e.g. ~1420 bytes to destinations across the tunnel. If your hosts are all configured for 1500 bytes MTU they can usually work out the lower path MTU in the absence of ICMP filtering, but it's also frequent that folks block the ...
I believe you are confusing which part of the Steelhead infrastructure that setting refers to. The latency that is mentioned in that setting is between your client PC (with Steelhead mobile) and the local Steelhead, not the SMC. The idea is that with a latency under 10ms you have a high likelihood of being on the same branch location as the Steelhead, so it ...
Two satellite vendors that I worked with (10 years ago) were.
Gilat Satellite Networks
Both have VSAT options that involve a lot of "spoofing" similar to what Riverbed does on the WAN. They'll terminate the TCP connection at the earth-terminal on each end to make the client think things are faster than they are.