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
Classification
Classification is necessary as a first step so that traffic in need of management can be identified.
For classification of traffic, SonicOS uses:
- Access Rules as the interface in Classic Mode. For more information, refer to Configuring Access Rules section in SonicOS 7.0 Rules and Policies Administration Guide for Classic Mode.
- Security Policy as the interface in Policy Mode. For more information, refer to Security Policy section in SonicOS 7.0 Rules and Policies Administration Guide for Policy Mode.
This provides fine controls using combinations of Address Object, Service Object, and Schedule Object elements, allowing for classification criteria as general as all HTTP traffic and as specific as SSH traffic from host A to server B on Wednesdays at 2:12am.
SonicWall network security appliances have the ability to recognize, map, modify, and generate the industry-standard external CoS (Class of Service) designators, DSCP (Differentiated Services Code Point) and 802.1p. For more information, refer to 802.1p and DSCP QoS.
When identified or classified, traffic can be managed. Management can be performed internally by SonicOS Bandwidth Management (BWM), which is effective as long as the network is a fully contained autonomous system. Once external or intermediate elements are introduced such as foreign network infrastructures with unknown configurations or other hosts contending for bandwidth (for example, the Internet), the ability to offer guarantee and predictability are diminished. In other words, as long as the endpoints of the network and everything in between are within your management, BWM works exactly as configured. Once external entities are introduced, the precision and efficacy of BWM configurations can begin to degrade.
But all is not lost. After SonicOS classifies the traffic, it can tag the traffic to communicate this classification to certain external systems that are capable of abiding by CoS tags, thus they too can participate in providing QoS.
- Many service providers do not support CoS tags such as 802.1p or DSCP. Also, most network equipment with standard configurations are not able to recognize 802.1p tags, and could drop tagged traffic.
- Although DSCP does not cause compatibility issues, many service providers will simply strip or ignore the DSCP tags, disregarding the code points.
- If you wish to use 802.1p or DSCP marking on your network or your service provider’s network, you must first establish that these methods are supported. Verify that your internal network equipment can support CoS priority marking, and that it is correctly configured to do so. Check with your service provider, some offer fee-based support for QoS using these CoS methods.
Was This Article Helpful?
Help us to improve our support portal