CCNA OSPF Questions

LDP hello messages are multicast on interfaces where LDP is explicitly enabled, typically via the 'mpls ldp' configuration. Because GigabitEthernet0/2 lacks this LDP configuration, it does not participate in LDP neighbor discovery or label binding exchange. Consequently, the LDP adjacency is confined to GigabitEthernet0/1, and only that interface exchanges label mappings; MPLS forwarding may still occur on Gi0/2 using labels learned from other sources, but no dynamic LDP labels are exchanged there.

This sequence correctly enables OSPFv2 SHA-256 HMAC authentication. The interface command ip ospf authentication key-chain references a key chain, which must be defined globally with a key that specifies the cryptographic algorithm hmac-sha-256 and a password. This provides stronger security than MD5. The key chain allows for key rollover and multiple keys with different lifetimes, which is essential for operational flexibility.

The configuration is complete because the 'router ospf <pid> vrf GREEN' command correctly creates an OSPF process bound to VRF GREEN, and the 'network' statement uses a wildcard mask to advertise the appropriate subnet into OSPF. The router-id is automatically selected from the highest loopback or active interface address in the VRF, so no explicit router-id is required. Thus, OSPF will operate correctly within the VRF.

The command 'ipv6 ospf 1 area 0' is used in interface configuration mode to enable OSPFv3 on that interface and assign it to area 0. The process ID '1' must match the OSPFv3 process configured globally with 'ipv6 router ospf 1'. This command allows the interface to form adjacencies and participate in OSPFv3. Without it, OSPFv3 will not run on the interface, even if the global process is configured.

The playbook is likely omitting OSPF attributes that the nxos_ospf module tracks, such as 'router-id'. When a parameter is not specified, the module may treat the desired value as empty or default (e.g., the router-id derived from the loopback address), while the running configuration contains an explicit value, causing the module to detect a difference and report 'changed'. This is a classic idempotency issue: the module does not ignore unspecified parameters; it attempts to reconcile the configuration to the playbook's declared state, and every run sees the same mismatch.

OSPF computes external routes from type 5 LSAs only if the originating ASBR is reachable through an intra-area or inter-area route. The SPF algorithm builds a shortest-path tree to the ASBR first; if the ASBR's router LSA is missing or the resulting next hop has no valid OSPF route, the external prefix is left in the LSDB but never installed in the RIB. This is a fundamental adjacency-dependent rule for external route installation.

OSPF DR/BDR election is based first on interface priority, then on Router ID. The highest priority wins. Priority 255 is the maximum value and ensures Router A has the highest priority on the segment, making it the DR provided no other router has the same priority with a higher Router ID. This is the standard way to force a router to become DR.

The always keyword removes the dependency on a local default route, so the router advertises 0.0.0.0/0 into OSPF regardless of its own routing table. The metric 10 and metric-type 1 arguments set the advertised cost and mark it as an E1 external route.

The OSPF cost on this interface is explicitly configured to 50 using the 'ip ospf cost' command. This manual assignment takes absolute precedence over any automatically derived cost, so the router uses exactly 50 when computing the SPF metric for routes learned via this interface. Because the configured value is 50, it is the correct answer.

This is correct because OSPF hello and dead intervals are configurable per interface, and once configured with 5 and 20 seconds, the router will use those exact values for sending hello packets and for declaring a neighbor unreachable. The dead interval of 20 seconds is four times the hello interval, maintaining the recommended ratio for OSPF stability and fast convergence. This configuration is valid and commonly used to tune OSPF convergence times on point-to-point links.

Every OSPF router originates a Type 1 Router LSA describing its own interfaces, neighbours and link costs, flooded within its area only. This satisfies the requirement that each router advertises its local topology, forming the basis of the area's shortest-path tree.

The NVE interface must be configured with a source-interface (typically a loopback) and the VNI must be associated with the correct VLAN. Without this mapping, VXLAN encapsulation or decapsulation fails, preventing communication between hosts on different VTEPs. This is a common misconfiguration that directly causes the described symptom, making this the correct action to resolve the issue.

On a non-broadcast (NBMA) OSPF network type, the link is treated as a multi-access segment, so after the neighbor 192.168.1.2 is manually configured, OSPF forms a full adjacency and performs a DR/BDR election. The router with the highest interface priority (then highest router ID) becomes DR, and election occurs only among routers with priority greater than 0. This is correct because non-broadcast network type requires unicast neighbor configuration and still has multi-access semantics.

