Why Is R1 Not Forming OSPF Adjacency with a Mismatched NSSA Option Bit?

Troubleshoot OSPF (v2/v3)
Answer Correct answer: B — configure the same OSPF area type on both routers so the NSSA option bit in the hello packets matches and the adjacency forms.

Refer to the exhibit. R1 is not forming adjacency on a point-to-point interface. Which action resolves the issue? - image

  1. The area numbers must be configured the same on each router.
  2. The area types must be configured the same on each router. Correct Answer
  3. The no-summary command must be included in the area configuration on R2.
  4. The no-summary command must be included in the area configuration on R1.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

It tests whether you can read the OSPF hello-level error (NSSA/stub option bit mismatch) and map it to an area-type mismatch rather than to an area-ID or LSA-filtering problem.

R1 fails to form an OSPF adjacency on a point-to-point link because the routers disagree on the area type, producing a mismatched NSSA/stub option bit in the hello packet. This page confirms that making the area types identical on both routers is the fix and explains why area numbers and no-summary are not the issue.

Most candidates pick A and try to align the area numbers, because 'area mismatch' is the classic adjacency breaker — but the exhibited error is the NSSA/stub option bit in the hello, which only an area TYPE mismatch causes.

Community Discussion (3 comments)

[Removed] 👍 2 Selected: B
B is corerct keyword is mismatched nssa
dapardo 👍 3
everytime you receive something like "mismatched nssa option bit" means its a mismatch on the area type: https://supportportal.juniper.net/s/article/ScreenOS-OSPF-is-not-coming-up-and-an-error-regarding-stub-nssa-option-bit-mismatch-is-generated-in-debugs?language=en_US. To resolve this issue, change the area type on any of the sites to match the peer site.
Bombbear_W 👍 2 Selected: B
https://community.cisco.com/t5/networking-knowledge-base/receiving-the-ospf-hello-from-x-x-x-x-with-mismatched-nssa/ta-p/3131668

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

The exhibit shows R1 receiving an OSPF hello whose NSSA (or stub) option bit does not match its own, so the packet is discarded and no adjacency forms on the point-to-point interface. The option bits in the OSPF hello — E-bit for stub, N-bit for NSSA — are derived purely from the area type configured on each router's interface. When R1's interface sits in an NSSA and R2's sits in a normal or stub area, the bits disagree and both routers log a mismatched option-bit condition. Making the area type identical on R1 and R2 (option B) aligns those bits, so hellos are accepted, the neighbor state progresses to FULL, and LSDB exchange proceeds normally. This is why B is the resolution the question is looking for.

Why the Other Options Are Wrong

Option A addresses the area ID, and although mismatched area IDs also stop adjacency, that failure produces an 'area mismatch'/'different area ID' rejection rather than an NSSA option-bit error, so it does not match the symptom shown. Options C and D involve the no-summary keyword, which is used on an ABR for totally stubby or totally NSSA areas to suppress type-3 LSAs — a flooding/LSA-scope mechanism that only takes effect after adjacency is already up, so it cannot fix a hello-level rejection on R1. In short, only changing the area type on both routers touches the mechanism that is actually broken here.

Community Comment Notes

As dapardo explained, any time you see a mismatched NSSA option bit the cause is an area-type disagreement, and the fix is to change the area type at one site to match its peer. The removed comment reinforces the same keyword logic, stating that the "keyword is mismatched nssa" and selecting B. Bombbear_W pointed to a Cisco knowledge base article about receiving the OSPF hello "with mismatched NSSA", which documents exactly this hello-option rejection. All three entries converge on option B.

Official Reference

Exam Strategy

When a stem says 'not forming adjacency' and an exhibit is present, read the logged error text before looking at the options: option-bit/N-bit/E-bit mismatches map to area type, while 'different area ID' maps to area number. Then pick the option that changes the setting on the routers shown in the exhibit, not one that only filters LSAs.

Frequently Asked Questions

How does a mismatched NSSA option bit stop the OSPF adjacency on R1?

The option bits in the OSPF hello are set by the area type, so if R1's interface is in an NSSA and R2's is not, the bits differ and R1 drops the hello, keeping the neighbor from reaching FULL.

Why is matching the area number (option A) not the fix here?

A different area ID produces its own 'area mismatch' rejection in the hello, not an NSSA option-bit error, so aligning area numbers would not clear the symptom shown in the exhibit.

More 300-410 FAQ →

Related Analysis

Practice All 300-410 Questions

Access 159 questions with complete answers and detailed explanations.

View Full 300-410 Practice Test →

← Back to 300-410 Study Guide