Riverbed

[BOAC]

Anyone here using or looked at this for WAN optimisation?

[The Nr Fairy]

Domestic or commercial ?

[batninth]

BOAC

Looked at it in my IT capacity at work to do acceleration on our WAN. PM me if you think any thoughts on my part will help

batninth

[BOAC]

NR - an acquaintance was asking - his company is going to use it. Just interested. Have PM'd B9th, thanks.

[mixture]

Think about it. Nothing can work the magic that a properly specced WAN will.

PM'd the rest... :cool:

[batninth]

Think about it. Nothing can work the magic that a properly specced WAN will.

Hmmm....not quite sure about that. I don't see why you should pass static data repeatedly over the WAN to take up bandwidth, which is where WAN accelerators score.

Trouble is, and this is where I suspect your comment is coming from, that these days we have 2/10ths of b****r all in terms of static data being passed around commercial networks - most of the traffic is either IP voice, or dynamically generated even if it is portal based content, or browser based applications. In this case, as you say, the WAN has to be correctly specced, monitored & managed

[mixture]

batninth,

Trouble is, and this is where I suspect your comment is coming from

The other half of my post probably would have clarified. But i decided I'd rather keep that bit out of the public eye. :ok:

Suffice to say. Each to their own experiences. I've had mine (and seen many others), you've had yours. Probably the fairest thing to say publicly about any sort of "WAN optimization" (riverbed or anyone else) is caveat emptor, due diligence required.

[Shunter]

Yes. Done some fairly comprehensive eval of Riverbed and other WAN opt solutions.

In the right circumstances it can pull off some pretty amazing results, but beware the website hype; it's based on CIFS/MAPI traffic which is notoriously inefficient. Even so, with a bit of man-in-the-middle work you can even get great results with dynamic encrypted traffic but bear in mind it only really shines with TCP traffic.

It's VERY expensive! Beware the pricelist aswell, the 155Mbps appliance means 155Mbps optimised, not raw!

Depending on the requirement Citrix is frequently cheaper...

Nothing can work the magic that a properly specced WAN will.

Sorry lad, not true.

[mixture]

Shunter,

Sorry lad, not true.

Honestly, I can't be bothered to argue with such a sweeping statement.... especially when you yourself point out a few limitations in your very own post. :ugh:

It's NOT a magic plug and play solution.... what worked in your "comprehensive evaluation" might not work for others on their network.

I have seen implementations miserably fail because despite "comprehensive evaluations" by people's IT departments who then go and become over-reliant (no budget shortages, so the "right" models were bought) on it rather than upgrading the WAN as they should have done in the first place and eventually admit defeat and do. Unfortunatley I am not in a position to provide public detail on anything and have no interest in sharing it with you over PM either.

As I said above.... caveat emptor to people considering it. By all means try it, but don't write off the WAN upgrade option, especially given the good deals that can be had these days compared to say a few years ago.

[Shunter]

I don't think anyone's suggesting it's a magic bullet, but it can be very powerful in the right circumstances.

Let's take a real-life scenario just for example... Site rolling out new web-based product over https with 128kbps footprint per user. Site has 100Mbps link already at 40% utilisation, and expects 700 concurrent users of new app. The figures result in a saturated line. Could upgrade site link, but backhaul only 100Mbps from non-21CN POP so waste of time.

Riverbed benchmarks show 60% reduction in effective throughput due to caching of dupe data at site and takes site back within available bandwidth.

Can be useful in the right circumstances, but an expensive experiment if you don't do your homework and validate it as a solution for your requirements.

[Mike-Bracknell]

I don't think anyone's suggesting it's a magic bullet, but it can be very powerful in the right circumstances.

Let's take a real-life scenario just for example... Site rolling out new web-based product over https with 128kbps footprint per user. Site has 100Mbps link already at 40% utilisation, and expects 700 concurrent users of new app. The figures result in a saturated line. Could upgrade site link, but backhaul only 100Mbps from non-21CN POP so waste of time.

Riverbed benchmarks show 60% reduction in effective throughput due to caching of dupe data at site and takes site back within available bandwidth.

Can be useful in the right circumstances, but an expensive experiment if you don't do your homework and validate it as a solution for your requirements.

So as you say you've done a comprehensive eval, how did it compare against the built-in de-dupe tools in Windows Server 2008/2008R2 ??