The command 'show bgp l2vpn evpn' displays the BGP EVPN table, including Type-2 routes (MAC/IP advertisement routes). If the switch is not receiving Type-2 routes, this command will show an empty table or missing entries for the expected MAC addresses. It is the primary command to verify EVPN route reception and is essential for troubleshooting control-plane learning.

Inter-area summarisation is configured on area border routers with the **area** *range* command, which consolidates Type 3 summary LSAs for networks within a specified area. This satisfies the stem's requirement for a true OSPF summarisation statement, since ABRs generate inter-area prefixes and can suppress individual component routes.

When OSPF redistributes a default route, the default metric-type is 2 (E2), which means the route's metric remains fixed at the ASBR-advertised value (20) and does not include the internal cost of reaching that ASBR. This is why a default route injected via redistribute or default-information originate is normally seen as an E2 route unless metric-type 1 is explicitly selected.

The OSPF configuration in the scenario explicitly sets the hello interval to 20 seconds and the dead interval to 80 seconds, which preserves OSPF's default dead-to-hello ratio of 4:1 (80/20 = 4). Because both neighbors are configured with these same values, the OSPF dead interval timer remains consistent, and adjacency formation occurs normally. This matches the requirement that neighbors must agree on timer values, not that a strict 4:1 ratio is mandated.

The 'show nve peers' command displays the state of VXLAN tunnel endpoints (VTEPs) and their peer relationships. It shows the IP address of each peer, the VNI, and the state (Up/Down). This directly verifies if VTEPs can communicate over the underlay, which is essential for VXLAN operation.

This is correct because the command uses the 'always' keyword to unconditionally originate a default route into the OSPF domain, and the explicit 'metric 20' and 'metric-type 2' keywords dictate the cost and external type of that route. The resulting LSA is an external type 2 (E2) route with a metric of 20, which will be advertised to all OSPF neighbors. No default route needs to exist in the local routing table for this advertisement to occur.

The VRF routing table shows a 'Gateway of last resort is 10.1.1.1' line, which indicates a default route of 0.0.0.0/0 is installed with next hop 10.1.1.1. This S* route means any destination not matching a more specific prefix will be sent to 10.1.1.1. Thus, the correct statement is that the VRF has a default route pointing to 10.1.1.1.

OSPFv2 message-digest authentication uses MD5 to hash the key and packet contents, so the key is never sent in cleartext. Configuring ip ospf authentication message-digest enables cryptographic authentication on the interface, and ip ospf message-digest-key 1 md5 supplies the key material. Neighbors must share the same key ID and key string for the adjacency to form, which satisfies the requirement to protect against spoofed hellos.

The virtual link is identified by the router ID of its remote endpoint, and in the displayed output 'ospf 2a54f7' (likely from 'show ip ospf virtual-links'), the destination is 'router 2.2.2.2'. This means 2.2.2.2 is the neighboring ABR that, together with the local router, forms the virtual adjacency across the transit area. Therefore, stating that 2.2.2.2 is the other endpoint is accurate.

Area 0 already enables MD5 authentication, but the interface itself lacks the enabling command, so no digest is sent. Adding 'ip ospf authentication message-digest' on GigabitEthernet0/0 activates authentication, allowing the configured key 1 to be used.

The interface-level command 'mpls label protocol tdp' takes precedence over any global or routing-protocol-level LDP configuration. On Cisco IOS, interface-specific configuration is applied after global settings and thus overrides them, so the interface uses TDP exclusively for label distribution. Even though 'router ldp' enables LDP globally, the interface's explicit TDP directive forces TDP on that interface. This is the standard precedence behavior for MPLS label protocol selection.

A static route to 192.168.1.0/24 with administrative distance 1 creates a more trustworthy entry than OSPF's default AD of 110, so the router prefers the static route for that exact prefix. This is the precise, surgical fix: it overrides OSPF only for this subnet while leaving all other OSPF-learned routes untouched, and it does not depend on the metrics of the two equal-cost OSPF paths.

GRE tunnels can carry multicast traffic, and when combined with IPsec, the GRE packets are encrypted. This allows OSPF to form neighbor adjacencies over the tunnel because OSPF uses multicast (224.0.0.5/224.0.0.6). Native IPsec cannot carry multicast, so GRE over IPsec is the standard solution for dynamic routing protocols requiring multicast over a VPN.

Routing protocols are essential for network stability, so they should be matched in dedicated class maps and given sufficient policing rates to avoid dropping legitimate updates. This allows CoPP to protect the CPU while preventing disruption to OSPF and BGP adjacencies, which is a key requirement in the scenario.

Separate class-maps allow granular classification, and the policy-map can apply different police actions per class. Routing classes can be policed generously (or with conform-action transmit and exceed-action transmit for critical control traffic), while SSH and SNMP are rate-limited. This is the standard CoPP design pattern for differentiated control-plane protection.

The 'adjacent neighbor count' of 2 is equal to the total neighbor count, which in OSPF terminology means every discovered neighbor has reached the full state after completing database exchange. On a multi-access broadcast segment, only the DR and BDR form full adjacencies with all routers, so this equality confirms that R2 has fully synchronized its LSDB with both neighbors and no neighbor is stuck in two-way or exstart state.

Setting the OSPF priority to 0 on an interface prevents that router from being elected as DR or BDR. The priority value is used in the DR election process; routers with priority 0 are ineligible. This is the correct method to ensure the router does not become DR or BDR while still participating in OSPF on that network.

The command 'router ospf 1 vrf CUSTOMER' starts an OSPF process with process ID 1 and associates it with the VRF named CUSTOMER. This is the correct syntax to enable OSPF within a specific VRF on Cisco IOS-XE. Once configured, OSPF will run in the context of that VRF, and routes will be installed in the VRF's routing table.

The route to 10.3.3.0/24 is an external route redistributed into OSPF. In the routing table, the code 'O E2' explicitly marks this as an OSPF external route of type 2. Type 2 (E2) routes are routes that originated outside the OSPF domain and were redistributed into OSPF, typically from another routing protocol such as EIGRP or BGP. The external cost is carried as configured on the ASBR, and in this case the metric of 20 is the default external cost for redistributed routes, confirming the redistributed origin.

CoPP is implemented using MQC constructs where a class map matches control plane traffic and a policy map defines policing actions. The policy map is then applied under the control-plane configuration mode using the service-policy command, which directs the policy to the route processor's traffic rather than to data plane interfaces.

Using a loopback interface as the VTEP source ensures high availability because it remains up as long as any path to the underlay exists. Advertising the loopback IP into OSPF makes it reachable by remote VTEPs, enabling VXLAN tunnels to form. This is the recommended design for VXLAN in Cisco Nexus environments.

CoPP works by classifying traffic into distinct classes and applying individual policers. Creating separate class-maps for each protocol allows the engineer to set appropriate rates for BGP and OSPF while still policing SSH and SNMP. This targeted approach protects the control plane without starving routing protocols, resolving the flapping while maintaining security.

The 'always' keyword in the 'default-information originate' command forces OSPF to generate and advertise a default route (0.0.0.0/0) throughout the entire OSPF domain, irrespective of whether a default route exists in the routing table. This guarantees connectivity to external networks via the advertising router even when it has no default route of its own, preventing blackholing in certain topologies.

The command 'ipv6 ospf 1 area 0' is the correct IOS interface subcommand to enable OSPFv3, the IPv6-capable version of OSPF, on that link. It starts OSPFv3 process 1 for that interface and places the interface in backbone area 0, which is the mandatory area that interconnects all other areas. The process ID is locally significant, and the area ID is a 32-bit value, with '0' being shorthand for 0.0.0.0.

The OSPF dead timer is the primary factor in convergence delay because it dictates how long a router waits for a missing hello before marking the neighbor unavailable. Setting the dead timer to 1 second ensures that a link failure is detected within roughly one second, and a hello interval of 333 milliseconds satisfies the standard three-hello requirement while maintaining a stable neighbor state. This direct reduction of the detection timer cuts the outage from tens of seconds to about one second, whereas other mechanisms only optimize post-detection processing.

In Ansible's ios_config module, the `parents` parameter specifies the configuration mode to enter before applying `lines`. When `parents` is set to 'router ospf 1', the module already issues that command to navigate into OSPF configuration mode. Adding `router ospf 1` again inside the `lines` list results in a nested command that the Cisco IOS parser does not accept in this context, producing a configuration error. The correct usage is to place only OSPF subcommands, such as network statements, in `lines` and let `parents` handle the mode entry.

The passive-interface default directive makes every OSPF-enabled interface passive unless a specific interface is later excluded. The no passive-interface GigabitEthernet0/0 command removes that default for Gi0/0, permitting OSPF hello packets and adjacency formation on that link. All other OSPF interfaces remain passive and silent, so only GigabitEthernet0/0 is active in OSPF terms. This precisely matches the configuration, making it the correct answer.

