Low DRE comrpession detected for server

[joeclarktx]

Low DRE comrpession detected for server

I am getting this warning on one of my WAAS appliances.  Has anyone else seen this? 

This is on a WAE 502 device running v5.0.1

The mispelling of "comrpession" is a copy and paste from the warning message

Thanks

[adrrojas]

Hi,

Can you please log in  the WAAS device and run the following command:

#Show dre auto-bypass.

Thanks.

[joeclarktx]

Here is the output from that command

#Show dre auto-bypass

DRE auto bypass entries:

                server: port    state DRE LAN MB   DRE Comp last_update  entry_age

-------------------------------------------------------------------------------------

   0       X.X.X.X: 1092      bypass       6192          0 %        19s       6d5h

Total entries: 1

Thank you

[Richard Ward]

you need to add a class-map for port 1092

[adrrojas]

Thanks for the reply!

This alarm present is originated by the WAAS auto-bypass feature.

With the DRE auto-bypass feature, WAAS monitors DRE compression ratio and for traffic with low DRE compression ratio , it will automatically put it into  bypass.  The way it works is that WAAS will generate an alarm when an  application has transferred  a large amount of data, 20% or more of the total DRE cache size  (cache-percent) and has very low DRE comp ratio < 10% (comp-threshold). This  traffic will then automatically be put in DRE bypass. The bypass entries will  age out  (default is 7 days) and any alarm will then be cleared.

You can also manually clear these entries out from the CLI using "clear dre auto-bypass" or "clear dre auto-bypass

Hope this helps!

[Natalie Ramirez]

I got this exact same message this week due to DFS-R, DFSR which is compressed and encrypted.  When I first checked the data on the WAAS by typing "show stat conn | inc 172.16.20.213" (ip address of DFS server), I saw multiple connections with TDL but 0.00%, so I took the ports in question (1330 and 57327) and created a DFSR Policy to only do TFO for those destination ports.  Later for some odd reason, DFSR changed ports and started using 1066 and 49310 and I got this error message, so I added those destination start ports to my class-map. 

You must determine what application is sending the data, if there is a setting in that application to remove encryption and/or compression.  If there is no way of getting it to stop encrypting like the useless aformentioned DFS Replication protocol, you must create a policy for that traffic with "TFO only" OR "passthrough"