What are two benefits of configuring OSPF database protection? (Choose two.)
A.
Protects the LSDB from being flooded by excessive LSA flooding.
B.
Provides intra-area route filtering and route summarization.
C.
Allows the device to participate in OSPF routing but not be used for transit traffic.
D.
Limits the number of LSAs in the LSDB (excluding those generated by the local router).
http://www.juniper.net/documentation/en_US/junos12.3/topics/topic-map/ospf-database-protection.html
OSPF Database Protection Overview
OSPF database protection allows you to limit the number of link-state advertisements (LSAs) not generated by the local router in a given OSPF routing instance, helping to protect the link-state database from being flooded with excessive LSAs. This feature is particularly useful if VPN routing and forwarding is configured on your provider edge and customer edge routers using OSPF as the routing protocol. An overrun link-state database on the customer edge router can exhaust resources on the provider edge router and impact the rest of the service provider network.
When you enable OSPF database protection, the maximum number of LSAs you specify includes all LSAs whose advertising router ID is not equal to the local router ID (nonself-generated LSAs). These might include external LSAs as well as LSAs with any scope such as the link, area, and autonomous system (AS).
Once the specified maximum LSA count is exceeded, the database typically enters into the ignore state. In this state, all neighbors are brought down, and nonself-generated LSAs are destroyed. In addition, the database sends out hellos but ignores all received packets. As a result, the database does not form any full neighbors, and therefore does not learn about new LSAs. However, if you have configured the warning-only option, only a warning is issued and the database does not enter the ignore state but continues to operate as before.
You can also configure one or more of the following options:
A warning threshold for issuing a warning message before the LSA limit is reached.
An ignore state time during which the database must remain in the ignore state and after which normal operations can be resumed.
An ignore state count that limits the number of times the database can enter the ignore state, after which it must enter the isolate state. The isolate state is very similar to the ignore state, but has one important difference: once the database enters the isolate state, it must remain there until you issue a command to clear database protection before it can return to normal operations.
A reset time during which the database must stay out of the ignore or isolate state before it is returned to a normal operating state.