Skip to content

Latest commit

 

History

History
137 lines (95 loc) · 5.61 KB

File metadata and controls

137 lines (95 loc) · 5.61 KB

6. Linux Kernel Interactions in SONiC

SONiC relies heavily on the Linux kernel for operational state, event notifications, and underlying network primitives. This section summarizes how SONiC processes interact with Linux via netlink, bridge, iproute2, and kernel-maintained data structures.

6.1 Linux as the Operational State Source

Linux maintains authoritative operational state for:

  • Link state (admin/oper)
  • IP addresses (IPv4/IPv6)
  • Neighbor entries (ARP/ND)
  • VLAN membership
  • Bridge FDB entries
  • Interface MTU, speed, duplex
  • Bonding (LAG) behavior

Manager daemons (*mgrd) write configuration to Linux, and syncd-side helpers listen for resulting operational events.

6.2 Netlink Overview

SONiC uses rtnetlink, a Linux kernel socket interface for networking events.

Common message types:

Message Type Meaning
RTM_NEWLINK Link added/changed
RTM_DELLINK Link removed
RTM_NEWADDR IP address added
RTM_DELADDR IP address removed
RTM_NEWNEIGH ARP/ND entry added/updated
RTM_DELNEIGH ARP/ND entry removed
RTM_GETLINK Query link info
RTM_GETNEIGH Query neighbor info

Processes listening on netlink:

  • portsyncd (link events)
  • intfsyncd (addresses)
  • neighsyncd (ARP/ND)
  • fdbsyncd (bridge FDB events)

Please refer to the Appendix for a primer on Linux Netlink.


6.3 Manager Daemons Writing to Linux

The following are CLI equivalents of commands executed by *mgrd daemons.

Bring up a port:

ip link set dev Ethernet0 up

Create VLAN interface:

ip link add name Vlan10 type bridge vlan_filtering 1
ip link set Vlan10 up

vlan_filtering 1 means enable VLAN-based bridging.

Add VLAN membership:

bridge vlan add dev Ethernet0 vid 10 pvid untagged

Assign IP to interface:

ip address add 10.1.1.1/24 dev Vlan10

These operations trigger kernel events consumed by syncd-side helpers.

6.4 syncd-side helpers Consuming Netlink

Linux Message / Event Type Process(es) Handling It Comments (Linux-Focused Only)
RTM_NEWLINK / RTM_DELLINK
(interface creation/removal, link up/down, operstate changes, carrier changes, ethtool-driven speed/FEC changes surfaced via netlink)
portsyncd Subscribes to Linux netlink messages for interface/link state. Does not write anything to Linux. Purely an observer of netlink RTM_NEWLINK/DELLINK events.
RTM_NEWADDR / RTM_DELADDR
(IP address added/removed on interfaces)
intfsyncd Subscribes to Linux netlink address messages. Detects IP address additions/removals (RTM_NEWADDR, RTM_DELADDR). Performs no writes to Linux IP stack.
ARP / NDP Neighbor Table Updates
(kernel learns neighbor MAC for an IP, or neighbor entry expires)
neighsyncd Monitors Linux neighbor (ARP/NDP) table via netlink neighbor events and periodic inspection. Does not modify ARP/NDP entries. Purely observes kernel neighbor changes.
FPM Route Messages from FRR Zebra
(RTM_NEWROUTE / RTM_DELROUTE over FPM socket)
fpmsyncd Does not subscribe to kernel netlink. Instead reads routing updates from FRR Zebra's FPM channel. Does not modify Linux routing tables. Only reads Zebra route notifications.
(Optional / Platform-specific) ethtool netlink notifications
(changes to speed, FEC, autoneg)
portsyncd Some platforms expose ethtool data via netlink. portsyncd observes these events but never writes them back.

6.5 Linux Bridge and FDB

SONiC relies on the kernel bridge for:

  • VLAN tagging/untagging behavior
  • FDB learning (dynamic MAC learning)
  • MAC aging
  • MAC move detection

Inspecting bridge state:

bridge fdb show
bridge vlan show
bridge link show

6.6 Linux Neighbor Table

The Linux kernel maintains ARP/ND tables.

Show neighbors:

ip neigh show

These entries generate events to neighsyncd, which updates APPL_DB.


6.7 Summary

Linux acts as:

  • The operational truth for network state.
  • The event emitter via netlink.
  • The FDB learning engine.
  • The initial packet classifier before SAI/ASIC rules apply.

SONiC daemons use Linux to translate configuration into kernel state and to listen for operational updates that eventually drive ASIC programming.