350-401 · topic practice
Practise 350-401 ENCOR 350-401 OSPF questions covering neighbour states, router IDs, areas, timers, passive interfaces, OSPF cost, route selection, and command-output troubleshooting.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
Why learners struggle
OSPF questions are often missed because learners confuse neighbour states, route selection rules, router IDs, areas, timers, and cost calculations. A question may look like it is testing OSPF, but the real decision may depend on administrative distance, route specificity, passive interfaces, DR/BDR behaviour, or command-output interpretation.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
Cisco IOS (classic)
Cisco NX-OS
Cisco IOS-XR
Cisco IOS-XE
Arista EOS
Drag a concept onto its matching description — or click a concept then click the description.
Simplifies SSH connections to network devices
Provides a unified API for configuration and state retrieval
Enables parallel task execution across inventory
Supports asynchronous network device communication
Offers raw SSH protocol implementation
Drag a concept onto its matching description — or click a concept then click the description.
Device hostname, vendor, model, OS version, serial number
Interface name, description, IP address, status, speed
BGP neighbor IP, remote AS, state, uptime
LLDP neighbor device ID, port ID, platform
Power supply, fan, temperature status
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Trap 1: The VRF is missing the route-target export command.
The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.
Trap 2: The PE router is not running a routing protocol with the CE router.
PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.
Trap 3: The MPLS LDP is not enabled on the PE-CE link.
MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.
The CE router does not have a default route pointing to the PE's VRF interface.
In an MPLS L3VPN, the CE router must have a route—either a default route or a specific prefix—that points toward the PE's VRF-facing interface as the next hop. Without such a route, the CE cannot forward packets to the PE for remote VPN destinations, so pings from the CE fail. The PE can still ping remote sites because its VRF routing table contains the remote VPNv4 routes, which proves the problem is the CE's missing next hop rather than the PE's VRF configuration.
The VRF is missing the route-target export command.
Why it fails: The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.
The PE router is not running a routing protocol with the CE router.
Why it fails: PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.
The MPLS LDP is not enabled on the PE-CE link.
Why it fails: MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Trap 1: The engineer used 'ip default-network' which is not supported in…
Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.
Trap 2: The internal routers have a route to the default network with a…
Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.
Trap 3: The engineer needs to configure 'eigrp stub' on the router to allow…
Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.
The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.
Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.
The static default route is not configured correctly; the engineer should use 'ip route 0.0.0.0 0.0.0.0 <next-hop>'.
Correct. The static default route must be correctly configured with a next-hop IP address. If the static route is missing or uses an interface instead of a next-hop, it may not be valid, and the redistribution will not propagate the route to internal routers, despite appearing in the topology table with a metric.
The internal routers have a route to the default network with a better metric from another source.
Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.
The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.
Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
Retrieve running configuration and state data
Retrieve configuration from a specific datastore
Modify the target configuration datastore
Confirm a candidate configuration as the new running config
Prevent other NETCONF sessions from altering a datastore
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused OSPF sessions
Every question in these sessions is drawn from the OSPF domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Sharpen your 350-401 knowledge of Architecture.
Practise 350-401 questions linked to Virtualization.
Work through 350-401 questions on Infrastructure.
Sharpen your 350-401 knowledge of Network Assurance.
Security practice questions for 350-401.
Targeted 350-401 practice covering Automation.
Practise eBGP/iBGP peering, path attributes, route selection and BGP troubleshooting.
Practise OSPF area types, LSA types, neighbour states and multi-area design.
Practise EIGRP DUAL, metrics, stub routing and route redistribution.
Practise VLAN configuration, trunk negotiation and inter-VLAN routing.
Practise RSTP, MSTP, port roles and STP protection features.
Practise extended ACLs, CoPP rate-limiting and control-plane protection.
A free account saves results across sessions and highlights which topics need work.
Sign up free