• SonicOS 7.1 Rules and Policies
• Overview
  • About SonicOS
  • SonicOS Workflow
  • How to Use the SonicOS Administration Guides
  • Guide Conventions
• Settings
  • Configuring App/Match/Malware
  • Configuring Content Filtering Service (CFS)
    • SonicWall CFS
    • CFS Custom Category
  • Geo-IP
    • Custom List
      • Editing a Custom List Entry
      • Deleting Custom List Entries
    • Using Geo-IP Diagnostics
  • Botnet
    • Configuring Botnet Settings
    • Creating Custom Botnet Lists
    • Viewing Dynamic Botnets Lists
    • Configuring a Dynamic Botnet List Server
    • Using Botnet Diagnostics
  • Decryption (DPI-SSL)
    • Certificate
    • Common Name
    • SSL Servers
  • Decryption (DPI-SSH)
  • Signature Update
• Security Policy
  • User & Country
  • App/URL/Custom Match
• NAT Policy
  • About NAT in SonicOS
  • About NAT Load Balancing
    • Determining the NAT LB Method to Use
    • Caveats
    • How Load Balancing Algorithms are Applied
    • Sticky IP Algorithm Examples
      • Example One - Mapping to a Network
      • Example Two - Mapping to an IP Address Range
  • About NAT64
    • Use of Pref64::/n
  • About FQDN-based NAT
  • About Source MAC Address Override
  • Viewing NAT Policy Entries
    • Changing the Display
    • Filtering the Display
  • Adding or Editing NAT or NAT64 Rule Policies
  • Deleting NAT Policies
  • Creating NAT Rule Policies: Examples
    • Creating a One-to-One NAT Policy for Inbound Traffic
    • Creating a One-to-One NAT Policy for Outbound Traffic
    • Inbound Port Address Translation via One-to-One NAT Policy
    • Inbound Port Address Translation via WAN IP Address
    • Creating a Many-to-One NAT Policy
    • Creating a Many-to-Many NAT Policy
    • Creating a NAT Load Balancing Policy for Two Web Servers
• Routing
  • About Routing
    • About Metrics and Administrative Distance
      • About Metrics
      • About Administrative Distance
    • Route Advertisement
    • ECMP Routing
    • Policy-based Routing
    • Policy-based TOS Routing
    • PBR Metric-based Priority
    • Policy-based Routing and IPv6
    • OSPF and RIP Advanced Routing Services
      • About Routing Services
        • Protocol Type
        • Maximum Hops
        • Split-Horizon
        • Poison Reverse
        • Routing Table Updates
        • Subnet Sizes Supported
        • Autonomous System Topologies
      • OSPF Terms
    • Drop Tunnel Interface
    • App-based Routing
  • Rules and Policies >
    • Configuring
      • Adding Static Routes
      • Probe-Enabled Policy-based Routing Configuration
• Decryption Policy
  • Client-side SSL Rules
  • Server-side SSL Rules
  • SSH Rules
  • Setting up the Decryption Policy Table
    • Managing the Decryption Policy Toolbars
    • Changing the Policy Priority
    • Creating Decryption Policies
      • Adding Decryption Policies
      • Editing Decryption Policies
      • Deleting Decryption Policies
• DoS Policy
  • Setting up the DoS Policy Table
    • Managing the DoS Policy Toolbars
    • Changing the DoS Policy Priority
    • Creating DoS Policies
      • Adding DoS Policies
      • Editing DoS Policies
      • Deleting DoS Policies
• DNS Policy
  • Creating DNS Policies
    • Adding DNS Policies
    • Editing DNS Policies
    • Deleting DNS Policies
  • DNS Doctoring
• Endpoint Policy
• Shadow
• SonicWall Support
  • About This Document

PBR Metric-based Priority

SonicOS supports a metric weighted cost assigned to a route policy for policy-based routing (PBR) that allows the configured metric to take precedence in route prioritization over the route specificity that used by default. Metrics have a value between 0 and 255. Lower metrics are considered better and take precedence over higher ones.

The general prioritization (high to low) of PBR routes is as follows, based on the policy fields defined as anything other than Any, or zero for TOS:

• Destination, Source, Service, TOS
• Destination, Source, Service
• Destination, Source, TOS
• Destination, Source
• Destination, Service, TOS
• Destination, Service
• Destination, TOS
• Destination
• Source, Service, TOS
• Source, Service
• Source, TOS
• Source
• Service, TOS
• Service
• TOS

Within these 15 classifications, routes are further prioritized based on the cumulative specificity of the defined route entries. For the source and destination fields, specificity is measured by counting the number of IP addresses represented in the address object. For example, the network address object, 10.0.0.0/24, would include 256 IP addresses, while the network address object, 10.0.0.0/20, would represent 4096. The longer /24 (24 bit) network prefix represents fewer host IP addresses and is more specific.

The new metric-weighted option allows the configured metric to take precedence in prioritization over the route specificity. With the option enabled, the precedence used during prioritization is as follows (high to low):

1. Route class (determined by the combination of source, destination, service, and TOS fields with values other than Any or zero)
2. The value of the Metric
3. The cumulative specificity of the source, destination, service, and TOS fields