Application Acceleration
Application Acceleration

Default/Prefered Decompressors

‎11-09-2009 07:59 AM

Hello,

 

I want to review my WXC architecture (nearly 60 WXC) - to decrease the number of tunnels- and I need more information and your advice about the Default/Prefered Decompressor option. I read the guide but I don't have the answer to my question.

 

1) When a remote Site A wants to reach another remote Site B passing through this Default Decompressor named HubA :

Is the flow, once arrived on HubA, uncompressed and re-compressed to go to the SiteB ?

Or is the flow no threated by HubA and go directly to SiteB ?

 

In this case, only a compression tunnel need to be established between SiteA and HubA and another one from HubA to SiteB right ?

 

Do you thing this would be as reliable as having a compression tunnel between those 2 sites A and B ?

 

2) In case of a specific interconnection (between 2 communities): SiteA <-> HubA - HubB <-> SiteB

Can HubA get HubB as default compressor to reach SiteB ?

If a flow goes from SiteA to SiteB, do I need to specify those 2 Hubs as default decompressor ?

 

Thanks a lot for your answers.

 

Julie

 

 

4 REPLIES 4
Application Acceleration

Re: Default/Prefered Decompressors

‎11-09-2009 09:00 AM

Hello Julie,

I'll try to answer some of your questions:

1/ In case of inline WXC @HubA, after decompression on HubA, the cleartext traffic is sent along the longest-match route BUT "remote routes" are not considered. In case of offpath WXC @HubA, the cleartext traffic is sent along the 0/0 route. Either way the cleartext traffic will NOT reenter another tunnel on the same WXC @HubA without being sent out to adjacent router and then returned back to WXC @HubA (if adjacent router is configured to do so).

Both cases above are TRUE only if "tunnel switching" is NOT enabled.

The chained tunnel/compression-decompression-recompression-decompression is possible but TCP Acceleration is likely to fail or degrade and overall performance to suffer. I would recommend a direct tunnel between SiteA and SiteB.

2/ Yes it can. If you decide to follow this path, triple compression/decompression job is likely to degrade performance even further.

That being said, you can always look into enabling tunnel switching but you would lose TCP Accel altogether. Only MSR will remain.

Good luck!

Rgds

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Application Acceleration

Re: Default/Prefered Decompressors

‎11-10-2009 01:13 AM

Thanks Alex for your answers.

 

Well, now I really don't think this should be a good idea to implement those decompressors Smiley Sad

We have sensitive applications and if it can decrease their performance, I wouldn't take this risk .

 

Do you know if this kind of architecture is often deployed ? Because now, I don't really understand the real use of those decompressors in fact ... except in case of several WXC on site...

 

Julie

Application Acceleration
Solution
Accepted by topic author JBO
‎08-26-2015 01:27 AM

Re: Default/Prefered Decompressors

‎11-10-2009 02:30 AM

Julie,

Default decompressor is very useful feature in case of hub-spoke design especially if there are hundreds of low-end WX/WXC deployed as spokes and spoke-to-spoke tunnel count is exception rather than norm.

You can have several default decompressors and they are used in the order specified in the config.

Preferred decompressor is also a useful feature when you have several equal-cost remote routes and you want to send a particular traffic to a chosen one. Of course, you can always play with "remote-route" cost but preferred decompressor is far simpler (one line of WXOS config) and does not require route cost manipulation.

I agree that maintaining/monitoring dozens of tunnels manually is a labour-intensive task.

I wonder if you are using CMS at all? It's capable of analysing/monitoring/graphing app performance and tunnel health for hundreds of WX/WXC.

Rgds

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Application Acceleration

Re: Default/Prefered Decompressors

‎11-12-2009 12:28 AM

Alex,

 

Thanks for all those information !

Indeed, I use CMS to manage and monitor my WXCs Smiley Happy

 

Julie