This document captures the new features added and enhancements done on existing features/sub-features for the SONiC 202012 release.
Branch : https://github.com/Azure/sonic-buildimage/tree/202012
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is here)
| Feature | Version |
|---|---|
| Linux kernel version | linux_4.19.0-9-2 (4.19.118-2+deb10u1) |
| SAI version | SAI v1.7.1 |
| FRR | 7.5 |
| LLDPD | 1.0.4-1 |
| TeamD | 1.28-1 |
| SNMPD | 5.7.3+dfsg-1.5 |
| Python | 3.6.0-1 |
| syncd | 1.0.0 |
| swss | 1.0.0 |
| radvd | 2.17-2~bpo9+1 |
| isc-dhcp | 4.4.1-2 |
| sonic-telemetry | 0.1 |
| redis-server/ redis-tools | 5.0.3-3~bpo9+2 |
- Kernel upgraded from 4.9.110-3deb9u6 (SONiC Release 201904) to 4.9.168-1+deb9u5 for SONiC release. Change log: https://tracker.debian.org/media/packages/l/linux/changelog-4.9.168-1deb9u5
- Docker upgraded from 18.09.2~3-0~debian-stretch to 18.09.8~3-0~debian-stretch. Change log: https://docs.docker.com/engine/release-notes/#18098
This feature is to modify the behavior of ECMP to achieve fine grained handling of ECMP for a specifically identified prefix and associated next-hops in configuration.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1315, 623, 1788, 4985, 374, 659, 1056, 5518, 5198, 693.
The goal of SONiC warm reboot is to be able restart and upgrade SONiC software without impacting the data plane. Warm restart of each individual process/docker is also part of the goal. Except for syncd and database docker, it is desired for all other network applications and dockers to support un-planned warm restart.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 3992, 1036, 5233,5163, 5108 & 1036.
During SWSS start, the prebuilt copp.json file is loaded as part of start script swssconfig.sh and written to APP_DB. CoppOrch then translates it to Host trap/policer tables and programmed to SAI. With this enhancement, the CoPP tables shall be loaded to Config_DB instead of APP_DB. The default CoPP json file shall be prebuilt to the image and loaded during initialization. Any Config_DB entries present shall be configured overwriting the default CoPP tables. This also ensures backward compatibility.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 358, 1333, 4861 & 1004
This is a feature to support SONiC for hardware console.
Pull Requests :5571 & 1155
This feature describes the persistent console configurations to control how to view/connect to a device via serial link.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 664, 673 ,1117 , 1120, 1130 ,1136 , 1166 , 1173, 1176 , 5438 & 5717.
This feature defines the solution on how the headroom is calculated by the well known formula based upon with the cable length and speed as input. Arbitrary cable length will be supported.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1338, 973, 4881, 1971, 361
This feature enables the synchronous mode for a closed-loop execution, if SAI APIs are called from the orchagent. In contrast to the previous asynchronous mode which cannot properly handle SAI API failures, the synchronous mode can gracefully handle SAI API failures by conducting the proper actions in orchagent. Therefore, the synchronous mode can substantially improve the reliability of SONiC.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 5237 , 650 , 652 , 653, 1094 & 5308.
This feature provides information about the EVPN VXLAN feature implementation based on RFC 7432 BGP EVPN solution over VXLAN tunnels for SONiC, including support for L2 and L3 VPN services, auto discovery of remote VTEPs, auto provisioning of tunnels and VLANs over VXLAN tunnels, control plane MAC learning and ARP suppression for reduced flooding, and support for VM mobility.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 339 ,350 , 1264 , 1266 , 1318 , 1267 & 870.
The Entity MIB contains several groups of MIB objects: entityPhysical group, entityLogical group and so on. Previously, SONiC only implemented part of the entityPhysical group following RFC2737. Since entityPhysical group is most commonly used, this extension will focus on entityPhysical group and leave other groups for future implementation. The group entityPhysical contains a single table called "entPhysicalTable" to identify the physical components of the system.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 134, 102, 5645, 168 & 2379
This feature extends and provides unified configuration and management capability for FRR-BGP features used in SONiC.This enhancement is to load any BGP/route-map configurations from config-DB as well independent of mgmt-framework NBI, the main change here is to add CONFIB_DB entries for FRR management into SONiC, and the ability to apply this config to FRR.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 5142
This feature is a design change that allows the PHY drivers to be separated from the Switch driver (SAI) by introducing a new driver API for PHYs. This allows diverse, multi-vendor hardware to be more easily supported. This change adds usage capability of this new interface to SONiC.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 347, 931, 1321, 624 & 4851.
This feature deals in depth with kubernetes-support. With this feature, an image could be downloaded from external repositaries and kubernetes does the deployment. The external Kubernetes masters could be used to deploy container image updates at a massive scale, through manifests. This new mode is referred as "kubernetes mode".
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 5421, 1133
The SONiC Management Framework provides a unified UI stack, enabling SONiC to be managed through an Industry-standard CLI, RESTCONF and gNMI (using OpenConfig data models). It also offers a rapid development environment for these user-interfaces, based upon automatic code generation from YANG models.
This set of enhancements extends the framework, including (but not limited to) the following additions: -
- CLI: Usability enhancements, performance enhancements, User-document generation
- Translib Infrastructure: Much of the UI infrastructure is separated out into a new repo (sonic-mgmt-common), de-coupling it from the UI code (which remains in the sonic-mgmt-framework repo). This allows the sonic-telemetry container (which also uses the infra) to be built and used independently from sonic-mgmt-framework. Other enhancements include support for RPC, YANG versioning, bulk calls (e.g. from gNMI), Authorization, and other code optimizations
- CVL: This is an infrastructure component to perform UI validations. It is enhanced here to support Dynamic Port Breakout configuration dependency and for improved performance.
- Transformer: This is an infrastructure component to perform YANG tree to configuration object translations. Enhancements include support for more overloading functions, cascaded operations (for dynamic port breakout) and aliasing
- REST Server: Enhancements include RBAC, RESTCONF, YANG module discovery, statistics and other optimizations
- Advance to Python 3.7
- Use of DBus for communication into the host
- Build enhancements
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4799,4765,4840,35, 38,126, 170, 10,11, 12, 13, 15, 16, 18, 19, 20, 21, 22, 23, 26, 27, 28, 31, 32, 34, 35, 50, 51,52, 53, 57, 60,65, 66, 67, 68, 69,71, 5810,5920,72, 73, 5714,61
This is a fix for common lib and associated files.
Pull Requests : 378
This is inline as part of moving all SONiC code from Python 2 (no longer supported) to Python 3.
Pull Requests : 5886, 6038, 6162, 6176, 1542
This feature is for a platform with more than one ASIC present on it, which is defined as a multi ASIC platform. SONiC so far supports platforms with single ASIC, we are enhancing SONiC to support multiple ASIC platforms.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4825, 4895, 4926, 4932, 4959, 4973, 5022, 5113, 5121, 5122, 5202, 5221, 5224, 5235, 5316, 5329, 5357, 5358, 5364, 5418, 5420, 5436, 5437, 5446, 5460, 5479, 5503, 5548, 87, 81, 138, 140, 141, 145, 154, 155, 158, 161, 166, 376, 856, 917, 978, 999, 1005, 1006, 1013, 1057, 1064, 1079, 1080, 1081, 1123, 1137 & 1127
This feature is for restoring each database with all data before warmboot and then flush unused data in each instance.Restore needs to be done in database docker since we need to know the database_config.json in new version. Need to copy all data rdb file into each instance restoration location and then flush unused database. All other logic remains the same as before.
Pull Requests : 5773 & 1205
SONiC FW utility uses platform API to interact with the various platform components. SONiC FW utility extends to support for the automatic firmware update based on "platform_components.json" under platform directory and next reboot option which is passed as a option for fwutil update all fw command. SONiC FW utility also extends to support for the automatic firmware update with a custom firmware package that can include any firmware update tool and the firmware update tool will be used for the firmware update if it's specified in the "platform_components.json".
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1165, 106
PDDF is a rapid platform development environment for SONiC, enabling new platforms to be quickly integrated into the SONiC eco-system by automating much of the routine development using simple description files. It supports both the SONiC Platform 1.0 and 2.0 designs (though 2.0 is preferred). Also supports BMC.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4756, 940, 92, 3387, 624, 62
This feature enables SONiC streaming telemetry agent to send Reboot-cause information. During the boot, the determine-reboot-cause service ( previously process-reboot-cause) determines the last reboot-cause, based on the hardware reboot-cause. And the software reboot-cause information and determine-reboot-cause service will save the JSON-formatted last previous reboot cause. information is "/host/reboot-cause/history/" by adding timestamp at the end of file name.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 5562, 1154
System health monitor is intended to monitor both critical services and peripheral device status and leverage system log, system status LED to and CLI command output to indicate the system status.In current SONiC implementation, we already have Monit which is monitoring the critical services status and also have a set of daemons.System health monitoring service will not monitor the critical services or devices directly, it will reuse the result of Monit and PMON daemons to summarize the current status and decide the color of the system health LED.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4835 & 4829
Please find the list of API's classified along the newly added SAI features. For further details on SAI API please refer SAI_1.7.1 Release Notes
SONiC community would like to thank all the contributors from various companies and the individuals who has contributed for the release. Special thanks to the major contributors - Microsoft, Broadcom, DellEMC, Mellanox, Alibaba, Linkedin, Nephos & Aviz.