SonicOS 7.0 Rules and Policies for Classic Mode
- SonicOS 7.0 Rules and Policies
- Access Rules
- Setting Firewall Access Rules
- About Connection Limiting
- Using Bandwidth Management with Access Rules
- Creating Access Rules
- Configuring Access Rules for IPv6
- Enabling and Disabling Access Rules
- Editing Access Rules
- Deleting Access Rules
- Restoring Access Rules to Default Settings
- Displaying Access Rules
- Displaying Access Rule Traffic Statistics
- Configuring Access Rules for NAT64
- Configuring Access Rules for a Zone
- Access Rules for DNS Proxy
- User Priority for Access Rules
- Access Rule Configuration Examples
- Setting Firewall Access Rules
- NAT Rules
- About NAT in SonicOS
- About NAT Load Balancing
- About NAT64
- About FQDN-based NAT
- About Source MAC Address Override
- Viewing NAT Policy Entries
- 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 One-to-Many NAT Load Balancing Policy
- Creating a NAT Load Balancing Policy for Two Web Servers
- Creating a WAN-to-WAN Access Rule for a NAT64 Policy
- DNS Doctoring
- Routing
- Content Filter Rules
- App Rules
- About App Rules
- Rules and Policies > App Rules
- Verifying App Rules Configuration
- App Rules Use Cases
- Creating a Regular Expression in a Match Object
- Policy-based Application Rules
- Logging Application Signature-based Policies
- Compliance Enforcement
- Server Protection
- Hosted Email Environments
- Email Control
- Web Browser Control
- HTTP Post Control
- Forbidden File Type Control
- ActiveX Control
- FTP Control
- Bandwidth Management
- Bypass DPI
- Custom Signature
- Reverse Shell Exploit Prevention
- Endpoint Rules
- SonicWall Support
About Administrative Distance
Administrative distance (admin distance) is a value that influences which source of routes should be used for two identical routes from different sources. The lower the administrative distance value, the more trusted the route.
The admin distance, when set, is only used by the ZebOS components when choosing which routes to:
- Populate into PBR
- Redistribute to other routing protocols when a static route competes with a route received from a particular routing protocol.
The admin distance is not used for prioritizing routes within PBR itself, so unless dynamic routing is in use, the admin distance set for a static route has no effect. When dynamic routing is being used, the admin distance provides a mechanism by which static routes defined in PBR can be compared to otherwise equivalent dynamic routes possibly received from protocols such as OSPF, RIP, or BGP. By default, the admin distance of a PBR static route inserted into the network services module (NSM) is equal to the metric defined for the PBR route. The admin distance of each static route may optionally be set to a different value when a custom value is entered for Admin Distance.
For example, if a simple (destination only) static route (for example, destination = 14.1.1.0/24
) is defined with a metric of 10 and the admin distance set to its default of Auto, that route is populated into NSM with an admin distance and metric of 10.
Now assume the same 14.1.1.0/24
route is received from both RIP and OSPF. RIP routes have a default admin distance of 120 and OSPF routes 110, so the static route, with a default admin distance (== the metric) of 10 would be preferred over both routes, and NSM would not populate either the OSPF or RIP route into PBR. If the admin distance of the static route had been set to 115 (keeping the metric at 10), however, then the OSPF route (at 110) would be preferred over the static route, but the RIP route would not. If the OSPF route disappeared, NSM would withdraw the OSPF route and would not populate the RIP route as its 120 AD is greater than the static route's 115 AD.
In either of the above cases, the static route is still preferred in PBR because all non-default routes populated into PBR from NSM are added with a 110 metric, which is greater than the metric of 10 for the static route.
If an admin distance of 110 and a metric > 110 are used for the static routes, the metric value passed to NSM would be used by OSPF when it compares the metric of the static route to the OSPF metric (or cost) of any competing OSPF route.
Was This Article Helpful?
Help us to improve our support portal