OSPF Integration and Image Support

Capability and management gate

The pinned SONiC FRR supervisor template includes ospfd conditionally when frr_mgmt_framework_config is true; it does not show universal activation. A template entry or an FRR feature list is not proof that an installed image enables OSPF, exposes an approved configuration API, persists it, or integrates it correctly with hardware.

show version
sonic-db-cli CONFIG_DB HGET "DEVICE_METADATA|localhost" frr_mgmt_framework_config
docker ps --format "{{.Names}}"
docker exec bgp supervisorctl status

Read-only examples need appropriate privileges and the actual container name. If support is absent or unverified, stop device mutation here and use an approved OSPF-capable image/lab. Do not flip metadata or start daemons to bypass that gate.

Configuration contract for a supported lab

In a separately provisioned supported image, S1/R1 use the drawn /30, unique router IDs192.0.2.1 and203.0.113.1, matching area0/authentication/timers/MTU, and active transit interfaces. Their LANs are advertised with passive interfaces; endpoint default gateways and return reachability are prepared. Ports are routed and not VLAN/LAG members.

The routing manager must apply the equivalent intent below. This is an FRR semantic fragment for discussion, not community config commands or an instruction to overwrite generated files:

! S1 equivalent intent, supported manager must own/persist it
router ospf
 ospf router-id 192.0.2.1
 network 198.51.100.0/30 area 0
 network 192.0.2.0/24 area 0
 passive-interface Ethernet0

R1 uses router-ID203.0.113.1, the same transit area, advertises203.0.113.0/24, and makes Ethernet4 passive. Exact API and daemon version remain image-specific.

Inspect adjacency through delivery

# Only after support and actual container name are confirmed
docker exec bgp vtysh -c "show ip ospf neighbor"
docker exec bgp vtysh -c "show ip ospf interface"
docker exec bgp vtysh -c "show ip ospf route"
show ip route 203.0.113.10
show arp

Peer router-ID203.0.113.1: Full (illustrative)
O>* 203.0.113.0/24 via198.51.100.2, Ethernet4

Illustrative shortened output, not a device observation.

OSPF adjacency state, its computed routes, zebra’s selected route, and programmed delivery are distinct. Full does not establish the requested prefix. A two-way state on a multi-access segment can be normal for some neighbor roles; diagnose the actual network type rather than treating every 2-Way as failure.

Supported-lab link fault and restoration

# S1 only, isolated lab transit link initially up
sudo config interface shutdown Ethernet4
show interfaces status Ethernet4
# Restore
sudo config interface startup Ethernet4

Observe adjacency and route behavior through actual timers and interface events, then repeat endpoint traffic. Retain the original supported-manager configuration; cleanup restores the initially-up link. Do not infer a universal convergence time, save the fault, or add direct FRR changes behind the manager.

Check your understanding

Six questions, four options each. Check each answer for an explanation, review your score, and retry.