Configuring OSPF in NetBase: Design the Fabric, Push with Confidence

OSPF is one of those protocols where the hard part isn’t the CLI — it’s making sure the right interfaces are in the right areas with the right timers and the right authentication. In a terminal you find out about a mistake when an adjacency refuses to come up. In NetBase you find out while you’re still filling in the fields, because the editor validates the design before it ever renders an router ospf … line.

This guide walks through a full OSPFv2 setup in NetBase, calls out where OSPFv3 diverges, and shows how the deploy review modal keeps a live network safe.

• A NetBase project with a router device tab.
• The OSPF process ID, area plan, and the interfaces you want to advertise.
• Optional but recommended: a NetBase connector assigned to the device so you can push the generated config at the end. The connector onboarding guide walks you through the built-in wizard.

Inside /components/router, click OSPF in the section strip. NetBase exposes two buttons:

• Add OSPFv2 process — classic, area-based OSPF.
• Add OSPFv3 process — the IPv6-ready variant (runs as its own address-family on IOS-XE). NetBase warns you about older-IOS support before it adds the card.

Pick OSPFv2 for now. A card appears with every OSPF knob on a single scrollable panel.

The Basic fields in an OSPF card:

• Process ID — required. 1–65535.
• Router ID override — optional. Use a loopback IP for a stable router ID even when interfaces flap.
• Area — required. NetBase accepts both numeric (0, 10) and dotted-quad (0.0.0.0) notation.
• Hello / Dead interval — optional timers. Leave blank to inherit the media defaults (10 / 40 on Ethernet, 30 / 120 on non-broadcast).
• Reference bandwidth — scales the OSPF cost so high-speed links don’t all end up at cost 1. The field is labelled “Reference bandwidth (bits)” so follow the hint in the input when you fill it in.
• Priority — DR / BDR election weight for broadcast segments.

OSPF lives or dies on the interface list. NetBase splits this into three multi-selects so there’s no ambiguity about which interfaces do what:

• Enabled interfaces — every interface OSPF runs on.
• Passive interfaces — still advertised (so the connected network shows up in the topology), but won’t send Hello packets. Use this on access-side interfaces that shouldn’t form adjacencies.
• Point-to-point interfaces — switches the network type to point-to-point, which skips DR/BDR election and speeds up adjacency on links that are genuinely between two routers.

All three dropdowns list every port that’s configured in the Interfaces tab of this device — so you never end up with a typo pointing at an interface that doesn’t exist.

Below them are three toggles that cover the most common corner cases:

• Advertise default route — flips default-information originate on.
• Redistribute static — adds redistribute static.
• Redistribute connected — adds redistribute connected.

The classic network … area … statements go under Add Network advertisement. Each one is a simple IP + wildcard pair — NetBase normalises whichever form you type and lets you re-use it in other protocols’ redistribution dropdowns.

Add redistribution creates a card where you pick:

• Route — source protocol (EIGRP, BGP, static, connected). The dropdown is filtered to protocols that are actually configured on this device, so you can’t accidentally redistribute a protocol that isn’t running.
• Route-map — only names that exist in the Policy tab show up.
• Metric — either leave “default” ticked or type bandwidth / delay / reliability / load / MTU explicitly.

Click Show config on the OSPF card. NetBase renders exactly what will be pushed:

router ospf 10
 router-id 10.0.0.1
 network 10.10.0.0 0.0.0.255 area 0
 network 192.0.2.0 0.0.0.3 area 10
 passive-interface default
 no passive-interface GigabitEthernet0/0
 redistribute static subnets
 redistribute connected subnets
!
interface GigabitEthernet0/0
 ip ospf priority 50
 ip ospf hello-interval 5
 ip ospf dead-interval 20

The Copy config button dumps it to the clipboard so you can paste into a change ticket or a code review. Every field update re-renders the preview live — there’s no “save” button on this panel.

If you added an OSPFv3 card instead, the fields are mostly the same but with one extra:

• Enabled IPv4 interfaces vs Enabled IPv6 interfaces — NetBase renders ipv6 ospf <pid> area … on the v6 list and the classic ip ospf <pid> area … on the v4 list so a dual-stacked process works correctly.
• Authkey — SHA-1 authentication key (IPsec-style).

The generated config wraps everything inside router ospfv3 <pid> with address-family ipv4 unicast / address-family ipv6 unicast blocks.

Click Deploy in the top-right of the editor. NetBase opens the review modal with two tabs:

• Changes — a human-readable, field-level diff against the last NetBase deploy. Great for PR reviews.
• Config — a side-by-side code diff against the device’s actual running-config, pulled by the connector in the background.

Every deploy runs in merge mode: NetBase only adds the lines the device is missing. If the device already had an router ospf 10 block from a previous manual change, it’s untouched unless your diff explicitly says otherwise. No surprises.

Click Deploy in the modal and a job queues on the connector. The Deployments panel streams back the logs in real time and archives the pre-deploy running-config on the device’s history page so you can rollback in one click.

After a successful deploy, run the usual checks on the device:

show ip ospf neighbor
show ip ospf interface brief
show ip route ospf

You should see your neighbours in FULL and every network you advertised in the route table. If not, the most common culprits are a timer / area mismatch (NetBase’s Show-config button is the fastest way to diff both sides) or a forgotten passive-interface default.

• Import running-config first. If the device already has an OSPF block you want to manage in NetBase, paste show running-config | section ospf into the Import from running-config dialog. Every field lands in the right NetBase control.
• Use presence for area design reviews. Invite a teammate to your project before you press deploy — presence chips show which field each person is editing, and the activity feed logs who changed what.
• Keep process IDs consistent across devices. OSPF process IDs are locally significant, but keeping them consistent makes dashboards and troubleshooting easier. The Dashboard’s Recent activity feed now includes the hostname + section summary so you can spot drift quickly.

OSPF is still OSPF — the protocol rules haven’t changed. What’s different is that the fields on the card, the generated IOS, and the eventual deploy all stay in lockstep, with a diff against the live device right before you press the button.