Management vrf snmp cli support by vharish02 · Pull Request #472 · sonic-net/sonic-utilities

vharish02 · 2019-02-26T21:51:16Z

CLI commands for configuring few parameters that are required in snmpd.conf.

"snmpd" daemon (snmp agent) shall use this configured IP address and VRF to listen on the particular IP address on that particular VRF.
"snmpd" daemon shall use the configured TRAP IP address and VRF to send the TRAPs to those servers connected in that particular VRF.
Requried back end snmpd patches are already applied in sonic-buildimage to handle this additional "VRF" configuration.

Configuration
root@sonic:# config vrf add mgmt
root@sonic:# config snmpagentaddress add 100.104.45.9 -v mgmt
root@sonic:# config snmptrap modify 3 100.94.212.7 -v mgmt
root@sonic:# cat /etc/sonic/snmp.yml
snmp_rocommunity: public
snmp_location: public
v1_trap_dest: NotConfigured
v2_trap_dest: NotConfigured
v3_trap_dest: 100.94.212.7:162%mgmt public
snmp_agent_address_1: 100.104.45.9%mgmt

root@sonic:~# docker exec -it snmp bash
The file /etc/snmp/snmpd.conf inside snmp docker shows the following configuration which will be used by snmpd daemon.
Following %mgmt will be used by snmpd to listen to the IP 100.104.45.9 in "mgmt" vrf.
agentAddress 100.104.45.9%mgmt

Following %mgmt will be used by snmpd to send traps to the server 100.94.212.7 in "mgmt" vrf.
informsink 100.94.212.7:162%mgmt public

This commit adds CLI support for management VRF using l3dev. mVRF can be enabled using config vrf add mgmt and deleted using config vrf del mgmt. Show commands for management VRF are added which displays the linux command output, will update show command display after concluding what would be the output for the show commands. Added cli to configure management interface(eth0), config interface ip eth0 add can be used to configure eth0 ip and config ip eth0 remove is used to remove eth0 ip. New cli config/show commands: config vrf add mgmt config vrf del mgmt config interface eth0 ip add ip/mask gatewayIP config interface eth0 ip remove ip/mask show mgmt-vrf show mgmt-vrf route show mgmt-vrf addresses show mgmt-vrf interfaces Signed-off-by: Harish Venkatraman <harish_venkatraman@dell.com>

a-barboza · 2019-07-30T01:29:49Z

Are the changes for SNMP CLI described anywhere ?
Can we add additional folks to review ?

kannankvs · 2019-09-11T07:52:36Z

@jleveque : We will resolve conflict for the PR after the main mvrf SNMP PR2608 is merged. Let us wait until then.

kannankvs · 2019-09-11T07:54:04Z

@a-barboza : We will be explaining these CLIs in the CLI reference manual. If you need the same information to be filled in this PR, let us know.

a-barboza · 2019-09-24T22:09:06Z

Why restart NTP ? (These changes are for SNMP ?)
clear_mgmt command: There are some new commands common to all mgmt-vrf ?
MGMT_INTERFACE, MGMT_VRF_CONFIG tables ?
There is a new "--gw" option? Why is this only for eth0 ? Can Front Panel (In-Band) port be part of the mgmt-vrf ?
Is the table Updated natshow script to support DNAT Pool changes #1001 reserved for mgmt-vrf, or is it Table# 1 ?
In snmpagentaddress why is the get_entry() there? Is it a No-OP ?
Is the Curl, Wget, SSH also supported for mgmt-vrf ?
Where is the mgmtvrf_ntpq command ?

kannankvs · 2019-09-25T18:39:56Z

@a-barboza : We shall look into this PR after we merge the PR463. Request you to kindly review the 463 and provide the comments.

kannankvs · 2019-09-25T19:10:58Z

@a-barboza : Reg Q5 "In snmpagentaddress why is the get_entry() there? Is it a No-OP ?",
I assume u meant the following line that is present before set_entry for SNMP_AGENT_ADDRESS_CONFIG.
config_db.get_entry('SNMP_AGENT_ADDRESS_CONFIG', (agentip, vrf))
This No-OP line shall be removed.

