BGP Config-as-Code: Ship Peering Changes Through a Pipeline, Not a Terminal

The riskiest line in any network is the one an engineer typed live into a router at 2am. BGP changes are especially unforgiving — one wrong neighbor statement and you blackhole a region. Config-as-code moves that change off the terminal and into a pipeline where it can be reviewed, tested, and rolled back.

The intent file

Instead of CLI, you describe the peering you want in a declarative file committed to git. A reviewer sees the diff in a pull request, not a screen-share of someone pasting config.

# intent/bgp/edge1.yml
device: edge1
asn: 65010
neighbors:
  - peer: 203.0.113.1
    remote_as: 64500
    description: "Transit-A"
    prefix_limit: 200000
    policies:
      import: TRANSIT-IN
      export: CUSTOMER-OUT

The pipeline stages

In Pipeline Studio you drag the stages that turn that file into a safe change. A typical BGP pipeline looks like this:

• YAML Lint + Schema Validate — catch typos and structural errors before anything runs.
• Batfish Analyze — model the change offline and confirm it doesn't break reachability.
• Dry Run — render the device config in --check mode so you see exactly what would change.
• Manual Approval — a human gate for production peering changes.
• Script Runner / NETCONF Push — apply the change to the candidate datastore, then commit.
• Connectivity Test + Post-Validate — confirm the session reached ESTABLISHED and prefixes are flowing.

Verify, don't assume

A deploy that "succeeds" but leaves a peer in IDLE is a failure you haven't noticed yet. The Connectivity Test and Post-Validate stages assert the session state and prefix counts after the push, so the pipeline only goes green when the change actually worked.