Add pre start check to ensure intfmgrd is running.
The check will run for 20 seconds at most.
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
Co-authored-by: Longxiang Lyu <35479537+lolyu@users.noreply.github.com>
src/linkmgrd
* d7ab364 - (HEAD -> 202205, origin/202205) [warmboot] config all interfaces back to `auto` if reconciliation times out (#220) (29 minutes ago) [Jing Zhang]
* Revert "[SNMP][IPv6]: Fix to use link local IPv6 address as snmp agentAddress (#16013) (#16102)"
This reverts commit 628e1ad981.
* Revert "[SNMP][IPv6]: Fix SNMP IPv6 reachability issue in certain scenarios (#15487) (#15826)"
This reverts commit 7cfb71bc18.
* [202205][Arista] Update arista platform submodules
- fix issue where platform debug info would no longer be in the dump
- fix issue in scd-xcvr where active low bits couldn't be set
- fix issue in scd-smbus where it perform an oob access
src/sonic-platform-common
* ade83aa - (HEAD -> 202205, origin/202205) [202205] Fix issue: should use 'Value' column to calculate the health percentage for Virtium SSD (#385) (4 weeks ago) [Junchao-Mellanox]
previously, get_num_asics() returns the maximum number of asics. however, the asic_count
should be actual number of asics populated which can be get from get_asic_presence_list().
ADO: 25158825
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
* [buffers] Add create_only_config_db_buffers.json for MLNX devices (not MSFT SKU), inject it at the start of the swss docker
Signed-off-by: vadymhlushko-mlnx <vadymh@nvidia.com>
* [buffers] Align the sonic-device_metadata.yang
Signed-off-by: vadymhlushko-mlnx <vadymh@nvidia.com>
---------
Signed-off-by: vadymhlushko-mlnx <vadymh@nvidia.com>
Upgrade the xgs SAI version to 7.1.62.4 to include the following changes:
7.1.62.4: ECMP CRM fix - CS00012312907
7.1.61.4: Includes nexthop group scaling fix - CS00012304075
7.1.60.4: CS00012302193 - SAI_SWITCH_ATTR_SWITCH_HARDWARE_INFO attribute value changed
7.1.59.4: [CS00012302400 CS00012302347]backport SONIC-76986 to SAI7.1: Fix the issue--"empty LAG can't be added to ACL entry"
7.1.57.4: [CSP CS00012296571] Backport SONIC-75371 jira on SAI 7.1 branch
7.1.56.4: [CSP CS00012302193] backport SONIC-72912 jira on SAI 7.1 branch
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
Update SDK/FW to 4.5.4318/2010.4316 and SAI to 2205.25.1.2 in order to include listed below fixes.
SDK/FW
In some cases, when an ACL has two or more rules with a similar key, modifying/removing one of the rules may cause modification/removal of one of the similar-key rules, instead of the requested rule.
Using module SPQCELRCDFB when connected to a 3rd party switch, there may either be no link or a very long link up time (~2 minutes).
In some case warmboot from 201911 to 202205 might result in dataplane traffic loss
When upgrade SONiC version using warm boot from version 201911/202012 to newer version, then doing cold boot back to older version and upgrade again to newer one warm boot might be fail.
SAI
Added support for dynamic ordered ECMP group (SAI_NEXT_GROUP_TYPE_DYNAMIC_ORDERED_ECMP)
"store and forward" KV was added
Added Support for IPV6 link local debug counters
---------
Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
Why I did it
Fixes for
MIGSMSFT-333 / SR 696141124 - Fix OREDERED ECMP NHG drop when route is added before members are added
MIGSMSFT-333 / SR 696141124 – Fix port handling of empty ecmp group to drop packets
Why I did it
SONiC service determine-reboot-cause might run before driver creating reset cause files. In that case, the reset cause will be "Unknown". This PR introduces a wait mechanism to wait for reset cause sysfs files ready.
How I did it
/run/hw-management/config/reset_attr_ready is the file to indicate all reset cause files are ready. In chassis.get_reboot_cause function, it waits /run/hw-management/config/reset_attr_ready for up to 45 seconds.
How to verify it
Manual test on master/202211/202205
Microsoft ADO (25266920)
sonic-mgmt xoff test was failing for [100g,120km]. Needed to update total headroom pool size when 100G line card is used as T2 uplink.
This size was calculated assuming 100g is used for downlink so cable length was 2km whereas it can also be used for uplink (cable length - 120km). so we need to do calculation based on 120km not 2km. Although it will be some wastage for 2km scenario but it should cover both cases.
This fixesNokia-ION/ndk#22
Note that this PR must be coupled with NDK version >= 22.9.13
Why I did it
To provide proper support for CMIS compliant transceiver module CDB operations (including FW related operations).
How I did it
Enhanced the transport subsystem so as to provide for up to 2k bytes of data to be passed to/from modules (as contrasted with the prior max of 128 bytes).
How to verify it
Ensure that new FW (firmware) can be programmed to CMIS compliant module(s) using the 'sfputil firmware ...' commands.
What I did:
Fixes: #16468
Why I did:
On Some chassis there is no dedicated eth1-midplane interface on supervisor for supervisor and LC communication but instead Linux bridge br1 is used for that. Because of this changes that were done to white-list traffic over eth1-midplane would not work.
How I did:
To fix this we are using altname property of ip link command to set eth1-midplane as altname of br interface. This is done to keep design generic across chassis and between supervisor and LC also. IP-table rules are updated to get parent/base interface name of eth1-midplane.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Why I did it
Release Notes for 8102-64H
• Fix NHG drop when route is added before members are added (MIGSMSFT-333 / SR 696141124)
• Added a new system device property "acl_set_dscp_encap_outer_only"
• IN_DISCARD counters report back per-port counters only instead of all counters that are per-port and also that are shared.
How I did it
Update platform version to 202205.2.2.12
#### Why I did it
To enable qos config for a certain backend deployment mode, for resource-type "Compute-AI".
This deployment has the following requirement:
- Config below enabled if DEVICE_TYPE as one of backend_device_types
- Config below enabled if ResourceType is 'Compute-AI'
- 2 lossless TCs' (2, 3)
- 2 lossy TCs' (0,1)
- DSCP to TC map uses 4 DSCP code points and maps to the TCs' as follows:
"DSCP_TO_TC_MAP": {
"AZURE": {
"48" : "0",
"46" : "1",
"3" : "3",
"4" : "4"
}
}
- WRED profile has green {min/max/mark%} as {2M/10M/5%}
This required template change <as in the PR> in addition to the vendor qos.json.j2 file (not included here).
### How I did it
#### How to verify it
- with the above change and the vendor config change, generated the qos.json file and verified that the objective stated in "Why I did it" was met
- verified no error
### Description for the changelog
Update qos_config.j2 for Comptue-AI deployment on one of backend device type roles
Why I did it
sonic-mgmt test failure is seen for update_firmware component API
Microsoft ADO: 25208748
How I did it
Edited API 2.0 to fix this issue.
How to verify it
Run sonic-mgmt test after the fix and verify it passes.
* [swss] Chassis db clean up optimization and bug fixes
This commit includes the following changes:
- Fix for regression failure due to error in finding CHASSIS_APP_DB in
pizzabox (#PR 16451)
- After attempting to delete the system neighbor entries from
chassis db, before starting clearing the system interface entries,
wait for sometime only if some system neighbors were deleted.
If there are no system neighbors entries deleted for the asic coming up,
no need to wait.
- Similar changes for system lag delete. Before deleting the
system lag, wait for some time only if some system lag memebers were
deleted. If there are no system lag members deleted no need to wait.
- Flush the SYSTEM_NEIGH_TABLE from the local STATE_DB. While asic
is coming up, when system neigh entries are deleted from chassis ap
db (as part of chassis db clean up), there is no orchs/process running to
process the delete messages from chassis redis. Because of this, stale system
neigh are entries present in the local STATE_DB. The stale entries result in
creation of orphan (no corresponding data path/asic db entry) kernel neigh
entries during STATE_DB:SYSTEM_NEIGH_TABLE entries processing by nbrmgr (after
the swss serive came up). This is avoided by flushing the SYSTEM_NEIGH_TABLE from
the local STATE_DB when sevice comes up.
Signed-off-by: vedganes <veda.ganesan@nokia.com>
* [swss] Chassis db clean up bug fixes review comment fix - 1
Debug logs added for deletion of other tables (SYSTEM_INTERFACE and SYSTEM_LAG_TABLE)
Signed-off-by: vedganes <veda.ganesan@nokia.com>
---------
Signed-off-by: vedganes <veda.ganesan@nokia.com>
(cherry picked from commit b13b41fc22)
Signed-off-by: anamehra anamehra@cisco.com
Added a check for DEVICE_METADATA before accessing the data. This prevents the j2 failure when var is not available.
Why I did it
Zebra core sometimes seen during config reload. Series of route-map deletions and then re-adds, and this triggers the hash table to realloc to grow to a larger size, then subsuquent route-map operations will be against a corrupted hash table.
Issue is seen when we have BFD Enable on Static Route table we see Static route-map being created/deleted based on bfd session state. However issue itself is very generic from FRR perspective.
Thie issue has detailed core info sonic-net/sonic-frr#37 . This PR fixes this issue.
Fixes#sonic-net/sonic-frr#37
Work item tracking
Microsoft ADO (17952227):
How I did it
This fix is already in Master frr/8.2.5. Porting this fix to 202205 branch to address this Zebra core.
sonic-net/sonic-frr@5f503e5
Solution:
The whole purpose of the delay of deletion and the storage of the route-map is to allow the using protocol the ability to process the route-map at a later time while still retaining the route-map name( for more efficient reprocessing ). The problem exists because we are keeping multiple copies of deletion events that are indistinguishable from each other causing hash havoc.
How to verify it
Verified running sonic-mgmt test, doing multiple config reloads.
chassis-packet: Update arp_update script for FAILED and STALE check (#16311)
1. Fixing an issue with FAILED entry resolution retry.
Neighbor entries in arp table may sometimes enter a FAILED state when the far end is down and reports the state as follows:
2603:10e2:400:3::1 dev PortChannel19 router FAILED
While the arp_update script handles the entries for FAILED in the following format, the above was not handled due to the token location (extra router keyword at index 4):
2603:10e2:400:3::1 dev PortChannel19 FAILED
The former format may appear if an arp resolution is tried on a link that is known but the far end goes down, e.g., pinging a STALE entry while the far end is down.
2. Refreshing STALE entries to make sure the far end is reachable.
STALE entries for some backend ports may appear in chassis-packet when no traffic is received for a while on the port. When the far end goes down, it is expected for BFD to stop sending packets on the session for which the far end is not reachable. But as the entry is known as stale, on the Cisco chassis, BFD keeps sending packets. Refreshing the stale entry will keep active links as reachable in the neighbor table while the entries for the far end down will enter a failed state. FAILED state entries will be retired and entered reachable when far end comes back up.
* [minigraph] remove number of lanes check for changing speed from 400G to 100G and set speed setting before lane reconfiguration (#15721)
8111 800G interface, split to 2x400G (each has 4 lanes) fails to change interface speed from 400G to 100G during deploy mg. In minigraph.xml, the interface speed configuration is good, but fails to generate the right value to config_db.json.
In order to support this SKU the speed transitioning should support both 4 lanes and 8 lanes in the port_config.ini.
Why I did it
before this change for a 400G to 100G transition, in all cases except when lanes are 8, we would continue and the line
ports.setdefault(port_name, {})['speed'] = port_speed_png[port_name]
would not be executed, hence the default speed will never be set for a case and config_db will not be updated,
where speed is transitioning from 400G to 100G or 40G, but lanes are not equal to 8.
In order for those cases to pass where lanes are not specifically 8, we need the change
Work item tracking
24242657
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
* fix UT
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
---------
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
Bmc is a valid neighbor type in minigraph, however it was missing from the YANG model definition. Usually, the Bmc type device can be neighbor of BmcMgmtToRRouter. This PR is to introduce this type.
Co-authored-by: Yaqiang Zhu <zyq1512099831@gmail.com>
