SONiC

Module 2

Control Plane, FRR & Route Lifecycle

How familiar routing protocols integrate into SONiC's service and database model.

~8 h3 h lecture4.5 h labs5 lessons5 labs10 check questions

Purpose

Teach how familiar routing protocols (especially BGP) integrate into SONiC's service and database architecture.

Build the habit of tracing a single route across every layer, from FRR to ASIC-facing state to actual forwarding.

Learning objectives

  • →Explain how FRR (zebra, bgpd, vtysh) runs inside SONiC and exchanges state with the rest of the system.
  • →Distinguish BGP Loc-RIB, zebra RIB, application state, and ASIC route objects.
  • →Trace a BGP route's full lifecycle from update to hardware programming.
  • →Explain why a route can exist in the control plane yet fail to forward.
  • →Compare the troubleshooting workflow across Cisco-style NOS, Dell OS10, and open-source vs enterprise SONiC.

Lessons

  1. FRR Inside SONiCSONiC does not ship a proprietary routing stack. It runs FRRouting — zebra and bgpd — inside the bgp container, driven by vtysh and by SONiC's own configuration path. The interesting part for a CCNP engineer is not the protocol (it is standard BGP) but the plumbing: how FRR is configured, who owns that configuration, and how learned routes leave FRR and enter the rest of SONiC.50m
  2. RIB, FIB & Hardware StateYou already know RIB versus FIB. SONiC stretches that two-layer idea into a chain of distinct state representations: bgpd's Loc-RIB, zebra's RIB, (optionally) the Linux kernel FIB, SONiC's APPL_DB route state, the ASIC_DB SAI route objects, and finally the real forwarding entries in silicon. A route can be present in one layer and absent in the next — and knowing which layer you are looking at is most of the diagnosis.55m
  3. BGP Route LifecycleThis lesson traces a single prefix end to end: a BGP UPDATE arrives, bgpd runs best-path, zebra selects and exports the route, fpmsyncd publishes it to APPL_DB, SWSS/orchagent resolves next-hop and neighbor dependencies, SAI objects are created, syncd programs the ASIC, and only then do packets forward. Each hop is a checkpoint you can observe.55m
  4. Control Plane vs Data PlaneA route can be perfectly valid in BGP and still forward nothing. This lesson catalogs the reasons that gap opens in SONiC: unresolved recursive next-hops, missing neighbor/interface dependencies, ASIC resource exhaustion, orchagent/syncd sync failures, and stale or inconsistent state — and how to tell them apart.50m
  5. Traditional NOS ComparisonYour routing troubleshooting reflexes came from an integrated NOS where a handful of show commands read one system. This lesson maps that workflow onto SONiC and contrasts four worlds — Cisco-style NOS, Dell OS10, open-source SONiC, and enterprise SONiC — so you know which instincts transfer and where the surface genuinely changes.45m

Labs

  1. Build a Routed AdjacencyBring up a routed link between two nodes (two SONiC-VS, or SONiC-VS plus a Linux host running FRR), establish an eBGP session, advertise test prefixes in both directions, and verify the received routes at the FRR layer. This is the foundation topology every later lab in this module reuses.ConfigurationVirtualOpen-source60m
  2. Trace One Route Through the SystemTake the prefix you learned in Lab 2.1 and document it at every layer: FRR (bgpd/zebra), the SONiC route command, APPL_DB, next-hop/neighbor state, ASIC_DB, and finally a data-plane test. This is a correlation lab — you are proving the same route exists (or does not) at each layer and filling in a tracing worksheet.CorrelationObservationVirtual60m
  3. Route WithdrawalWatch a prefix leave the system. Establish forwarding for a test prefix, then withdraw it at the source and observe the removal cascade — control plane (FRR), application state (APPL_DB), and hardware state (ASIC_DB) — while testing forwarding before and after. The point is to see teardown propagate in the same order as install, and to time it.ObservationCorrelationVirtual45m
  4. Failure Injection: BGP ContainerDeliberately 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.Failure injectionVirtualObservation60m
  5. Broken Next-Hop ScenarioCreate the classic 'valid in BGP, not forwarding' condition on purpose: a route whose next-hop cannot be fully resolved, so it lives happily in the control plane but never programs a hardware entry. Your job is to diagnose the broken dependency using the lifecycle and layer-tracing skills from this module — then fix it.TroubleshootingFailure injectionVirtual55m

Module summary

  • A route is not one object — it is a chain of representations, and forwarding depends on the whole chain resolving.
  • A healthy control plane does not guarantee correct forwarding: recursive next-hops, neighbors, interfaces, and hardware resources all gate it.

Completion checklist

  • ☐ I established eBGP between two SONiC nodes and advertised test prefixes.
  • ☐ I traced one route through FRR, the SONiC route command, APPL_DB, next-hop state, and ASIC_DB.
  • ☐ I observed control-plane, application-state, and hardware-state removal on a withdrawal.
  • ☐ I injected a BGP container failure and explained what kept forwarding and why.
  • ☐ I diagnosed a route that is present in the control plane but cannot forward.
Carry this forward

Finish the labs before moving on — later modules assume you can navigate the databases and containers hands-on, not just in theory.