A public works yard needs municipal LAN and WAN prefixes advertised into OSPFv2 so other single-area routers learn those routes. What action achieves that goal?
Select an answer to reveal the explanation.
Short Explanation
Want other public-works routers to learn the yard’s LANs? Put those networks into the one OSPF area so OSPF can advertise them. LLDP and MAC flooding will not magically publish IP prefixes for you.
Full Explanation
A public-works yard that needs LAN and WAN prefixes learned by other single-area OSPFv2 routers must include those municipal networks in the OSPF process for that area—via network statements or interface OSPF enablement—so the router originates LSAs advertising reachability. Peers in the same area install those routes from the shared LSDB. That inclusion step is what turns connected municipal subnets into OSPF-advertised prefixes.
Configuring only LLDP medians so Layer-2 neighbors inject IP prefixes automatically fails by concept: LLDP discovers devices; it does not advertise IP prefixes into OSPF. Disabling IP routing and relying on MAC flooding to carry subnet reachability fails by concept: without IP routing, inter-subnet forwarding and OSPF collapse to a broken model. Creating local VLANs without assigning any interfaces to the OSPF process fails by concept: VLANs alone do not place networks into OSPF.
Exam caveat: interfaces must be up/up and in the correct area; passive-interface choices affect adjacency but included networks still need correct OSPF participation. Operational check: add the yard’s LAN/WAN networks to the single area, confirm LSAs in show ip ospf database, and verify other public-works routers install the prefixes with show ip route ospf.