Skip to content

[TACACS+]: Add config command for TACACS+ source address#171

Open
liuqu wants to merge 1 commit intosonic-net:masterfrom
liuqu:feature/tacacs+_src_ip
Open

[TACACS+]: Add config command for TACACS+ source address#171
liuqu wants to merge 1 commit intosonic-net:masterfrom
liuqu:feature/tacacs+_src_ip

Conversation

@liuqu
Copy link
Copy Markdown

@liuqu liuqu commented Dec 14, 2017

- What I did

  • Add config command for TACACS+ source address

- How to verify it

  • Check "TACPLUS|global" table in configDB
127.0.0.1:6379[4]> hgetall TACPLUS|global
1) "src_ip"
2) "100.1.1.1"

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

# config tacacs src_ip 100.1.1.1    
# show tacacs
TACPLUS global auth_type pap (default)
TACPLUS global src_ip 100.1.1.1
TACPLUS global timeout 3
TACPLUS global passkey test123

TACPLUS_SERVER address 10.65.254.222
               priority 1
               tcp_port 49

-->

* Add config command to specify TACACS+ source address
  command: config tacacs src_ip <ip_address>

  Signed-off-by: Chenchen Qi <chenchen.qcc@alibaba-inc.com>
vdahiya12 added a commit to vdahiya12/sonic-utilities that referenced this pull request Jul 23, 2021
…dors (sonic-net#171)

This PR refactors the firmware information MUX_CABLE_INFO output to return the following fields for each target.

{
"version_active": "",
"version_inactive": "",
"version_next": "",
}
So by calling this for all the 3 MCU's TOR1, TOR2 and NIC we can get the below result.
which would be stored in state db table MUX_CABLE_INFO

{
"version_nic_active": "0.6MS",
"version_nic_inactive": "0.5MS",
"version_nic_next": "0.6MS",
"version_self_active": "0.5MS",
"version_self_inactive": "0.6MS",
"version_self_next": "0.6MS",
"version_peer_active": "0.6MS",
"version_peer_inactive": "0.6MS",
"version_peer_next": "0.6MS",
} 

Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
mihirpat1 pushed a commit to mihirpat1/sonic-utilities that referenced this pull request Sep 15, 2023
… split the get_part_number and get_vendor API's (sonic-net#171)

This PR adds a stub function definition with details as to how it should be implemented by a Y cable vendor.

Description
Added a stub function definition with a doc string describing how it should be implemented
Cleaning up and split some API's for vendors

Motivation and Context
Firmware upgrade is a functionality that vendors need to implement, this PR adds the definition
and a description of how the implementation of this firmware_upgrade API should be

How Has This Been Tested?
Will be tested once implemented
for cleanup API's opened a python shell and executed API's for correctness

Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
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
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.

2 participants