NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. RouterOS 7: /routing ospf instance add name=default router-id=10.0.0.1
2. /routing ospf area add name=backbone area-id=0.0.0.0 instance=default
3. /routing ospf interface-template add interfaces=ether2 area=backbone networks=192.168.88.0/24
4. GUI: Routing → OSPF → *Instances*, *Areas*, *Interface Templates* tabs, in that order.
5. Verify: /routing ospf neighbor print

Changed across versions

• 6.xConfigured with separate /routing ospf network and /routing ospf interface menus — a network statement advertises a prefix, a per-interface entry tunes behavior on it.
• 7.xBoth are replaced by a single /routing ospf interface-template: a template matches interfaces by name or network prefix and applies OSPF participation directly. RouterOS 6 OSPF config does not carry over — this is a rebuild, not an upgrade.

Gotchas & notes

• RouterOS 6 and 7 OSPF configuration are incompatible — almost every guide online is for v6. Confirm your version before following anything, including this one.
• router-id is not set automatically to anything sensible — set it explicitly or you get adjacency instability when interfaces change.
• The interface template's networks= field decides what gets advertised; adding the interface without it forms an adjacency that advertises nothing.
• Set passive on templates for user-facing interfaces so you do not send hellos onto client VLANs.

Steps

1. GUI: Network → OSPF → set *Router ID*, add an *Area* (0.0.0.0), then add *Networks* and *Interfaces*.
2. CLI: config router ospf → set router-id 10.0.0.1 → config area → edit 0.0.0.0 → next → end → config ospf-interface → edit "to-core" → set interface "port2" → set network-type broadcast → next → end → config network → edit 1 → set prefix 192.168.1.0 255.255.255.0 → set area 0.0.0.0 → next → end → end
3. Verify: get router info ospf neighbor and get router info ospf interface

Gotchas & notes

• FortiOS needs both a network statement (what to advertise) and an ospf-interface entry (how to behave on that link). Configuring only one is the standard reason an adjacency never forms or forms but advertises nothing.
• A firewall policy is not required for OSPF to the FortiGate itself, but the interface's allowaccess must not block it — OSPF is local-in traffic.
• Set router-id manually; the auto-selected value can change on reboot and reset all adjacencies.
• With VDOMs, OSPF is per-VDOM and inter-VDOM links need their own adjacencies.

Steps

1. UniFi Network does not expose OSPF for gateways in the UI.
2. Some UniFi L3 switches (Pro Aggregation / Enterprise models) support OSPF via Settings → Routing or a per-device config in recent firmware — check your specific model and version.
3. Otherwise: use static routes, or place a router that speaks OSPF alongside the UniFi gateway.

Gotchas & notes

• Treat UniFi as a static-routing platform. If a design needs dynamic routing at the edge, that is a reason to pick a different gateway rather than to fight the controller.
• Config injection via config.gateway.json (older USG) allowed OSPF but is deprecated, unsupported on UDM, and lost on migration — do not build a production design on it.
• UniFi does support BGP on some UDM/UXG models via an uploaded FRR config file, which is a separate and more current escape hatch than the old JSON method.

Steps

1. router ospf 1 → router-id 10.0.0.1 → network 192.168.1.0 0.0.0.255 area 0 → passive-interface default → no passive-interface GigabitEthernet0/1
2. Or interface-based (IOS-XE): interface Gi0/1 → ip ospf 1 area 0
3. Save: copy running-config startup-config
4. Verify: show ip ospf neighbor, show ip ospf interface brief, show ip route ospf

Gotchas & notes

• The network statement takes a wildcard mask, not a subnet mask, and it selects *interfaces to enable OSPF on* — it does not itself advertise a prefix. Misreading that is the most common OSPF error on IOS.
• Set passive-interface default then selectively un-set it. Otherwise you flood hellos onto every user VLAN, which is both noisy and a security issue.
• Adjacency stuck in EXSTART/EXCHANGE almost always means an MTU mismatch between the two interfaces; INIT means hellos are one-way (ACL or wrong subnet mask).
• Both sides must agree on area, hello/dead timers, authentication, and network type. show ip ospf interface prints all of these — diff them across the link.

Steps

1. Network → Virtual Routers → <router> → OSPF: tick *Enable*, set *Router ID*.
2. Add an Area (0.0.0.0), then inside it add the Interface with its type (broadcast/p2p) and metric.
3. Commit.
4. Verify: Network → Virtual Routers → More Runtime Stats → OSPF tabs, or CLI show routing protocol ospf neighbor.

Gotchas & notes

• OSPF is configured per virtual router; the interfaces you add must already belong to that VR.
• Requires a Commit, and OSPF commits can briefly reset adjacencies — schedule accordingly.
• The interface must be a Layer 3 interface with an IP and be assigned to a zone, but no security policy is needed for the firewall's own OSPF traffic. An interface *Management Profile* is also not required for OSPF.
• Redistribution into OSPF needs a separate Redistribution Profile under the virtual router; connected routes are not advertised just because the interface is in an area.

