SonicOS 7 Profile Objects
Managing QoS Marking
QoS marking is configured from the Traffc Shaping tab of the Add/Edit Rule dialog of the Policy > Rules and Policies > Access Rules > Add Rule page.
Both 802.1p and DSCP marking as managed by SonicOS Access Rules provide four actions: None, Preserve, Explicit, and Map. The default action for DSCP is Preserve and the default action for 802.1p is None.
The below table describes the behavior of each action on both methods of marking.
Action | 802.1p (layer 2 CoS) | DSCP (layer 3) | Notes |
---|---|---|---|
None |
When packets matching this class of traffic (as defined by the Access Rule) are sent out the egress interface, no 802.1p tag will be added. |
The DSCP tag is explicitly set (or reset) to 0. |
If the target interface for this class of traffic is a VLAN subinterface, the 802.1p portion of the 802.1q tag will be explicitly set to 0. If this class of traffic is destined for a VLAN and is using 802.1p for prioritization, a specific Access Rule using the Preserve, Explicit, or Map action should be defined for this class of traffic. |
Preserve | Existing 802.1p tag will be preserved. | Existing DSCP tag value will be preserved. | |
Explicit | An explicit 802.1p tag value can be assigned (0-7) from a drop-down menu that will be presented. | An explicit DSCP tag value can be assigned (0-63) from a drop-down menu that will be presented. | If either the 802.1p or the DSCP action is set to Explicit while the other is set to Map, the explicit assignment occurs first, and then the other is mapped according to that assignment. |
Map | The mapping setting defined in the Object > Profile Objects > QoS Marking page will be used to map from a DSCP tag to an 802.1p tag | The mapping setting defined in the Object > Profile Objects > QoS Marking page will be used to map from an 802.1 tag to a DSCP tag. An additional checkbox will be presented to Allow 802.1p Marking to override DSCP values. Selecting this checkbox will assert the mapped 802.1p value over any DSCP value that might have been set by the client. This is useful to override clients setting their own DSCP CoS values. | If Map is set as the action on both DSCP and 802.1p, mapping will only occur in one direction: if the packet is from a VLAN and arrives with an 802.1p tag, then DSCP will be mapped from the 802.1p tag; if the packet is destined to a VLAN, then 802.1p will be mapped from the DSCP tag. |
For example, refer below image which provides a bi-directional DSCP tag action.
Bi-directional DSCP tag action
HTTP access from a Web-browser on 192.168.168.100 to the Web server on 10.50.165.2 will result in the tagging of the inner (payload) packet and the outer (encapsulating ESP) packets with a DSCP value of 8. When the packets emerge from the other end of the tunnel, and are delivered to 10.50.165.2, they will bear a DSCP tag of 8. When 10.50.165.2 sends response packets back across the tunnel to 192.168.168.100 (beginning with the very first SYN/ACK packet) the Access Rule will tag the response packets delivered to 192.168.168.100 with a DSCP value of 8.
This behavior applies to all four QoS action settings for both DSCP and 802.1p marking.
One practical application for this behavior would be configuring an 802.1p marking rule for traffic destined for the VPN zone. Although 802.1p tags cannot be sent across the VPN, reply packets coming back across the VPN can be 802.1p tagged on egress from the tunnel. This requires that 802.1p tagging is active of the physical egress interface, and that the [Zone] > VPN Access Rule has an 802.1p marking action other than None.
After ensuring 802.1p compatibility with your relevant network devices, and enabling 802.1p marking on applicable SonicWall interfaces, you can begin configuring Access Rules to manage 802.1p tags.
The Remote Site 1 network could have two Access Rules configured as in the below table.
Setting | Access Rule 1 | Access Rule 2 |
---|---|---|
General View | ||
Action | Allow | Allow |
From Zone | LAN | VPN |
To Zone | VPN | LAN |
Service | VOIP | VOIP |
Source | Lan Primary Subnet | Main Site Subnets |
Destination | Main Site Subnets | Lan Primary Subnet |
Users Allowed | All | All |
Schedule | Always on | Always on |
Enable Logging | Enabled | Enabled |
Allow Fragmented Packets | Enabled | Enabled |
QoS View | ||
DSCP Marking Action | Map | Map |
Allow 802.1p Marking to override DSCP values | Enabled | Enabled |
802.1p Marking Action | Map | Map |
The first Access Rule (governing LAN > VPN) would have the following effects:
- VoIP traffic (as defined by the Service Group) from LAN Primary Subnet destined to be sent across the VPN to Main Site Subnets would be evaluated for both DSCP and 802.1p tags.
The combination of setting both DSCP and 802.1p marking actions to Map is described in the table earlier in Managing QoS Marking.
Sent traffic containing only an 802.1p tag (for example, CoS = 6) would have the VPN-bound inner (payload) packet DSCP tagged with a value of 48. The outer (ESP) packet would also be tagged with a value of 48.
Assuming returned traffic has been DSCP tagged (CoS = 48) by the firewall at the Main Site, the return traffic will be 802.1p tagged with CoS = 6 on egress.
Sent traffic containing only a DSCP tag (for example, CoS = 48) would have the DSCP value preserved on both inner and outer packets.
Assuming returned traffic has been DSCP tagged (CoS = 48) by the firewall at the Main Site, the return traffic will be 802.1p tagged with CoS = 6 on egress.
Sent traffic containing only both an 802.1p tag (for example, CoS = 6) and a DSCP tag (for example, CoS = 63) would give precedence to the 802.1p tag and would be mapped accordingly. The VPN-bound inner (payload) packet DSCP would be tagged with a value of 48. The outer (ESP) packet would also be tagged with a value of 48.
Assuming returned traffic has been DSCP tagged (CoS = 48) by the firewall at the Main Site, the return traffic will be 802.1p tagged with CoS = 6 on egress.
To examine the effects of the second Access Rule (VPN>LAN), we’ll look at the Access Rules configured at the Main Site, as shown below:
Setting | Access Rule 1 | Access Rule 2 |
---|---|---|
General View | ||
Action | Allow | Allow |
From Zone | LAN | VPN |
To Zone | VPN | LAN |
Service | VOIP | VOIP |
Source | Lan Subnets | Remote Site 1 Subnets |
Destination | Remote Site 1 Subnets | Lan Subnets |
Users Allowed | All | All |
Schedule | Always on | Always on |
Enable Logging | Enabled | Enabled |
Allow Fragmented Packets | Enabled | Enabled |
QoS View | ||
DSCP Marking Action | Map | Map |
Allow 802.1p Marking to override DSCP values | Enabled | Enabled |
802.1p Marking Action | Map | Map |
VoIP traffic (as defined by the Service Group) arriving from Remote Site 1 Subnets across the VPN destined to LAN Subnets on the LAN zone at the Main Site would hit the Access Rule for inbound VoIP calls. Traffic arriving at the VPN zone will not have any 802.1p tags, only DSCP tags.
- Traffic exiting the tunnel containing a DSCP tag (for example, CoS = 48) would have the DSCP value preserved. Before the packet is delivered to the destination on the LAN, it will also be 802.1p tagged according to the QoS Marking settings (for example, CoS = 6) by the firewall at the Main Site.
- Assuming returned traffic has been 802.1p tagged (for example, CoS = 6) by the VoIP phone receiving the call at the Main Site, the return traffic will be DSCP tagged according to the conversion map (CoS = 48) on both the inner and outer packet sent back across the VPN.
- Assuming returned traffic has been DSCP tagged (for example, CoS = 48) by the VoIP phone receiving the call at the Main Site, the return traffic will have the DSCP tag preserved on both the inner and outer packet sent back across the VPN.
- Assuming returned traffic has been both 802.1p tagged (for example, CoS = 6) and DSCP tagged (for example, CoS = 14) by the VoIP phone receiving the call at the Main Site, the return traffic will be DSCP tagged according to the conversion map (CoS = 48) on both the inner and outer packet sent back across the VPN.
Was This Article Helpful?
Help us to improve our support portal