Setting the OSPF priority to 0 on an interface makes that router ineligible to become DR or BDR. This is the correct way to prevent a router from participating in the DR/BDR election. The router will still form adjacencies and exchange routing information, but it will remain a DROTHER. This setting is commonly used on routers that should not be DR/BDR, such as those with lower processing power or at the edge of the network.

In OSPF broadcast multiaccess networks, the DR/BDR election is governed by the interface priority field, which ranges from 0 to 255. Setting a priority of 0 explicitly marks the router as ineligible to participate in the election, so it can never be selected as the DR or BDR, regardless of its Router ID or any other factor. The router remains fully operational as a DROther and still establishes adjacencies with the DR and BDR.

The BGP EVPN address family carries MAC and IP address reachability information in the form of EVPN routes, such as Type 2 and Type 5 routes. This allows VTEPs to learn about remote hosts and VTEPs, facilitating the creation of VXLAN tunnels and enabling efficient forwarding without flooding.

R1's interface shows 2WAY/DROTHER with neighbour 10.0.0.3, and FULL/DR with 10.0.0.2, meaning R1 formed full adjacency only with the DR. On a broadcast segment, DROTHERs stay in 2WAY with each other, so R1 itself is a DROTHER, not the DR or BDR.

Creating separate class-maps allows the engineer to apply distinct policers to each traffic type. By giving SSH a higher rate limit or configuring it to always transmit, management access is protected. OSPF and BGP can be rate-limited independently to prevent control plane overload. This granular approach is the recommended CoPP design for protecting critical management traffic.

Every OSPF router originates a Type 1 Router LSA describing its own links, interface states and costs, flooded only within its area. This satisfies the requirement that each router advertises its local topology, forming the basis of the area's shortest-path tree.

This configuration enables OSPF MD5 authentication on the interface and defines the key with ID 1 and password 'Cisco123'. The 'ip ospf authentication message-digest' command activates MD5 authentication for OSPF on that interface, and the 'ip ospf message-digest-key' command specifies the key. This is the correct method to configure MD5 authentication on a per-interface basis in Cisco IOS.

This configuration enables OSPF on the router, advertises the internal subnet, and sets all interfaces to passive by default. The 'no passive-interface GigabitEthernet0/0' command re-enables OSPF hello processing only on the internal interface, allowing adjacencies to form there while suppressing them on the DMZ and Internet interfaces. This matches the requirement exactly.

This is the best practice. By creating separate classes, the engineer can apply different rate limits. Management traffic should have a higher rate limit to ensure administrators can always access the device, while control plane protocols can have lower limits to protect the route processor. This granularity ensures that critical management access is not starved during an attack, and routing protocols are still protected but not at the expense of management access.

On a point-to-point OSPF network type, Cisco's default hello interval is 10 seconds, identical to the default on broadcast networks. This is because both network types use the same timer defaults on Cisco IOS, and the dead interval is then calculated as 4 × 10 = 40 seconds. Since the option specifically addresses the hello interval, it is correct.

CoPP policies that apply a blanket rate limit to all control plane traffic can inadvertently throttle essential routing protocol messages like BGP keepalives and updates. If the rate limit is too low or not exempting BGP, sessions may flap due to missed keepalives or delayed updates. The policy must be fine-tuned to allow sufficient bandwidth for routing protocols.

Ansible is declarative, agentless, and connects to managed nodes over SSH without installing any agent software. Its network modules, including ios_config and ios_ospf, target Cisco IOS and IOS XE devices and push configuration from playbooks. This matches the requirement for consistency across many routers, no on-device agent, and SSH-based transport exactly as described.

OSPF hello and LSA traffic to the route processor must be permitted at a sufficient rate to maintain adjacency. Creating a class-map for OSPF and assigning a policer with an adequate CIR ensures control plane protection remains in place while allowing legitimate routing protocol traffic, which resolves the flapping caused by the default policer dropping OSPF packets.

On Ethernet (broadcast) and point-to-point links, OSPF's default hello interval is 10 seconds, as defined in RFC 2328. This 10-second hello is also paired with a default dead interval of 40 seconds (four times the hello), allowing a neighbor to be declared down after missed hellos. This setting balances fast neighbor detection with acceptable control-plane overhead on high-bandwidth LAN segments.

This command enables OSPF process 1 on the interface and assigns it to area 0. It is the interface-level method for enabling OSPF, which is precise and avoids the need for network statements. This is the recommended practice in modern Cisco IOS because it directly associates the interface with the OSPF process and area, reducing configuration errors.

This command enables OSPFv3 on the interface and associates it with OSPF process 1 and area 0. It is the correct way to enable OSPFv3 for IPv6 on an interface in Cisco IOS. The process ID must match the one configured in the global 'ipv6 router ospf' command. This command is essential for OSPFv3 operation on a per-interface basis.

The network command under router ospf with a wildcard mask matching the LAN subnet will advertise the LAN prefix into OSPF regardless of the WAN IP address. This is the standard method to enable OSPF on an interface and advertise its connected network. It does not depend on the WAN IP, so it remains stable when the DHCP lease changes.

100 Mbps is the OSPF default reference bandwidth defined in RFC 2328, and it is used in the formula cost = reference-bandwidth / interface-bandwidth. With this default, a 100 Mbps interface has a cost of 1, and any interface faster than 100 Mbps also receives a cost of 1 because OSPF costs are integer values; this is why network administrators often raise the reference bandwidth in modern high-speed networks.

In the EXSTART state, OSPF routers exchange Database Description (DBD) packets to negotiate the master/slave relationship and begin advertising their link-state databases. DBD packets are often the largest OSPF packets sent, and if one router has a lower interface IP MTU, the DBD packet may exceed that MTU and be silently dropped by the receiving router's IP stack. Because the DBD packet never arrives, the routers cannot complete the master/slave negotiation and remain stuck in EXSTART indefinitely. This is a textbook symptom of an MTU mismatch on the OSPF interface.

OSPF hellos and LSAs are being dropped because the policer for the OSPF class is too restrictive. Increasing the CIR for that class allows more OSPF control traffic to reach the route processor, stabilizing adjacencies. This maintains protection for other protocols while addressing the specific queue that is over-policing legitimate OSPF packets during normal adjacency formation and maintenance.

The global command 'ipv6 router ospf 100' creates the OSPFv3 routing process with process ID 100 and enters router configuration mode. Only after this process exists can interface-level commands like 'ipv6 ospf 100 area 0' become operational. This is the missing required step, making the configuration functional and allowing the router to exchange LSAs with its neighbors.

This is the correct behavior. The `point-to-point` OSPF network type is designed for links that connect exactly two routers, such as serial interfaces using PPP or HDLC. By definition, it eliminates DR/BDR election because there is no need to reduce adjacency flooding on a two-router segment, and it uses the default 10-second hello interval (with a 40-second dead interval). Configuring `ip ospf network point-to-point` is redundant when the interface already defaults to this type, but it is often used to explicitly override an interface's default OSPF network type on platforms like Ethernet or Frame Relay.

Within an MPLS L3VPN, simply running OSPF in the VRF does not make a CE route available to the MP-BGP VPNv4 control plane. The PE must explicitly execute a redistribution command, such as 'redistribute ospf 1 vrf CUSTOMER' under 'router bgp AS ... address-family ipv4 vrf CUSTOMER'. Missing this command means the OSPF-installed route stays confined to the VRF RIB; it is never given a route distinguisher, tagged with an export route target, or sent to remote PEs. Consequently, even a healthy OSPF adjacency and populated VRF still result in no VPNv4 prefix.

For redistributed external routes, OSPF installs the type 5 LSA only if the forwarding address is reachable through an OSPF internal route. If that address resolves via another protocol or not at all, the route stays in the database but never enters the routing table.

Ingress replication with BGP EVPN allows the leaf to replicate BUM traffic to all remote VTEPs in the EVPN control plane without using multicast in the underlay. This is the correct approach when multicast replication is not desired. The command `ingress-replication protocol bgp` enables this behavior.

In a totally stubby area, the ABR suppresses Type 4 (ASBR-summary) and Type 5 (AS-external) LSAs, and also replaces all Type 3 inter-area summaries with a single default route. This leaves only Type 1 (router) and Type 2 (network) LSAs for intra-area topology, plus the injected Type 3 default LSA for any traffic leaving the area. Therefore, the allowed LSA set is exactly Type 1, Type 2, and the default Type 3.

CoPP requires a policy map to be attached to the control plane with service-policy input under control-plane configuration mode. Without this attachment, the class maps and policy map exist but are not enforced on control-plane traffic, leaving the route processor unprotected.