A county elections office runs OSPF for courts inside a VRF while city-hall networks remain in the global table on the same chassis. How should OSPF be applied for the courts VRF?
Select an answer to reveal the explanation.
Short Explanation
Courts OSPF has to live inside the courts VRF ‘room’—same chassis, different routing brain—so hellos and LSAs do not mingle with city hall’s global table.
Full Explanation
OSPF for the county elections courts VRF must run in the VRF context—VRF-aware process (router ospf <id> vrf <name>) or the platform’s VRF address-family mode—so adjacencies, LSAs, and the courts RIB stay inside that table while city-hall networks remain global on the same chassis.
Running a single OSPF process only in global and mapping courts interfaces with secondary IPs does not place courts routing in the VRF table and risks mixing domains. BGP confederations do not make OSPF unnecessary inside the VRF for an IGP-based courts design; confederation is an IBGP scaling tool, not a substitute for VRF-aware OSPF. PBR moving OSPF hellos from global into the courts VRF after adjacency forms is not how VRF OSPF is built—interfaces and the process must belong to the VRF from the start.
Exam caveat: interface ip vrf forwarding must be set before OSPF network/ip ospf area statements will operate in that VRF. Router-IDs and process IDs can overlap across VRFs but clarity helps operations.
Operational check: show ip ospf neighbor vrf <courts>, show ip route vrf <courts>, and ensure global show ip ospf neighbor does not unexpectedly list courts adjacencies. Fail a courts link and confirm SPF remains isolated from city-hall global OSPF.