- Why I did it
Mellanox MSN2410 platforms have a non-functional error log: "ERR pmon#sensord: Error getting sensor data: dps460/#10: Can't read". This error is because of a firmware issue with some PSU, we are not able to upgrade the FW online. Since there is no functional impact, this error log can be ignored safely
- How I did it
Add a new rsyslog rule to the rsyslog-container.conf.j2, if the docker name is pmon and the platform name matches, the new rule will be inserted into the docker rsyslogd.conf
- How to verify it
run regression on the MSN2410 platform to make the error log will not be printed to the syslog.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
Why I did it
To fix the EVPN type5 failure seen in FRR when there are multipaths for nexthop. The type5 routes were queued
show ip route vrf Vrf1
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF Vrf1:
B>q 5.5.5.0/24 [200/0] via 30.0.0.2, Vlan100 onlink, weight 1, 00:00:40
q via 40.0.0.3, Vlan100 onlink, weight 1, 00:00:40
C>* 10.0.0.0/24 is directly connected, Vlan10, 00:00:43
B>q 100.0.0.0/24 [200/0] via 30.0.0.2, Vlan100 onlink, weight 1, 00:00:40
q via 40.0.0.3, Vlan100 onlink, weight 1, 00:00:40
Work item tracking
Microsoft ADO (number only):
How I did it
Porting the FRR fixFRRouting/frr#14835
How to verify it
Validated EVPN multipath with the scenario and confirmed its working.
The format of the media_settings.json file was updated to support the Port SI Per Speed Enhancements. Since media_checker is the validator for the media_settings.json file, it needs to be updated to align with the new format.
How I did it
I added six new SI parameter names introduced as part of the Port SI Per Speed Enhancements. Additionally, I implemented handling for the new hierarchy level (lane_speed_key) in the updated media_settings.json format while maintaining backward compatibility with vendors whose JSON does not support port SI per speed.
How to verify it
I locally built the Debian package using 'make target/debs/bullseye/sonic-device-data_1.0-1_all.deb,' and it completed successfully. Jenkins also built the entire image, which includes the media_checker as part of its process.
[arp_update]: Flush MAC mismatch neighbors
- Check for MAC mismatch between neighbor entries in the kernel and APPL_DB
- Flush any entries with a mismatch
Currently in this repo would not build dhcp_server container image by default, which would cause that building issue for dhcp_server introduced by other modules cannot be noticed in time.
This PR is to set build dhcp_server container in vs image.
How I did it
Remove Python3 venv in Python3-only sonic-mgmt-docker
How to verify it
There is no impact to sonic-mgmt-docker:latest tag.
Build sonic-mgmt-docker with LEGACY_SONIC_MGMT_DOCKER=y, see python3 venv is there.
Build sonic-mgmt-docker with LEGACY_SONIC_MGMT_DOCKER=n, see python3 venv is NOT included.
This change was submitted directly to 202205 but it's also needed in master and 202305 with SAI9.x
#13346
There has been a couple CSPs for this as well:
CS00012273013 - [7.1][J2, J2c+] Disable SA Equals DA trap on DNX
CS00012320965 - SAI9.2: iBGP doesn't work due to SA_EQUALS_DA trap
If SA_EQUALS_DA trap is enabled iBGP won't work as the Ethernet-IB0 ports are expected to get packets with SA==DA.
In the VOQ chassis design, for outgoing control plane packets, the packets goes the recycle port for routing, therefore the dmac of the packet should be the asic router mac. The source mac is assigned by the kernel, so it is also the asic router mac.
Why I did it
sonic_dhcp_server.whl contains not only dhcp_server functionality but also part of dhcp_relay functionality, the existing naming is not appropriate.
Why I did it
HLD implementation: Container Hardening (sonic-net/SONiC#1364)
Work item tracking
Microsoft ADO (number only): 14807420
How I did it
Reduce linux capabilities in privileged flag
How to verify it
Check container's settings: Privileged is false and container only has default Linux caps, does not have extended caps.
Modify j2 template files in docker-dhcp-relay. Add dhcprelayd to group dhcp-relay instead of isc-dhcp-relay-VlanXXX, which would make dhcprelayd to become critical process.
In dhcprelayd, subscribe FEATURE table to check whether dhcp_server feature is enabled.
2.1 If dhcp_server feature is disabled, means we need original dhcp_relay functionality, dhcprelayd would do nothing. Because dhcrelay/dhcpmon configuration is generated in supervisord configuration, they will automatically run.
2.2 If dhcp_server feature is enabled, dhcprelayd will stop dhcpmon/dhcrelay processes started by supervisord and subscribe dhcp_server related tables in config_db to start dhcpmon/dhcrelay processes.
2.3 While dhcprelayd running, it will regularly check feature status (by default per 5s) and would encounter below 4 state change about dhcp_server feature:
A) disabled -> enabled
In this scenario, dhcprelayd will subscribe dhcp_server related tables and stop dhcpmon/dhcrelay processes started by supervisord and start new pair of dhcpmon/dhcrelay processes. After this, dhcpmon/dhcrelay processes are totally managed by dhcprelayd.
B) enabled -> enabled
In this scenaro, dhcprelayd will monitor db changes in dhcp_server related tables to determine whether to restart dhcpmon/dhrelay processes.
C) enabled -> disabled
In this scenario, dhcprelayd would unsubscribe dhcp_server related tables and kill dhcpmon/dhcrelay processes started by itself. And then dhcprelayd will start dhcpmon/dhcrelay processes via supervisorctl.
D) disabled -> disabled
dhcprelayd will check whether dhcrelay processes running status consistent with supervisord configuration file. If they are not consistent, dhcprelayd will kill itself, then dhcp_relay container will stop because dhcprelayd is critical process.
Why I did it
Fixing CVEs CVE-2023-46752 CVE-2023-46753 CVE-2023-47234 CVE-2023-47235
Work item tracking
Microsoft ADO (number only):
How I did it
Porting the fixes in the below PRs
FRRouting/frr#14645FRRouting/frr#14716
How to verify it
Running regression
- Why I did it
The current low power mode setting implementation requests the user to set the port to admin down first before toggling LP mode, this is not backward compatible, now revert it to the old way so that the user can toggle the LP mode regardless of the port admin status.
- How I did it
Revert the recent changes related to LPM in PR #14130 and #16545
- How to verify it
Run all sfputil and SFP platform API related tests on all the Mellanox platforms.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
Why I did it
Fixing sonic-cfg-help to handle nested container scenario. In case of nested container, the inner container name acts as key for the table. For e.g.
"AUTO_TECHSUPPORT": {
"GLOBAL": {
}
}
Previous output
AUTO_TECHSUPPORT
Description: AUTO_TECHSUPPORT part of config_db.json
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| Field | Description | Mandatory | Default | Reference |
+=========================+====================================================+=============+===========+=============+
| state | Knob to make techsupport invocation event-driven | | | |
| | based on core-dump generation | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| rate_limit_interval | Minimum time in seconds between two successive | | | |
| | techsupport invocations. Configure 0 to explicitly | | | |
| | disable | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| max_techsupport_limit | Max Limit in percentage for the cummulative size | | | |
| | of ts dumps. No cleanup is performed if the value | | | |
| | isn't configured or is 0.0 | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| max_core_limit | Max Limit in percentage for the cummulative size | | | |
| | of core dumps. No cleanup is performed if the | | | |
| | value isn't congiured or is 0.0 | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| available_mem_threshold | Memory threshold; 0 to disable techsupport | | 10.0 | |
| | invocation on memory usage threshold crossing | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| min_available_mem | Minimum Free memory (in MB) that should be | | 200 | |
| | available for the techsupport execution to start | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| since | Only collect the logs & core-dumps generated since | | | |
| | the time provided. A default value of '2 days ago' | | | |
| | is used if this value is not set explicitly or a | | | |
| | non-valid string is provided | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
New output
AUTO_TECHSUPPORT
Description: AUTO_TECHSUPPORT part of config_db.json
key - GLOBAL
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| Field | Description | Mandatory | Default | Reference |
+=========================+====================================================+=============+===========+=============+
| state | Knob to make techsupport invocation event-driven | | | |
| | based on core-dump generation | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| rate_limit_interval | Minimum time in seconds between two successive | | | |
| | techsupport invocations. Configure 0 to explicitly | | | |
| | disable | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| max_techsupport_limit | Max Limit in percentage for the cummulative size | | | |
| | of ts dumps. No cleanup is performed if the value | | | |
| | isn't configured or is 0.0 | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| max_core_limit | Max Limit in percentage for the cummulative size | | | |
| | of core dumps. No cleanup is performed if the | | | |
| | value isn't congiured or is 0.0 | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| available_mem_threshold | Memory threshold; 0 to disable techsupport | | 10.0 | |
| | invocation on memory usage threshold crossing | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| min_available_mem | Minimum Free memory (in MB) that should be | | 200 | |
| | available for the techsupport execution to start | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
| since | Only collect the logs & core-dumps generated since | | | |
| | the time provided. A default value of '2 days ago' | | | |
| | is used if this value is not set explicitly or a | | | |
| | non-valid string is provided | | | |
+-------------------------+----------------------------------------------------+-------------+-----------+-------------+
Work item tracking
Microsoft ADO (number only):
How I did it
Fixing sonic-cfg-help tool to handle nested container
How to verify it
Added UT to verify it.
This is change taken as part of the HLD: sonic-net/SONiC#1470.
In this PR we add the logic to parse the SecondarySubnets field in the minigraph and add a flag in "secondary" in the vlan_interface table of the config db.
Microsoft ADO (number only): 16784946
How I did it
Made changes in the minigraph.py to parse the xml entry and add the parsed value to the config db
How to verify it
Added python tests in the sonic-config-engine folder to test the config db entries.
This is change taken as part of the HLD: sonic-net/SONiC#1470 and this is a follow up on the PR #16827 where in the docker-dhcp we pick the value of primary gateway of the interface from the VLAN_Interface table which has "secondary" flag set in the config_db
Microsoft ADO (number only): 16784946
How did I do it
- Changes in the j2 file to add a new "-pg" parameter in the dhcpv4-relay.agents.j2, the ip would be retrieved from the config db's vlan_interface table such that the interface which are picked will have secondary field set.
- Changes in isc-dhcp to re-order the addresses of the discovered interface and which has the ip which has the passed parameter.
Change DHCP rate limit in SONiC copp configuration to 100 PPS as this is
necessary to ensure that DHCP flood does not cause LACP/BGP flaps in all
scenarios
This is an extension to the change in image_config: copp: Enable rate limiting
for bgp, lacp, dhcp, lldp, macsec and udld #14859 and sonic-mgmt change in
[tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199
Why I did it
300 PPS is not sufficient to prevent LACP/BGP flaps in all cases. 100 PPS seems to
provide better resiliency against DHCP traffic flood to CPU.
Microsoft ADO 25776614:
Send DHCP broadcast packets to DUT and verify that they are trapped to CPU at 100 PPS.
Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Fix bug: #17161 (comment)
multi-asic platforms it will never go to the else part as DATABASE_TYPE is always ""
Microsoft ADO (number only): 25072889
Move the checker NAMESPACE_ID == "" back
Signed-off-by: Ze Gan <ganze718@gmail.com>
#### Why I did it
src/sonic-host-services
```
* 50db9d3 - (HEAD -> master, origin/master, origin/HEAD) Move sonic-host-services-data from sonic-buildimage into this repo (3 hours ago) [Saikrishna Arcot]
* 1a9442f - Replace libpam-cracklib with libpam-pwquality (3 hours ago) [Saikrishna Arcot]
* 31590a1 - Fix diff output in test for Python 3 (3 hours ago) [Saikrishna Arcot]
* cc3e330 - Specify test dependencies under extra_requires (3 hours ago) [Saikrishna Arcot]
```
#### How I did it
#### How to verify it
#### Description for the changelog
- Why I did it
Fix the issue with configuration generation from the minigrapth:
- How I did it
Change the default breakout mode for internal ports to the mode that corresponds platfom.json configuration.
- How to verify it
1. Deploy minigraph
2. Run config load_minigraph -y command
Why I did it
HLD implementation: Container Hardening (sonic-net/SONiC#1364)
Work item tracking
Microsoft ADO (number only): 14807420
How I did it
Reduce linux capabilities in privileged flag
How to verify it
Run restapi sonic-mgmt tests on sn4600c
Check container's settings: Privileged is false and container only has default Linux caps, does not have extended caps.
* [Marvell-arm64] Add platform support for rd98DX35xx
This change adds following two variants of rd98DX35xx board to arm64
build.
Board with CPU integrated into the 98DX35xx switching chip:
Platform: arm64-marvell_rd98DX35xx-r0
HwSKU: rd98DX35xx
ASIC: marvell
Port Config: 32x1G + 16x2.5G + 6x25G
Board with external CN9131 CPU connected over PCI to 98DX35xx
switching chip:
Platform: arm64-marvell_rd98DX35xx_cn9131-r0
HwSKU: rd98DX35xx_cn9131
ASIC: marvell
Port Config: 32x1G + 16x2.5G + 6x25G
Change-Id: I21dc9fe972417daaabb20a5bddf7779d72b7972e
Signed-off-by: Pavan Naregundi <pnaregundi@marvell.com>
* Add HWSKU for rd98DX35xx and rd98DX35xx_cn9131
This patch adds new HWSKU's for Marvell arm64 platforms rd98DX35xx
and rd98DX35xx_cn9131.
Change-Id: Id7c14f49f0e304335cc4ca73dcae52362c49d231
Signed-off-by: Pavan Naregundi <pnaregundi@marvell.com>
---------
Signed-off-by: Pavan Naregundi <pnaregundi@marvell.com>
What I did:
In Chassis TSA mode Loopback0 Ip's of each LC's should be advertise through e-BGP peers of each remote LC's
How I did:
- Route-map policy to Advertise own/self Loopback IP to other internal iBGP peers with a community internal_community as define in constants.yml
- Route-map policy to match on above internal_community when route is received from internal iBGP peers and set a internal tag as define in constants.yml and also delete the internal_community so we don't send to any of e-BGP peers
- In TSA new route-map match on above internal tag and permit the route (Loopback0 IP's of remote LC's) and set the community to traffic_shift_community.
- In TSB delete the above new route-map.
How I verify:
Manual Verification
UT updated.
sonic-mgmt PR: sonic-net/sonic-mgmt#10239
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
- Why I did it
Added YANG model as part of Generic Hash feature development
- How I did it
Added YANG model
- How to verify it
1. Add UT
2. Verified manually with the feature qualification
Signed-off-by: Nazarii Hnydyn <nazariig@nvidia.com>
- Why I did it
To fix BIOS firmware update after fresh image installation from ONiE
- How I did it
Initialized empty GRUB environment file after ONiE installation
- How to verify it
1. Install image from ONiE
2. Run BIOS firmware upgrade
Signed-off-by: Nazarii Hnydyn <nazariig@nvidia.com>
- Why I did it
Support running hw-management service on MSN4700 emulation platform.
- How I did it
Use physical EEPROM instead of the fake one
Do not skip PSUd, PCId, thermal control daemon
Adjust PCIe and thermal configuration files
Adjust platform.json for different chassis names and thermals
Remove a patch to hw-management in order to enable it
- How to verify it
Run Nvidia simulation on SN4700 (ASIC and Platform)
Signed-off-by: Stephen Sun <stephens@nvidia.com>
- Why I did it
In order to activate FW after it was upgraded need to perform reboot.
If reboot wasn't performed and user need to upgrade to another SONiC image then it will fail.
The reason for that is that during SONiC upgrade new FW should be installed but it will fail because previously installed FW wasn't activated.
In order to allow 2nd FW upgrade without reboot in-between need to reactivate FW image.
This change handles such flow.
Example of issue scenario:
User installed SONiC image on the switch
Then for some reason FW was upgraded by user or script but reboot was not performed to activate it.
After that upgrade to new SONiC image will fail because new image need to install FW but it fails due to previous one wasn't activated.
- How I did it
In "mlnx-fw-upgrade" script check if FW upgrade failed with the error that FW was already installed but reboot was not performed.
If so then perform FW image reactivation and try to upgrade FW again.
- How to verify it
Install SONiC image on the switch
Then upgrade FW but don't perform reboot.
After that upgrade to new SONiC image and check that upgrade was successfull.
Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
Why I did it
- Convert hw-dump into generate-dump plugins
- Enable DRAM scrubber on some products
- Fix xcvr driver active low register bit logic
- Improve cooling algorithm (now considers xcvrs and modules)
- Add linecard graceful shutdown (disabled by default)
The scrubber was enabled for the following products:
- DCS-7050QX-32S
- DCS-7050CX3-32S
- DCS-7060CX-32S
What I did:
Revert the GTSM feature for VOQ iBGP session done as part of #16777.
Why I did:
On VOQ chassis BGP packets go over Recycle Port and then for Ingress Pipeline Routing making ttl as 254 and failing single hop check.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Sub PRs:
sonic-net/sonic-host-services#84
#17191
Why I did it
According to the design, the database instances of DPU will be kept in the NPU host.
Microsoft ADO (number only): 25072889
How I did it
To follow the multiple ASIC design, I assume a new platform environment variable NUM_DPU will be defined in the /usr/share/sonic/device/$PLATFORM/platform_env.conf. Based on this number, NPU host will launch a corresponding number of instances for the DPU database.
Signed-off-by: Ze Gan <ganze718@gmail.com>
SAI 9.x requires a SYNCD_SHM_SIZE specified otherwise it will default to 64mb which is insufficient for syncd.
E.G. of a few failures seen when insufficient shmem was set
ha_init: The file: warmboot_data_0 is of size=762[MB] and is beyond the directory: /dev/shm available storage of size=64[MB]#015
syncd.sh[26074]: Cannot get SYNCD_SHM_SIZE for chip: [869] in /usr/share/sonic/device/x86_64-broadcom_common/syncd_shm.ini. Skip set SYNCD_SHM_SIZE.
Syncd hangs here:
syncd#syncd: [none] SAI_API_SWITCH:_brcm_sai_shr_ha_section_resize:536 start=0x7f6e641b4000, end=0x7f6e645b4000, len=302276608, free=0x7f6e641b4000
Broadcom recommended using 1gb for DNX devices.
Since currently we don't use SAI9.x on master and 202305 this change won't fix anything until we upgrade the SAI on those branches.
#### Why I did it
src/sonic-dbsyncd
```
* e294eb0 - (HEAD -> master, origin/master, origin/HEAD) Update the code coverage rate to 80% (#63) (16 hours ago) [xumia]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/sonic-platform-daemons
```
* 55a6828 - (HEAD -> master, origin/master, origin/HEAD) Update the code coverage rate to 80% (#406) (16 hours ago) [xumia]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Why I did it
Work item tracking
Microsoft ADO (number only): 25858445
How I did it
sonic-mgmt-docker with both Python2 and Python3 tag is latest
sonic-mgmt-docker with Python3 only tag is py3only
How to verify it
Why I did it
Add config_db monitor and customize options for dhcpservd. HLD: sonic-net/SONiC#1282
Work item tracking
Microsoft ADO (number only): 25600859
How I did it
Add support to customize unassigned DHCP options. Current support type: binary, boolean, ipv4-address, string, uint8, uint16, uint32
Add db config change monitor for dhcpservd
How to verify it
Unit tests in sonic-dhcp-server all passed
