Configuring BGP in NetBase: From UI to running-config

If you’ve ever wrestled with router bgp … blocks in a terminal window, you know the feeling: one typo, a forgotten neighbor … activate, and suddenly half your prefixes are gone. NetBase flips the script — you describe your BGP design visually, watch the Cisco IOS config materialise line by line, and only then hand it to the device. This tutorial walks through a full BGP setup inside NetBase, explains what each field maps to in show running-config, and covers the deploy flow that keeps a live network safe.

• A NetBase project with a router device tab (a fresh “Router 1” is fine).
• The AS number you plan to use plus the peer AS / peer IP from whoever you’re peering with (an upstream ISP, another AS in your org, a lab partner…).
• Optional: a NetBase connector assigned to the router if you want to push the config live at the end. Adding one is a 3-step wizard on the Connectors page.

Jump to /components/router in NetBase — or just hit ⌘K and type “router”. Along the section strip at the top of the device editor you’ll find BGP sitting between EIGRP and Multicast. Click it.

If this is the first time you’re touching BGP on this device, the tab is empty and shows Add BGP process. One click creates a card and puts you on the first required field.

A BGP process in NetBase lives on a single card with these fields:

• AS — your autonomous system number. This is the only field marked required when the card is first added.
• Router ID — a 32-bit value used to uniquely identify the speaker inside the AS. Use a loopback address here if you have one; otherwise NetBase falls back to the highest IP at runtime.
• Authentication key — optional MD5 key applied to all peers. Enabled automatically on every neighbour you add afterwards.
• Classic / Modern — Classic stays on the legacy BGP syntax (great for Packet Tracer and pre-15.x IOS). Modern unlocks IPv6 advertisements and per-address-family knobs.
• Advertise default route — flips neighbor … default-originate on every peer.

Nothing here surprises anyone who’s configured BGP before, but the difference is that NetBase validates it as you type. Leave AS blank and the card turns red. Type a non-numeric router ID and the field flags it immediately. You find your mistakes before IOS does.

Scroll down and NetBase gives you four buttons:

• Add IPv4 peer — adds a neighbour card (IP, remote AS, next-hop-self, route-map filters).
• Add IPv6 peer — same, for neighbor … activate inside address-family ipv6. Only enabled in Modern mode.
• Add IPv4 / IPv6 network advertisement — each one becomes a network X.X.X.X mask … line.
• Add redistribution — pick an existing OSPF / EIGRP / connected / static source and optionally a route-map and metric.

Crucially, the dropdowns for route-maps, prefix-lists, and redistribution sources are pre-populated from the current project’s data — no typos, no silent references to a route-map that doesn’t exist.

Click Show config on the BGP card and NetBase pops a modal with the exact Cisco IOS syntax your inputs rendered into. You’ll see something like:

router bgp 65010
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 network 10.10.0.0 mask 255.255.0.0
 neighbor 192.0.2.254 remote-as 65001
 neighbor 192.0.2.254 description UPSTREAM-ISP
 neighbor 192.0.2.254 password cisco
 neighbor 192.0.2.254 route-map SET-LOCAL-PREF in

This is the same renderer that runs when you deploy — the modal is just a dry-run view. Changes to any field on the card update this preview in real time, and the Copy config button lets you paste it into a change ticket or a peer review.

When you’re ready to push the config to a live device, click Deploy in the top-right corner of the editor. NetBase opens the Deploy Review modal with two tabs:

• Changes — a field-level, human-readable diff against the device’s last NetBase deploy (added neighbour, changed MD5 key, etc.).
• Config — a side-by-side code diff against the device’s actual live running-config, which NetBase’s connector has already pulled in the background.

Everything NetBase deploys runs in merge mode: we only add the lines the device is missing. Existing config outside of your BGP edits stays untouched — there’s no no router bgp nuclear option in this path. If you ever need to remove a neighbour, it shows up in the diff as a targeted no neighbor … rather than a wholesale rebuild.

Click Deploy in the modal and a job is queued on the connector. The activity feed on the Dashboard updates in real time, and the device-history tab archives the running-config that was in place before the push so you can restore it with one click if something goes sideways.

• Start from paste. If the device already has a BGP config you want to bring into NetBase, paste show running-config | section bgp into the Import from running-config dialog (⌘K → Import from running-config…). NetBase parses it, shows you a three-way preview, and you opt-in per section.
• Use project sharing for peering changes. Invite the peer’s on-call to your project before you press deploy — they see every field change in real time via live presence, and the activity feed is a free audit log.
• Name your route-maps first. Add the route-maps / prefix-lists from the Policy tab before you wire them up in BGP; NetBase dropdowns only show names that actually exist.

BGP doesn’t stop being BGP just because there’s a GUI on top of it — the protocol still demands the same care around peering and policy. But a visual editor that types the IOS syntax for you, diffs against live running-config before every push, and records every change takes a lot of the anxiety out.

Ready to try it? Open console.netbaseapp.com and add a router to your project — the BGP tab is one click away.