-
Notifications
You must be signed in to change notification settings - Fork 3
SONiC_202006_Release_Notes
This document captures the new features added and enhancements done on existing features/sub-features for the SONiC 202006 release.
Branch : https://github.com/Azure/sonic-buildimage/tree/202006
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is here)
| Feature | Version |
|---|---|
| Linux kernel version | linux_4.9.0-11-2 (4.9.189-3+deb9u2) |
| SAI version | SAI v1.5.1 |
| FRR | 7.2 |
| LLDPD | 0.9.6-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.3.5-2 (PR2946 ) |
| sonic-telemetry | 0.1 |
| redis-server/ redis-tools | 5.0.3-3~bpo9+2 |
- Kernal upgraded from 4.9.110-3deb9u6 (SONiC Release 201904) to 4.9.168-1+deb9u5 in this 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 document provides functional design and specifications of BFD protocol as defined in RFC 5880, 5881, 5882 and 5883.BFD protocol defines a method of rapid detection of the failure of a forwarding path by checking that the next hop router is alive. The protocol will be able to detect the forwarding path failure in milliseconds depending on the actual configuration.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 3838 ,5197
This document provides functional design and specifications of BFD protocol as defined in RFC 5880, 5881, 5882 and 5883.BFD protocol defines a method of rapid detection of the failure of a forwarding path by checking that the next hop router is alive. The protocol will be able to detect the forwarding path failure in milliseconds depending on the actual configuration.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 3292, 4117, 4425
This document provides functional design and specifications of BFD protocol as defined in RFC 5880, 5881, 5882 and 5883.BFD protocol defines a method of rapid detection of the failure of a forwarding path by checking that the next hop router is alive. The protocol will be able to detect the forwarding path failure in milliseconds depending on the actual configuration.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1238
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 the new proposal, 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
This document describes a means (framework) for an application executed inside a container to securely request the execution of an operation ("action") by the host OS.This framework is intended to be used by the SONiC management and telemetry containers, but can be extended for other application containers as well.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4840
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 145, 4711
Ports can be broken out to different speeds with various lanes in most HW today. However, on SONiC, the port breakout modes are hard-coded in the profiles and only loaded at initial time. In case we need to have a new port breakout mode, we would potentially need a new image or at least need to restart services which would impact the traffic of the box on irrelevant ports. The feature is to address the above issues.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4235, 3910, 1242, 1219, 1151, 1150, 1148, 1112, 1085, 766, 72, 859, 767, 765, 3912, 3911, 3909, 3907, 3891, 3874, 3861, 3730
Quality of Service (QoS) scheduling and shaping features enable better service to certain traffic flows.Queue scheduling provides preferential treatment of traffic classes mapped to specific egress queues. SONiC supports SP, WRR, and DWRR scheduling disciplines.Queue shaping provides control of minimum and maximum bandwidth requirements per egress queue for more effective bandwidth utilization. Egress queues that exceed an average transmission rate beyond the shaper max bandwidth will stop being serviced. Additional ingress traffic will continue to be stored on the egress queue until the queue size is exceeded which results in tail drop.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1296, 991
A modern network switch is a sophisticated equipment which consists of many auxiliary components which are responsible for managing different subsystems (e.g., PSU/FAN/QSFP/EEPROM/THERMAL) and providing necessary interfaces (e.g., I2C/SPI/JTAG).Basically these components are complex programmable logic devices with it's own HW architecture and software. It is very important to always have the latest recommended software version to improve device stability, security and performance. In order to make software update as simple as possible and to provide a nice user frindly interface for various maintenance operations (e.g., install a new FW or query current version) we might need a dedicated FW utility.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4764, 4758, 941, 942, 87, 82
The Ethernet switches of today have evolved and are entering several key segments providing switch chips for enterprise, data-center, and carrier, as well as optical transceivers, Gearbox PHYs and 25Gbps Re-timers. If the platform/hardware supports it, the PHY may be configurable to speeds including 10G, 25G, 40G, 50G, and 100G, and beyond. Some platforms contain an external PHY, while others have PHYs embedded in the switch ASIC (Internal PHY). The abstraction interface contains a set of SAI APIs providing new functionality in support of the most recent PHY advancements and requirements. Through utilizing this new external PHY interface, this project adds configuration and management capabilities for these new external PHY requirements.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 347, 931, 1321, 624, 4851
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4671, 4727, 4726, 4665, 4515, 4598, 4529, 4480
Management framework makes use of the translation library (Translib) written in golang to convert the data models exposed to the management clients into the Redis ABNF schema format. Supported management servers can make use of the Translib to convert the incoming payload to SONiC ABNF schema and vice versa depending on the incoming request. Translib will cater to the needs of REST and gNMI servers. Later the Translib can be enhanced to support other management servers if needed. This framework will support both standard and custom YANG models for communication with the corresponding management servers.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 18, 19, 25
SONiC OS is portable across different network devices with supported ASIC via Switch Abstraction Interface (SAI). These devices primarily differ in the way various device specific hardware components are accessed, and thus require custom device drivers and python plugins. Each platform vendor implements these custom device drivers and plugins. The feature requirement is to support a SONiC platform driver development framework to enable rapid development of custom device drivers and plugins.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 4756, 940, 92
This feature describes the high level design details on how the SONiC PDE is constructed as well as details on the PDE test suite. The PDE is available to ODMs and others looking to add new platform support, and it optimizes the development and qualification process. It offers a pre-canned, minimal code package to which the ODM can add their necessary platform driver files and static configuration files. Furthermore, the PDE will provide a test suite where platform developers can quickly test their drivers and configuration files to resolve issues more easily without relying on the full SONiC application and infrastructure to be in place.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 3778, 28
SONiC OS is portable across different network devices with supported ASIC via Switch Abstraction Interface (SAI). These devices primarily differ in the way various device specific hardware components are accessed, and thus require custom device drivers and python plugins. Each platform vendor implements these custom device drivers and plugins. The feature requirement is to support a SONiC platform driver development framework to enable rapid development of custom device drivers and plugins.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 3387, 624, 62
This feature describes the high level design details on Port/Port-channel mirroring support, dynamic session management, ACL rules can continue to use port/ERSPAN sessions as the action, Configuration CLI for mirror session.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1314, 936
This feature describes the high level design details on Port/Port-channel mirroring support, dynamic session management, ACL rules can continue to use port/ERSPAN sessions as the action, Configuration CLI for mirror session.
Refer HLD document and below mentioned PR's for more details.
Pull Requests : 1314, 936
When an interface is enabled with "proxy_arp", the same is enabled in the kernel. ASIC ARP packet action is also updated to trap these packets to CPU in those interfaces.
Refer HLD Document for more details.
Pull Requests : 617
Refer HLD Document for more details.
Pull Requests : 1533
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 summary 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
Thermal control daemon has been added to monitor the temperature of devices (CPU, ASIC, optical modules, etc) and the running status of fan. It retrieves the switch device temperatures via platform APIs and raises alarms when the high/low thresholds are hit.It also stores temperature values fetched from sensors and thermal device running status to the DB.
Refer HLD Document for more details.
Pull Requests : 73, 777, 49, 3949,832
Please find the list of API's classified along the newly added SAI features. For further details on SAI API please refer [SAI_1.5_Release_notes]([https://github.com/kannankvs/md2/blob/master/SAI_1.5%20Release%20notes.md](https://github.com/kannankvs/md2/blob/master/SAI_1.5 Release notes.md))
| S.No | Feature | API |
|---|---|---|
| 1 | TAM | 1. sai_create_tam_report_fn 2. sai_remove_tam_int_f 3. sai_set_tam_int_attribute_fn 4. sai_get_tam_int_attribute_fn 5. sai_tam_telemetry_get_data_fn |
| 2 | NAT | 1. sai_create_nat_range_fn 2. sai_remove_nat_range_fn 3. sai_get_nat_range_attribute_fn 4. sai_get_nat_range_attribute_fn 5. sai_create_nat_fn 6. sai_remove_nat_fn 7. sai_set_nat_attribute_fn 8. sai_get_nat_attribute_fn |
| 3 | sFLOW | 1. sai_hostif_type_genetlink 2. sai_hostif_attr_genetlink_mcgrp_name 3. sai_hostif_table_entr_channel_type_genetlink |
| 4 | Generic Resource Monitoring | 1. sai_object_type_get_availability |
| 5 | SAI counter | 1. sai_create_counter_fn 2. sai_remove_counter_fn 3. sai_set_counter_attribute_fn 4. sai_get_counter_attribute_fn 5. sai_get_counter_stats_fn 6. sai_get_counter_stats_ext_fn 7. sai_clear_counter_stats_fn |
| 6 | Drop Counters | 1. sai_create_debug_counter_fn 2. sai_remove_debug_counter_fn 3. sai_set_debug_counter_attribute_fn 4. sai_get_debug_counter_attribute_fn |
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.
- Home
- FAQ
- For Users
- For Developers
- Sonic Roadmap Planning
- Report Issues
- Presentations
- Community Meetings
- Join Us