SonicOS 7.0 Objects
- SonicOS 7.0
- Match Objects
- Zones
- How Zones Work
- Default Zones
- Security Types
- Allow Interface Trust
- Effect of Wireless Controller Modes
- Zones Overview
- The Zones Page
- Adding a New Zone
- Adding a New Zone in Policy Mode
- Adding a New Zone in Classic Mode
- Configuring a Zone for Guest Access
- Configuring a Zone for Open Authentication and Social Login
- Configuring the WLAN Zone
- Configuring the RADIUS Server
- Configuring DPI-SSL Granular Control per Zone
- Enabling Automatic Redirection to the User-Policy Page
- Cloning a Zone
- Editing a Zone
- Deleting Custom Zones
- Addresses
- Addresses Page
- About UUIDs for Address Objects and Groups
- Working with Dynamic Address Objects
- Services
- URI Lists
- Schedules
- Dynamic Group
- Email Addresses
- Match Objects
- Countries
- Applications
- Web Categories
- Websites
- Match Patterns
- Custom Match
- Profile Objects
- Endpoint Security
- Bandwidth
- QoS Marking
- Content Filter
- DHCP Option
- Block Page
- Anti-Spyware
- Gateway Anti-Virus
- Log and Alerts
- Intrusion Prevention
- AWS
- Action Profiles
- Security Action Profile
- DoS Action Profile
- Action Objects
- App Rule Actions
- Content Filter Actions
- Object Viewer
- SonicWall Support
802.1p Marking
SonicOS supports layer 2 and layer 3 CoS methods for broad interoperability with external systems participating in QoS enabled environments.
The layer 2 method is the IEEE 802.1p standard. The standard uses a three-bit field within an Ethernet frame header to assign priority levels to packets moving within a network segment. With the technique, this priority value is used to differentiate traffic as illustrated in the following figure.
TPID | Tag Protocol Identifier begins at byte 12 (after the 6 byte destination and source fields), is 2 bytes long, and has an Ether type of 0x8100 for tagged traffic. |
802.1p |
|
CFI | Canonical Format Indicator is a single-bit flag, always set to zero for Ethernet switches. CFI is used for compatibility reasons between Ethernet networks and Token Ring networks. If a frame received at an Ethernet port has a CFI set to 1, then that frame should not be forwarded as it is to an untagged port. |
VLAN ID | VLAN ID (starts at bit 5 of byte 14) is the identification of the VLAN. It has 12-bits and allows for the identification of 4,096 (2^12) unique VLAN ID’s. Of the 4,096 possible IDs, an ID of 0 is used to identify priority frames, and an ID of 4,095 (FFF) is reserved, so the maximum possible VLAN configurations are 4,094. |
Enable 802.1p marking on any Ethernet interface of the SonicWall appliance to support 802.1p tags. You can control the behavior of the 802.1p field within these tags with Access Rules (Classic Mode) or Security Action Profiles (Policy Mode). The default 802.1p action of None will reset existing 802.1p tags to zero (0), unless otherwise configured. For more information, refer to Applying QoS Marking.
Enabling 802.1p marking allows the target interface:
- To recognize incoming 802.1p tags generated by 802.1p capable network devices.
- To generate 802.1p tags, as controlled by Access Rules (Classic Mode) or Security Action Profiles (Policy Mode).
Frames that have 802.1p tags inserted by SonicOS bears VLAN ID 0.
Enabling 802.1p marking on an interface does not create the 802.1p tags. These tags are inserted according to Access Rules (Classic Mode) or Security Policies (Policy Mode) only. By the 802.1p marking default settings, SonicOS disrupt communications with 802.1p-incapable devices.
Specific support is required from the networking devices to use 802.1p method for prioritization.
- Many voice and video over IP devices provide support for 802.1p, make sure that the feature is enabled.
- Check your equipment’s documentation for information on 802.1p support if you are unsure.
- Many server and host network cards (NICs) have the ability to support 802.1p, but the feature is usually disabled by the default. Make sure that the feature is enabled.
- On Win32 operating systems, you can check for and configure 802.1p settings on the Advanced view of the Properties page of your network card. If your card supports 802.1p, it is listed as 802.1p QoS, 802.1p Support, QoS Packet Tagging or something similar.
If your network interface supports the 802.1p feature, make sure that the feature is present and enabled on the network interface and then only the network interface can generate packets with 802.1p tags, as governed by QoS capable applications. By the default, general network communications does not have tags inserted so as to maintain compatibility with 802.1p-incapable devices.
If your network interface does not support 802.1p, it is not able to process 802.1p tagged traffic, and ignores it. Make sure when defining Access Rules (Classic Mode) or Security Action Profiles and Security Policies(Policy Mode) to enable 802.1p marking that the target devices are 802.1p capable.
When performing a packet capture (for example, with the diagnostic tool Ethereal) on 802.1p capable devices, some 802.1p capable devices do not show the 802.1q header in the packet capture. Conversely, a packet capture performed on an 802.1p-incapable device almost invariably shows the header, but the host is unable to process the packet.
It is important to introduce DSCP Marking because of the potential interdependency between the two marking methods, 802.1p and DSCP as well as to explain why the interdependency exists. For more information, refer to QoS Marking Actions.
In DSCP marking: Example scenario, we have Remote Site 1 connected to Main Site by an IPsec VPN. The company uses an internal 802.1p or DSCP capable VoIP phone system, with a private VoIP signaling server hosted at the Main Site. The Main Site has a mixed gigabit and Fast-Ethernet infrastructure, while Remote Site 1 is all Fast Ethernet. Both sites employ 802.1p capable switches for prioritization of internal traffic.
- PC-1 at Remote Site 1 is transferring a 23 terabyte PowerPoint™ presentation to File Server 1, and the 100mbit link between the workgroup switch and the upstream switch is completely saturated.
- At the Main Site, a caller on the 802.1p or DSCP capable VoIP Phone
10.50.165.200
initiates a call to the person at VoIP phone192.168.168.200
. The calling VoIP phone 802.1p tags the traffic with priority tag 6 (voice), and DSCP tags the traffic with a tag of 48.- If the link between the Core Switch and the firewall is a VLAN, some switches will include the received 802.1p priority tag, in addition to the DSCP tag, in the packet sent to the firewall; this behavior varies from switch to switch, and is often configurable.
- If the link between the Core Switch and the firewall is not a VLAN, there is no way for the switch to include the 802.1p priority tag. The 802.1p priority is removed, and the packet (including only the DSCP tag) is forwarded to the firewall.
When the firewall sent the packet across the VPN/WAN link, it could include the DSCP tag in the packet, but it is not possible to include the 802.1p tag. This would have the effect of losing all prioritization information for the VoIP traffic, because when the packet arrived at the Remote Site, the switch would have no 802.1p MAC layer information with which to prioritize the traffic. The Remote Site switch would treat the VoIP traffic the same as the lower-priority file transfer because of the link saturation, introducing delay—maybe even dropped packets—to the VoIP flow, resulting in call quality degradation.
So how can critical 802.1p priority information from the Main Site LAN persist across the VPN/WAN link to Remote Site LAN? Through the use of QoS Mapping.
QoS Mapping is a feature which converts layer 2 802.1p tags to layer 3 DSCP tags so that they can safely traverse (in mapped form) 802.1p-incapable links; when the packet arrives for delivery to the next 802.1p-capable segment, QoS Mapping converts from DSCP back to 802.1p tags so that layer 2 QoS can be honored.
In our above scenario, the firewall at the Main Site assigns a DSCP tag (for example, value 48) to the VoIP packets, as well as to the encapsulating ESP packets, allowing layer 3 QoS to be applied across the WAN. This assignment can occur either by preserving the existing DSCP tag, or by mapping the value from an 802.1p tag, if present. When the VoIP packets arrive at the other side of the link, the mapping process is reversed by the receiving SonicWall, mapping the DSCP tag back to an 802.1p tag.
- The receiving SonicWall at the Remote Site is configured to map the DSCP tag range 48-55 to 802.1p tag 6. When the packet exits the firewall, it bears 802.1p tag 6. The Switch recognizes it as voice traffic, and prioritizes it over the file-transfer, guaranteeing QoS even in the event of link saturation.
Was This Article Helpful?
Help us to improve our support portal