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
Subnet Sizes Supported
RIPv1 was first implemented when networks were strictly class A, class B, and class C (and later D and E):
Class A | 1.0.0.0 to 126.0.0.0 (0.0.0.0 and 127.0.0.0 are reserved) |
---|---|
|
|
|
|
|
|
Class B | 128.0.0.0 to 191.255.0.0 |
|
|
|
|
|
|
Class C | 192.0.0.0 to 223.255.255.0 |
|
|
|
|
|
|
Class D | 225.0.0.0 to 239.255.255.255 (multicast) |
|
|
|
|
Class E | 240.0.0.0 to 255.255.255.255 (reserved) |
|
|
|
This method of address allocation proved to be very inefficient because it provided no flexibility, neither in the way of segmentation (subnetting) or aggregation (supernetting, or CIDR – classless inter-domain routing) by means of VLSM – variable length subnet masks.
VLSM, supported by RIPv2 and OSPF, allows for classless representation of networks to break larger networks into smaller networks:
For example, take the classful 10.0.0.0/8
network, and assign it a /24
netmask. This subnetting allocates an additional 16-bits from the host range to the network range (24-8=16). To calculate the number of additional networks this subnetting provides, raise 2 to the number of additional bits: 2^16=65,536. Thus, rather than having a single network with 16.7 million hosts (usually more than most LAN’s require) it is possible to have 65,536 networks, each with 254 usable hosts.
VLSM also allows for route aggregation (CIDR):
For example, if you had 8 class C networks: 192.168.0.0/24
through 192.168.7.0/24
, rather than having to have a separate route statement to each of them, it would be possible to provide a single route to 192.168.0.0/21
which would encompass them all.
This ability, in addition to providing more efficient and flexible allocation of IP address space, also allows routing tables and routing updates to be kept smaller.
Was This Article Helpful?
Help us to improve our support portal