Steps

1. OSPF is not in the base system. Install the FRR package: System → Package Manager → Available Packages → frr.
2. Services → FRR → Global Settings → enable, set the router ID.
3. Services → FRR → OSPF → enable, add *Interfaces* with their area, and add networks under *Networks*.
4. Allow OSPF on the relevant interface's firewall rules (protocol 89 / multicast 224.0.0.5).
5. Verify: Status → FRR → OSPF neighbors.

Gotchas & notes

• You must add firewall rules for OSPF. Unlike the other platforms, pfSense filters traffic destined to itself on non-default interfaces, so protocol 89 to 224.0.0.5 and to the neighbor's address needs an explicit pass rule. This is the number one cause of an adjacency that never forms.
• The older openospfd package is abandoned — use FRR.
• FRR settings are stored in pfSense config but FRR itself has its own state; after big changes restart the service from Status → Services rather than trusting a live reload.
• Package availability tracks pfSense versions; check the package is supported before planning an upgrade around it.

Steps

1. Confirm the feature exists on this box/license first: open Network → Routing and check whether an OSPF tab is present — dynamic routing (RIP/OSPF/BGP) is model- and license-tier dependent, and it's not universal across every Gen7 TZ SKU.
2. Network → Routing → OSPF → Global Settings (naming varies slightly by firmware build) → enable OSPF, set the *Router ID*.
3. Network → Routing → OSPF → Areas → Add → *Area ID* 0.0.0.0, *Type* Normal (backbone).
4. Network → Routing → OSPF → Interfaces → Add (or via the OSPF settings tied to the interface itself) → select the interface (e.g. X0), assign it to Area 0.0.0.0, set Hello/Dead intervals, priority, cost, and authentication if needed, then enable.
5. Verify: Network → Routing → OSPF → Neighbors — adjacency should reach Full; also check Network → Routing → Route Table for OSPF-origin routes appearing from the neighbor.

Gotchas & notes

• SonicOS follows the FortiGate/PAN-OS/RouterOS-7 philosophy: you attach an interface to an area directly. There is no Cisco/MikroTik-v6-style network <prefix> area 0 wildcard statement to advertise a connected subnet — if the interface isn't explicitly bound to the area, nothing on it gets advertised.
• OSPF configuration is 100% GUI. This is one of the platform's clearest illustrations of the CLI/GUI gap SonicWall itself acknowledges — the E-CLI has no OSPF configuration surface at all, not even a read-only 'show ospf neighbor' — you have to be in the web GUI to see adjacency state.
• Redistributing static/connected routes into OSPF is a separate GUI step (a Route Advertisement / redistribution page), not part of the Areas/Interfaces flow — don't assume enabling OSPF on an interface also announces your static routes.
• Because dynamic routing is gated by model/license, don't assume a TZ box configured identically to an NSa box will show the same OSPF/BGP tabs — check availability before troubleshooting a 'missing' menu as if it were a bug.

Steps

1. Insight-managed routers & Orbi Pro APs: Not supported. These devices have zero dynamic-routing capability — Insight's app/portal exposes only static routes and basic NAT/firewall settings; there is no CLI on these SKUs to fall back to.
2. Smart Switches (Lite CLI): Not supported. Even the L3-capable Smart Switch models top out at static routing (and on some, RIP); the Lite CLI is monitoring/VLAN-config only and has no routing-protocol commands.
3. M4200/M4300 (fully-managed) GUI: Routing → OSPF → Configuration → set OSPF Admin Mode to Enable → Routing → OSPF → Interface Configuration → select the routing VLAN/interface → set Area ID to 0.0.0.0 and enable OSPF on it.
4. M4200/M4300 CLI: enable → configure → ip routing → router ospf → network 10.10.0.0 0.0.255.255 area 0.0.0.0 (Cisco-style network + inverse mask statement) → exit → optionally also tag the VLAN interface directly: interface vlan 10 → ip ospf areaid 0.0.0.0 → exit.

Gotchas & notes

• This task is the clearest illustration of why 'NETGEAR' isn't one platform: OSPF exists on exactly one product line (M4200/M4300) out of the whole Insight family — routers and Orbi Pro APs can't do dynamic routing at all, by design, since they're meant to be zero-touch cloud devices.
• The M4300's CLI feels close to Cisco IOS but is a FASTPATH-derived command set, not real IOS — network-statement syntax with an inverse (wildcard) mask works, but show output, area/interface interaction, and defaults diverge enough that pasted Cisco config will often fail to parse.
• Confirm the specific M4300/M4200 SKU and software image actually includes the L3/routing feature set before planning around this — some M4300 units ship or can be run in L2-only mode, in which case router ospf won't even be a valid config context.
• ip routing has to be explicitly enabled globally before router ospf does anything — coming from a platform where L3 switches route by default, it's easy to configure OSPF fully and see no adjacency form because routing itself was never turned on.