Refer to the exhibit. An attacker can advertise OSPF fake routes from 172.16.20.0 network to the OSPF domain and black hole traffic. Which action must be taken to avoid this attack and still be able t

Question

Exhibits

Options

• AConfigure 172.16.20.0 as a stub network.
• BApply a policy to filter OSPF packets on R2.
• CConfigure a passive Interface on R2 toward 172.16.20.0.
• DConfigure graceful restart on the 172.16.20.0 interface.

• A
  4% (1)
• B
  8% (2)
• C
  83% (20)
• D
  4% (1)

Explanation

OSPF Passive Interface Explanation

Configuring a passive interface on R2 toward 172.16.20.0 stops OSPF hello packets from being sent out that interface, which prevents any device on that network from forming an OSPF neighbor relationship and injecting fraudulent routing updates - while still allowing R2 to advertise the subnet into the OSPF domain. This is the ideal balance between security and functionality.

Why the distractors are wrong:

• A (Stub network): A stub area restricts LSA types domain-wide and doesn't specifically prevent a rogue device from participating in OSPF on that segment.
• B (Filter OSPF packets on R2): Filtering OSPF packets could break legitimate OSPF operation and doesn't elegantly solve the problem of rogue neighbor formation.
• D (Graceful restart): Graceful restart is a high-availability feature that maintains forwarding during a restart - it has no security function against fake route injection.

Memory Tip : Think of a passive interface as a "listen-only" door - R2 knows the subnet exists and tells the rest of OSPF about it, but no one on that segment can "knock back" with hello packets to form a neighbor relationship and inject bad routes.

No community discussion yet for this question.