Module 2 · Control Plane, FRR & Route Lifecycle

Failure Injection: BGP Container

60 minLabFailure injectionVirtualObservation

Deliberately stop and restart the bgp container and observe the split between control-plane state (adjacencies drop) and data-plane state (already-programmed routes may persist). Baseline first, inject, observe adjacencies and retained/removed forwarding, record convergence, then restore. Behavior here is heavily dependent on warm-restart features, image version, and configuration — this lab teaches you to characterize your specific box, not to memorize a universal outcome.

Safety: Disruptive — lab only

Disrupts forwarding or services. Run only in a dedicated virtual lab you can roll back. Never on production or shared physical switches.

Disruptive: stopping the bgp container drops adjacencies. Run only in the virtual lab with a snapshot ready.

Behavior varies with warm-restart features, image version, and configuration — do not present your single observation as universal SONiC behavior.

Reuses Lab 2.1

  sonic-a bgp container stop/start ; peer stays up

Objective

• Observe the decoupling of control-plane and data-plane state during a routing-daemon outage.
• Record whether forwarding for learned prefixes persists while bgp is down.
• Measure re-convergence time on restart.
• Characterize your image's behavior rather than assume a universal one.

Starting state

• eBGP Established; test prefix forwarding.
• You know whether BGP warm-restart / graceful-restart is configured on this image.
• A revertable snapshot exists.

Prerequisites: Labs 2.1–2.3 complete; a working prefix forwarding across the link. · A VM snapshot to revert to (Lab 1.1 baseline or a fresh one). · Lesson 2.4 (control vs data plane).

Tasks

1
Record warm-restart / graceful-restart configuration
Behavior of this lab hinges on these features — capture them before injecting.
SONiC CLI
```
show warm_restart config
```
FRR / vtyshlook for graceful-restart capability
```
vtysh -c 'show bgp neighbors'
```
Expected:
- A record of whether warm/graceful restart is enabled for BGP on this box.
What happened internally: With warm-restart, forwarding is explicitly designed to persist across a bgp restart; without it, outcomes differ. This is why no single behavior is universal.
2
Baseline control-plane and data-plane state
FRR / vtysh
```
vtysh -c 'show ip bgp summary'
```
SONiC DB
```
sonic-db-cli APPL_DB HGETALL 'ROUTE_TABLE:10.2.2.0/24'
```
Linux
```
ping -c 2 10.2.2.1
```
Expected:
- Established; route in APPL_DB; ping succeeds.
What happened internally: Anchors the 'before' so the injection delta is measurable.
3
Inject: stop the bgp container
Linux Disruptivestops the routing daemon container
```
sudo systemctl stop bgp
```
Linux
```
docker ps --filter name=bgp
```
Expected:
- bgp container no longer running; adjacency will drop.
What happened internally: Stopping bgp kills bgpd/zebra. The FPM export stops, but whatever was already programmed in ASIC_DB/silicon is not automatically flushed by the mere absence of bgpd.
4
Observe adjacency loss vs. retained forwarding
Immediately and then over the next minute, watch both planes.
SONiC DB
```
sonic-db-cli APPL_DB HGETALL 'ROUTE_TABLE:10.2.2.0/24'
```
Linuxdoes forwarding persist while bgp is down?
```
ping -c 5 10.2.2.1
```
Expected:
- Adjacency is down (no daemon).
- Whether the route/forwarding persists is image/warm-restart/config dependent — record exactly what you observe.
What happened internally: This is the core lesson: control-plane presence and data-plane programming are separate. Some images retain forwarding (by design or by not flushing); others tear it down. Do not generalize your result.
5
Restore: start the bgp container and time convergence
Linuxrestart the routing daemon
```
sudo systemctl start bgp
```
FRR / vtysh
```
vtysh -c 'show ip bgp summary'
```
Expected:
- Session returns to Established; note the time from start to Established and to re-received prefixes.
What happened internally: On restart bgpd rebuilds state from config and re-learns from the peer; warm-restart influences whether forwarding was maintained throughout.
6
Confirm full reconciliation
SONiC DB
```
sonic-db-cli APPL_DB HGETALL 'ROUTE_TABLE:10.2.2.0/24'
```
Linux
```
ping -c 3 10.2.2.1
```
Expected:
- Route present and forwarding restored; no lingering inconsistency across layers.
What happened internally: Verifies the system converged back to the Lab 2.1/2.2 baseline.

Troubleshooting branches

If: Session does not return to Established

Then: Confirm bgp container actually started (docker ps), config persisted, and the peer is still up.

If: Forwarding never returns after restart

Then: Check for APPL_DB↔ASIC_DB divergence and orchagent/syncd errors; if stuck, revert to snapshot.

If: Unexpected retained/black-holed forwarding

Then: Record it — it is exactly the control/data-plane decoupling this lab demonstrates; note warm-restart config in your findings.

Cleanup / rollback

Confirm eBGP Established and forwarding restored.
If state is inconsistent, revert to the snapshot rather than hand-repairing.

Lab evidence checklist

☐ Warm/graceful-restart config recorded.
☐ Baseline (Established + forwarding) captured.
☐ Behavior during bgp-down captured (adjacency + forwarding).
☐ Convergence time on restart recorded.
☐ Full reconciliation confirmed.

Reflection

Did forwarding persist while bgp was down on your image? What does that imply for a routing-daemon crash in production?
How would warm-restart change your risk assessment for restarting the bgp container during an incident?

Lab notes & observations