kannankvs · 2019-10-09T22:54:43Z

This PR has dependency on PR3586 for handling these config change in the backend. Request you to merge this after the PR3586 is merged.

kannankvs · 2019-10-11T06:11:25Z

Dependent PR3586 is merged. Request the reviewers to review this PR.
One build is failing w.r.t. FRR which is nothing related to this PR. Can it be restarted?

kannankvs · 2019-10-14T05:45:08Z

retest this please

kannankvs · 2019-10-14T18:01:00Z

retest this please

kannankvs · 2019-10-22T19:08:23Z

@jleveque, @prsunny : Now that the code freeze deadline is nearing, can you review this and provide comments?

) #### Why I did it sonic-net/sonic-utilities#472 Added SNMP_AGENT_ADDRESS_CONFIG table in config db. This PR is to add corresponding YANG model for that table. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Added YANG modesl for SNMP_AGENT_ADDRESS_CONFIG. keys: agent_ip, port number, vrf. CLI implementaion checks if agent_ip, port number already exists in CONFIG_DB table, if it does, then new entry is not added. So added another condition to ensure combination of agent_ip and port is unique. Below is an example of how data looks like in DB: ``` 127.0.0.1:6379[4]> HGETALL "SNMP_AGENT_ADDRESS_CONFIG|10.1.1.1|161|foo" 1) "NULL" 2) "NULL" 127.0.0.1:6379[4]> HGETALL "SNMP_AGENT_ADDRESS_CONFIG|10.1.0.32|161|" 1) "NULL" 2) "NULL" ``` #### How to verify it Added unit-test for various combinations and ensures that it passes.

…ic-net#15587) #### Why I did it sonic-net/sonic-utilities#472 Added SNMP_AGENT_ADDRESS_CONFIG table in config db. This PR is to add corresponding YANG model for that table. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Added YANG modesl for SNMP_AGENT_ADDRESS_CONFIG. keys: agent_ip, port number, vrf. CLI implementaion checks if agent_ip, port number already exists in CONFIG_DB table, if it does, then new entry is not added. So added another condition to ensure combination of agent_ip and port is unique. Below is an example of how data looks like in DB: ``` 127.0.0.1:6379[4]> HGETALL "SNMP_AGENT_ADDRESS_CONFIG|10.1.1.1|161|foo" 1) "NULL" 2) "NULL" 127.0.0.1:6379[4]> HGETALL "SNMP_AGENT_ADDRESS_CONFIG|10.1.0.32|161|" 1) "NULL" 2) "NULL" ``` #### How to verify it Added unit-test for various combinations and ensures that it passes.

