#### Why I did it
src/sonic-utilities
```
* 83a548de - (HEAD -> 202305, origin/202305) Disable Key Validation feature during sonic-installation for Cisco Platforms (#3115) (22 hours ago) [selvipal]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/sonic-snmpagent
```
* 6f59d29 - (HEAD -> 202305, origin/202305) Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) (#309) (33 minutes ago) [mssonicbld]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/sonic-snmpagent
```
* 2efaf2e - (HEAD -> 202305, origin/202305) Revert "[action] [PR:303] Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303)" (#308) (4 minutes ago) [StormLiangMS]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Currently, whenever isc-dhcp-relay forwards a packet upstream,
internally, it will try to send it on a "fallback" interface. My
understanding is that this isn't meant to be a real interface, but
instead is basically saying to use Linux's regular routing stack to
route the packet appropriately (rather than having isc-dhcp-relay
specify specifically which interface to use).
The problem is that on systems with a weak CPU, a large number of
interfaces, and many upstream servers specified, this can introduce a
noticeable delay in packets getting sent. The delay comes from trying to
get the ifindex of the fallback interface. In one test case, it got to
the point that only 2 packets could be processed per second. Because of
this, dhcrelay will easily get backlogged and likely get to a point
where packets get dropped in the kernel.
Fix this by adding a check saying if we're using the fallback interface,
then don't try to get the ifindex of this interface. We're never going
to have an interface named this in SONiC.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
#### Why I did it
src/sonic-snmpagent
```
* b0a4bcc - (HEAD -> 202305, origin/202305) Set the execute bit on sysDescr_pass.py (#306) (22 hours ago) [Andre Kostur]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/linkmgrd
```
* f5e9b54 - (HEAD -> 202305, origin/202305) [CodeQL] fix unmet build dependency (#222) (10 hours ago) [Jing Zhang]
* 2282cc5 - [active-standby] Probe the link in suspend timeout (#235) (22 hours ago) [Longxiang Lyu]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/sonic-utilities
```
* 93c42272 - (HEAD -> 202305, origin/202305) [chassis]: Support show ip bgp summary to display without error when no external neighbors are configured on chassis LC (#3099) (22 hours ago) [Arvindsrinivasan Lakshmi Narasimhan]
```
#### How I did it
#### How to verify it
#### Description for the changelog
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
double commit PR-16450 because of cherry pick conflict for PR#202305
Work item tracking
Microsoft ADO (number only):
How I did it
How to verify it
Why I did it
When we disable telemetry.service, sonic-hostservice will not start. And root cause is sonic-hostservice is only wanted by telemetry.service.
Work item tracking
Microsoft ADO (number only):
How I did it
Add dependency for gnmi.service.
How to verify it
Disable telemetry.service and build new image, and then check sonic-hostservice with new image.
#### Why I did it
src/sonic-swss
```
* ac94f0b7 - (HEAD -> 202305, origin/202305) [202305][routeorch] Fixing bug with multiple routes pointing to nhg (#3002) (2 hours ago) [Nikola Dancejic]
```
#### How I did it
#### How to verify it
#### Description for the changelog
*What I did:
Enable BFD for Static Route for chassis-packet. This will trigger the use of the feature as defined in here: #13789
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
For 40G optics there is SAI handling of T0 facing ports to be set with SR4 type and unreliable los set for a fixed set of ports. For this property to be invoked the requirement is set
phy_unlos_msft=1 in config.bcm.
This change is to meet the requirement and once this property is set, the los/interface type settings is applied by SAI on the required ports.
Why I did it
For Arista-7060CX-32S-Q32 T1, 40G ports RX_ERR minimalization during connected device reboot
can be achieved by turning on Unreliable LOS and SR4 media_type for all ports which are connected to T0.
The property phy_unlos_msft=1 is to exclusively enable this property.
Microsoft ADO: 25941176
How I did it
Changes in SAI and turning on property
How to verify it
Ran the changes on a testbed and verified configurations are as intended.
with property
admin@sonic2:~$ bcmcmd "phy diag xe8 dsc config" | grep -C 2 "LOS"
Brdfe_on = 0
Media Type = 2
Unreliable LOS = 1
Scrambling Disable = 0
Lane Config from PCS = 0
without property
admin@sonic:~$ bcmcmd "phy diag xe8 dsc config" | grep -C 2 "LOS"
Brdfe_on = 0
Media Type = 0
Unreliable LOS = 0
Scrambling Disable = 0
Lane Config from PCS = 0
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
#### Why I did it
src/sonic-utilities
```
* 651a80b1 - (HEAD -> 202305, origin/202305) Modify teamd retry count script to base BGP status on default BGP status (#3069) (22 hours ago) [Saikrishna Arcot]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/linkmgrd
```
* 2f5971f - (HEAD -> 202305, origin/202305) [warmboot] use config_db connector to update mux mode config instead of CLI (#223) (4 hours ago) [Jing Zhang]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/linkmgrd
```
* 2089ab6 - (HEAD -> 202305, origin/202305) Exclude DbInterface in PR coverage check (#224) (3 hours ago) [Jing Zhang]
```
#### How I did it
#### How to verify it
#### Description for the changelog
#### Why I did it
src/sonic-snmpagent
```
* e5fd192 - (HEAD -> 202305, origin/202305) Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true (#303) (9 hours ago) [DavidZagury]
```
#### How I did it
#### How to verify it
#### Description for the changelog
DEPENDS ON: sonic-net/sonic-swss#2997sonic-net/sonic-utilities#3093
What I did
Revert the feature.
Why I did it
Revert bgp suppress FIB functionality due to found FRR memory consumption issues and bugs.
How I verified it
Basic sanity check on t1-lag, regression in progress.
Backport PR #17458 due to conflict.
Why I did it
Optimize syslog rate limit feature for fast and warm boot
Work item tracking
Microsoft ADO (number only):
How I did it
Optimize redis start time
Don't render rsyslog.conf in container startup script
Disable containercfgd by default. There is a new CLI to enable it (in another PR)
How to verify it
Manual test
Regression test
#### Why I did it
src/sonic-swss
```
* 5643db9a - (HEAD -> 202305, origin/202305) [muxorch] Fixing cache bug in updateRoute logic (#2982) (6 hours ago) [Nikola Dancejic]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Signed-off-by: anamehra anamehra@cisco.com
Why I did it
Fixes#16990 for 202305/202205 branch
Note: This PR is for 202305 and 202205. For master, a new PR will be raised with a new field (Uphold=) provided by debian bookworm to handle the dependency failure restartability of the processes.
determine-reboot-cause and process-reboot-cause service does not start If the database service fails to restart in the first attempt. Even if the Database service succeeds in the next attempt, these reboot-cause services do not start.
The process-reboot-cause service also does not restart if the docker or database service restarts, which leads to an empty reboot-cause history
deploy-mg from sonic-mgmt also triggers the docker service restart. The restart of the docker service caused the issue stated in 2 above. The docker restart also triggers determine-reboot-cause to restart which creates an additional reboot-cause file in history and modifies the last reboot-cause.
This PR fixes these issues by making both processes start again when dependency meets after dependency failure, making both processes restart when the database service restarts, and preventing duplicate processing of the last reboot reason.
Work item tracking
Microsoft ADO 25892856
How I did it
Modified systemd unit files to make determine-reboot-cause and process-reboot-cause services restartable when the database service restarts.
On the restart, the determine-reboot-cause service should not recreate a new reboot-cause entry in the database. Added check for first start or restart to skip entry for restart case.
How to verify it
On single asic pizza box:
Installed the image and check reboot-cause history
restart database service and verify that determine-reboot-cause and process-reboot-cause services also restart. Verify that reboot-cause shows correct data and no new entry is created for restart.
On Chassis:
Installed the image and check reboot-cause history
restart the database service and verify that determine-reboot-cause and process-reboot-cause services also restart. Verify that reboot-cause shows correct data and no new entry is created for restart.
Reboot LC. On Supervicor, stop database-chassis service.
Let database service on LC fail the first time. determine-reboot-cause and process-reboot-cause would fail to start due to dependency failure
start database-chassis on Supervisor. Database service on LC should now start successfully.
Verify determine-reboot-cause and process-reboot-cause also starts
Verify show reboot-cause history output
Why I did it
To fix ecmp hash polarization issue.
Work item tracking
Microsoft ADO (number only): 26085143
How I did it
Add sai_hash_seed_config_hash_offset_enable=1 in all config.bcm that Broadcom T1 uses.
HardwareSku
Force10-S6100-T1
Force10-S6100-ITPAC-T1
Force10-S6100
Celestica-DX010-C32
Arista-7260CX3-C64
Arista-7060CX-32S-Q32
Arista-7060CX-32S-C32-T1
Arista-7060CX-32S-C32
Arista-7050QX32S-Q32
Arista-7050QX-32S-S4Q31
Arista-7050-QX32
Arista-7050-QX-32SInclude Broadcom's fix by upgrading xgs SAI version to 8.4.35.0.
8.4.35.0: [CSP 00012324019] back-porting SONIC-75006 to SAI8.4
8.4.34.0:
[CSP 00012318293] back-porting SONIC-81534 to SAI8.4;
ECMP LB traffic polarization, configure hash_offset along with hash_seed attr
Run qual with only xgs SAI version upgraded to 8.4.35.0:
on TH2: https://elastictest.org/scheduler/testplan/6579b36ccfacd86e78e3e885?leftSideViewMode=detail&prop=status&order=ascending
on TH: https://elastictest.org/scheduler/testplan/657a75f8c1d3b51fc1d585b4?leftSideViewMode=detail&prop=status&order=ascending
How to verify it
use tests/ecmp/test_ecmp_sai_value.py to verify.
Fix zebra leaking memory with fib suppress enabled. Porting the fix from
FRRouting/frr#14983
While running test_stress_route.py, systems with lower memory started to throw low memory logs. On further investigation, a memory leak has been found in zebra which was fixed in the FRR community.
