cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1671
Views
25
Helpful
23
Replies

WAAS Quesrion

asmith1972
Level 1
Level 1

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?

Thanks

Cheers

23 Replies 23

mark.duffy
Level 1
Level 1

Hi

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.

Cheers

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.

"Riverbed does change the IP addresses across the WAN, but they do not tunnel traffic."

What is your definition of "tunnel"?

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.

Hi Damien,

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.

Thanks,

Bob

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:

QoS policies

Security policies

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.

<<

Hi There,

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?

Josh Tseng

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: