A transit authority runs OSPF inside a courts VRF-Lite instance while a separate global OSPF process serves parks networks on the same edge router. What operational reality should the team verify?

A transit authority running OSPF for courts inside a VRF-Lite instance while a separate global OSPF process serves parks on the same edge router must verify routing-context isolation. Each VRF maintains its own OSPF routing context—typically a dedicated process or address-family instance—so adjacencies, LSDBs, and RIBs for courts do not share routes with parks (or global) unless route leaking is explicitly configured. VRF-Lite’s purpose on shared hardware is precisely that separation of Layer-3 tables and control-plane instances, which is why the correct operational reality is per-VRF OSPF context without automatic route sharing. One OSPF adjacency in the global table automatically neighboring every VRF interface fails because VRF interfaces are not in the global routing context; global OSPF does not auto-extend into VRF instances. VRF-Lite collapsing all OSPF router IDs into a single shared LSDB across VRFs by default contradicts VRF isolation; LSDBs remain per context. Claiming courts VRF OSPF can only run OSPFv3 and never OSPFv2 is false—address family and process design determine v2 versus v3, and VRF-Lite does not mandate IPv6-only OSPF for courts. Exam caveat: unique RIDs are still best practice per process/context; leaking is intentional and must be policy-controlled to avoid courts/parks prefix bleed. Operational check: confirm separate OSPF process or VRF-aware configuration; show ip ospf and show ip route vrf <courts> versus global/parks tables; ensure no unintended redistribute/leak statements; verify neighbor formation only on interfaces in the intended VRF.