OSPF Troubleshooting Scenarios

30 seconds

Why it fails: The 30-second value is the default OSPF HelloInterval for NBMA (Non-Broadcast Multi-Access) networks such as Frame Relay, ATM, and X.25, where multicast Hello delivery is not natively supported. Ethernet, by contrast, natively supports multicast/broadcast, so OSPF uses the faster 10-second HelloInterval as its default. A 30-second hello would not be the default on Ethernet, and a neighbor using the default dead interval of 40 seconds would be declared down almost immediately because the dead interval is only four times the default 10-second hello, not four times 30 seconds.

5 seconds

Why it fails: A 5-second hello interval is the default for OSPF on NBMA (Non-Broadcast Multi-Access) networks, not for Ethernet. On an Ethernet broadcast multi-access link, the default hello interval is 10 seconds. This option is tempting because 5 seconds is the default for OSPF point-to-point and NBMA interfaces, so it is correct for those specific network types, but the stem explicitly specifies an Ethernet link.

40 seconds

Why it fails: The 40-second value is not a hello interval at all — it is the default OSPF RouterDeadInterval on broadcast and point-to-point networks, including Ethernet. This dead interval is four times the HelloInterval (4 × 10 seconds = 40 seconds) and represents how long a router waits without receiving a Hello packet before declaring its neighbor down. Since the question specifically asks for the hello interval, this option is incorrect, even though 40 seconds is the related default dead timer for the same interface type.

The OSPF adjacency between PE1 and CE1 is down.

Why it fails: An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.

The VRF forwarding table on PE1 is full.

Why it fails: A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.

MPLS LDP is not enabled on the PE1-CE1 link.

Why it fails: LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

VRF CUSTOMER-A is not using BGP for routing

Why it fails: This statement is incorrect because the routing table for VRF CUSTOMER-A explicitly includes a BGP entry. The 'B' code in the output is standard for Border Gateway Protocol routes, and the presence of this entry with a valid next-hop (192.168.1.2) proves BGP is operational for this VRF. BGP is often configured under 'router bgp' with an address-family ipv4 (or ipv6) vrf CUSTOMER-A to enable per-VRF route exchange. Therefore, claiming BGP is not used contradicts the direct evidence from the show ip route vrf output.

The default route is learned via BGP

Why it fails: The gateway of last resort being 10.0.1.1 does not mean the default route was learned via BGP. A default route in the routing table is shown as 0.0.0.0/0, and its source can be static configuration, connected, or a dynamic protocol such as OSPF or EIGRP. The BGP entry for 10.0.2.0/24 is a distinct, non-default prefix, and there is no indication in the output that a BGP-learned default route exists. It is equally plausible the default route is a static route pointed to 10.0.1.1 originating from the service provider or local configuration.

GigabitEthernet0/0.100 is not associated with VRF CUSTOMER-A

Why it fails: This is incorrect because the directly connected route for GigabitEthernet0/0.100 appears within the VRF CUSTOMER-A routing table. If the subinterface had not been associated with the VRF, its connected network would reside in the global routing table instead. A subinterface is placed into a VRF by issuing the 'vrf forwarding CUSTOMER-A' command under the interface configuration, which tags all subsequently learned routes on that interface with the VRF instance. Therefore, the presence of that interface's connected routes in the VRF table is definitive proof of association.

OSPF adjacency will not form because the hello interval is too low for point-to-point.

Why it fails: This is incorrect because 10 seconds is the standard, expected hello interval for OSPF point-to-point networks, not 'too low.' A hello interval is only problematic when it fails to match the neighbor's configured interval, causing the dead timer to expire prematurely. Since the neighbor also uses 10/40, the timers are compatible and adjacency forms normally.

The network command under router ospf will be ignored because the interface has an explicit network type.

Why it fails: The network command under router ospf is still fully processed; it is responsible for assigning the interface to an OSPF area, not for determining the network type. The explicit interface-level point-to-point configuration only overrides the OSPF network type and its associated parameters like timers or DR/BDR behavior. Area assignment remains valid, so the interface participates in OSPF exactly as intended.

OSPF will use the default broadcast network type because the point-to-point keyword is misspelled.

Why it fails: The keyword 'point-to-point' is correctly spelled in the interface configuration, so the network type is not misinterpreted. Even if a typo existed, IOS would reject the invalid command rather than silently falling back to the default broadcast network type, which would cause a configuration error. Therefore, the adjacency forms with point-to-point characteristics, not broadcast.

The 'network' command should specify the interface instead of the subnet.

Why it fails: This is incorrect because OSPF network commands are designed to match IP addresses using a network number and wildcard mask, not interface names. The proper syntax is 'network <network> <wildcard-mask> area <area-id>', and interface-level OSPF activation would be done with 'ip ospf <pid> area <area-id>' on the interface itself. Specifying an interface in the network command would be invalid and is not supported in IOS.

The 'vrf definition GREEN' must include a 'route-target' command.

Why it fails: Route-targets are only necessary in MPLS VPN environments to control the export and import of VPNv4 routes between PE routers. In VRF-lite, which provides VRF awareness and route isolation on a single device without MPLS, route-targets are not required. The 'vrf definition GREEN' can be configured with just an address-family and interface membership, making the statement false.

The OSPF process must be configured under the global VRF context, not using 'vrf GREEN'.

Why it fails: This is mistaken because placing the OSPF process in the global context would associate it with the global routing table, not VRF GREEN. The correct method is exactly what is shown: 'router ospf <pid> vrf GREEN', which binds the OSPF instance to the VRF and allows its network statements to only match interfaces in that VRF. Therefore, the configuration correctly uses the vrf keyword.

The route to 10.1.1.0/24 is in the same OSPF area as R3.

Why it fails: The route to 10.1.1.0/24 is in the same OSPF area as R3. The routing table entry for 10.1.1.0/24 shows 'O IA', which stands for OSPF Inter-Area route. An IA route means the network belongs to a different OSPF area than the one in which R3 resides; it was advertised by an Area Border Router (ABR) using a Type 3 LSA. Therefore, it is not in the same area as R3 — it is from another area.

The metric for 10.3.3.0/24 includes the internal cost to the ASBR.

Why it fails: The metric for 10.3.3.0/24 includes the internal cost to the ASBR. For an OSPF External Type 2 (E2) route, the metric shown in the routing table is the external cost only — the cost configured or advertised by the ASBR — and does not include the internal OSPF cost from R3 to the ASBR. This is a key distinction between E1 and E2 routes: E1 adds the internal cost to the external cost, while E2 does not. Since the displayed metric is 20 and the route type is E2, the internal cost is intentionally omitted.

R3 is an ASBR.

Why it fails: R3 is an ASBR. The routing table output on R3 shows it receiving external routes (O E2 for 10.3.3.0/24), which only indicates that some other router redistributed those routes into OSPF. An Autonomous System Boundary Router (ASBR) is a router that injects external routes into OSPF, but nothing in the output suggests R3 is performing that redistribution. R3 is simply an internal OSPF router learning about the external routes via LSAs, not the source of those routes.

The route is an OSPF intra-area route

Why it fails: In OSPF, an intra-area route is derived from Type 1 or Type 2 LSAs and is listed with the route code 'O' in show ip route output. The routing table snippet explicitly shows 'type inter area' for this prefix, which is the marker for a Type 3 LSA generated by an ABR. Because the output does not say 'intra area' and the route type is explicitly inter-area, calling it an intra-area route is incorrect.

The route is an OSPF external route

Why it fails: OSPF external routes are flagged as 'type external' and have an E1 or E2 metric as well as the 'O E1' or 'O E2' route code. They are generated by an ASBR redistributing external networks, using Type 5 or Type 7 LSAs. The output here lacks any external metric marker and explicitly says 'type inter area', so this prefix is not an external OSPF route.

The route is learned via EIGRP

Why it fails: This prefix is learned via OSPF because the line 'Known via ospf 1' names the routing protocol and process ID. EIGRP routes are always displayed with 'Known via eigrp' followed by the autonomous system number, and they also use different route types such as internal or external. Since the output clearly points to OSPF as the source, and the route type is inter-area, EIGRP cannot be the originating protocol.

30 seconds

Why it fails: 30 seconds is the default OSPF hello interval for non-broadcast multi-access (NBMA) networks, such as Frame Relay or ATM, where neighbors may be reachable only via manual configuration and lower-speed links. However, the question asks about an enterprise network design on Ethernet, which is a broadcast network type, so 30 seconds is incorrect for that context. NBMA's longer hello interval reduces overhead on slow WAN links, but it also slows down failure detection compared to broadcast.

5 seconds

Why it fails: A 5-second hello interval is not a default for any OSPF network type. While you can manually configure OSPF timers to 5 seconds (or even lower) to achieve faster convergence, this is not a standard default and would generate twice the hello traffic of the 10-second default on broadcast networks. If used, the dead interval would typically be 20 seconds (4 * 5), making OSPF less tolerant of transient packet loss. Since the question asks for the default, 5 seconds is wrong.

20 seconds

Why it fails: 20 seconds is not a default OSPF hello interval for any standard network type. It is not specified in RFC 2328 or the OSPFv2 standard for broadcast, point-to-point, NBMA, or point-to-multipoint links. If a network engineer sees a 20-second hello, it must have been manually configured, perhaps to deliberately slow hello traffic, but it does not align with OSPF's default behavior. Thus, this value is incorrect for a default enterprise Ethernet design.

Type 1, Type 2, Type 3, Type 5

Why it fails: Type 5 LSAs advertise routes from outside the OSPF autonomous system, such as redistributed static or RIP routes. Both stubby and totally stubby areas filter these external LSAs to reduce routing table size and prevent external route flapping from affecting internal routers. Since a totally stubby area blocks all Type 5 LSAs, listing Type 5 in the allowed set is factually wrong.

Type 1, Type 2, Type 4, Type 5

Why it fails: Type 4 LSAs are generated by ABRs to advertise the location of an ASBR to other areas, and Type 5 LSAs carry the actual external routes. A totally stubby area prevents external routes from being learned, which also makes Type 4 LSAs irrelevant because there is no ASBR reachability to advertise. Both Type 4 and Type 5 are filtered at the ABR, so an option that includes either is incorrect.

Type 1, Type 2, Type 3 (including default), Type 4

Why it fails: Although a totally stubby area does permit Type 1, Type 2, and a default Type 3 LSA, it explicitly blocks Type 4 LSAs. The ABR does not forward ASBR-summary LSAs into a totally stubby area, even though it injects the default inter-area route. Including Type 4 in the allowed LSA list is therefore inaccurate; only the default Type 3 summary is permitted as the sole inter-area route.

Set the OSPF priority to 0 on Router A's interface.

Why it fails: Priority 0 means the router is ineligible to become DR or BDR. This would prevent Router A from becoming DR, which is the opposite of the requirement. It is used to exclude a router from the election, such as on a router that should only be a DROTHER.

Configure a higher Router ID on Router B.

Why it fails: A higher Router ID on Router B would make Router B more likely to win the election if priorities are equal. This would work against the goal of making Router A the DR. The requirement is to ensure Router A wins, so increasing Router B's Router ID is counterproductive.

Set the OSPF network type to point-to-point on Router A's interface.

Why it fails: Changing the network type to point-to-point eliminates the DR/BDR election entirely because point-to-point networks do not elect a DR or BDR. This would not satisfy the requirement for Router A to become DR; it would remove the concept of DR on that interface.

Configure static VXLAN tunnels between the VTEPs using the destination-udp-port command.

Why it fails: Static VXLAN tunnels are not a standard configuration on Cisco Nexus switches; VXLAN typically uses a control plane such as BGP EVPN or flood-and-learn with multicast. The destination-udp-port command does not create static tunnels. This option is incorrect because it misrepresents VXLAN tunnel establishment and does not resolve the lack of communication between hosts.

Enable OSPF on the loopback interfaces and advertise them into the underlay.

Why it fails: The loopback interfaces are already reachable per the scenario, so enabling OSPF and advertising them would not address the actual fault. The underlay routing is functioning; the problem lies in the VXLAN data plane or control plane, such as missing NVE interface configuration or incorrect VNI-to-VLAN mapping. This action is redundant and does not resolve the inability of hosts to communicate across VTEPs.

Enable PIM sparse mode on the underlay and configure a rendezvous point for multicast replication.

Why it fails: PIM sparse mode is used for multicast replication in VXLAN flood-and-learn mode, but the scenario does not specify that multicast is required or that it is missing. The primary issue is likely a basic NVE or VNI configuration error. Adding PIM would not fix a missing source-interface or VNI mapping, and it introduces unnecessary complexity without addressing the root cause.