What is the motivation for this PR? To fix the bug in the test case. How did you do it? Initially as part of the design (sonic-net/sonic-utilities#472) when we configure mgmt-vrf, we are supposed to update the snmpagentaddress as well. However, this was missing as part of this testcase. We have updated a fixture that removes ipv6 address from the DUT and only tests the ipv4 address. There were 2 motivations to introduce the same: 1. Currently the sonic-mgmt script only focuses on ipv4 test scenario. 2. When we update snmpagentaddress, the snmp docker restarts. There is a limit to restart the same upto 3 times in a span of 20min. If we have ipv6 address on eth0, we have to issue snmpagentaddress command 4 times which inturn restart snmp 4 times (2 removals and 2 additions, each for ipv4 and ipv6) and service fails. Updating ipv6 for snmpagentaddress is important because if eth0 has ipv4 and ipv6, and eth0 is over mgmt-vrf, then we need to put both IPs in mgmt-vrf using snmpagentaddress. How did you verify/test it? Executed the testcases. mvrf/test_mgmtvrf.py::TestReboot::test_warmboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_reboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_fastboot PASSED Signed-off-by: sarabjeets <sarabjeets@marvell.com>

…t#19883) What is the motivation for this PR? To fix the bug in the test case. How did you do it? Initially as part of the design (sonic-net/sonic-utilities#472) when we configure mgmt-vrf, we are supposed to update the snmpagentaddress as well. However, this was missing as part of this testcase. We have updated a fixture that removes ipv6 address from the DUT and only tests the ipv4 address. There were 2 motivations to introduce the same: 1. Currently the sonic-mgmt script only focuses on ipv4 test scenario. 2. When we update snmpagentaddress, the snmp docker restarts. There is a limit to restart the same upto 3 times in a span of 20min. If we have ipv6 address on eth0, we have to issue snmpagentaddress command 4 times which inturn restart snmp 4 times (2 removals and 2 additions, each for ipv4 and ipv6) and service fails. Updating ipv6 for snmpagentaddress is important because if eth0 has ipv4 and ipv6, and eth0 is over mgmt-vrf, then we need to put both IPs in mgmt-vrf using snmpagentaddress. How did you verify/test it? Executed the testcases. mvrf/test_mgmtvrf.py::TestReboot::test_warmboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_reboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_fastboot PASSED Signed-off-by: sarabjeets <sarabjeets@marvell.com>

…t#19883) What is the motivation for this PR? To fix the bug in the test case. How did you do it? Initially as part of the design (sonic-net/sonic-utilities#472) when we configure mgmt-vrf, we are supposed to update the snmpagentaddress as well. However, this was missing as part of this testcase. We have updated a fixture that removes ipv6 address from the DUT and only tests the ipv4 address. There were 2 motivations to introduce the same: 1. Currently the sonic-mgmt script only focuses on ipv4 test scenario. 2. When we update snmpagentaddress, the snmp docker restarts. There is a limit to restart the same upto 3 times in a span of 20min. If we have ipv6 address on eth0, we have to issue snmpagentaddress command 4 times which inturn restart snmp 4 times (2 removals and 2 additions, each for ipv4 and ipv6) and service fails. Updating ipv6 for snmpagentaddress is important because if eth0 has ipv4 and ipv6, and eth0 is over mgmt-vrf, then we need to put both IPs in mgmt-vrf using snmpagentaddress. How did you verify/test it? Executed the testcases. mvrf/test_mgmtvrf.py::TestReboot::test_warmboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_reboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_fastboot PASSED Signed-off-by: sarabjeets <sarabjeets@marvell.com> Signed-off-by: mssonicbld <sonicbld@microsoft.com>

…23386) What is the motivation for this PR? To fix the bug in the test case. How did you do it? Initially as part of the design (sonic-net/sonic-utilities#472) when we configure mgmt-vrf, we are supposed to update the snmpagentaddress as well. However, this was missing as part of this testcase. We have updated a fixture that removes ipv6 address from the DUT and only tests the ipv4 address. There were 2 motivations to introduce the same: 1. Currently the sonic-mgmt script only focuses on ipv4 test scenario. 2. When we update snmpagentaddress, the snmp docker restarts. There is a limit to restart the same upto 3 times in a span of 20min. If we have ipv6 address on eth0, we have to issue snmpagentaddress command 4 times which inturn restart snmp 4 times (2 removals and 2 additions, each for ipv4 and ipv6) and service fails. Updating ipv6 for snmpagentaddress is important because if eth0 has ipv4 and ipv6, and eth0 is over mgmt-vrf, then we need to put both IPs in mgmt-vrf using snmpagentaddress. How did you verify/test it? Executed the testcases. mvrf/test_mgmtvrf.py::TestReboot::test_warmboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_reboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_fastboot PASSED Signed-off-by: mssonicbld <sonicbld@microsoft.com> Co-authored-by: Sarabjeet Singh [Marvell] <sarabjeets@marvell.com>

…t#19883) (sonic-net#23386) What is the motivation for this PR? To fix the bug in the test case. How did you do it? Initially as part of the design (sonic-net/sonic-utilities#472) when we configure mgmt-vrf, we are supposed to update the snmpagentaddress as well. However, this was missing as part of this testcase. We have updated a fixture that removes ipv6 address from the DUT and only tests the ipv4 address. There were 2 motivations to introduce the same: 1. Currently the sonic-mgmt script only focuses on ipv4 test scenario. 2. When we update snmpagentaddress, the snmp docker restarts. There is a limit to restart the same upto 3 times in a span of 20min. If we have ipv6 address on eth0, we have to issue snmpagentaddress command 4 times which inturn restart snmp 4 times (2 removals and 2 additions, each for ipv4 and ipv6) and service fails. Updating ipv6 for snmpagentaddress is important because if eth0 has ipv4 and ipv6, and eth0 is over mgmt-vrf, then we need to put both IPs in mgmt-vrf using snmpagentaddress. How did you verify/test it? Executed the testcases. mvrf/test_mgmtvrf.py::TestReboot::test_warmboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_reboot PASSED mvrf/test_mgmtvrf.py::TestReboot::test_fastboot PASSED Signed-off-by: mssonicbld <sonicbld@microsoft.com> Co-authored-by: Sarabjeet Singh [Marvell] <sarabjeets@marvell.com>

vharish02 force-pushed the managementVRF_snmp_cli_support branch from f6071a6 to b5647b9 Compare July 17, 2019 21:59

kannankvs added 2 commits October 9, 2019 14:47

resolved conflict and changed cli syntax

46d0acd

Merge branch 'master' into managementVRF_snmp_cli_support

34eab78

kannankvs closed this Oct 9, 2019

kannankvs reopened this Oct 10, 2019

lguohan approved these changes Oct 29, 2019

View reviewed changes

lguohan merged commit 8218b09 into sonic-net:master Oct 29, 2019

SuvarnaMeenakshi mentioned this pull request Jun 22, 2023

[YANG][SNMP]: Add YANG model for SNMP_AGENT_ADDRESS_CONFIG table sonic-net/sonic-buildimage#15587

Merged

11 tasks

sarabjeetsingh1509 mentioned this pull request Jul 29, 2025

[MVRF] All 3 Test cases under TestReboot class are failing. sonic-net/sonic-mgmt#19883

Merged

12 tasks

mssonicbld mentioned this pull request Mar 27, 2026

[action] [PR:19883] [MVRF] All 3 Test cases under TestReboot class are failing. sonic-net/sonic-mgmt#23386

Merged

12 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Management vrf snmp cli support#472

Management vrf snmp cli support#472
lguohan merged 3 commits intosonic-net:masterfrom
vharish02:managementVRF_snmp_cli_support

vharish02 commented Feb 26, 2019 •

edited by kannankvs

Loading

Uh oh!

a-barboza commented Jul 30, 2019

Uh oh!

kannankvs commented Sep 11, 2019

Uh oh!

kannankvs commented Sep 11, 2019

Uh oh!

a-barboza commented Sep 24, 2019 •

edited

Loading

Uh oh!

kannankvs commented Sep 25, 2019

Uh oh!

kannankvs commented Sep 25, 2019

Uh oh!

kannankvs commented Oct 9, 2019

Uh oh!

kannankvs commented Oct 11, 2019

Uh oh!

kannankvs commented Oct 14, 2019 •

edited

Loading

Uh oh!

kannankvs commented Oct 14, 2019

Uh oh!

kannankvs commented Oct 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

vharish02 commented Feb 26, 2019 • edited by kannankvs Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-barboza commented Jul 30, 2019

Uh oh!

kannankvs commented Sep 11, 2019

Uh oh!

kannankvs commented Sep 11, 2019

Uh oh!

a-barboza commented Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kannankvs commented Sep 25, 2019

Uh oh!

kannankvs commented Sep 25, 2019

Uh oh!

kannankvs commented Oct 9, 2019

Uh oh!

kannankvs commented Oct 11, 2019

Uh oh!

kannankvs commented Oct 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kannankvs commented Oct 14, 2019

Uh oh!

kannankvs commented Oct 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vharish02 commented Feb 26, 2019 •

edited by kannankvs

Loading

a-barboza commented Sep 24, 2019 •

edited

Loading

kannankvs commented Oct 14, 2019 •

edited

Loading