• SonicOS 8 Rules and Policies
• Overview
  • Working with SonicOS
  • SonicOS Workflow
  • How to Use the SonicOS Administration Guides
  • Guide Conventions
• Access Rules
  • Setting Firewall Access Rules
    • About Connection Limiting
    • Using Bandwidth Management with Access Rules
      • Enabling Bandwidth Management on an Access Rule
    • Creating Access Rules
    • Configuring Access Rules for IPv6
      • About Stateful Packet Inspection Default Access Rules
    • Enabling and Disabling Access Rules
    • Editing Access Rules
    • Deleting Access Rules
    • Restoring Access Rules to Default Settings
    • Displaying Access Rules
      • By Zones
      • By Column
    • 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
    • Enabling Ping
    • Blocking LAN Access for Specific Services
    • Allowing WAN Primary IP Access from the LAN Zone
• NAT Rules
  • 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
    • Displaying Information about Policies
  • 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
  • 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 > Routing Rules
    • Configuring Routing Rules
      • Adding Static Routes
      • Probe-Enabled Policy-based Routing Configuration
• DNS Rules
  • Creating DNS Filtering Profiles
  • Configuring DNS Filtering
    • Creating DNS Policy Rules
      • Editing DNS Policies
      • Deleting DNS Policies
    • Configuring Global DNS Filtering Settings
    • Configuring DNS Filtering Custom Domains
  • Viewing DNS Rules Information
    • Viewing DNS Rules Using the Dashboard
    • Viewing DNS Filtering Reports
• Content Filter Rules
  • About Content Filtering Rules (CFS)
    • About Content Filter Rules
    • About UUIDs for CFS Policies
    • About Content Filter Action Objects
    • How CFS Works
  • Configuring CFS Policies
    • About the Content Filter Rule Table
      • Searching the Content Filter Rule Table
    • Adding a Content Filter Rule
    • Editing a Content Filter Rule
    • Deleting Content Filter Rules
• App Rules
  • About App Rules
    • What are App Rules?
      • About App Rules Policies
      • About App Rules Capabilities
    • Benefits of App Rules
    • How Does Application Control Work?
    • About App Rules Policy Creation
    • Licensing App Rules and App Control
    • Terminology
  • Rules and Policies > App Rules
    • Configuring an App Rules Policy
  • Verifying App Rules Configuration
    • Useful Tools
      • Wireshark
      • Hex Editor
  • 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
      • Blocking Outbound Proprietary Files Over FTP
      • Blocking Outbound UTF-8 / UTF-16 Encoded Files
      • Blocking FTP Commands
    • Bandwidth Management
    • Bypass DPI
    • Custom Signature
    • Reverse Shell Exploit Prevention
      • Generating the Network Activity
      • Capturing and Exporting the Payload to a Text File Using Wireshark
      • Creating a Match Object
      • Defining the Policy
• Endpoint Rules
• SonicWall Support
  • About This Document

OSPF Terms

OSPF is substantially more complicated to configure and maintain than RIP. The following concepts are critical to understanding an OSPF routing environment:

• Link state – As it pertains to OSPF, a link is an egress interface on a router, and the state describes characteristics of that interface, such as its cost. Link states are sent in the form of Link State Advertisements (LSA) which are contained within Link State Update (LSU) packets, one of five types of OSPF packets.

• Cost – A quantification of the overhead required to send a packet along a particular link. Cost is calculated by dividing a reference bandwidth (usually 100mbit, or 10^8 bit) by an interface’s speed. The lower the cost, the more preferable the link. Some common path costs are shown in Cost Calculation for Different Interfaces.

  Cost Calculation for Different Interfaces

  Interface	Divided by 10^8 (100mbit) = OSPF Cost
  Fast Ethernet	1
  Ethernet	10
  T1 (1.544mbit)	64
  DSL (1mbit)	100
  DSL (512kbps)	200
  64kbps	1562
  56kbps	1785

• Area – The network comprising the group of OSPF routers intended to share a common Link State Database. OSPF networks are built around the backbone area (area 0, or 0.0.0.0) and all other areas must connect to the backbone area (unless virtual links are used, which is generally discouraged). Area assignment is interface specific on an OSPF router; in other words, a router with multiple interfaces can have those interfaces configured for the same or different areas.

