Build a Routed Adjacency

Bring 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.

  AS 65001                         AS 65002
  ┌───────────────┐   .1  .2   ┌───────────────┐
  │  sonic-a      │Ethernet0──┤ Ethernet0      │
  │ 10.0.12.1/31  │───────────│ 10.0.12.2/31   │
  │ lo 10.1.1.1   │   p2p link│ lo 10.2.2.1     │
  └───────────────┘           └───────────────┘
   advertise 10.1.1.0/24       advertise 10.2.2.0/24

Prerequisites: Lesson 2.1 complete. · Two nodes reachable over management; a shared L2 segment for the data link (one vCenter port group). · Lab 1.1 baseline snapshot exists on each SONiC-VS.

Tasks

1. 1

   Confirm the routing config mode before editing

   Decide whether SONiC config or FRR config is authoritative on each node so your BGP config persists.

   SONiC DB Copy

   sonic-db-cli CONFIG_DB HGET 'DEVICE_METADATA|localhost' docker_routing_config_mode

   Expected:

   • A mode string (e.g., split or unified) telling you where to configure BGP.

   What happened internally: Editing the wrong surface risks your config being regenerated/overwritten on the next reload. This check makes the rest of the lab deterministic.

2. 2

   Configure the routed interface on sonic-a

   Assign a /31 to Ethernet0 and add a loopback carrying the test prefix.

   SONiC CLI Copy

   sudo config interface ip add Ethernet0 10.0.12.1/31

   SONiC CLItest prefix source Copy

   sudo config interface ip add Loopback1 10.1.1.1/24

   SONiC CLI Copy

   show ip interfaces

   Expected:

   • Ethernet0 shows 10.0.12.1/31; Loopback1 shows 10.1.1.1/24; both oper-up.

   What happened internally: config interface writes intent to CONFIG_DB; managers translate it toward APPL_DB and the interface orchagent programs the router interface toward SAI.

3. 3

   Configure the peer side

   Mirror the addressing on the second node (SONiC-VS or Linux/FRR).

   SONiC CLIon sonic-b; on Linux/FRR use ip addr add Copy

   sudo config interface ip add Ethernet0 10.0.12.2/31

   Expected:

   • Reachability across the /31: each side can ping the other's interface IP.

   What happened internally: A successful ping here proves the L2 link and interface programming — the substrate BGP will run over.

4. 4

   Configure eBGP on both sides

   Configure BGP on the surface that owns routing config on each node. The vtysh form below applies where FRR owns config; on unified-mode SONiC, use the SONiC BGP config path instead.

   FRR / vtyshsonic-a (AS 65001); mirror with AS 65002 / 10.2.2.0/24 on the peer Copy

   vtysh -c 'conf t' \
     -c 'router bgp 65001' \
     -c ' neighbor 10.0.12.2 remote-as 65002' \
     -c ' address-family ipv4 unicast' \
     -c '  network 10.1.1.0/24' \
     -c '  neighbor 10.0.12.2 activate' \
     -c ' exit-address-family' \
     -c 'end'

   Expected:

   • Configuration accepted with no errors; neighbor appears in the BGP config.

   What happened internally: bgpd now has neighbor intent and will attempt the TCP session and the BGP FSM toward Established.

5. 5

   Verify the session and received prefixes

   FRR / vtysh Copy

   vtysh -c 'show ip bgp summary'

   FRR / vtysh Copy

   vtysh -c 'show ip bgp'

   FRR / vtyshthe prefix learned from the peer Copy

   vtysh -c 'show ip route 10.2.2.0/24'

   Expected:

   • Neighbor state Established with a nonzero prefix-received count.
   • The peer's test prefix present in the BGP table and selected into the zebra RIB.

   What happened internally: Established + received prefix confirms the control plane through zebra. This lab intentionally stops at FRR; Lab 2.2 traces the same prefix onward to hardware.

6. 6

   Save configuration

   SONiC CLIpersist SONiC-owned config Copy

   sudo config save -y

   Expected:

   • config_db.json updated; on FRR-owned nodes also vtysh -c 'write memory'.

   What happened internally: Persistence differs by config mode — save on the surface that owns the config, per your Task 1 finding.