Core Containers
The most distinctive aspect of SONiC's design: containerization.
From the above design diagram of SONiC, we can see that in SONiC, all services are in the form of containers. After logging into the switch, we can view the currently running containers by using the docker ps command:
admin@sonic:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ddf09928ec58 docker-snmp:latest "/usr/local/bin/supe…" 2 days ago Up 32 hours snmp
c480f3cf9dd7 docker-sonic-mgmt-framework:latest "/usr/local/bin/supe…" 2 days ago Up 32 hours mgmt-framework
3655aff31161 docker-lldp:latest "/usr/bin/docker-lld…" 2 days ago Up 32 hours lldp
78f0b12ed10e docker-platform-monitor:latest "/usr/bin/docker_ini…" 2 days ago Up 32 hours pmon
f9d9bcf6c9a6 docker-router-advertiser:latest "/usr/bin/docker-ini…" 2 days ago Up 32 hours radv
2e5dbee95844 docker-fpm-frr:latest "/usr/bin/docker_ini…" 2 days ago Up 32 hours bgp
bdfa58009226 docker-syncd-brcm:latest "/usr/local/bin/supe…" 2 days ago Up 32 hours syncd
655e550b7a1b docker-teamd:latest "/usr/local/bin/supe…" 2 days ago Up 32 hours teamd
1bd55acc181c docker-orchagent:latest "/usr/bin/docker-ini…" 2 days ago Up 32 hours swss
bd20649228c8 docker-eventd:latest "/usr/local/bin/supe…" 2 days ago Up 32 hours eventd
b2f58447febb docker-database:latest "/usr/local/bin/dock…" 2 days ago Up 32 hours database
Let's briefly introduce these containers here.
数据库容器：database
This container runs Redis, the central database in SONiC that we have mentioned many times, which holds the configuration and state information of all switches, and through which SONiC provides the underlying communication mechanism to each service.
We can see the running redis process inside this container by docker: the
admin@sonic:~$ sudo docker exec -it database bash
root@sonic:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 82 13.7 1.7 130808 71692 pts/0 Sl Apr26 393:27 /usr/bin/redis-server 127.0.0.1:6379
...
root@sonic:/# cat /var/run/redis/redis.pid
82
So how does another container access this Redis database? The answer is through a Unix socket, which we can see in the database container, which maps the /var/run/redis directory on the switch into the database container, allowing the database container to create the socket: /var/run/redis:
# In database container
root@sonic:/# ls /var/run/redis
redis.pid redis.sock sonic-db
# On host
admin@sonic:~$ ls /var/run/redis
redis.pid redis.sock sonic-db
Then map this socket to other containers, so that all containers can access the central database, for example, the swss container:
admin@sonic:~$ docker inspect swss
...
"HostConfig": {
"Binds": [
...
"/var/run/redis:/var/run/redis:rw",
...
],
...
交换机状态管理容器：swss（Switch State Service）
This container is arguably the most critical container in SONiC, it is the brain of SONiC, which runs a large number of *syncd and *mgrd services to manage all aspects of the switch configuration, such as Port, neighbor, ARP, VLAN, Tunnel, etc., etc. Also running inside is the orchagent mentioned above, which is used to handle configuration and status changes related to the ASIC in a unified manner.
The approximate functions and processes of these services have already been mentioned above, so we won't go over them again. Here we can take a look at the services running in this container by using the ps command:
admin@sonic:~$ docker exec -it swss bash
root@sonic:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 43 0.0 0.2 91016 9688 pts/0 Sl Apr26 0:18 /usr/bin/portsyncd
root 49 0.1 0.6 558420 27592 pts/0 Sl Apr26 4:31 /usr/bin/orchagent -d /var/log/swss -b 8192 -s -m 00:1c:73:f2:bc:b4
root 74 0.0 0.2 91240 9776 pts/0 Sl Apr26 0:19 /usr/bin/coppmgrd
root 93 0.0 0.0 4400 3432 pts/0 S Apr26 0:09 /bin/bash /usr/bin/arp_update
root 94 0.0 0.2 91008 8568 pts/0 Sl Apr26 0:09 /usr/bin/neighsyncd
root 96 0.0 0.2 91168 9800 pts/0 Sl Apr26 0:19 /usr/bin/vlanmgrd
root 99 0.0 0.2 91320 9848 pts/0 Sl Apr26 0:20 /usr/bin/intfmgrd
root 103 0.0 0.2 91136 9708 pts/0 Sl Apr26 0:19 /usr/bin/portmgrd
root 104 0.0 0.2 91380 9844 pts/0 Sl Apr26 0:20 /usr/bin/buffermgrd -l /usr/share/sonic/hwsku/pg_profile_lookup.ini
root 107 0.0 0.2 91284 9836 pts/0 Sl Apr26 0:20 /usr/bin/vrfmgrd
root 109 0.0 0.2 91040 8600 pts/0 Sl Apr26 0:19 /usr/bin/nbrmgrd
root 110 0.0 0.2 91184 9724 pts/0 Sl Apr26 0:19 /usr/bin/vxlanmgrd
root 112 0.0 0.2 90940 8804 pts/0 Sl Apr26 0:09 /usr/bin/fdbsyncd
root 113 0.0 0.2 91140 9656 pts/0 Sl Apr26 0:20 /usr/bin/tunnelmgrd
root 208 0.0 0.0 5772 1636 pts/0 S Apr26 0:07 /usr/sbin/ndppd
...
ASIC管理容器：syncd
This container is mainly used to manage the ASICs on the switch, and it runs the syncd service. The SAI (Switch Abstraction Interface) and ASIC Driver provided by each vendor we mentioned before are placed in this container. It is the existence of this container that allows SONiC to support many different ASICs without modifying the upper layer services. In other words, without this container, the SONiC is a brain in a tank, except for some basic configuration, other than only by thinking, nothing can be done.
There are not many services running in the syncd container, namely syncd, which we can view with the ps command, and in the /usr/lib directory, where we can also find this immense and unbelievable SAI file compiled to support ASIC: the
admin@sonic:~$ docker exec -it syncd bash
root@sonic:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 20 0.0 0.0 87708 1544 pts/0 Sl Apr26 0:00 /usr/bin/dsserve /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
root 32 10.7 14.9 2724404 599408 pts/0 Sl Apr26 386:49 /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
...
root@sonic:/# ls -lh /usr/lib
total 343M
...
lrwxrwxrwx 1 root root 13 Apr 25 04:38 libsai.so.1 -> libsai.so.1.0
-rw-r--r-- 1 root root 343M Feb 1 06:10 libsai.so.1.0
...
各种实现特定功能的容器
There are many more containers in SONiC that exist to implement some specific functionality. These containers generally have special external interfaces (non-SONiC CLI and REST API) and implementations (non-OS or ASIC), such as
- bgp：用来实现BGP协议（Border Gateway Protocol，边界网关协议）的容器
- lldp：用来实现LLDP协议（Link Layer Discovery Protocol，链路层发现协议）的容器
- teamd：用来实现Link Aggregation（链路聚合）的容器
- snmp：用来实现SNMP协议（Simple Network Management Protocol，简单网络管理协议）的容器
Similar to SWSS, in order to accommodate the SONiC architecture, they all run the same kinds of services we mentioned above in the middle:
- 配置管理和下发（类似
*mgrd）：lldpmgrd，zebra（bgp） - 状态同步（类似
*syncd）：lldpsyncd，fpmsyncd（bgp），teamsyncd - 服务实现或者外部接口（
*d）：lldpd，bgpd，teamd，snmpd
管理服务容器：mgmt-framework
We have seen in previous sections how to use SONiC's CLI for some switch configuration, but in a real production environment, it is not practical to manually log into the switch to configure all the switches using the CLI, so SONiC provides a REST API to solve this problem. The implementation of this REST API is in the mgmt-framework container. We can view it with the ps command:
admin@sonic:~$ docker exec -it mgmt-framework bash
root@sonic:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 16 0.3 1.2 1472804 52036 pts/0 Sl 16:20 0:02 /usr/sbin/rest_server -ui /rest_ui -logtostderr -cert /tmp/cert.pem -key /tmp/key.pem
...
其实除了REST API，SONiC还可以通过其他方式来进行管理，如gNMI，这些也都是运行在这个容器中的。其整体架构如下图所示 [2]：
Here we can also find that we actually use the CLI, the underlying is also achieved by calling this REST API ~
平台监控容器：pmon（Platform Monitor）
The services inside this container are basically used to monitor the operational status of some basic hardware of the switch, such as temperature, power, fans, SFP events, etc. Again, we can use the ps command to view the services running in this container:
admin@sonic:~$ docker exec -it pmon bash
root@sonic:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 28 0.0 0.8 49972 33192 pts/0 S Apr26 0:23 python3 /usr/local/bin/ledd
root 29 0.9 1.0 278492 43816 pts/0 Sl Apr26 34:41 python3 /usr/local/bin/xcvrd
root 30 0.4 1.0 57660 40412 pts/0 S Apr26 18:41 python3 /usr/local/bin/psud
root 32 0.0 1.0 57172 40088 pts/0 S Apr26 0:02 python3 /usr/local/bin/syseepromd
root 33 0.0 1.0 58648 41400 pts/0 S Apr26 0:27 python3 /usr/local/bin/thermalctld
root 34 0.0 1.3 70044 53496 pts/0 S Apr26 0:46 /usr/bin/python3 /usr/local/bin/pcied
root 42 0.0 0.0 55320 1136 ? Ss Apr26 0:15 /usr/sbin/sensord -f daemon
root 45 0.0 0.8 58648 32220 pts/0 S Apr26 2:45 python3 /usr/local/bin/thermalctld
...
Most of these services we can guess what they do from the name, only xcvrd in the middle is not so obvious, here xcvr is the abbreviation of transceiver, it is used to monitor the optical modules of the switch, such as SFP, QSFP and so on.