[mixture]

Site rolling out new web-based product over https with 128kbps footprint per user. Site has 100Mbps link already at 40% utilisation, and expects 700 concurrent users of new app. The figures result in a saturated line. Could upgrade site link, but backhaul only 100Mbps from non-21CN POP so waste of time.


One of many possible approaches ..... howver PPRuNe is not the place for technical debate over this.

But yes, as batninth pointed out earlier.... if you've got one of those scenarios with a lot of dupe data floating around then sure, it's probably a great solution.

[Shunter]

How did it compare against the built-in de-dupe tools in Windows Server 2008/2008R2 ?

I think you're comparing apples with oranges. You're referring to filesystem de-duplication I presume which is a something of a different application albeit the technology is similar-ish in concept. Not played with 2008 particularly so couldn't really comment. I don't spend a lot of time tooling around with servers any more, and if I do it's usually something a little more heavy-duty than Windows.

The Riverbed stuff works by checksumming chunks of data as it traverses a WAN link and caching it. Next time a recognised chunk hits the sender it discards the payload and sends a token to the receiver which serves up the data to the destination host. You also have the option of cutting a cert to allow SSL decryption; man-in-the-middle style; and cache that content too.

Chatty protocols see a substantial improvement but stuff that's already heavily optimised (eg. ICA traffic) will show very little.

PPRuNe is not the place for technical debate

If it's in the computing forum I don't see why not.

[mixture]

Given the expansion of the PPRuNe acronym, plus the computers topic description :


Anyone with questions about the terribly complex world of computers or the internet should try here. We will also try and help with troubleshooting any technical problems you may have with the forums.

I suspect the intention was not to encourage debate or detailed troubleshooting of the joys of commercial or government networks, something for which there already exist many more suitable forums likely to be visited by a greater number of people versed in the technologies involved than PPRuNe.

Obviously within the realms of reasonable free speech and the mods, there's nothing stopping someone starting up a topic on, say BGP troubleshooting.... but I reckon it'd be a lost cause.

Just a thought.... :ok:

[Mike-Bracknell]

I think you're comparing apples with oranges. You're referring to filesystem de-duplication I presume which is a something of a different application albeit the technology is similar-ish in concept. Not played with 2008 particularly so couldn't really comment. I don't spend a lot of time tooling around with servers any more, and if I do it's usually something a little more heavy-duty than Windows.

Oh lah-de-dah wouldn't be caught with a Windows OS...

I was talking about BranchCache:

Windows Server 2008 R2: Branch Cache (http://www.microsoft.com/windowsserver2008/en/us/branch-cache.aspx)

and was wondering, since you had obviously done some research on the viability of the Riverbed product, whether built-in 'freebie' tools like this negated a certain percentage of the Riverbed USP given it's noted expense.

:)

(and I too don't see why we need to pander to the lowest common denominator in IT terms for 100% of the threads, and would be up for some BGP troubleshooting if necessary - it's not as if we're drowning in semi-advanced IT, is it?).

[Shunter]

I won't pretend I've spent more than 2 minutes reading up on BranchShare, but it seems to be a file-level caching system as opposed to raw TCP. In such case I'm sure it would speed up links where people commonly access the same files on web or file servers (corporate web-apps for example, or some "can in a bin" mpg which Terry from accounts put on T: drive). Doesn't sound like it works at the protocol level though and if so its benefit would be pretty specific. However something is better than nothing when it's free.

When AD finally gets some features (or I get made redundant) I'm sure I'll give it another look. You know, basic stuff like sacking getting rid of the stupid global catalogue and being a proper directory instead of an NT domain with a pleather coat, properly tuneable replication, master/slave partitioning, filtered replicas, attribute sync priority etc... Most folks have no need for stuff like that, and that's why Windows is their perfect choice, but if you want to pound the living crap out of it as a metadirectory it doesn't cut it (read: MIIS). But that's a whole different, boring, lengthy discussion

[Mike-Bracknell]

Doesn't sound like it works at the protocol level though and if so its benefit would be pretty specific. However something is better than nothing when it's free.

It doesn't, but I was wondering out loud whether you'd actually got any raw data of the amount of caching that occurs at the protocol level versus the filesystem level in general usage? (or was your eval purely lab-based?)