Module 1 · SONiC Architecture & Operating Model

Interface Lifecycle

55 minLabConfigurationCorrelationVirtualOpen-source

Follow a single interface IP through the whole system: add it, find its CONFIG_DB entry, check the Linux netdev, verify application/hardware-facing state, then remove it and confirm every layer cleans up. One object, traced end to end.

Safety: Caution

May change state — take a snapshot first.

Use the lab-only /31 on an unused interface; do not touch a production-carrying port.

Reading ASIC_DB is safe; editing it directly is not — only READ it here.

One interface, five representations

  config → CONFIG_DB(INTERFACE) → APPL_DB → ASIC_DB(SAI RIF)
                                 │
                                 └─ Linux netdev (ip addr)   STATE_DB (observed)

Objective

• Add and remove an interface IP through the SONiC CLI.
• Observe the same change reflected across CONFIG_DB, the Linux netdev, APPL_DB, and hardware-facing state.
• Confirm clean teardown at every layer on removal.

Starting state

• SONiC-VS reachable; host bash + sonic-db-cli available.
• Chosen interface has no conflicting IP configuration.

Prerequisites: Lessons 1.4 and 1.5 complete. · An unused front-panel interface (e.g. Ethernet0) available; baseline snapshot for rollback.

Tasks

1
Add an IP to the interface
SONiC CLIlab-only address on an unused port
```
sudo config interface ip add Ethernet0 10.99.99.1/31
```
Expected:
- Command returns without error. (Acceptance ≠ programmed — you will now verify propagation.)
What happened internally: The CLI writes desired state to CONFIG_DB and returns immediately; the rest of the flow happens asynchronously.
2
Observe the CONFIG_DB entry (intent)
SONiC DB
```
sonic-db-cli CONFIG_DB SCAN 0 MATCH "INTERFACE|Ethernet0*" COUNT 50
```
SONiC DB
```
sonic-db-cli CONFIG_DB HGETALL "INTERFACE|Ethernet0|10.99.99.1/31"
```
Expected:
- An INTERFACE key for Ethernet0 and a key carrying the IP/prefix — the desired state now exists.
What happened internally: This is the top of the flow from Lesson 1.5: intent recorded in CONFIG_DB, a manager will translate it next.
3
Check the Linux netdev
Linux
```
ip addr show Ethernet0
```
Expected:
- The address appears on the kernel netdev — the host-layer representation of the intent.
What happened internally: The intmgr/manager configures the kernel netdev too, but remember: the netdev is a representation, not proof the ASIC forwards. That is what the next check is for.
4
Verify application and hardware-facing state
Confirm the router interface propagated toward hardware via APPL_DB and ASIC_DB (SAI router interface object).
SONiC DB
```
sonic-db-cli APPL_DB SCAN 0 MATCH "INTF_TABLE:Ethernet0*" COUNT 50
```
SONiC DBSAI RIF objects (hardware-facing intent, not silicon)
```
sonic-db-cli ASIC_DB SCAN 0 MATCH "*ROUTER_INTERFACE*" COUNT 100
```
Expected:
- An APPL_DB INTF_TABLE entry, and one or more SAI_OBJECT_TYPE_ROUTER_INTERFACE objects in ASIC_DB.
What happened internally: You have now traced intent all the way to ASIC_DB. Remember ASIC_DB is hardware-facing INTENT; a traffic test would confirm the silicon actually forwards.
5
Remove the IP and confirm cleanup at every layer
SONiC CLI
```
sudo config interface ip remove Ethernet0 10.99.99.1/31
```
SONiC DB
```
sonic-db-cli CONFIG_DB HGETALL "INTERFACE|Ethernet0|10.99.99.1/31"
```
Linux
```
ip addr show Ethernet0
```
SONiC DB
```
sonic-db-cli ASIC_DB SCAN 0 MATCH "*ROUTER_INTERFACE*" COUNT 100
```
Expected:
- CONFIG_DB key gone; address gone from the netdev; the corresponding SAI RIF object withdrawn from ASIC_DB.
What happened internally: Removal propagates the same path in reverse: CONFIG_DB delete → manager → APPL_DB withdrawal → orchagent → SAI remove → ASIC_DB object gone. Clean teardown at every layer is the goal.

Troubleshooting branches

If: IP present in CONFIG_DB but not on the netdev

Then: The interface manager may not have processed it — check swss/intfmgr logs; verify APPL_DB.

If: No ROUTER_INTERFACE object in ASIC_DB

Then: The APPL_DB→SAI→syncd path stalled — check orchagent and syncd logs; this is exactly the swss→syncd handoff from Lesson 1.3.

Cleanup / rollback

Ensure the test IP is removed from all layers (verified in the last task).
Revert to the baseline snapshot if any layer did not clean up.

Lab evidence checklist

☐ CONFIG_DB INTERFACE key before/after.
☐ Linux netdev address before/after.
☐ APPL_DB INTF_TABLE and ASIC_DB ROUTER_INTERFACE presence, then withdrawal.
☐ A short note on which layer confirmed intent vs which would confirm forwarding.

Reflection

You saw the address on the netdev AND a SAI RIF object — which one is closer to proving forwarding, and why is neither definitive?
On removal, which layer would you check first to be sure nothing was left stranded?

Lab notes & observations