Wireless Access

Reply
New Contributor

Aruba mobility cluster high value traffic classification

how/when/where is the high value traffic classified by the mobility controller in order to be synchronised to standby cluster member ? can the classification be changed ?

Aruba Employee

Re: Aruba mobility cluster high value traffic classification

High value sessions are only synchronized in an L2-connected cluster of mobility controllers. If the cluster is L3-connected, then sessions can not be synchronized.

 

The synchronization is automatic for an L2-connected cluster.

 

High value sessions are TCP connections like FTP. It should be noted that where priority and/or TOS is changed, or the session is DPI-modified, it becomes a high-value session. So voice going through an ALG, for instance, would be high-value.


Charlie Clemmer
Aruba Customer Engineering
New Contributor

Re: Aruba mobility cluster high value traffic classification

Hello Charlie,

 

My cluster is L2-Connected.

 

I can see that my FTP sessions are high value session by default. I tried the same with SSH but the sessions are not classified as high value session by default. I then added a policy for the assigned role to change priority / TOS value for all my SSH sessions. The assigment of the priority / TOS value can be seen with sh datapath session and confirms that the policy is working. Unfortunately I can still not see the SSH sessions synchronized to standby or assigned as high value sessions (sh datapath session high-value). We are running version 8.3.0.0.

 

Thanks for any feedback.

 

 

Occasional Contributor II

Re: Aruba mobility cluster high value traffic classification

I have also witnessed this situation on arubaos 8.3.0.2, but there is a solution.

 

I tried setting SSH as "high priority" and as TOS=46 for example but here is no "h" in the datapath session and it is not sychronized to the other L2 cluster members.

 

I has used a rule as such

 

any any svc-ssh permit queue high tos 46 position 1

 

intially expecting that to work, but it did not....

 

i managed to solve the problem by changing the rule to this instead:

 

any any app ssh permit queue high tos 46 position 1

 

i believe this is not a bug but in fact how it should be working.

 

you must use rule type "app" instead of "access-control" to enable the "high value" feature set.  Also, setting tos=x does not seem required, simply setting queue=high seemed to get me the desired "high value" determination.  

 

I hope this helps

 

Neal Vadekar

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: