📘 PCNSE OSPF Exam Essentials: Expanded Guide

1. OSPF Fundamentals Revisited

• Protocol Type: OSPF is a link-state routing protocol. Instead of just advertising reachable networks like distance-vector protocols, it describes the state of its own links and neighbors using Link-State Advertisements (LSAs). Each router builds an identical Link-State Database (LSDB) for an area, which is essentially a map of that area's topology. The Shortest Path First (SPF) algorithm (Dijkstra's algorithm) runs against this database to calculate the best, loop-free paths.
• Router ID (RID): A unique 32-bit identifier for each OSPF router within the OSPF domain. It's crucial for identifying routers and preventing loops. It's typically selected as the highest IP address on any active loopback interface, or if no loopback exists, the highest IP address on any active physical interface. It can also be manually configured, which is the recommended practice for stability. Duplicate RIDs can cause significant routing issues.
• Neighbors and Adjacencies: Routers on the same network segment become *neighbors* if their Hello packets parameters match (Area ID, timers, authentication, subnet mask, MTU). They become fully *adjacent* after successfully exchanging LSDB information. Adjacency formation goes through several states.
• DR/BDR Election (Multi-Access Networks): On broadcast and Non-Broadcast Multi-Access (NBMA) networks (like Ethernet), a Designated Router (DR) and Backup Designated Router (BDR) are elected to reduce the amount of LSA flooding. All other routers (DROthers) form full adjacencies only with the DR and BDR. The election is based first on OSPF interface priority (higher is better, 0 means ineligible). If priorities tie, the highest Router ID wins. The BDR takes over if the DR fails. There's no DR/BDR election on point-to-point links.
• OSPF Network Types: OSPF behavior changes based on the interface network type (e.g., Broadcast, Point-to-Point, NBMA, Point-to-Multipoint). This affects neighbor discovery (multicast vs. unicast Hellos) and DR/BDR election. Palo Alto firewalls default to 'Broadcast' for Ethernet interfaces. Mismatched network types can prevent adjacency.

2. Deep Dive into OSPF LSA Types

LSAs are the building blocks of the OSPF LSDB. Different LSA types carry specific pieces of topology or reachability information. Understanding their purpose and scope is critical for troubleshooting.

• Type 1 (Router LSA): Generated by every router and flooded *within an area*. Describes the router's links (interfaces), their state, IP address/mask, and cost. Uniquely identified by the originating router's RID.
• Type 2 (Network LSA): Generated by the DR on multi-access segments (Broadcast, NBMA) and flooded *within that area*. Lists all routers attached to that segment, including the DR, plus the network prefix and mask. Helps model the multi-access network itself. Identified by the DR's interface IP address.
• Type 3 (Summary LSA): Generated by Area Border Routers (ABRs) and flooded *from one area into other areas*. Advertises network prefixes learned via Type 1 and Type 2 LSAs in one area to other areas. Allows inter-area communication without flooding the entire topology everywhere. The name "Summary" is misleading as summarization must be explicitly configured. Identified by the network prefix being advertised.
• Type 4 (ASBR Summary LSA): Generated by ABRs and flooded *into areas* to advertise the location (RID) of an Autonomous System Boundary Router (ASBR). Tells routers in other areas how to reach the ASBR to get to external routes. Identified by the ASBR's Router ID.
• Type 5 (AS External LSA): Generated by ASBRs and flooded *throughout the OSPF domain* (except stub areas). Advertises routes external to the OSPF domain (e.g., redistributed from static, BGP, EIGRP). Identified by the external network prefix.
• Type 7 (NSSA External LSA): Generated by ASBRs *within a Not-So-Stubby Area (NSSA)* to advertise external routes. Flooded only within the NSSA. The NSSA ABR translates Type 7 LSAs into Type 5 LSAs to flood them into the rest of the OSPF domain. Identified by the external network prefix.
• Other Types (Less Common for PCNSE):
  • Type 6: Multicast OSPF (MOSPF) - Not widely used/supported.
  • Types 8, 9, 10, 11 (Opaque LSAs): Used for extensions like MPLS-TE or carrying other data. Generally flooded based on scope (link, area, AS).

LSAs have an age, typically refreshing every 30 minutes and timing out after 60 minutes (MaxAge). Issues with LSA aging or flooding can indicate problems.

3. OSPF Area Types and LSA Filtering

OSPF areas limit the scope of LSA flooding, reducing LSDB size and computational overhead on routers, thus improving stability and scalability. Palo Alto firewalls support standard OSPF area types.

• Normal Area (including Backbone Area 0): Allows all LSA types (1, 2, 3, 4, 5). All routers in a normal area have a full topology view of that area and receive summary/external routes from other areas. Area 0 is the core; all other areas must connect to it (directly or via virtual link).
• Stub Area: Blocks Type 4 and Type 5 LSAs (ASBR Summary and External). Routers in a stub area don't know the specifics of external routes or the exact location of ASBRs. The ABR injects a Type 3 default route (0.0.0.0/0) into the stub area for reaching external destinations. Useful for areas with limited resources or no need for external route details.
• Totally Stubby Area (TSA - Cisco Proprietary, but concept relevant): Blocks Type 3, Type 4, and Type 5 LSAs. Routers only learn intra-area routes and a single default route from the ABR for *all* destinations outside the area (both inter-area and external). Provides maximum LSDB reduction. Palo Alto uses the standard OSPF types, but the concept of minimizing LSAs is key.
• Not-So-Stubby Area (NSSA): A variation of a stub area that allows external routes to be imported *within* the area via an ASBR residing in the NSSA. These external routes are advertised as Type 7 LSAs within the NSSA. Like a stub area, it blocks Type 4 and Type 5 LSAs coming *from* other areas. The NSSA ABR translates Type 7 LSAs into Type 5 LSAs to propagate them to the rest of the OSPF domain. Optionally, the NSSA ABR can inject a Type 7 default route.
• Totally NSSA (Concept): Combines NSSA functionality (allowing local ASBRs and Type 7 LSAs) with Totally Stubby behavior (blocking incoming Type 3 summaries, in addition to Type 4/5). The ABR injects a default route.

Area type mismatches between neighbors will prevent adjacency formation.

4. Redistribution and Route Filtering

Injecting routes from other sources (static, connected, other dynamic protocols like BGP) into OSPF is called redistribution. This is done by an ASBR.

• Configuration: On Palo Alto firewalls, redistribution is configured using Redistribution Profiles found under Network > Virtual Routers > [Your VR] > Redistribution Profiles .
  • You create a profile, give it a priority (lower value = higher priority).
  • Select the source protocol(s) to redistribute (e.g., Static, Connected, BGP).
  • Optionally set a metric value and the OSPF external route type (Type 1 or Type 2).
  • Type 1 (E1): Cost includes the external metric *plus* the internal OSPF cost to reach the ASBR.
  • Type 2 (E2): Cost is only the external metric; internal cost is ignored for path selection (though used as a tie-breaker). This is the default.
• Exporting: The Redistribution Profile must be applied as an Export Rule under the OSPF configuration ( Network > Virtual Routers > [Your VR] > OSPF > Export Rules ). You can also choose to allow redistribution of the default route here.
• Filtering: Controlling which routes get redistributed is crucial.
  • Basic Filtering: The Redistribution Profile itself acts as a filter based on source protocol. You can add specific prefixes to include or exclude.
  • Priority-Based Filtering: Create multiple Redistribution Profiles. A profile with a lower priority number is evaluated first. You can create a high-priority profile (e.g., priority 1) with action "No Redist" for specific prefixes you want to block, and a lower-priority profile (e.g., priority 5) with action "Redist" for the broader category (like all static routes).
  • OSPF-Specific Filters: When redistributing *from* OSPF *to* another protocol (like BGP), the profile allows filtering based on OSPF path type (Intra-Area, Inter-Area, Ext-1, Ext-2), Area ID, or Tag.
  • Area Range (Summarization): Used for summarizing intra-area routes at the ABR (Type 3 LSA summarization). Configured under OSPF > Area > Range .
  • Filter Lists (Inter-Area): While PAN-OS doesn't have the exact `area filter-list` command like Cisco for Type 3 filtering, control over inter-area routes is typically managed via redistribution filtering at the ABR or careful area design. Summarization can also limit Type 3 LSAs.

5. OSPF Cost and Path Selection

• Cost Calculation: OSPF uses cost as its metric. Lower cumulative cost paths are preferred. The cost of an interface is typically calculated based on its bandwidth using the formula: Cost = Reference Bandwidth / Interface Bandwidth .
  • The default reference bandwidth (often 100 Mbps or 1 Gbps depending on platform/OS) can lead to faster links (e.g., 1 Gbps, 10 Gbps) having the same low cost (e.g., 1) if the reference isn't adjusted.
  • You can change the global reference bandwidth under the OSPF protocol settings in the virtual router.
  • You can manually override the calculated cost on a per-interface basis under Network > Virtual Routers > [Your VR] > OSPF > Area > Interface . This is often necessary for traffic engineering or when auto-cost calculation is inaccurate.
• Path Selection Order: OSPF doesn't simply choose the lowest cost path overall. It prioritizes routes based on their type *first*, and then uses cost as a tie-breaker within the same type. The general preference order is:
  1. Intra-Area (O) routes
  2. Inter-Area (O IA) routes
  3. External Type 1 (E1 or N1 for NSSA) routes
  4. External Type 2 (E2 or N2 for NSSA) routes
  For example, an Intra-Area route will always be preferred over an Inter-Area route, even if the Inter-Area route has a lower calculated cost. Within the same type (e.g., two E1 routes), the one with the lower cumulative cost wins.
• Influence on Routing: By adjusting interface costs, you can influence which path OSPF selects. Increasing the cost on an interface makes paths through it less desirable. This is a common technique for traffic engineering or forcing traffic over a preferred link.

6. OSPF Neighbor States

Troubleshooting often involves checking the OSPF neighbor state. Adjacency only forms when the state reaches Full .

• Down: Initial state. No valid OSPF Hellos heard recently (within the Dead Interval).
• Attempt: Only relevant for manually configured neighbors on NBMA networks. Trying to send unicast Hellos.
• Init: A Hello packet has been received from the neighbor, but it doesn't contain the local router's RID. Indicates unidirectional communication.
• 2-Way: Bi-directional communication established. Each router sees its own RID in the neighbor's Hello. On multi-access networks, DR/BDR election happens. Routers that won't become fully adjacent (DROTHER to DROTHER) stop here.
• ExStart: First step in forming an adjacency. Routers decide which will be the primary (master) for exchanging Database Descriptor (DBD or DDP) packets and determine the initial sequence number.
• Exchange: Routers exchange DBD packets describing their LSDB contents. The router may identify LSAs it needs.
• Loading: Routers request missing or outdated LSAs using Link State Request (LSR) packets and receive them via Link State Update (LSU) packets containing the full LSA details.
• Full: LSDBs are synchronized. The routers are fully adjacent. This is the goal state for routers that need to exchange full routing information (e.g., DR, BDR, point-to-point neighbors).

7. Common OSPF Troubleshooting on Palo Alto Firewalls

• Neighbor Adjacency Issues (Stuck in Init, ExStart, etc.):
  • Verify Layer 1/2 connectivity (interface up/up, cabling).
  • Check OSPF interface configuration: Ensure OSPF is enabled on the correct interface within the correct area. Network > Virtual Routers > [VR] > OSPF > Area > Interface .
  • Mismatched Parameters: Area ID, Hello/Dead timers, MTU, Subnet Mask, Authentication (type and key), Area Type (Stub/NSSA flags) MUST match between neighbors.
  • Check for passive interface configuration: Ensure the interface isn't accidentally set to passive. Network > Virtual Routers > [VR] > OSPF > Area > Interface > Passive . A passive interface advertises its network but doesn't send/receive Hellos.
  • Duplicate Router IDs: Ensure RIDs are unique across the OSPF domain.
  • Firewall Rules/ACLs: Although less common for OSPF itself if configured correctly, ensure no Security Policy or external ACL is blocking OSPF traffic (IP Protocol 89, or multicast addresses 224.0.0.5 / 224.0.0.6).
  • Network Type Mismatch: Ensure interfaces agree on the OSPF network type (e.g., Broadcast vs Point-to-Point).
  • DR/BDR Issues: On multi-access networks, check DR/BDR status. Problems here can affect adjacency.
  • Use CLI command: show routing protocol ospf neighbor to view neighbor state and related information.
• Routes Not Appearing in Routing Table:
  • Check OSPF neighbor state (must be Full for adjacency).
  • Verify LSA Database: Use show routing protocol ospf lsa type [type_number] to see if the LSA for the missing network exists in the LSDB.
  • Check Area Type Restrictions: Are you in a stub/NSSA area that filters the type of LSA carrying the route (e.g., Type 5 external route into a stub area)?
  • Redistribution Issues:
    • Is the route being correctly redistributed into OSPF? Check the Redistribution Profile configuration (correct source type, metric, filters).
    • Is the Redistribution Profile applied via an Export Rule in the OSPF configuration?
    • Check priorities if multiple redistribution profiles overlap.
  • Route Filtering: Check for any summarization (`area range`) or other potential filters blocking the route advertisement.
  • Check Administrative Distance: Is another routing protocol with a better (lower) AD providing the same route? (OSPF default AD is 110).
  • Use CLI command: show routing route to view the routing table. Filter by protocol if needed.
  • Check Runtime Stats in the WebUI: Network > Virtual Routers > More Runtime Stats .
• Suboptimal Routing:
  • Check OSPF Costs: Verify interface costs along the path. Adjust costs manually to influence path selection if needed.
  • Area Design: Ensure logical area design. Crossing areas adds cost and complexity; unnecessary ABR hops might cause suboptimal paths.
  • Route Type Preference: Remember OSPF prefers O > OIA > E1/N1 > E2/N2, regardless of cost. Is a less preferred route type being chosen because a better type isn't available or advertised correctly?
  • Summarization: Incorrect summarization can sometimes blackhole traffic or hide more specific, optimal paths.

8. Palo Alto Networks OSPF Troubleshooting Commands

Key CLI commands for OSPF troubleshooting on PAN-OS:

• show routing protocol ospf neighbor : Displays neighbor status, state, priority, DR/BDR information. Critical for adjacency issues.
• show routing protocol ospf neighbor interface <interface_name> : Detailed neighbor info for a specific interface.
• show routing protocol ospf interface : Shows OSPF parameters for interfaces (cost, timers, type, state, DR/BDR).
• show routing protocol ospf area : Displays information about configured OSPF areas.
• show routing protocol ospf lsdb : Shows a summary of the Link State Database.
• show routing protocol ospf lsdb type <type_name> lsid <lsa_id> advrtr <adv_router_id> : Displays details of a specific LSA (e.g., `type router lsid 1.1.1.1 advrtr 1.1.1.1`).
• show routing route type ospf : Displays only OSPF routes currently in the routing table (RIB).
• show routing fib : Displays the Forwarding Information Base (what the data plane actually uses).
• debug routing ospf [packet | event | lsa | nsm | spf] : Enables debugging for specific OSPF components (use with caution, can be CPU intensive). packet shows Hellos, DBDs, etc. lsa shows LSA flooding/updates. event shows neighbor state changes.
• less mp-log routed.log : View the routing daemon logs for errors or events.
• Check Runtime Stats in the WebUI: Network > Virtual Routers > [VR Name] > More Runtime Stats provides a GUI overview of neighbors, routes, LSDB, etc.

Palo Alto Networks OSPF Troubleshooting Commands (CLI)

Show Commands (Verification)

• show routing protocol ospf neighbor
  Displays the status, state, and basic information about OSPF neighbors. Essential for checking adjacency.
• show routing protocol ospf neighbor interface
  Provides detailed OSPF neighbor information for a specific interface.
• show routing protocol ospf interface
  Shows OSPF parameters configured on interfaces (cost, timers, network type, state, DR/BDR).
• show routing protocol ospf interface
  Displays detailed OSPF configuration and status for a specific interface.
• show routing protocol ospf area
  Lists configured OSPF areas and their types.
• show routing protocol ospf area
  Shows details for a specific OSPF area, including ranges (summarization) and interfaces.
• show routing protocol ospf lsdb
  Provides a summary view of the Link State Database (LSDB).
• show routing protocol ospf lsdb type [ lsid advrtr ]
  Displays detailed information about specific LSAs in the LSDB. Example types: router , network , summary , asbr-summary , external , nssa-external .
• show routing protocol ospf summary
  Provides a general summary of the OSPF process, including Router ID, area counts, neighbor counts, and redistribution settings.
• show routing protocol ospf statistics
  Displays statistics related to OSPF operations, like SPF runs and LSA counts.
• show routing route type ospf
  Filters the routing table (RIB) to show only routes learned via OSPF.
• show routing fib | match OSPF
  Displays the Forwarding Information Base (FIB - data plane table) and filters for OSPF entries.
• show routing redistribution profile
  Displays the configuration of a specific redistribution profile used to import routes into OSPF.

Debug Commands (Real-time Logging)

Caution: Debug commands can be CPU-intensive and generate a large volume of logs. Use them judiciously in a production environment and disable them promptly after troubleshooting.

• debug routing ospf level dump
  Sets the highest level of debugging detail for all OSPF components (very verbose).
• debug routing ospf level info
  Sets a general informational level of debugging.
• debug routing ospf level warning
  Sets debugging to show only warnings and errors (less verbose).
• debug routing ospf off
  Turns off all OSPF debugging.
• debug routing ospf component level
  Enables debugging for specific OSPF components. Common components:
  • packet : Shows details of sent/received OSPF packets (Hello, DBD, LSR, LSU, LSAck).
  • event : Logs significant OSPF events like neighbor state changes, interface state changes.
  • lsa : Tracks LSA flooding, generation, and aging.
  • spf : Shows SPF calculation triggers and results.
  • nsm : Neighbor State Machine events.
  • dd : Database Description packet exchange details.
  • route : Route table calculation events.
  Example: debug routing ospf component event level dump
• show counter global filter delta yes packet-filter yes | match ospf
  Shows packet counters, useful to see if OSPF packets are being received/sent at the hardware level, potentially identifying drops.

Packet Capture (Traffic Analysis)

• tcpdump filter "proto ospf"
  A basic filter for tcpdump (often run within a diag command or specific debug context) to capture OSPF packets (IP Protocol 89).
• Configuring Packet Capture via WebUI/CLI:
  Use the built-in packet capture feature ( Monitor > Packet Capture or CLI request troubleshooting packet-capture... commands) to capture traffic on specific interfaces.
  • Stage Name: Give your capture a name.
  • Filter: Use filters like ip proto 89 or specific IP addresses (e.g., host 224.0.0.5 or host 224.0.0.6 or host ).
  • Interface: Specify the firewall interface involved in the OSPF adjacency.
  • Enable and run the capture, then download the PCAP file for analysis in Wireshark.

Other Useful Commands & Logs

• less mp-log routed.log
  Views the routing daemon log file, which contains OSPF events, errors, and debug output (if enabled).
• show system resources | match routed
  Checks the CPU/memory usage of the 'routed' process, which handles dynamic routing. High usage could indicate instability or heavy load.
• show counter interface
  Displays interface counters, useful for checking for physical layer errors or packet drops that might affect OSPF communication.
• Check Runtime Stats in WebUI:
  Network > Virtual Routers > [Select VR] > More Runtime Stats provides a GUI overview of neighbors, routes, LSDB, etc.

OSPF troubleshooting Quiz

9. Potential PCNSE Exam Questions on OSPF