BGP Integration and Operations

Follow an existing BGP neighbor from configuration intent through selected routes to packet evidence.

Lesson 14 of 18Prerequisite: core lessons 01–09 or equivalent operator knowledge

By the end, you should be able to:

Inspect a prepared CONFIG_DB-managed neighbor.
Separate session state, prefix acceptance, selection, and programming.
Perform a targeted administrative session fault and inverse.

Scope: community SONiC 202505 source baseline; single ASIC/default namespace unless stated. Commands, outputs, faults, and recovery are illustrative only. Confirm image, management mode, and platform support before a separate lab. No device commands, builds, containers, or packet tests were executed for this course.

One peer, several evidence boundaries

Original lab map. A192.0.2.10/24 uses S1 E0 .1; B203.0.113.10/24 uses peer E4 .1. The peer returns192.0.2.0/24 through S1.

Prepared neighbor and management baseline

Assume an isolated, already working CONFIG_DB-integrated BGP lab. S1 and peer have the shown ASNs and routed /30 link, administrative-up ports, correct policies, and explicit endpoint return reachability. The neighbor is initially administratively up and established. No unrelated sessions are changed.

This lesson starts after provisioning through the image’s approved configuration method. Expected intent includes S1 local ASN65001 and neighbor198.51.100.2 with remote ASN65002/local_addr198.51.100.1. Authentication, AF activation, and policies must match the lab. Do not treat a partial JSON excerpt as a full restorable configuration.

Inspect intent and the running routing view

sonic-db-cli CONFIG_DB HGETALL "BGP_NEIGHBOR|198.51.100.2"
show runningconfiguration bgp
show bgp summary
show bgp neighbors 198.51.100.2
show ip route 203.0.113.10

The modern community wrapper is show bgp summary; historical documentation also includes older Quagga command forms. Use local help. Direct FRR changes may conflict with the configuration manager and have different persistence rules.

Neighbor 198.51.100.2  AS65002  State/PfxRcd: 1
B>* 203.0.113.0/24 [20/0] via 198.51.100.2, Ethernet4

Illustrative shortened output, not a device observation.

An established session is only the first boundary

Check peer transport and capabilities, then whether the prefix was accepted by policy, selected among candidates, exported through the image’s forwarding integration, and programmed with a usable adjacency. bgpd handles BGP; zebra coordinates routing; fpmsyncd handles FPM integration on the common route path. BGP itself does not forward each transit packet.

A received prefix count does not prove this particular prefix was selected. A selected route still needs programming and packet evidence. Check a bounded A-to-B exchange and the peer’s return path. No AS-path theory or OSPF comparison is duplicated here.

Shut down only the prepared neighbor

sudo config bgp shutdown neighbor 198.51.100.2
show bgp summary
show ip route 203.0.113.10
# Exact inverse for the initially-up neighbor
sudo config bgp startup neighbor 198.51.100.2

The checked CLI changes the selected neighbor’s administrative intent in CONFIG_DB. Avoid all. After convergence the session can display an administrative idle condition; route retention/withdrawal depends on graceful-restart and other route sources. Record timers and actual route lookup rather than inventing immediate failure.

After restoration verify establishment, the intended prefix, next-hop programming, and traffic. Cleanup is restoring this neighbor’s original up state; the prepared topology remains. Do not persist the fault or overwrite unrelated startup state.

Key takeaways

Use the image’s management model for neighbor intent.
Session up, prefix accepted, route selected, and packets delivered are different checks.
Target one neighbor, not every session.
Timers and alternate routes affect withdrawal and recovery observations.

Check your understanding

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

Sources & scope

Reviewed 18 October 2026. Community release-source pins: utilities 7511bf2f8ea3582c2b67cf5016f8e8237e62882b; buildimage ff3c0c9f686a1d0dbddbe813b233b3b7a51bd8e2. FRR 10.2 and RFC references explain semantics; they do not identify an installed image’s exact daemon version. Windows reference code is separately pinned: SWSS b8a9b65494c234ac33b6cf0a2b7f13fb291cee7f, buildimage 128f6802b6e1, utilities cc4fbb3e8313, SAI Redis dd925f4cf6fa. These are source-inspection baselines, not deployed-binary or hardware validation.

Exact inspected files and actual website checks are recorded in SOURCE-REVIEW.txt. No vendor CLI extension, production support level, scale, or timing guarantee is implied.