Hi We have a MPLS network with numerous sites but all our apps run from a central location.
Anyway we'd like to put a WAAS device on 1 of the remote sites to see if it improves the performance of the apps. If we do this dow we just need to get 1 WASS box for the remote site or do we need 2 - 1 at the remote end and 1 at the data centre?
Also anyone know if there is a doc - saying WAAS speeds up Citrix, Exchange etc.. traffic by x amount?
Works well in an MPLS network, just use redirection lists.
Minimum supported deployment is 3 boxes, 1 remote, 1 central to front servers and a management box to configure it all. You can technically do some of it with 2 boxes but its not TAC supported and the GUI is clunky.
If you dig around on CCO you'll see some "marketing numbers" on performance increase, best thing to do is go for a try before you by from Cisco, contact your account manager. That way you test it in your network and see if it improves things, odds are you will see a big difference, we've deployed a few between the US and UK and the customer was very happy. Things like exchange and CIFS (NT Shares) work best in my opinion.
Big Cisco fan here, but we run HP/Riverbed optimization (WAAS not available when we deployed). There are no tunnels, and L4 transparency is maintained, as is dscp. Only drawbacks are cost, and the very low TCP connection limit.
Riverbed absolutely tunnels optimized traffic. If you are seeing non-tunneled traffic then it is traffic not being optimized by Riverbed. The tunneling is fundamental to their software architecture. They would have to completely re-engineer their software to get same transparency as Cisco WAAS.
Take a sniffer capture of traffic optimized by Riverbed and you will see Steelheads talking to Steelheads.
It appears you're correct - the Steelheads pick up the connection after it's established (maintaining transparency for firewall rules at least), and then the traffic transfer takes plece between the Riverbed devices. It does look like the dscp is being copied, but I'll have to do some more tests to make sure.
Thanks for clearing that up!
Riverbed does change the IP addresses across the WAN, but they do not tunnel traffic. We looked at both Cisco WAAS and Riverbed Steelhead and both products alter traffic over the WAN in some fashion. Both Riverbed and Cisco worked fine with our Cisco VoIP and QoS infrastructure. We have ultimately decided to go with Riverbed because it was easier to deploy and faster across our applications, which is windows file shares, Exchange 2003, and Oracle financials. We also talked to some very large customers in our market sector that have successfully deployed Riverbed. We have deployed at 15 locations and will soon be moving to the other 58.
The only impact that both these products have on our environment is that the traffic monitored over the WAN by our Network Physics implementation either reports the IP addresses of the Riverbed box in Riverbed's case or reports the altered optimized data in Cisco's case. The traffic reports are no longer relevant cuz the traffic is optimized! We have since moved the monitoring probes to the LAN side and also use the monitoring capabilities on the Riverbed box. We now get good traffic reports. The point of all this is that either Cisco or Riverbed could be deployed non-disruptively. At the end of the day you should look at which one is easier and nets the better performance for the applications that you care about.
A tunnel encapsulates multiple flows into a new single virtual connection. The original packets are carried in the payload of tunneling packets carrying the new virtual connection. A good example of a tunnel is a GRE connection.
In contrast, WAN acceleration vendors like Riverbed, Juniper, Silver-Peak, and a variety of network devices use proxy TCP connections. Conceptually it is no different from what a web proxy does, which is terminate the local connection and initiate a new proxy TCP connection to communicate with the destination. Yes, a web proxy does NAT and changes the IP addresses, but no, a web proxy is not a tunneling device. In the same way, devices like Riverbed's Steelhead appliance are not tunneling device s because each end-to-end TCP connection has its own individual proxy TCP connection stretching over the WAN between the devices.
Cisco's WAAS approach is a bit different. I believe the WAAS appliance spoofs the IP address of the original client and server in the optimized traffic flow sent by the WAAS devices. This can be good or bad depending on the network configuration.
A simple sniffer trace between the Steelheads will conclusively show that it's tunneling. Source IP is of a Steelhead. Destination IP is of remote steelhead. TCP port is 7800, a dedicated port used by Riverbed. All original source/destination addresses and TCP port information is obfuscated.
This is not analagous to to a Web proxy as the Riverbed solution requires a pair of devices- one to source the tunnel and the second to terminate it. A Web proxy simply terminates a session and map it to a new one. No remote device is required.
Lastly, Cisco WAAS does not spoof any information, all original addressing and tcp port information is passed transparently.
Is it possible to tunnel with Cisco WAAS? In some instances, it may be desirable to have the accelerating device create a tunnel, so that IPSec/GRE is not required further down the line (e.g. remote sites connected via Internet).
WAAS does not have the capability of sourcing or terminating tunnels but it does work transparently with routers and/or firewalls which are providing IPSEC tunnel transport between locations over public networks.
You are correct in stating that Riverbed proxies TCP connections, but both Juniper and Silver-Peak do not proxy connections. They work differently. Those vendors have products that rely on explicit tunnels between WAN acceleration peers. Tunnel architectures expose their own set of issues and Riverbed does not tunnel!
Both Riverbed and Cisco proxy connections, but that is where the similarities end. Cisco uses "transparent addressing" for WAN connections and Riverbed uses "correct addressing". It is not necessarily a bad thing that Riverbed's correct addressing approach presents the IP information for the acceleration appliances instead of the original IP addresses involved in the traffic flow.
Peter Sevcik from NetForecast has written a good document (located on www.wdsforum.org) that discusses Cisco's "transparent addressing" approach and Riverbed's "correct addressing". The net-net is that both approaches transform WAN traffic in some way and there are configurations that allow you to deal with each method.
There are more important topics to look for when investigating Application Acceleration, including how easy are these devices to deploy and manage and what is the performance impact on your critical applications.
I've read the article that you mentioned and I came away less than impressed as it is intentionally misleading.
First, "correct addressing" is nothing more than Riverbed marketing terminology for "tunnel".
There is nothing "correct" about it as this method completely obfuscates all true source/destination IP addressing.
Moreover the impact of a tunneled solution breaks many critical network functions:
Network Monitoring capablities
More complex troubleshooting
The customers I work with every day don't see these functions as arbitrary.
>>Lastly, Cisco WAAS does not spoof any information, all original addressing and tcp port information is passed transparently.
Just a few questions here--who is sending the data--the Cisco WAAS or the original sending host? Isn't the data in the traffic payload placed there by the WAAS device? If so, isn't the WAAS device sending the data, but pretending that the end-host sent it? Sounds like spoofing to me. And what happens if the destination host receives that traffic. Will it be able to do anything with the compressed payload? Or worse, what prevents it from thinking the compressed payload is actual TCP data intended for its application?
Packets optimized via WAAS are tagged with a unique TCP option. Upon reciept or optimized traffic the remote WAAS device strips the TCP option, restores the payload and forwards to host. Is WAAS compressing the payload in between? Yes. That is a foundational function of WAN optimization technology works.
This method allows WAAS to operate transparently- no source/destination addresses or TCP port values are changed.
In the event of a WAE failure, in-flight data destined for an endpoint would be dropped by that endpoint due to crc mismatch and the session would need to renegotiate. Data integrity due to a WAE failure is preserved.
Hope that helps.
CRC? The only CRC I'm aware of is at the Ethernet layer, and that would be generated by the switch or router local to the destination host. Why would there be a CRC mismatch in this case?
Thanks in advance for your help.
"Correct addressing" ... LOL! What a joke.
This is the third term I think they have come up with now.
The fact is this, Riverbed changes both the source and destination of the packet. This fundamentally changes the identity and routing behavior of the traffic from the original design and intent of the topology. If looks like a tunnel and acts like a tunnel ... guess what? Its a TUNNEL!
Riverbed's tunnel based architecture might be OK for the smaller networks where things like QoS, network analysis and security dont have alot of importance.
However, in the larger enterprise networks where true transparency and security does matter, Riverbed is not bearing scrutiny very well and Cisco WAAS is winning deal after deal. I see it every day.
Regarding QoS - how does NBAR behave when it sees optimized packets? Does it only do identification at L4, or is there some mechanism to allow L5-7 discovery?
Just to clarify what was previously posted ...
The TCP sequence number used for the optimized connection is different from that which is used on the client/server original connections. In the event that an optimized packet is received by the client/server, it should be ignored because the TCP sequence number is outside the expected window. So it is not the checksum, but rather the TCP sequence number.
** FOR THE BENEFIT OF OTHER FORUM USERS, PLEASE CREATE A SEPARATE TOPIC FOR ADDITIONAL QUESTIONS THAT DO NOT PERTAIN TO THE ORIGINAL POST IN THIS CONVERSATION **