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 ?
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.
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.