• Neighbors – OSPF routers on a common network segment have the potential to become neighbors by means of sending Hello packets. Hello packets act as a form of advertisement and identification, and if two OSPF routers share a common set of certain characteristics, they become neighbors upon seeing their own router ID in the other router’s Hello packet. Hello packets are also used in the DR (Designated Router) and BDR (Backup Designated Router) election process. For two routers to become neighbors, the characteristics that they must have in common are:

  • Area-ID – An area ID identifies an OSPF area with a 32-bit value, and is generally represented in an IP address format. OSPF requires at a minimum the backbone area, area 0 (or 0.0.0.0) for operation.

  • Authentication – Authentication types can generally be set to none, simple text, or MD5. When using simple text, authentication should be used only for identification, as it is sent in the clear. For security, MD5 should be used.

  • Timer intervals – Hello and Dead intervals must be the same. The Hello interval specifies the number of seconds between Hello packets (as a Keepalive function), and the Dead interval specifies the number of seconds after which a router is considered unavailable if a Hello is not received.

  • Stub area flag – A Stub area is an area that only requires a single point of egress, and therefore does not require a full list of external link advertisements. The stub area flag on two potential neighbors must be the same to avoid inappropriate link state exchanges. Another factor that affects neighboring is the kind of network. OSPF recognizes three network types:

    • Broadcast – For example, Ethernet. In broadcast networks, neighboring can be established with all other routers in the broadcast domain.
    • Point to Point – For example, serial links. In point to point (or point to multipoint) networks, neighboring can be established with the router at the other end of the link.
    • NBMA (non-broadcast multiple access) – For example, frame relay. In NBMA networks, neighbors must be explicitly declared.

• Link State Database – The Link State Database is composed of the LSA’s sent and received by neighboring OSPF routers that have created adjacencies within an area. The database, after complete, contains all the link state information for a given area, at which time the Shortest Path First (SPF) algorithm is applied to determine the optimal route to all connected networks based on cost. The SPF algorithm employs the Dijkstra path finding algorithm, which essentially regards all routers as vertices in a graph, and computes the cost between each vertex.

• Adjacencies – OSPF routers exchange LSA’s with adjacent routers to create the LSDB. Adjacencies are created in different fashions depending on the network type (see Neighbors above). Generally, the network type is broadcast (for example, Ethernet) so adjacencies are formed by the exchanging OSPF packets in a handshake-like fashion (see OSPF Packet types below). To minimize the amount of information exchanged between adjacent routers, segments (broadcast domains) with multiple OSPF routers elect a Designated Router (DR) and a Backup Designated Router (BDR) using Hello packets.

• DR (Designated Router) – On multi-access segments, OSPF routers elect a DR and a BDR, and all other routers on the segment create adjacencies with the DR and the BDR. DR election is based on a router’s OSPF Priority, which is a configurable value from 0 (not eligible for DR) to 255. The router with the highest priority becomes the DR. In the event of a priority tie, the router with the highest Router ID (based on interface addressing) wins. When a router is the DR, its role is uncontested until it becomes unavailable.

  LSA’s are then exchanged within LSUs across these adjacencies rather than between each possible pairing combination of routers on the segment; see Routing adjacencies: Designated Router (DR). Link state updates are sent by non-DR routers to the multicast address 225.0.0.6, the RFC1583 assigned ‘OSPFIGP Designated Routers’ address. They are also flooded by DR routers to the multicast address 225.0.0.5 ‘OSPFIGP All Routers’ for all routers to receives the LSA’s.

  Routing Adjacencies: Designated Router (DR)

  

• OSPF Packet types – The five types of OSPF packets are:

  • Hello (OSPF type 1) – Sent at a certain interval to establish and maintain relationships with neighboring OSPF routers, and elect Designated Routers. (Sent during the initialization and the 2-WAY phases on LSDB synchronization).

  • Database Description (OSPF type 2) – Sent between OSPF routers during the creation of an adjacency. During the Exstart phase of LSDB synchronization, DD packets establish an ISN (initial sequence number) used to track LSA’s, and they establish a master/slave relationship between neighboring OSPF routers. In the Exchange phase of LSDB synchronization, they contain short versions of Link State Advertisements. Because DD exchanges can span multiple packets, they are exchanged in a poll (master) and response (slave) fashion to ensure completeness.

  • Link State Request (OSPF type 3) – During the Loading phase of LSDB synchronization, LSR packets are sent to request database updates from a neighbor. This is the final step in the establishment of an adjacency.

  • Link State Update (OSPF type 4) – Sent in response to Link State Requests, LSU packets flood adjacencies with Link State Advertisements to achieve LSDB synchronization.

  • Link State Acknowledgment (OSPF type 5) – To ensure reliability of LSA flooding, all updates are acknowledged.

