41 questions · OSPF topic · All types, answers revealed
Without an explicit router ID, Junos OS selects the highest loopback interface address, or the highest physical interface address if no loopback exists, and expresses it as a 32-bit dotted-quad IPv4 address. OSPFv3 still uses this same 32-bit format.
You are troubleshooting an OSPF network on Junos devices. A router in area 1 is not receiving external routes from an ASBR in area 0. The ABR connecting the areas is correctly configured. You suspect a problem with LSA flooding. Which LSA type is used by the ASBR to advertise external routes, and what is its flooding scope?
Type 5 LSAs are generated by ASBRs to advertise external routes. They are flooded throughout all areas except stub, totally stubby, and NSSA areas. In this scenario, area 1 is a standard area, so Type 5 LSAs should be flooded into it by the ABR. The ABR generates Type 4 LSAs to advertise the ASBR, and Type 5 LSAs are propagated. If not received, check area type or filtering.
Why this answer
OSPF external routes are advertised by ASBRs using Type 5 LSAs. These LSAs have domain-wide flooding scope, meaning they are propagated through all areas except stub, totally stubby, and NSSA areas. In the scenario, area 1 is a normal area, so the ABR should flood Type 5 LSAs into it.
If external routes are missing, possible causes include area type misconfiguration, LSA filtering, or the ABR not generating Type 4 LSAs for the ASBR.
Exam trap
The trap here is confusing Type 4 LSAs (which advertise the ASBR) with Type 5 LSAs (which advertise the external routes themselves).
Which TWO features characterize OSPFv3 compared to OSPFv2? (Choose two)
OSPFv3 retains the 32-bit dotted-quad router ID format inherited from OSPFv2, even though it runs over IPv6. This satisfies the stem's requirement for a shared characteristic, since the router ID is not derived from the IPv6 addressing scheme.
Why this answer
Option B is correct because OSPFv3, like OSPFv2, still uses a 32-bit unsigned router ID that is written in dotted-decimal IPv4 format, even though OSPFv3 runs over IPv6; the router ID is not an IPv6 address. Option D is correct because OSPFv3 forms adjacencies and sends hello packets using IPv6 link-local addresses (fe80::/10) on each interface, which is a key operational difference from OSPFv2's use of interface IPv4 addresses. Option A is incorrect because OSPFv3 does not exclusively use MD5 in the OSPF header; it relies on IPv6 IPsec (AH/ESP) for authentication, and later RFCs also define OSPFv3 authentication trailer options.
Option C is incorrect because OSPFv3 still requires a backbone area, Area 0, for multi-area topologies just like OSPFv2. Option E is incorrect because OSPFv3 dynamically learns inter-area routes through LSAs and the SPF calculation; it does not require manual static routes for inter-area paths.
You are configuring authentication for OSPF on a Junos router using MD5. Where must the MD5 key ID and password be defined in the configuration hierarchy?
Junos applies OSPF MD5 authentication per interface, defined under the interface stanza within the area hierarchy. Placing the key ID and password at [edit protocols ospf area <area> interface <interface> authentication md5] satisfies the stem's requirement for where MD5 credentials are configured.
Why this answer
On Junos, OSPF MD5 authentication is configured at the interface level under the OSPF area hierarchy. The correct path is [edit protocols ospf area <area> interface <interface> authentication md5], where you specify the key ID and password. This binds the authentication to the specific OSPF interface, which is required because OSPF authentication is per-interface, not global.
How to eliminate wrong answers
Option B is wrong because [edit protocols bgp group <group> authentication-key] configures BGP authentication, not OSPF — it's a different protocol entirely. Option C is wrong because [edit routing-options autonomous-system] sets the AS number for BGP, unrelated to OSPF authentication. Option D is wrong because [edit system authentication-order] controls the order of authentication methods for user login (e.g., RADIUS, TACACS+, local), not routing protocol authentication.
Which command allows an administrator to view the OSPF link-state database (LSDB) summary on a Junos device?
The 'show ospf database' operational command queries the router's link-state advertisements, displaying the LSDB contents and summary per area and LSA type. It directly satisfies the requirement to view the OSPF link-state database summary on a Junos device.
Why this answer
The command 'show ospf database' displays the OSPF link-state database (LSDB) summary, including all LSAs (Router, Network, Summary, External) and their details. This is the correct command to view the LSDB on a Junos device.
Exam trap
The trap is confusing commands that show OSPF neighbors, routes, or interfaces with the command that shows the LSDB; candidates must remember that 'show ospf database' is specifically for the LSDB.
How to eliminate wrong answers
Option A is wrong because 'show ospf neighbor' displays OSPF neighbor adjacencies, not the LSDB. Option B is wrong because 'show route protocol ospf' shows routes learned via OSPF in the routing table, not the LSDB. Option D is wrong because 'show ospf interface' displays OSPF interface parameters (area, cost, state), not the LSDB.
You are troubleshooting an OSPF network where an NSSA area is connected to the backbone via an ABR. External routes are being injected into the NSSA by an ASBR. Which router is responsible for translating Type 7 LSAs into Type 5 LSAs before flooding them into the backbone area?
The NSSA ABR performs Type 7 to Type 5 translation, converting LSAs originated by the ASBR inside the not-so-stubby area before flooding them into the backbone. The ASBR originates Type 7 LSAs but does not translate them.
Why this answer
In OSPF NSSA, external routes are injected as Type 7 LSAs by the ASBR. The NSSA ABR is responsible for translating Type 7 LSAs into Type 5 LSAs before flooding them into the backbone area (Area 0), because Type 7 LSAs are only flooded within the NSSA. This translation allows external routes to be propagated to the rest of the OSPF domain.
Exam trap
JNCIS-ENT often tests the specific router responsible for Type 7-to-Type 5 translation — candidates frequently pick the ASBR instead of the NSSA ABR.
How to eliminate wrong answers
Option B is wrong because the ASBR originates Type 7 LSAs but does not perform the Type 7-to-Type 5 translation — that is the ABR's role. Option C is wrong because internal routers within the NSSA do not translate LSAs; only the ABR at the NSSA boundary does. Option D is wrong because the DR is responsible for flooding LSAs on a segment, not for translating Type 7 to Type 5.
While reviewing OSPF logs on a Junos device, you notice frequent adjacency flaps. You suspect a mismatch in the OSPF timer configurations. Which two timers must match identically on adjacent OSPF interfaces for an adjacency to form?
OSPF neighbours exchange Hello packets at the Hello interval; the Dead interval is the silence period before declaring the neighbour down. Both values must match identically on adjacent interfaces, otherwise the router tears down the adjacency, producing exactly the frequent flaps observed in the logs.
Why this answer
OSPF Hello and Dead intervals are critical parameters that must match identically on connected interfaces; otherwise, hello packets are rejected or dead timers expire prematurely.
Which OSPF packet type is used to acknowledge the receipt of Link-State Updates (LSUs) to ensure reliable flooding?
Link-State Acknowledgment (Type 5) packets explicitly acknowledge received LSUs, providing the reliability OSPF requires for flooding. Unlike implicit acknowledgement via echoed LSAs, Type 5 packets confirm receipt directly, satisfying the stem's demand for reliable flooding over unreliable transport.
Why this answer
OSPF uses Link-State Acknowledgment (Type 5) packets to explicitly acknowledge the receipt of Link-State Update (LSU) packets, ensuring reliable flooding of LSAs. When a router receives an LSU, it sends an LSAck to confirm receipt; if not acknowledged, the LSU is retransmitted. This mechanism guarantees that all routers in an area receive LSAs reliably.
Exam trap
JNCIS-ENT often tests the distinction between OSPF packet types and their specific roles, especially confusing acknowledgment packets with request or update packets.
How to eliminate wrong answers
Option A is wrong because Database Description (Type 2) packets are used to summarize the link-state database during adjacency formation, not to acknowledge LSUs. Option B is wrong because Link-State Request (Type 3) packets are used to request specific LSAs that are missing or outdated, not to acknowledge receipt. Option C is wrong because Hello (Type 1) packets are used for neighbor discovery and maintaining adjacency, not for acknowledging LSAs.
Which TWO actions occur during OSPF link-state database flooding on a Junos routing device? (Choose two)
On receipt of an LSA, the Junos device installs it into its link-state database and returns a Link-State Acknowledgment, ensuring reliable flooding. This satisfies the flooding action of updating the LSDB while confirming receipt to the sender.
Why this answer
Option D is correct because when a Junos router receives an LSA during OSPF flooding, it installs the LSA into its link-state database (LSDB), runs the SPF algorithm if the topology changed, and sends a Link State Acknowledgment back to the sender to confirm reliable receipt. Option E is correct because OSPF flooding requires the router to forward (flood) the received LSA out all other OSPF-enabled interfaces in the same area, excluding the interface on which the LSA was received, so that every router in the area maintains an identical LSDB. Option A is wrong because OSPF LSAs are never converted into BGP path attributes; OSPF and BGP are separate protocols with independent databases and attributes.
Option B is wrong because flooding an LSA does not cause static routes to be deleted from the routing table. Option C is wrong because OSPF flooding does not reset all neighbor adjacencies on the device; adjacencies remain up and only the LSDB is updated and the LSA is re-flooded.
Which TWO OSPF packet types are used for reliable flooding and direct acknowledgment of Link State Advertisements? (Choose two.)
Link State Update packets carry the actual LSAs during flooding, delivering them to neighbours so their link-state databases converge. The stem's requirement for reliable flooding is satisfied because LSUs transport the advertisements themselves, while reliability comes from the Link State Acknowledgment packets sent in response.
Why this answer
Option D (Link State Update (LSU) packets) is correct because LSU packets carry the actual LSAs during OSPF flooding; a router sends LSUs to neighbors to reliably propagate link-state information throughout an area. Option E (Link State Acknowledgment (LSAck) packets) is correct because LSAcks provide the explicit, direct acknowledgment of received LSAs, which is the mechanism that makes OSPF flooding reliable. Together, LSU and LSAck implement reliable flooding: LSU delivers LSAs and LSAck confirms receipt.
Option A (DBD packets) is used during database exchange to summarize the link-state database and establish master/slave sequencing, not for flooding LSAs or acknowledging them. Option B (Hello packets) discovers and maintains neighbors and elects DR/BDR, but does not carry LSAs or acknowledge them. Option C (LSR packets) requests specific LSAs that a router is missing after comparing databases, so it is not part of reliable flooding or direct acknowledgment.
Exam trap
JNCIS-ENT often tests the distinction between OSPF packet types and their specific roles, causing candidates to confuse the functions of DBD, LSR, and LSU/LSAck in the reliable flooding process.
Type 3 summary LSAs are originated by the ABR to describe inter-area destinations, flooding them into the adjacent area to advertise networks learned from one area into another. This directly satisfies the stem's requirement for the LSA an ABR generates when propagating routes between areas, rather than intra-area Type 1 or Type 2 LSAs.
Why this answer
Type 3 Summary LSAs are generated by ABRs to advertise inter-area routes — networks from one area injected into another. The ABR originates a Type 3 LSA for each prefix it knows from a different area, allowing routers in the receiving area to reach those destinations without running SPF for the source area's topology.
Exam trap
The trap is confusing Type 3 Summary LSAs (inter-area) with Type 5 AS-external LSAs (redistributed external routes); candidates must remember that ABRs use Type 3, while ASBRs use Type 5.
How to eliminate wrong answers
Option A is wrong because Type 2 Network LSAs are generated by the DR on a multi-access segment to describe the subnet and attached routers, not to summarize between areas. Option B is wrong because Type 1 Router LSAs are flooded within a single area to describe a router's links and are not used for inter-area advertisement. Option D is wrong because Type 5 AS-external LSAs are generated by ASBRs to advertise routes redistributed from outside the OSPF domain, not inter-area prefixes.
Which Junos command displays detailed information about OSPF neighbor states, including dead timer countdowns and address bindings?
The detail keyword expands each neighbour entry beyond the summary view, exposing dead timer countdowns, router IDs, interface addresses and area bindings. This satisfies the requirement for neighbour state plus timer and address information in a single command.
Why this answer
The command 'show ospf neighbor detail' displays comprehensive information about each OSPF neighbor, including neighbor state (Full, 2-Way, etc.), neighbor ID, interface address, dead timer countdown, and area. This is the go-to command for verifying adjacency health and troubleshooting OSPF neighbor issues on Junos devices.
Exam trap
The trap is confusing 'show ospf neighbor detail' with 'show ospf database detail' — candidates often pick the database command when the question asks about neighbor state and dead timers.
How to eliminate wrong answers
Option B is wrong because 'show ospf statistics' displays packet counters and protocol statistics, not per-neighbor state or dead timers. Option C is wrong because 'show route table inet.0' displays the routing table, not OSPF neighbor details. Option D is wrong because 'show ospf database detail' displays the link-state database contents (LSAs), not neighbor state or dead timer information.
You are configuring OSPF on a Juniper router. The router must not generate any OSPF packets or form adjacencies on interface ge-0/0/1, but the interface must remain in the OSPF configuration for future use. Which configuration statement accomplishes this?
Marking the OSPF interface as passive stops the router from sending Hello packets and forming adjacencies on that interface, but the network is still advertised into OSPF as a stub network. This matches the requirement exactly: no OSPF packets are generated on the interface, and the interface remains in the OSPF configuration.
Why this answer
A passive OSPF interface remains in the OSPF configuration but does not send or receive OSPF control packets, so it cannot form adjacencies. The connected network is still advertised as a stub network into the area. This is the standard Junos approach when an interface must be included in OSPF for reachability but must not participate in adjacency formation.
Exam trap
The trap here is confusing priority 0, which only prevents DR/BDR election, with passive, which suppresses all OSPF packet generation and adjacency formation on the interface.
Which command is used on a Junos device to clear the OSPF database and force a re-synchronization with neighbors?
`clear ospf database` flushes the local link-state database and triggers the device to re-request LSAs from its OSPF neighbours, forcing adjacency re-synchronisation. This directly satisfies the stem's requirement to clear the database and force re-synchronisation, unlike neighbour-specific or protocol-wide reset commands.
Why this answer
The 'clear ospf database' command clears the OSPF link-state database and forces the router to re-synchronize with its neighbors by re-exchanging LSAs. This is used to recover from database corruption or to force a refresh. It does not reset the OSPF process itself.
Exam trap
The trap is confusing commands that clear neighbors versus those that clear the database; candidates may pick 'clear ospf neighbor' thinking it resets the database, but it only drops adjacencies.
How to eliminate wrong answers
Option A is wrong because 'restart ospf-protocol' is not a valid Junos command; OSPF is restarted via 'restart routing' or 'restart ospf'. Option B is wrong because 'clear ospf neighbor' clears neighbor adjacencies but does not specifically clear the database. Option D is wrong because 'reset routing-protocol ospf' is not a valid Junos command.
Which TWO states are valid OSPF operational adjacency states seen in Junos operational outputs? (Choose two)
2-Way appears in Junos OSPF neighbour output once bidirectional communication is confirmed via hello packets, before database synchronisation. It is a genuine operational adjacency state, satisfying the stem, whereas states such as Init, Down or Attempt reflect pre-adjacency conditions rather than formed adjacencies.
Why this answer
Option A (2-Way) is correct because in OSPF, 2-Way is a valid adjacency state where bidirectional communication between two routers is confirmed; on broadcast and NBMA networks, routers remain in 2-Way with non-DR/BDR neighbors, and it appears in Junos outputs such as 'show ospf neighbor'. Option D (Full) is correct because Full is the final OSPF adjacency state, indicating that the link-state databases of the two routers are fully synchronized, and it is likewise displayed in Junos operational output. The unmarked options do not belong: Listen is an OSPF interface state (not an adjacency/neighbor state), Connected is not an OSPF state at all, and Active is not a valid OSPF neighbor state (it is associated with other protocols such as EIGRP or PIM).
What is the primary function of the OSPF Designated Router (DR) on a broadcast network segment?
On a multi-access segment the DR reduces adjacencies to a full mesh by having all other routers form adjacencies only with it and the BDR. This minimises LSA flooding traffic, satisfying the stem's requirement on broadcast segments.
Why this answer
The DR reduces network traffic and LSA flooding overhead by acting as a central focal point for exchanging routing information and generating the Network LSA (Type 2) on multi-access segments.
An OSPF area contains routers running Junos OS where external routes must be imported into the OSPF domain from a BGP core. However, the area must not accept external AS-external LSAs (Type 5) from other areas, but must allow routers within this area to originate external routes themselves. Which area type fulfills this requirement?
An NSSA blocks Type 5 AS-external LSAs from other areas while permitting its own routers to originate external routes as Type 7 LSAs, later translated to Type 5 at the ABR. This exactly matches the stem's dual constraint.
Why this answer
A Not-So-Stubby Area (NSSA) is designed to allow external routes to be imported into the OSPF domain from a non-OSPF protocol (like BGP) while preventing Type 5 AS-external LSAs from other areas. NSSAs use Type 7 LSAs for external routes originated within the area, which are translated to Type 5 at the NSSA ABR. This fulfills the requirement: the area does not accept Type 5 LSAs from other areas, but routers within can originate external routes.
Exam trap
JNCIS-ENT often tests the differences between stub, totally stubby, and NSSA areas, and candidates may incorrectly choose stub area when external route origination is required, forgetting that stub areas do not allow external LSAs to be originated.
How to eliminate wrong answers
Option A is wrong because a Backbone Area (Area 0) accepts all LSA types, including Type 5, and does not restrict external LSAs. Option B is wrong because a Totally Stubby Area blocks all external LSAs (Type 5) and also summary LSAs (Type 3), and routers within cannot originate external routes. Option C is wrong because a Standard Stub Area blocks Type 5 LSAs but also does not allow routers within to originate external routes; it only allows a default route from the ABR.
An administrator needs to configure an OSPF stub area on a Juniper router. Which THREE characteristics apply to a standard OSPF stub area? (Choose three.)
The area border router generates a default route into the stub area, letting internal routers reach external destinations without carrying external LSAs. This satisfies the stem's stub-area requirement, since Type 5 LSAs are blocked and the default route replaces them.
Why this answer
In a standard OSPF stub area, the ABR blocks Type 5 AS-external LSAs from being flooded into the area (option C), which is the defining restriction that keeps external routing information out of the stub. To still provide reachability to external destinations, the ABR injects a default route (0.0.0.0/0) into the stub area via a Type 3 summary LSA (option B), so internal routers can forward traffic toward the ABR. Because Type 5 LSAs are blocked and external connectivity depends on that default route, ASBRs cannot reside inside a stub area, and virtual links cannot transit a stub area (option D) since a virtual link requires the transit area to carry Type 5 LSAs and cannot be configured through a stub.
Option A is incorrect because Type 3 summary LSAs are still permitted in a standard stub area (only totally stubby areas block Type 3 LSAs, except the default route). Option E is incorrect because an ASBR inside the area would generate Type 5 LSAs, which are not allowed in a stub area.
Exam trap
JNCIS-ENT often tests the differences between stub, totally stubby, and NSSA areas, and candidates may incorrectly assume that Type 3 LSAs are blocked in a standard stub area.
You are troubleshooting an OSPF adjacency issue on a Junos router. The neighbor state is stuck in 'ExStart'. You have verified that the interfaces are up and IP connectivity exists. Which configuration mismatch is most likely causing this problem?
In OSPF, during the ExStart state, routers exchange Database Description (DBD) packets to negotiate the master/slave relationship and determine the initial sequence number. If the MTU sizes on the interfaces do not match, the routers cannot successfully exchange DBD packets because the MTU is included in the DBD packet and must match. This causes the adjacency to remain in ExStart. The issue is resolved by configuring matching MTU values or using the mtu-ignore option.
Why this answer
The ExStart state is part of the OSPF database exchange process. During this state, routers negotiate who will be the master and the initial DD sequence number. A common cause of getting stuck in ExStart is an MTU mismatch, because the MTU is carried in DBD packets and must match for successful negotiation.
Other mismatches like hello interval, area ID, or authentication would prevent the adjacency from reaching ExStart. In Junos, you can use the mtu-ignore option under the OSPF interface to bypass MTU checking.
During the establishment of an OSPF adjacency, two routers exchange Database Description (DBD) packets. What is the primary purpose of the DBD packet exchange in the OSPF protocol sequence?
DBD packets carry link-state advertisement headers only, not full LSAs. Neighbours compare these summaries to determine which LSAs each lacks, then request missing entries via Link State Request packets, achieving database synchronisation before the adjacency reaches Full state.
Why this answer
The DBD (Database Description) packet exchange is the second stage of OSPF adjacency formation, after Hello packets establish bidirectional communication. Its purpose is to exchange summary headers of each router's link-state database so both routers can determine which LSAs they are missing and need to request via Link-State Request packets. This synchronization ensures both neighbors have an identical view of the topology before entering the Full state.
Exam trap
JNCIS-ENT often tests the confusion between DBD, LSR, LSU, and LSAck packet roles — candidates frequently pick 'request missing LSAs' for DBD when that is actually the LSR function.
How to eliminate wrong answers
Option B is wrong because neighbor discovery on a shared segment is performed by Hello packets (multicast to 224.0.0.5), not DBDs. Option C is wrong because requesting specific missing LSAs is the job of Link-State Request (LSR) packets, which follow the DBD exchange. Option D is wrong because explicit acknowledgment of LSA receipt is handled by Link-State Acknowledgment (LSAck) packets, not DBDs.
You are configuring OSPF on a Juniper router and need to control which router becomes the Designated Router (DR) on a broadcast network. Which two statements about OSPF DR election on Junos are true? (Choose two.)
When multiple routers have the same interface priority, OSPF uses the highest Router ID as the tiebreaker to determine the DR. This is a standard part of the OSPF DR election process and is accurately described in this statement.
Why this answer
OSPF DR election on a broadcast network is determined first by the highest interface priority, and if priorities are equal, by the highest Router ID. A router with priority 0 is excluded from the election. The election is not repeated on every Hello; it occurs when the network first comes up or when the DR/BDR fail.
Exam trap
The trap here is assuming that a high Router ID can override a priority of 0, when priority 0 actually makes the router ineligible for DR or BDR regardless of Router ID.
An administrator is configuring OSPF on a Junos device and notices that two routers on a broadcast segment are stuck in the 2-Way state. What is the most likely cause of this behavior on a broadcast network?
On a broadcast multi-access segment, routers that are neither DR nor BDR remain in 2-Way with each other by design, since full adjacency is only formed with the DR and BDR. This is expected, not a fault.
Why this answer
Exam trap
JNCIS-ENT often tests whether candidates recognize that 2-Way between DROthers is normal, not a fault — many assume any non-Full state indicates a configuration mismatch like hello or authentication.
How to eliminate wrong answers
Option A is wrong because a hello interval mismatch would prevent the routers from forming any adjacency at all — they would stay in Init or Down, not 2-Way. Option C is wrong because an authentication mismatch would also prevent adjacency formation entirely, typically leaving neighbors in Down or Init with authentication failure logs. Option D is wrong because an area type mismatch (e.g., totally stubby vs. standard) would cause LSA exchange failures and prevent Full adjacency, but the symptom would be stuck in ExStart/Exchange or repeated adjacency resets, not a stable 2-Way.
When calculating OSPF path costs in a network containing high-speed links (such as 10Gbps and 40Gbps interfaces), what default reference bandwidth does Junos use, and what configuration adjustment is typically required to differentiate costs accurately?
Junos defaults to a 100 Mbps reference bandwidth, so 10Gbps and 40Gbps interfaces all calculate a cost of 1 and become indistinguishable. Raising the reference bandwidth (for example to 10G or higher) restores meaningful cost differentiation across high-speed links.
Why this answer
Junos OSPF uses a default reference bandwidth of 100 Mbps, so any interface at 100 Mbps or faster gets a cost of 1, making 1G, 10G, and 40G links indistinguishable. To differentiate high-speed links, the reference bandwidth must be increased (e.g., to 10G or higher) using the reference-bandwidth statement under protocols ospf.
Exam trap
JNCIS-ENT often tests the default OSPF reference bandwidth value (100 Mbps) and the fact that all links ≥100 Mbps get cost 1, causing candidates to assume a higher default like 1 Gbps or 10 Gbps.
How to eliminate wrong answers
Option B is wrong because the default reference bandwidth is 100 Mbps, not 100 Gbps, and decreasing it would worsen cost differentiation for high-speed links. Option C is wrong because the default is 100 Mbps, not 10 Gbps, and without adjustment all links ≥100 Mbps share cost 1. Option D is wrong because the default is 100 Mbps, not 1 Gbps, and Junos does not automatically assign fractional costs — costs are integers, and links faster than the reference bandwidth are clamped to cost 1.
In an OSPF NSSA configuration on a Junos device, which router is specifically responsible for translating Type 7 LSAs into Type 5 LSAs when propagating routes out of the NSSA into the backbone?
Within an NSSA, the ABR with the highest router ID performs Type 7 to Type 5 translation, flooding those external LSAs into the backbone. Other ABRs suppress translation to avoid duplicate Type 5 advertisements, so only one translator is elected.
Why this answer
In an OSPF NSSA, Type 7 LSAs are generated by the ASBR for external routes. The NSSA ABR is responsible for translating Type 7 LSAs into Type 5 LSAs when propagating them into the backbone area. If multiple ABRs exist, the one with the highest router ID is elected as the translator to avoid duplicate translation.
Exam trap
JNCIS-ENT often tests the specific router responsible for Type 7-to-5 translation; candidates incorrectly pick the ASBR (which originates Type 7) or the DR, missing that it is the NSSA ABR with the highest router ID.
How to eliminate wrong answers
Option A is wrong because the DR on the NSSA segment handles DR/BDR election for the broadcast network, not LSA translation. Option C is wrong because the ASBR originates Type 7 LSAs but does not translate them to Type 5; translation is an ABR function. Option D is wrong because internal NSSA routers do not perform translation; only ABRs connected to both the NSSA and the backbone can translate.
You are troubleshooting an OSPF network and notice that a router's OSPF state is stuck in 'ExStart'. What is the most common reason for this adjacency state issue?
OSPF neighbours exchange DBD packets during ExStart, and a mismatched interface MTU prevents them from agreeing on the master/slave relationship and database description sequence numbers, leaving the adjacency stuck. Matching MTU values on both interfaces resolves the negotiation.
Why this answer
OSPF adjacency stuck in ExStart is almost always caused by an MTU mismatch between the two neighbors. During ExStart, routers exchange DBD packets to elect a master/slave and agree on the initial sequence number; if the interface MTUs differ, the larger DBD packets are dropped, and the routers keep retransmitting without progressing to Exchange. This is the classic ExStart/Exchange hang.
Exam trap
JNCIS-ENT often tests the ExStart vs Exchange distinction — candidates blame authentication or area mismatches, but those fail earlier in the state machine; ExStart specifically points to MTU or DBD sequence issues.
How to eliminate wrong answers
Option A is wrong because duplicate router IDs prevent adjacency formation entirely (stuck in Init or Down) or cause instability, not a specific ExStart hang — the neighbor would not reach two-way communication. Option B is wrong because authentication mismatches cause the adjacency to fail at the Init/2-Way stage with authentication failure messages, not ExStart. Option D is wrong because an area ID mismatch prevents the Hello packets from being accepted, so the neighbor never reaches ExStart — it stays in Down or Init.
At MaxAge the LSA is considered invalid; the router floods a MaxAge copy to purge it from every link-state database in the area, then removes it locally. This satisfies the stem's condition for flushing the aged LSA.
Why this answer
How to eliminate wrong answers
Option A is wrong because SPF recalculation does not purge LSAs; it only recalculates routes based on the current LSDB. Option B is wrong because missing three hello packets results in the dead timer expiring, which tears down the adjacency, but does not directly purge LSAs. Option D is wrong because the OSPF dead timer expiring on the local interface also tears down the adjacency, but LSA purging is based on the LSA's age, not the dead timer.
You are tasked with tuning OSPF convergence times on a Juniper EX Series switch. Which configuration command hierarchy allows you to modify the OSPF Hello and Dead intervals on a specific interface?
The interface stanza under the OSPF area hierarchy targets a single interface, satisfying the requirement to tune Hello and Dead timers per interface rather than globally. Junos applies these values to that interface's OSPF adjacency, so convergence can be adjusted without affecting other links.
Why this answer
On Junos, OSPF interface timers are configured under the '[edit protocols ospf area <area-id> interface <interface-name>]' hierarchy. The 'hello-interval' and 'dead-interval' commands modify the Hello and Dead timers for that specific interface, allowing per-interface tuning for faster convergence.
Exam trap
The trap is selecting a plausible-sounding but invalid hierarchy like 'routing-options ospf' or 'interfaces ... family inet ospf' — candidates must remember OSPF timers live under 'protocols ospf area ... interface'.
How to eliminate wrong answers
Option A is wrong because 'routing-options ospf' is not a valid hierarchy for OSPF interface timers — OSPF is configured under 'protocols ospf'. Option C is wrong because OSPF timers are not configured under the interface's 'family inet' stanza; that hierarchy is for interface addressing and other protocols. Option D is wrong because 'system ospf' is not a valid configuration hierarchy for OSPF timers.
Type 4 ASBR Summary LSAs are flooded by the ABR into non-backbone areas, advertising the route to the ASBR itself. Type 1 describes intra-area routers, Type 3 describes networks, and Type 5 carries the external prefixes, so only Type 4 supplies ASBR reachability.
Why this answer
Type 4 (ASBR Summary LSA) is generated by the ABR to advertise the reachability of an ASBR to routers in other areas. Since Type 5 LSAs are flooded throughout the OSPF domain but do not contain the ASBR's router ID reachability information, routers in non-backbone areas need a Type 4 LSA to know how to reach the ASBR that originated the Type 5 LSAs.
Exam trap
The trap is confusing Type 4 and Type 5 — Type 5 carries the external prefix, but Type 4 carries the reachability to the ASBR that originated the Type 5, which is required for routers in other areas.
How to eliminate wrong answers
Option A is wrong because Type 2 (Network LSA) is generated by the DR on a multi-access network to describe the subnet and attached routers — it has nothing to do with ASBR reachability. Option B is wrong because Type 7 (NSSA External LSA) is used within an NSSA to carry external route information, not to provide reachability to the ASBR itself. Option D is wrong because Type 5 (AS-external LSA) carries the external route prefix and metric, but it does not provide the intra-domain reachability to the ASBR — that is the job of Type 4.
You are configuring OSPF route summarization on an ABR in a Junos environment. You want to summarize routes from Area 1 into Area 0. Which Junos configuration hierarchy is used to define this summary?
Correct. The area range statement under the source area is used on an ABR to summarize prefixes entering the backbone.
Why this answer
To summarize routes from Area 1 into Area 0 on an ABR in Junos, you configure the `range` statement under the OSPF area that contains the routes to be summarized. The correct hierarchy is `set protocols ospf area 0.0.0.1 range 192.168.0.0/16`, where 0.0.0.1 is Area 1. This instructs the ABR to advertise the summary route into other areas.
Exam trap
The trap is confusing inter-area summarization (`range` under area) with external summarization (`summary-prefix` under protocols ospf) or with static routes.
How to eliminate wrong answers
Option A is wrong because it configures a static discard route, not OSPF summarization. Option B is wrong because `summary-prefix` is used for external route summarization (ASBR), not inter-area summarization. Option C is wrong because export policies are used for route redistribution, not for OSPF area summarization.
Which LSA type is originated by a Designated Router (DR) on a broadcast or NBMA network to describe all the routers attached to that multi-access segment?
Type 2 Network LSAs are generated by the DR to list every router attached to the multi-access segment, identified by the DR's interface IP address. This satisfies the stem's requirement for describing all routers on a broadcast or NBMA network, unlike Type 1 Router LSAs, which each router originates individually.
Why this answer
The Type 2 Network LSA is originated by the Designated Router (DR) on a broadcast or NBMA multi-access segment and lists all routers that are fully adjacent to the DR on that segment, including the DR itself. It describes the multi-access network as a pseudo-node, allowing other routers to compute the topology without needing full-mesh adjacencies. The Network LSA's Link State ID is the DR's interface IP address on that segment.
Exam trap
The trap is confusing Type 1 and Type 2 LSAs — candidates know the DR originates something but forget that Type 1 is per-router while Type 2 is specifically the multi-access network description.
How to eliminate wrong answers
Option A is wrong because Type 3 Summary LSAs are originated by Area Border Routers (ABRs) to advertise inter-area prefixes between areas, not to describe multi-access segments. Option B is wrong because Type 4 ASBR Summary LSAs are also originated by ABRs, but they advertise the location of an Autonomous System Boundary Router (ASBR) to other areas — they have nothing to do with DR function. Option D is wrong because Type 1 Router LSAs are originated by every OSPF router to describe its own links and states; while the DR does originate a Type 1, the LSA that specifically describes the multi-access segment and its attached routers is the Type 2.
Type 5 AS-external LSAs are flooded domain-wide by the ASBR to describe destinations learned from the external BGP process, satisfying the requirement to inject external routes into the OSPF domain. They carry the forwarding address and external metric, and are the standard mechanism for redistributed routes in a single-area or backbone-connected topology.
Why this answer
When an ASBR redistributes external routes (such as those learned via BGP) into an OSPF domain, it originates a Type 5 AS-external LSA to describe each external destination. Type 5 LSAs are flooded throughout the OSPF area (except stub/NSSA areas) and carry the external metric and forwarding address. This is the standard mechanism for injecting non-OSPF routes into OSPF.
Exam trap
The trap is confusing Type 4 (which describes the ASBR's location) with Type 5 (which describes the external destinations themselves) — candidates often pick Type 4 thinking it carries the external route.
How to eliminate wrong answers
Option A is wrong because Type 7 NSSA LSAs are used only within Not-So-Stubby Areas to carry external routes that are then translated to Type 5 by the NSSA ABR — they are not the general ASBR-to-domain mechanism outside NSSA. Option B is wrong because Type 3 Summary LSAs are generated by ABRs to advertise inter-area routes between areas, not external routes. Option C is wrong because Type 4 Summary LSAs are generated by ABRs to advertise the location of an ASBR to other areas — they describe the ASBR itself, not the external destinations.
Which OSPF area is mandatory in any multi-area OSPF routing architecture?
Area 0, the backbone area, is mandatory in any multi-area OSPF architecture. All other areas must connect to it, either physically or through a virtual link, because inter-area routing information is distributed through the backbone.
Why this answer
Area 0, also known as the backbone area, is mandatory in multi-area OSPF architectures. All other areas must connect directly or via virtual links to Area 0.
You are configuring OSPF on a Juniper EX Series switch. You want to change the OSPF hello interval and dead interval on a specific interface to improve convergence. Which configuration hierarchy should you use?
This command correctly modifies the hello and dead intervals for OSPF on the specified interface. The hello-interval and dead-interval statements are valid under the interface hierarchy in OSPF. This allows per-interface tuning, which is essential for convergence. The dead interval is typically four times the hello interval, so 5 and 20 are consistent.
Why this answer
In Junos, OSPF interface parameters such as hello-interval and dead-interval are configured under the [edit protocols ospf area area-id interface interface-name] hierarchy. This allows per-interface tuning. The hello interval determines how often hello packets are sent, and the dead interval determines how long to wait before declaring a neighbor down.
Both must match on neighboring routers for an adjacency to form. The correct syntax uses hello-interval and dead-interval directly under the interface.
Exam trap
The trap here is misplacing the timer configuration under a timers sub-hierarchy or under the interface family, rather than directly under the OSPF interface.
An administrator implements OSPF on a Junos router with virtual links to span a disconnected non-backbone area across a non-backbone transit area to reach Area 0. What is a key design best practice regarding OSPF virtual links in enterprise networks?
Virtual links traverse a non-backbone transit area, creating a topology dependent on that area's stability and complicating fault isolation. Juniper documentation therefore recommends them only as temporary fixes for migration or repair, not as permanent design elements.
Why this answer
OSPF virtual links are a temporary solution to connect a disconnected area to the backbone. Best practice is to avoid them in permanent designs because they add complexity, are difficult to troubleshoot, and can introduce instability. They should only be used during transitional periods, such as when merging networks or during migration, and then replaced with proper physical or logical links.
Exam trap
JNCIS-ENT often tests the misconception that virtual links are a permanent solution or that they alter the transit area's properties. Candidates might think the transit area becomes part of the backbone, but it does not; it remains a separate area.
How to eliminate wrong answers
Option A is wrong because virtual links do not require a metric of 1; the metric is used for cost calculation but is not a design best practice. Option C is wrong because virtual links do not convert the transit area into an extension of the backbone; the transit area remains a regular area, and the virtual link simply provides a logical path for LSAs. Option D is wrong because the transit area cannot be a totally stubby area; virtual links require the transit area to have full LSDB synchronization, which is incompatible with stubby area restrictions.
Which OSPF packet type is responsible for discovering neighbors and maintaining adjacencies on a Junos device?
Hello packets (Type 1) are exchanged periodically on OSPF-enabled interfaces to discover neighbours and maintain adjacencies. They carry parameters such as hello and dead intervals, area ID and router priority, which must match before an adjacency forms.
Why this answer
OSPF Hello packets (Type 1) are responsible for neighbor discovery and maintaining adjacencies. They are sent periodically on OSPF-enabled interfaces, and they carry parameters like router ID, area ID, hello/dead intervals, and neighbor lists. If Hellos stop arriving within the dead interval, the adjacency is torn down.
Exam trap
The trap is confusing Hello (Type 1) with Database Description (Type 2) — both are involved in adjacency formation, but Hello is specifically for discovery and keepalive.
How to eliminate wrong answers
Option A is wrong because Link-State Update (Type 4) is used to flood link-state advertisements (LSAs) after adjacencies are formed, not to discover neighbors. Option C is wrong because Link-State Request (Type 3) is used to request specific LSAs from a neighbor during database synchronization. Option D is wrong because Database Description (Type 2) packets are used to exchange database summaries during adjacency formation, but they don't discover neighbors — Hellos do that first.
During OSPF database synchronization, two Junos routers exchange Database Description (DBD) packets. One router repeatedly sends DBD packets with the master/slave bit set incorrectly or encounters sequence number mismatches, causing the adjacency to loop in the Exchange state. Which OSPF packet type is immediately sent by a router to request missing link-state information once the ExStart/Exchange transition completes?
Once ExStart and Exchange complete, the router sends Link-State Request (Type 3) packets to ask neighbours for the specific LSAs missing from its database. This directly resolves the incomplete database that keeps the adjacency looping in Exchange.
Why this answer
Once the ExStart/Exchange transition completes, a router sends Link-State Request (Type 3) packets to request specific link-state advertisements (LSAs) that are missing or outdated. This occurs after the Database Description exchange, where routers identify which LSAs they need. The Link-State Request is used to request the full LSA from the neighbor.
Exam trap
JNCIS-ENT often tests OSPF packet types and their order; candidates may confuse Link-State Request with Link-State Update or Database Description, especially under adjacency issues.
How to eliminate wrong answers
Option B is wrong because Hello packets (Type 1) are used for neighbor discovery and maintenance, not for requesting LSAs. Option C is wrong because Database Description packets (Type 2) are used during the Exchange state to summarize the database, not to request specific LSAs. Option D is wrong because Link-State Update packets (Type 4) are used to send the requested LSAs, not to request them.
You are configuring OSPF on a Junos device and notice that Type 3 LSAs are not being generated or propagated into a specific area. When examining the configuration under protocols ospf, you see that the area is defined with the no-summaries parameter. Which area type has been configured?
The 'no-summaries' option configures a totally stubby area, blocking Type 3, 4, and 5 LSAs.
Why this answer
In Junos OS, the 'no-summaries' parameter under 'set protocols ospf area' defines a Stub area as a totally stubby area, which suppresses Type 3 summary LSAs from being injected into the area by the ABR.
You are troubleshooting an OSPF adjacency issue between two Juniper EX Series switches. One switch logs an error stating 'OSPF packet received with mismatched area ID'. Where in the Junos CLI should you check and correct this parameter?
The area ID is configured under the OSPF area hierarchy, so mismatches are corrected at [edit protocols ospf area <area-id>]. Both switches must share an identical area ID on the connecting interface for the adjacency to form; editing this stanza resolves the logged mismatch error directly.
Why this answer
The OSPF area ID is configured per interface under '[edit protocols ospf area <area-id> interface <interface-name>]'. If two routers have mismatched area IDs on the same link, the adjacency will not form and the 'mismatched area ID' error is logged. Correcting the area ID on the interface under the correct area hierarchy resolves the issue.
Exam trap
JNCIS-ENT often tests the exact Junos hierarchy for OSPF area assignment; candidates confuse area-level parameters (stub, nssa) with interface-level area membership, or pick router-id thinking it controls area adjacency.
How to eliminate wrong answers
Option B is wrong because '[edit system services ospf]' is not a valid Junos hierarchy for OSPF configuration; OSPF is configured under '[edit protocols ospf]'. Option C is wrong because '[edit protocols ospf area <area-id> stub]' configures the area as a stub area, which is a different parameter and does not set the area ID itself. Option D is wrong because '[edit routing-options router-id <ip-address>]' sets the router ID, not the area ID; a router ID mismatch would cause a different error (e.g., duplicate router ID).
An operator executes the 'show ospf database' command on a Junos device and notices multiple Type 2 Network LSAs. Under which specific network topology condition are Type 2 LSAs generated?
Type 2 Network LSAs are generated by the DR for multi-access networks.
Why this answer
Type 2 Network LSAs are generated by the Designated Router (DR) on multi-access broadcast segments (e.g., Ethernet) to represent the subnet and list all routers attached to that segment. The DR originates the Network LSA, which includes the DR's interface IP address and the Router IDs of all OSPF routers on the segment. This LSA is only produced when a DR is elected, which occurs on broadcast or NBMA networks where multiple routers share the same subnet.
Thus, option D correctly identifies the condition.
Exam trap
JNCIS-ENT often tests the misconception that Type 2 LSAs are generated on any OSPF link, confusing them with Type 1 Router LSAs, which are generated on all links regardless of network type.
How to eliminate wrong answers
Option A is wrong because stub areas filter external LSAs (Type 5) and do not inherently generate Type 2 LSAs; Type 2 LSAs are independent of area type and depend on network type. Option B is wrong because virtual links are used to connect areas to the backbone through a transit area and do not generate Type 2 LSAs; they use Type 4 summary LSAs and unicast OSPF packets. Option C is wrong because point-to-point links do not elect a DR and therefore do not generate Type 2 Network LSAs; instead, they use Type 1 Router LSAs to describe the link.
An administrator wants to configure an OSPF Not-So-Stubby Area (NSSA) on a Junos router. Which THREE characteristics distinguish an NSSA from a standard OSPF Stub Area? (Choose three)
An NSSA, like a stub area, does not accept Type 5 AS-external LSAs from the backbone, so external reachability is not flooded in. This matches the stem's requirement to distinguish NSSA behaviour from standard stub areas.
Why this answer
Option A is correct because, like a standard stub area, an NSSA blocks Type 5 AS-external LSAs from entering the area from the backbone, keeping the area's LSDB free of external routes. Option C is correct because the defining feature of an NSSA is that routers within it can originate external routes as Type 7 NSSA-external LSAs, which is not permitted in a standard stub area. Option D is correct because the NSSA ABR translates those Type 7 LSAs into Type 5 LSAs before flooding them into the backbone, allowing external reachability to propagate beyond the NSSA.
Option B is wrong because NSSA is an area-type attribute and has nothing to do with automatically converting internal links to broadcast point-to-multipoint networks. Option E is wrong because an NSSA can support multiple ABRs; there is no such prohibition.
Exam trap
The trap is confusing NSSA with stub areas; candidates may forget that NSSA allows Type 7 LSAs and translation to Type 5, while stub areas block all external LSAs.
You are configuring OSPF on a Junos device and need to ensure that the router prefers internal OSPF intra-area paths over inter-area paths, and inter-area paths over external paths. According to OSPF route preference rules, what is the evaluation order?
Junos OSPF route preference follows this exact hierarchy: intra-area routes are preferred first, then inter-area, then external Type 1, and finally external Type 2. This ordering satisfies the stem's requirement to prefer intra-area over inter-area, and inter-area over external paths.
Why this answer
OSPF route preference follows a strict order: intra-area (O) routes are most preferred, then inter-area (O IA), then external Type 1 (E1), and finally external Type 2 (E2). This order is based on the OSPF path selection algorithm, where routes within the same area are considered most reliable and external routes least.
Exam trap
The trap is mixing up the preference between external Type 1 and Type 2, or placing external routes above internal ones; candidates must memorize the exact order: intra-area > inter-area > E1 > E2.
How to eliminate wrong answers
Option B is wrong because it reverses intra-area and inter-area preference; intra-area is always preferred over inter-area. Option C is wrong because it places external Type 1 above intra-area, which is incorrect; external routes are always less preferred than internal OSPF routes. Option D is wrong because it reverses the entire order, placing external Type 2 first, which is the least preferred.
Ready to test yourself?
Try a timed practice session using only OSPF questions.