QoS on Spark 2350 - DiffServ Marking vs LLQ Behavior

[Rafael140852]

Hello everyone,

I have a scenario where a Spark 2350 running R82.00.10 (998002203) is managed by an SMS R82 JHF Take 107.

I need to implement a QoS policy and I have some questions regarding the behavior of the different QoS policy types. I have been testing both the Recommended Policy and the Express Policy.

With the Express Policy, everything works as expected regarding DiffServ marking. The packets are correctly marked, which is a requirement in my environment. However, I cannot find a way to implement a true Low Latency Queue (LLQ) or strict priority queue. Since I have SCADA/IEC-104 traffic, having low-latency prioritization is an important requirement.

With the Recommended Policy, I have:

Custom QoS classes created.
Rules matching the appropriate traffic and assigning it to the correct class.
Guaranteed bandwidth configured per class.
The classes attached directly to the WAN interface.
Inbound and outbound bandwidth correctly configured on the interface.
The logs show that the traffic is matching the expected QoS rule and class. For example, I can see entries such as:

Best_Effort -> af31 -> Rule_af31

which indicates that the traffic is being classified correctly.

However, the packets are not being marked with the expected DSCP value. When I capture the traffic with tcpdump, the packets still leave with:

tos 0x0 (Best Effort).

My questions are:

Is DSCP/DiffServ remarking supported only with Express Policy on Spark appliances?
Is it possible to configure LLQ or strict-priority queuing for SCADA/IEC-104 traffic on a Spark 2350?
In Recommended Policy, should the DiffServ code configured in the QoS class automatically remark the packet DSCP field, or is additional configuration required?
Is there any known limitation of SMB/Spark QoS compared to Gaia gateways regarding DiffServ marking and LLQ functionality?
Any guidance or experience with similar SCADA deployments would be greatly appreciated.

Thank you.

[PhoneBoy]

According to this, DiffServ is only supported on Express Policy: https://support.checkpoint.com/results/sk/sk183400 

[OxO]

Hi,

I'm currently watching the same thing, on R81.20

>> Is DSCP/DiffServ remarking supported only with Express Policy on Spark appliances?
> According to this, DiffServ is only supported on Express Policy: https://support.checkpoint.com/results/sk/sk183400

That contradicts (also in R82.10 Admin Guide):

And a "diffserv" ruleset is basically a subruleset which this output actually confirms (if you try to install a recommended as express)

Policy Install Error Message
####
- Express QoS policy cannot contain sub-rules.
####

And the other way around there is no way to create an "Class of Service" on a express ruleset.

>> The logs show that the traffic is matching the expected QoS rule and class. For example, I can see entries such as:
>> Best_Effort -> af31 -> Rule_af31

But on normal GAIA gateways, the LOG-output would only be: "af31 -> Rule_af31"

For TESTING I had a simple Topo/Ruleset:

Both SARK and GAIA are managed by the same SMS

TOPO: LAN-X <-SPARK-> T-LAN <-GAIA-> LAN-Y

QoS:

####

EF(VoIP)

CS4 (MGMT)

BE (default)

####

Traffic	GAIA: Rule Matching	GAIA: ToS
EF	EF-VOIP	0xb8
CS4	CS4-MGMT	0x80
BE	Best_Effort->Default	0x00

Traffic	SPARK: Rule Matching	SPARK: ToS
EF	Best_Effort->EF->VOIP	0x00
CS4	Best_Effort->CS4->MGMT	0x00
BE	Best_Effort->Best_Effort->Default	0x00

Therefore, a clear statement from CP would be helpful here as to whether "diffserv" SET is possible on SPARK or not.

Best

[OxO]

> Therefore, a clear statement from CP would be helpful here as to whether "diffserv" SET is possible on SPARK or not.

I need to correct myself—upon closer inspection... the set should work; the only issues would be the SPAK QoS (Recommended) ruleset matching and the resulting correct DiffServ handling/setting.

That is likely why 0x00 is always set by SPARK.

Both FW should set in/out EF (0xb8)

[OxO · Accepted solution]

to bring this to a conclusion: today I had a small timeslot - and perfomred a new test:

https://support.checkpoint.com/results/sk/sk178604
https://support.checkpoint.com/results/sk/sk183400

If you read carefully, SMBGWY-2530 also says:

Click to Expand

Delay Sensitivity feature and Differential Services marking feature can be used on Centrally Managed SMB appliance only under Express QoS mode.

Configuration is done in the "Advanced (UTM-1 Edge & SG80 Gateways)" section of the QoS action properties window.
Under Traditional QoS mode only Best Effort QoS class is supported. Using any other Diffserv/Latency classes will disable QoS policy.

So on the SPARK Policy I switched back to "Express" and modified the ruleset accordingly - with normal Rules and under action (properties) the DSCP Value in Decimal:

Traffic	SPARK: Rule Matching	SPARK: ToS
EF	Best_Effort->VOIP	0xb8
CS4	Best_Effort->MGMT	0x80
BE	Best_Effort->Default	0x00

Now its also working on SPARK.

[PhoneBoy]

Glad you found a working solution!