Skip to content

[neighbor_advertiser] Use full vlan name for vxlan tunnel map programming#604

Merged
yxieca merged 1 commit intosonic-net:masterfrom
pavel-shirshov:pavelsh/advertiser_fix
Aug 14, 2019
Merged

[neighbor_advertiser] Use full vlan name for vxlan tunnel map programming#604
yxieca merged 1 commit intosonic-net:masterfrom
pavel-shirshov:pavelsh/advertiser_fix

Conversation

@pavel-shirshov
Copy link
Copy Markdown
Contributor

- What I did

- How I did it
Fixed a bug which caused incorrect programming of vxlan tunnel map.

- How to verify it
Run the script and check that syslog doesn't have any errors.

- Previous command output (if the output of a command-line utility has changed)

- New command output (if the output of a command-line utility has changed)

-->

@pavel-shirshov
Copy link
Copy Markdown
Contributor Author

retest this please

@yxieca yxieca merged commit 53281d0 into sonic-net:master Aug 14, 2019
nazariig pushed a commit to nazariig/sonic-utilities that referenced this pull request May 6, 2025
…om TRANSCEIVER_INFO table (sonic-net#171)

<!--
 Please make sure you've read and understood our contributing guidelines:
 https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

 failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` **

 If this is a bug fix, make sure your description includes "closes #xxxx",
 "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
 issue when the PR is merged.

 If you are adding/modifying/removing any command or utility script, please also
 make sure to add/modify/remove any unit tests from the tests
 directory as appropriate.

 If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
 subcommand, or you are adding a new subcommand, please make sure you also
 update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
 your changes.

 Please provide the following information:
-->

#### What I did
xcvrd will now move the `status` field from the TRANSCEIVER_STATUS table to the TRANSCEIVER_STATUS_SW table. This is being done via the below PRs

[Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table by mihirpat1 · Pull Request sonic-net#1964 · sonic-net/SONiC](sonic-net/SONiC#1964)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request sonic-net#604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

Therefore, the corresponding CLIs that rely on the TRANSCEIVER_STATUS table for retrieving transceiver presence need to be changed.

However, a more robust method to retrieve transceiver presence is by checking if the TRANSCEIVER_INFO table is present. Thus, the relevant code change will be made to address this.

#### How I did it
The CLI handler now looks at the TRANSCEIVER_INFO table to find transceiver presence

#### How to verify it
No change in output when command is executed after putting the change manaully
```
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 unknown True unknown unknown
Ethernet8 unknown True unknown unknown
Ethernet12 unknown True unknown unknown
Ethernet16 unknown True unknown unknown
Ethernet20 unknown True unknown unknown
Ethernet24 unknown True unknown unknown
Ethernet28 unknown True unknown unknown

```

For the case where TRANSCEIVER_INFO table is missing by manually deleteing it for example on Port Ethernet4

```
admin@sonic:~$ redis-cli -n 6 DEL "TRANSCEIVER_INFO|Ethernet4"
(integer) 1
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 standby False standby READY
Ethernet8 standby True standby READY

```
#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)

MSFT ADO - 32337615
stepanblyschak pushed a commit to stepanblyschak/sonic-utilities that referenced this pull request May 20, 2025
…es (sonic-net#176)

<!--
 Please make sure you've read and understood our contributing guidelines:
 https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

 failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` **

 If this is a bug fix, make sure your description includes "closes #xxxx",
 "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
 issue when the PR is merged.

 If you are adding/modifying/removing any command or utility script, please also
 make sure to add/modify/remove any unit tests from the tests
 directory as appropriate.

 If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
 subcommand, or you are adding a new subcommand, please make sure you also
 update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
 your changes.

 Please provide the following information:
-->

#### What I did
1. With the recent transceiver DOM and STATUS table related changes, the handles of the following CLIs need to be modified to ensure that the CLI function inline to the existing behavior
 1. show int transceiver eeprom -d
 2. show int transceiver status
 3. show int transceiver pm
 4. sfputil show eeprom -d -p EthernetXX

2. Also, all the diagnostics related tables will not be present only for the first subport for breakout ports. Hence, made the corresponding CLI handler related changes to support this
3. Modified the `sfputil show error-status` CLI handler to use `TRANSCEIVER_STATUS_SW` instead of `TRANSCEIVER_STATUS` table

#### How I did it
1. Replaced function call for get_transceiver_bulk_status with get_transceiver_dom_real_value
5. As part of displaying o/p for "show int transceiver status" CLI, we are now fetching data from TRANSCEIVER_DOM_FLAG, VDM flag tables and TRANSCEIVER_STATUS_FLAG tables as well since the relevant fields have been moved to these new tables
6. As part of display o/p for "show int transceiver pm" CLI, we are now fetching data from VDM threshold tables as well since the relevant fields have been moved to these new tables

Related PRs
sonic-net/SONiC#1954
[[cmis] Separate Flag-Specific Fields for DOM and Status APIs by mihirpat1 · Pull Request sonic-net#556 · sonic-net/sonic-platform-common](sonic-net/sonic-platform-common#556)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request sonic-net#604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

#### How to verify it
Following tests were attempted and confirmed to pass

1. Diagnostic table related verification
	1. Compare tables with nightly image and ensure non-CMIS transceivers do not change their mapping for DOM and status tables
	2. Compare DOM sensor, threshold and status tables between current and nightly. Ensure units are not shown
	3. Dump TRANSCEIVER_INFO table for CMIS transceiver to ensure is_replaceable field is present
2. CLI verification
	1. sudo sfputil show error-status - This should dump output for all the ports and the behavior should not change between nightly and private image
	2. Use invalid port name (Ethernet2033) to dump show int transceiver info, status CLI. Ensure to note new errors in PR description for invalid ports
	3. For breakout scenario, keep 2 subports in different CMIS_STATES and ensure the CLI o/p is different for status CLI for both subports
3. Run transceiver onboarding test due to TRANSCEIVER_INFO table deletion change
4. XCVRD stop/start
	1. Stop xcvrd and ensure all diagnostic tables are deleted
	2. Start xcvrd and ensure all diagnostic tables are populated
5. Link flap event handling
	1. Change link flap count for different types of transceivers and ensure no crash is seen. This is to ensure that the link event handler code does not cause any crash for non-CMIS transceivers
	2. Shutdown peer port and ensure the tables get updated which are handled via link event update handler.
		Also, execute sfputil reset on 10 different physical ports and ensure that all the corresponding flags on the remote side are updated for all 8 lanes of a DR8 optic
		Specifically, we need to ensure that the following flags are set wherein X represents the lane number
		1. LOSFlagRxX (page 11, byte 147)
		2. CDRLOLFlagRxX (page 11, byte 148)
		3. OpticalPowerLowAlarmFlagRxX (page 11, byte 150)
		4. OpticalPowerLowWarningFlagRxX (page 11, byte 152)
6. Transceiver OIR test
	1. Remove transceiver and ensure all diagnostic related tables are deleted
	2. Insert transceiver and ensure all diagnostic tables are populated
	3. Stop xcvrd and remove transceiver and ensure TRANSCEIVER_INFO table is present. Start xcvrd and ensure that the TRANSCEIVER_INFO table is now deleted
	4. Insert the transceiver now
7. Ensure firmware upgrade is successfull and TRANSCEIVER_FIRMWARE_INFO table changes only for the primary subport eventhough, the upgrade was triggered for a non-primary subport
8. Ensure SFF manager crash is seen with nightly and is resolved with this PR (since the PR has the fix for [SffLoggerForPortUpdateEvent class does not have log_debug function · Issue sonic-net#605 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#605))

#### Previous command output (if the output of a command-line utility has changed)
The output of show int transceiver info and show int transceiver eeprom will change if an invalid port name is passed to the CLI

```
root@str4-sn5600-3:/home/admin# show int transceiver info Ethernet8
Ethernet8: SFP EEPROM Not detected
root@str4-sn5600-3:/home/admin#
```

#### New command output (if the output of a command-line utility has changed)
```
root@str4-sn5600-3:/home/admin# show int transceiver info Ethernet8
Error: Found KeyError while getting first subport for Ethernet8
Error: Unable to get first subport for Ethernet8 while converting SFP info
Ethernet8: SFP EEPROM Not detected
root@str4-sn5600-3:/home/admin#
```
MSFT ADO - 32238285
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants