On the DCS-7060CX-32S, a SEU can happen on a CPLD which by default would reboot the platform.
Other SEU scenarios are already handled but this one was missed since it's specific to this platform.
It's a pretty rare case which will now be reported in the syslog the same way others are.
Include SAI bug fixes:
Apply device MAC on port host interface when port is removed from LAG.
[Shared Headroom]: fixed watermark handling for SHP flow
Decrease verbosity of policer unbind message when no policer is attached
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
When we add allow-list key with action above route-map gets updated . For eg if we add deny action above template will become to no-export community. Now if we delete the key Issue is we still keep the no-export and do not move back to drop community.
This PR fixes this issue by rolling back default route-map community value back to constants.yml default action.
** Why I did it **
Disable SDK extended dump due to issue found
** How I did it **
Update SAI submodule
** How to verify it **
Verify the SDK extended dump is not called.
Signed-off-by: Eran Dahan <erand@nvidia.com>
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
- Why I did it
The command sudo ip netns identify <pid> is used in function get_current_namespace
to check in the cli command is running in host context or within a namespace.
This function is used for every CLI command and command sudo ip netns identify <pid> needs to be added in sudoer files to allow users with RO access to run show cli commands
This problem is not there on single asic platforms.
- How I did it
Add ip netns identify [0-9]* to sudoers file.
d324eaec945081f8718468b39a8cf12dae965fd5 (HEAD -> 201911, origin/201911) [PFCWD] Fix 'start' pfcwd command (#1345)
235c61cccbbbb1f948f53b561c98888681b7071a [ecnconfig] handle backend port names when extracting port I/F ID from the port name (#1361)
7f5c3b497148fdd8e710131c5ac3f9f0a5f2cddf Drop explict 3 seconds pause between two object updates/deletes. (#1359)
12c899207917751eac719916be69c0078671963d add vlan_intf_object only if there are ipv4 or ipv6 mappings (#1377)
52ce2c32bf4e267d043a739641f5eefba3f3910f Add subcommand description to interfaces counters (#1373)
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan arlakshm@microsoft.com
- Why I did it
This PR has the changes to support having different swss.rec and sairedis.rec for each asic.
The logrotate script is updated as well
- How I did it
Update the orchagent.sh script to use the logfile name options in these PRs(Azure/sonic-swss#1546 and Azure/sonic-sairedis#747)
In multi asic platforms the record files will be different for each asic, with the format swss.asic{x}.rec and sairedis.asic{x}.rec
Update the logrotate script for multiasic platform .
* Fix exception in bgpmon caused by duplicate keys
It is possible that BGP neighbors in IPv4 and IPv6 address families
share the same name (such as bgp monitor). However, such case is not
handled in bgpmon, and an Exception will be raised. This commit will
address the issue by Using set instead of list to avoid duplicate keys.
Following changes were done for ebtables:
- Support for Multi-asic platforms. Ebtable filters are installed in namespace for multi-asic and not host. On Single asic installed on host.
- For Multi-asic platforms we don't want to install on host otherwise Namespace-to-Namespace communication does not happens since ARP Request are not forwarded.
- Updated to use text file to restore ebtables rules then the binary format. Rules are restore as part of Database docker init instead of rc.local
- Removed the ebtable service files for buster as not needed as filters are restored/installed as part of database docker init.
All the binaries are pre-installed with ebtables* binary are same as ebatbles-legacy-*
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Issue: Binary ebtables config file is CPU arch dependent
Fix: Load the text config during firsttime boot and
Generate the binary persistent atomic file
Signed-off-by: Antony Rheneus <arheneus@marvell.com>
when parallel build is enabled, both docker-fpm-frr and docker-syncd-brcm
is built at the same time, docker-fpm-frr requires swss which requires to
install libsaivs-dev. docker-syncd-brcm requires syncd package which requires
to install libsaibcm-dev.
since libsaivs-dev and libsaibcm-dev install the sai header in the same
location, these two packages cannot be installed at the same time. Therefore,
we need to serialize the build between these two packages. Simply uninstall
the conflict package is not enough to solve this issue. The correct solution
is to have one package wait for another package to be uninstalled.
For example, if syncd is built first, then it will install libsaibcm-dev.
Meanwhile, if the swss build job starts and tries to install libsaivs-dev,
it will first try to query if libsaibcm-dev is installed or not. if it is
installed, then it will wait until libsaibcm-dev is uninstalled. After syncd
job is finished, it will uninstall libsaibcm-dev and swss build job will be
unblocked.
To solve this issue, _UNINSTALLS is introduced to uninstall a package that
is no longer needed and to allow blocked job to continue.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
backport c4b5b002c3
make swss build depends only on libsairedis instead of syncd. This allows to build swss without depending
on vendor sai library.
Currently, libsairedis build also buils syncd which requires vendor SAI lib. This makes difficult to build
swss docker in buster while still keeping syncd docker in stretch, as swss requires libsairedis which also
build syncd and requires vendor to provide SAI for buster. As swss docker does not really contain syncd
binary, so it is not necessary to build syncd for swss docker.
[submodule]: update sonic-sairedis
1e42517996bfe41ac58d4c25ee3f93502befcb9d (HEAD -> 201911) [build]: add option to build without syncd
Signed-off-by: Guohan Lu <lguohan@gmail.com>
**- Why I did it**
There is a preference to use thermalctld instead of fancontrol for 201911 release branch. The Arista platform submodule updates and thermal policies in the platforms will allow Arista devices to use thermalctld instead of fancontrol.
**- How I did it**
I cherry-picked the necessary commits from master branch for sonic-platform-modules-arista into 201911 branch. I've also added the file to skip fancontrol and added the thermal policies json.
**- How to verify it**
On Gardena, Upperlake, Clearlake, and Lodoga thermalctld is up and running with no errors. Fans show ~29%.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
In order to prevent "mlxsw_minimal" driver accessing ASIC during in
service firmware upgrade flow, SDK will raise "OFFLINE" 'udev' event
at early beginning of such flow. When this event is received,
hw-managemnet will remove "mlxsw_minimal" driver.
There is no need to implement opposite "ONLINE" event, since this flow
is ended up with "kexec".
Signed-off-by: Kebo Liu <kebol@nvidia.com>
Bugs fixes:
All | Kernel | During system reload when CPU is loaded with heavy traffic, a Kernel Panic may occur.
All | Modules, Port split | FW stuck when device rebooted with locked Optical Transceivers in split mode
Spectrum-3 | PFC | On Spectrum-3 systems, slow reaction time to Rx pause packets on 40GbE ports may lead to buffer overflow on servers.
Spectrum-3 | SN4700, Port Split | On rare occasion SN4700, conducting 100G split (4x25G) in NRZ when splitter port 1 or 2 are down, ports 3 and 4 will also go down.
Enahncments:
All | Kernel | new notification on ISSU start, so other kernel drivers can disable any interface to ASIC
Signed-off-by: Kebo Liu <kebol@nvidia.com>
Recent changes brought l2 vlan concept which do not have DHCP
clients behind them and so DHCP relay is not required. Also,
dhcpmon fails to launch on those vlans as their interfaces
lack IP addresses. This PR limit launch of both DHCP relay
and dhcpmon to L3 vlans only.
singed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
Fix#119
when parallel build is enable, multiple dpkg-buildpackage
instances are running at the same time. /var/lib/dpkg is shared
by all instances and the /var/lib/dpkg/updates could be corrupted
and cause the build failure.
the fix is to use overlay fs to mount separate /var/lib/dpkg
for each dpkg-buildpackage instance so that they are not affecting
each other.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
sonic-slave tag only allows all lower case. In case the user
name is mixed case, we need to change user name to all lower case.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
With the release of pip21.0 (https://pypi.org/project/pip/#history) on branch 201911 stretch build is failing with below error logs:
As per https://pypi.org/project/pip/ pip21.0 does not not support python2 from Jan 2021. To fix this tag the pip to 20.3.3 version which was being used last and is working fine.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
**- Why I did it**
Earlier today we found a bug in the SONiC TSA implementation.
TSC shows incorrect output (see below) in case we have a route-map which contains TSA route-map as a prefix.
```
admin@str-s6100-acs-1:~$ TSC
Traffic Shift Check:
System Mode: Not consistent
```
The reason is that TSC implementation has too loose regexps in TSA utilities, which match wrong route-map entries:
For example, current TSC matches following
```
route-map TO_BGP_PEER_V4 permit 200
route-map TO_BGP_PEER_V6 permit 200
```
But it should match only
```
route-map TO_BGP_PEER_V4 permit 20
route-map TO_BGP_PEER_V4 deny 30
route-map TO_BGP_PEER_V6 permit 20
route-map TO_BGP_PEER_V6 deny 30
```
**- How I did it**
I fixed it by using egrep with `^` and `$` regexp markers which match begin and end of the line.
**- How to verify it**
1. Add follwing entry to FRR config:
```
str-s6100-acs-1#
str-s6100-acs-1# conf t
str-s6100-acs-1(config)# route-map TO_BGP_PEER_V4 permit 200
str-s6100-acs-1(config-route-map)# end
```
2. Use the TSC command and check output. It should show normal.
```
admin@str-s6100-acs-1:~$ TSC
Traffic Shift Check:
System Mode: Normal```
[Submodule update] sonic-utilities
- [db_migrator][201911] Support shared headroom in db_migrator on Mellanox platform (#1261)
- Multi-ASIC support show ip/v6 route additional parameters (#1333)
Signed-off-by: Stephen Sun <stephens@nvidia.com>
To pick up new commits from sonic-linux-kernel repo:
[201911] Backport patches to increase critical threshold for ASIC and validate transceiver temperature 2f173b45da29f3643212d6c9111db321797453ec Azure/sonic-linux-kernel@2f173b4
Signed-off-by: Kebo Liu <kebol@nvidia.com>
b8f0c3a [snmpagent] [201911] Fix hardcoded qsfp lane count by reading sensor status from DB (#183)
**- Why I did it**
Update submodule pointer for snmpagent to include fix for hardcoded qsfp lane count
**- How I did it**
Update snmpagent submodule
**- How to verify it**
Run build.
In scenario where upgrade gets config from minigraph, it could miss tacacs credentials as they are not in minigraph. Hence restore explicitly upon load-minigraph, if present.
- Why I did it
Upon boot, when config migration is required, the switch could load config from minigraph. The config-load from minigraph would wipe off TACACS key and disable login via TACACS, which would disable all remote user access. This change, would re-configure the TACACS if there is a saved copy available.
- How I did it
When config is loaded from minigraph, look for a TACACS credentials back up (tacacs.json) under /etc/sonic/old_config. If present, load the credentials into running config, before config-save is called.
- How to verify it
Remove /etc/sonic/config_db.json and do an image update. Upon reboot, w/o this change, you would not be able ssh in as remote user. You may login as admin and check out, "show tacacs" & "show aaa" to verify that tacacs-key is missing and login is not enabled for tacacs.
With this change applied, remove /etc/sonic/config_db.json, but save tacacs & aaa credentials as tacacs.json in /etc/sonic/. Upon reboot, you should see remote user access possible.
* Use 20 and 30 route-map entries instead of 2 and 3 for TSA
* Added support for dynamic "Allow list" default action.
Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com>
Updating submodule for sonic-swss to get the changes to Azure 201911. The following were the commits that were part of this submodule.
[201911-SWSS]flushing FDB entries per VLAN when deleting VLAN (PR#Azure/sonic-swss#1575) 9519fead3fc63972131de9cb8963a5aeacf7b23d