• Link State Advertisements (LSA) – There are 7 types of LSA’s:

  • Type 1 (Router Link Advertisements) - Sent by an OSPF router to describe the links to each area to which it belongs. Type 1 LSA’s are only flooded into a router’s area.

  • Type 2 (Network Links Advertisements) – Sent by the DR for an area describing the set of routers within the network. Type 2 LSA’s are only flooded into a router’s area.

  • Type 3 (Summary Link Advertisements) – Sent across areas by ABRs (Area Border Routers) to describe the networks within an area. Type 3 LSA’s are also used for route aggregation purposes, and are not sent to Totally Stubby Areas.

  • Type 4 (AS Summary Link Advertisements) – Sent across areas by ABRs to describe networks within a different AS. Type 4 LSA’s are not sent to Stub Areas.

  • Type 5 (AS External Link Advertisements) – Sent by ASBR (Autonomous System Boundary Routers) to describe routes to networks in a different AS. Type 5 LSA’s are net sent to Stub Areas. There are two types of External Link Advertisements:

    • External Type 1 - Type 1 packets add the internal link cost to the external link cost when calculating a link’s metric. A Type 1 route is always preferred over a Type 2 route to the same destination.

    • External Type 2 - Type 2 packets only use the external link cost to determine the metric. Type 2 is generally used when there is only one path to an external AS.

  • Type 6 (Multicast OSPF or MOSPF) - Called source/destination routing, this is in contrast to most unicast datagram forwarding algorithms (like OSPF) that route based solely on destination. For more information about MOSPF, see RFC1584 – Multicast Extensions to OSPF.

  • Type 7 (NSSA AS External Link Advertisements) – Sent by ASBRs that are part of an NSSA (see ‘Stub Area’).

  • Stub Area – A stub area is an area that only requires one path, rather than an optimal path. This can be an area with only a single point of egress, or it can be an area where SPF optimization is not necessary. All routers in a stub area must be configured as stub routers, and rather than receiving the full state database, and computing the SPF tree, they receive only summary link information.

    There are different type of stub area:

    • Stub area – The standard stub area receives all LSA’s except for LSA type 5 (AS External Link advertisement). This helps to keep the LSDB smaller, and reduces the computational overhead on the router.
    • Totally Stubby Area – A special type of stub area into which LSA types 3 (Summary Links), 4 (AS Summary Links) and 5 are not passed. Only intra-area routes, and a default route are advertised into totally stubby areas.
    • NSSA (Not So Stubby Area) – Described by RFC3101, NSSA is a hybrid stub area that allows external routes to be flooded within the NSSA area using type 7 LSA’s (NSSA AS External Routes), but does not accept type 5 LSA’s from other areas. NSSAs are useful when connecting a remote site running a different IGP (such as RIP) to an OSPF site, where the remote site’s routes do not need to be distributed back to the main OSPF site. An NSSA ABR (Area Border Router) also has the ability to translate type 7 to type 5 LSA’s (this is possible only from the SonicOS CLI).

• Router Types – OSPF recognizes 4 types of routers, based on their roles; see OSPF-Recognized Router Types Example.

  OSPF-Recognized Router Types Example

  

• IR (Internal Router) - A router whose interfaces are all contained within the same area. An internal router’s LSDB only contains information about its own area.

• ABR (Area Border Router) – A router with interfaces in multiple areas. An ABR maintains LSDBs for each area to which it is connected, one of which is typically the backbone.

• Backbone Router – A router with an interface connected to area 0, the backbone.

• ASBR (Autonomous System Boundary Router) – A router with an interface connected to a non-OSPF AS (such as a RIP network) which advertises external routing information from that AS into the OSPF AS.