Code Monkey home page Code Monkey logo

sonic-snmpagent's Introduction

Total alerts Language grade: Python

SNMP Subagent

AgentX implementation for SONiC Switch State Service. See the SONiC website for more information on the SONiC project.

MIB implementations included:

To install:

$ python3.5 setup.py install

To run the daemon:

$ python3.5 -m sonic_ax_impl [-d 10]

To switch log level of already running snmp-subagent process

1.) Find PID of the process.

root 42 1 12 06:37 ? 01:23:46 python3.6 -m sonic_ax_impl

2.) Send SIGUSR1 signal to Process

root@lnos-x1-a-csw04:/# kill -SIGUSR1 42

Sending SIGUSR1 signal to process again will reset the log level.

sonic-snmpagent's People

Contributors

abdosi avatar anilkpandey avatar bingwang-ms avatar chenkelly avatar dplore avatar jleveque avatar joyas-joseph avatar junchao-mellanox avatar keboliu avatar lguohan avatar liorghub avatar liuh-80 avatar liushilongbuaa avatar mad4321 avatar michelmoriniaux avatar mykolaf avatar oleksandrivantsiv avatar pavel-shirshov avatar pettershao-ragilenetworks avatar prsunny avatar qiluo-msft avatar raphaelt-nvidia avatar samaity avatar stepanblyschak avatar sumukhatv avatar suvarnameenakshi avatar vivekrnv avatar ysmanman avatar yxieca avatar zhenggen-xu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sonic-snmpagent's Issues

AttributeError: 'NoneType' object has no attribute 'decode'

In the latest master image, the newly pulled in commit: #72 will cause issue when the information cannot be retrieved from the database.

Aug 9 23:29:26.815914 SONiC ERR snmp/snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#012 File "/usr/local/lib/python3.6/dist-packages/ax_interface/mib.py", line 40, in start#012 self.reinit_data()#012 File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ieee802_1ab.py", line 270, in reinit_data#012 b'lldp_loc_man_addr').decode('utf-8')#012AttributeError: 'NoneType' object has no attribute 'decode'

Add a test case for LLDP_LOC_CHASSIS.lldp_loc_man_addr has only one IPv6 address

Add a test case for LLDP_LOC_CHASSIS.lldp_loc_man_addr has only one IPv6 address.
This is a follow up issue for #164

Description

Steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

UnavailableDataError for Key "COUNTERS_PORT_NAME_MAP" in COUNTERS_DB

Aug 31 20:27:22.308214 switch75 ALERT pmon/sensord: Sensor alarm: Chip max1617a-i2c-40-2a: ASIC: -5.0 C (min = -5.0 C, max = -5.0 C) [ALARM]
Aug 31 20:27:44.565279 switch75 ERR snmp/snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#12 File "/usr/local/lib/python3.6/dist-packages/ax_interface/mib.py", line 40, in start#012 self.reinit_data()#12 File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/vendor/cisco/ciscoPfcExtMIB.py", line 38, in reinit_data#012 self.oid_name_map = mibs.init_sync_d_interface_tables(self.db_conn)#12 File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/init.py", line 88, in init_sync_d_interface_tables#012 if_name_map, if_id_map = port_util.get_interface_oid_map(db_conn)#12 File "/usr/local/lib/python3.6/dist-packages/swsssdk/port_util.py", line 40, in get_interface_oid_map#012 if_name_map = db.get_all('COUNTERS_DB', 'COUNTERS_PORT_NAME_MAP', blocking=True)#12 File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 38, in wrapped#012 ret_data = f(inst, db_name, *args, **kwargs)#12 File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 310, in get_all#012 raise UnavailableDataError(message, _hash)#012swsssdk.exceptions.UnavailableDataError: Key 'COUNTERS_PORT_NAME_MAP' unavailable in database 'COUNTERS_DB'

restart or stopping the snmp-agent generates call traceback with syslog ERROR

Description

Steps to reproduce the issue:

  1. docker exec snmp supervisorctl stop snmp-agent or docker exec snmp supervisorctl restartsnmp-agent

Describe the results you received:
Got python traceback error with syslog ERR.

Dec 18 12:54:16.079672 str-msn2700-01 INFO snmp#snmp-subagent [sonic_ax_impl] INFO: Recieved 'SIGTERM' signal, shutting down...
Dec 18 12:54:16.080600 str-msn2700-01 INFO snmp#snmp-subagent [ax_interface] INFO: AgentX socket connection closed.
Dec 18 12:54:16.081329 str-msn2700-01 INFO snmp#snmp-subagent [ax_interface] INFO: Run disabled. Connection loop stopping...
Dec 18 12:54:16.087179 str-msn2700-01 ERR snmp#snmp-subagent [sonic_ax_impl] ERROR: Uncaught exception in sonic_ax_impl.main
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/main.py", line 70, in main
    event_loop.run_until_complete(agent.run_in_event_loop())
  File "/usr/lib/python3.6/asyncio/base_events.py", line 466, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.6/dist-packages/ax_interface/agent.py", line 49, in run_in_event_loop
    await asyncio.wait_for(background_task, BACKGROUND_WAIT_TIMEOUT, loop=self.loop)
  File "/usr/lib/python3.6/asyncio/tasks.py", line 352, in wait_for
    return fut.result()
AttributeError: '_asyncio.Task' object has no attribute 'send'
Dec 18 12:54:20.016122 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:16,078 INFO waiting for snmp-subagent to stop
Dec 18 12:54:20.016548 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:18,078 INFO waiting for snmp-subagent to stop
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:20,079 INFO waiting for snmp-subagent to stop
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:22,079 INFO waiting for snmp-subagent to stop
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:24,079 INFO waiting for snmp-subagent to stop
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:26,078 WARN killing 'snmp-subagent' (76) with SIGKILL
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:26,079 INFO waiting for snmp-subagent to stop
Dec 18 12:54:30.032563 str-msn2700-01 INFO snmp#supervisord 2016-12-18 12:54:26,083 INFO stopped: snmp-subagent (terminated by SIGKILL)

Describe the results you expected:
No traceback message and syslog ERR logs expected

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**
SONiC Software Version: SONiC.HEAD.7-c9275173
Distribution: Debian 9.9
Kernel: 4.9.0-8-2-amd64
Build commit: c9275173
Build date: Sat Jun 15 09:57:18 UTC 2019
Built by: johnar@jenkins-worker-4

Platform: x86_64-accton_as7712_32x-r0
HwSKU: Accton-AS7712-32X
ASIC: broadcom
Serial Number: 771232X1633006
Uptime: 12:21:07 up  3:18,  3 users,  load average: 0.35, 0.33, 0.39

Docker images:
REPOSITORY                 TAG                 IMAGE ID            SIZE
docker-syncd-brcm          HEAD.7-c9275173     dcd654ca4343        392MB
docker-syncd-brcm          latest              dcd654ca4343        392MB
docker-lldp-sv2            HEAD.7-c9275173     e1b3912e86f8        299MB
docker-lldp-sv2            latest              e1b3912e86f8        299MB
docker-dhcp-relay          HEAD.7-c9275173     49d9c70412da        288MB
docker-dhcp-relay          latest              49d9c70412da        288MB
docker-database            HEAD.7-c9275173     d764ed141abf        280MB
docker-database            latest              d764ed141abf        280MB
docker-snmp-sv2            HEAD.7-c9275173     137d0904759d        313MB
docker-snmp-sv2            latest              137d0904759d        313MB
docker-orchagent           HEAD.7-c9275173     61ff16fd4581        319MB
docker-orchagent           latest              61ff16fd4581        319MB
docker-teamd               HEAD.7-c9275173     a3b32b85f53a        301MB
docker-teamd               latest              a3b32b85f53a        301MB
docker-sonic-telemetry     HEAD.7-c9275173     69fc95f17751        302MB
docker-sonic-telemetry     latest              69fc95f17751        302MB
docker-router-advertiser   HEAD.7-c9275173     3fb74e2b862b        280MB
docker-router-advertiser   latest              3fb74e2b862b        280MB
docker-platform-monitor    HEAD.7-c9275173     1b6410dd4202        326MB
docker-platform-monitor    latest              1b6410dd4202        326MB
docker-fpm-frr             HEAD.7-c9275173     4187e87f0e00        309MB
docker-fpm-frr             latest              4187e87f0e00        309MB
docker-ptf                 latest              00938f526d99        628MB
**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

lldpRemTable not exposed until snmp container is restarted.

Description

lldpRemTable not exposed until snmp container is restarted.

Environment
SONiC Software Version: SONiC.criteo.0-ecb63b1 - HwSku: Arista-7060CX-32S-C32 - Distribution: Debian 9.6 - Kernel: 4.9.0-7-amd64

Steps to reproduce the issue:

  1. compile using sonic-net/sonic-buildimage@465ebba (201807 as well).
  2. try to snmpwalk and search for OIDs in 1.0.8802, should fail.
  3. restart SNMP container: docker restart snmp
  4. redo snmpwalk, should get results for OIDs in 1.0.8802

Describe the results you expected:

Getting lldpRemTable contents right after boot.

Explanation

I think there's an issue in poll_lldp_entry_updates in some way when the entry are not available from the start.

But I noticed that this container start is delayed due to https://github.com/Azure/sonic-buildimage/blob/d57bef55dbb584352c05e7d0bdb2cea215a537a9/files/build_templates/snmp.timer#L5, so it should definitely be ready.
Got these logs BEFORE the first restart which probably explain the behavior:

Nov 22 14:09:41.683104 sp01 WARNING snmp#snmp-subagent [sonic_ax_impl] WARNING: Invalid interface name in *' in APP_DB, skipping
Nov 22 14:09:48.879592 sp01 WARNING snmp#snmp-subagent [sonic_ax_impl] WARNING: Invalid interface name in TRANSCEIVER_INFO|*                      in STATE_DB, skipping

sonic-py-swsssdk seems involved here, will try to dig a bit more later.

"Dynamic Update" Implementation / Performance

#3 implemented dynamic updates, but I feel the implementation fractures responsibility of OID lookups and may inhibit performance. This issue is entirely based in opinion.

  • The LUT should be the only entity required to get/get-next OID. MIBUpdaters should not overlap functionally with the LUT/MIBTable. MIBUpdaters should only specify the callable object for a given sub-id. E.g. 1.1.2.2 where 2.2 is the sub-id. 1.1 is the prefix.

  • The desired complexity for OID lookups (gets) should be O(1) and get-next calls should be at most O(n). See https://wiki.python.org/moin/TimeComplexity. To get to O(1)/O(n), the MIBTable has to include all OIDs statically.

While dynamic updates were not originally considered in the first release, some simple interfaces can be implemented that will allow MIBUpdater instances to "write-back" to the LUT. Under this new paradigm, MIBUpdaters will update database table copies and instruct the LUT to add/remove OID entries. The new flow require implementing MIBUpdater to incorporate a "table update" and include a reference to the MIBTable during the updater start-up process.

class MIBUpdater:
    # ...
    async def start(self, mib_table):
        # Run the update while we are allowed
        while self.run_event.is_set():
            # run the background update task
            self.update_data()
            # (optionally) compute the update
           try:
               add_remove = self.update_table()
           except NotImplementedError:
               logger.debug("No 'table_update' impl for {}".format(self.__class__.__name__))
           else:
               # update the table
               add, remove = add_remove
               mib_table.remove_oids(remove)
               mib_table.add_oids(add, self)

            # wait based on our update frequency before executing again.
            # randomize to avoid concurrent update storms.
            await asyncio.sleep(self.frequency + random.randint(-2, 2))

    def update_table(self):
      # subclasses must optionally implement this
      raise NotImplementedError()
class MIBTable:

   # ...
   def remove_oids(self, removed_oids):
      for oid in rm:
         self.pop(oid)

   def add_oids(self, additions, mib_updater_inst):
       for oid in additions:
          self[oid] = mib_updater_inst

The above places responsibility on MIBUpdaters to keep copies of their OID ranges, so some basic set logic is required when computing the (add, remove) sets. Something similar to:

old_oids = {(1,1,1,1), (1,1,1,2)}

new_oids = {(1,1,1,1), (1,1,1,3)}

remove = old_oids - new_oids
# limit the number of additions to optimize table updates.
add = new_oids - old_oids

*An important note: MIBUpdater implementations should return None if a lookup fails, this communicates back to the MIBTable.get_next() functions that no data is available and to continue searching down the sorted LUT. This contractual agreement avoids a locking semaphore for MIBTable read/writes. try/except KeyError and return None should be sufficient.

Using the above interface, many of the changes added in #3 can be reverted that touched the ax_interface.mib and eliminate the need to slice the trailing decimals in a dynamic subtree.

RIF SAI ID key unavailable error in COUNTERS_DB

Description

Steps to reproduce the issue:

  1. Load later master image(.345) , with SNMP docker build off of SNMP master branch code compiled using sonic-py-swsssdk from master branch.
  2. Once SNMP service comes up, view syslog to look for snmp error.

Describe the results you received:

syslog has error message:
raise UnavailableDataError(message, _hash)#012swsssdk.exceptions.UnavailableDataError: Key 'b'COUNTERS:oid:0x60000000005a1'' unavailable in database '2'

The counters DB does not have counter for any of the RIF SAI IDs

Seen after #133

Describe the results you expected:
The unavailable data error should not be visible.

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

[201811] build failure due to psutil version change, 5.7.0 is fine, higher version causes failure

we need fix psutil version, looks 201811 branch uses python3.4, on master branch it is python3.6, then higher psutil version 5.7.1 is fine

Installed /sonic/src/sonic-snmpagent/python_arptable-0.0.2-py3.4.egg
Searching for psutil>=4.0
Reading https://pypi.python.org/simple/psutil/
Best match: psutil 5.7.1
Downloading https://files.pythonhosted.org/packages/2c/5c/cb95a715fb635e1ca858ffb8c50a523a16e2dc06aa3e207ab73cb93516af/psutil-5.7.1.tar.gz#sha256=4ef6845b35e152e6937d4f28388c2440ca89a0089ced0a30a116fa3ceefdfa3a
Processing psutil-5.7.1.tar.gz
Writing /tmp/easy_install-k41w49qa/psutil-5.7.1/setup.cfg
Running psutil-5.7.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-k41w49qa/psutil-5.7.1/egg-dist-tmp-eaxqyor5
/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'python_requires'
warnings.warn(msg)
error: Setup script exited with error in psutil setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
[ FAIL LOG END ] [ target/python-wheels/asyncsnmp-2.1.0-py3-none-any.whl ]
make: *** [target/python-wheels/asyncsnmp-2.1.0-py3-none-any.whl] Error 1
slave.mk:402: recipe for target 'target/python-wheels/asyncsnmp-2.1.0-py3-none-any.whl' failed
Makefile.work:131: recipe for target 'target/sonic-broadcom.bin' failed
make[1]: *** [target/sonic-broadcom.bin] Error 2
make[1]: Leaving directory '/data/johnar/workspace/broadcom/buildimage-brcm-201811'
Makefile:6: recipe for target 'target/sonic-broadcom.bin' failed
make: *** [target/sonic-broadcom.bin] Error 2
+++ --- Making target/sonic-aboot-broadcom.swi --- +++
BLDENV=stretch make -f Makefile.work stretch
make[1]: Entering directory '/data/johnar/workspace/broadcom/buildimage-brcm-201811'
SONiC Build System

Add unit-test to check if interface MIB includes IB and Rec ports

Description

Steps to reproduce the issue:
#244 adds Recirc port support.
Basic unit test is added in the PR. This issue is created to ensure that unit test similar to https://github.com/Azure/sonic-snmpagent/blob/master/tests/namespace/test_interfaces.py#L243 is added for Ethernet-IB and Rec ports.

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

ipCidrRouteTable snmp walk fails

Description

SNMP walk for OID 1.3.6.1.2.1.4.24.4 fails to provide any info

Steps to reproduce the issue:

  1. Bring up Sonic VS T1 topology
  2. Make sure BGP neighborship is established and routes are populated
  3. Trigger SNMP walk : snmpwalk -v 2c -c public 1.3.6.1.2.1.4.24.4

Describe the results you received:
vxr@ubuntu:~$ snmpwalk -v 2c -c public 10.250.0.105 1.3.6.1.2.1.4.24.4
iso.3.6.1.2.1.4.24.4 = No Such Object available on this agent at this OID

Describe the results you expected:

IP routing entries

Additional information you deem important (e.g. issue happens only occasionally):

Looking at rfc4292.py:RouteUpdater:update_data, it seems like we skip all IP addresses that are not 0.0.0.0/0. Is that intentional?

**Output of `show version`:**

root@vlab-03:/home/admin# show ver

SONiC Software Version: SONiC.master.565-e0781f46
Distribution: Debian 10.6
Kernel: 4.19.0-9-2-amd64
Build commit: e0781f4
Build date: Mon Nov 23 08:32:04 UTC 2020
Built by: johnar@jenkins-worker-12

Platform: x86_64-kvm_x86_64-r0
HwSKU: Force10-S6000
ASIC: vs
Serial Number: 000000
Uptime: 02:40:04 up 1:41, 1 user, load average: 1.07, 0.65, 0.70

Docker images:
REPOSITORY TAG IMAGE ID SIZE
docker-gbsyncd-vs latest fc2bcaf7dc91 447MB
docker-gbsyncd-vs master.565-e0781f46 fc2bcaf7dc91 447MB
docker-syncd-vs latest a599f4b6a7c9 447MB
docker-syncd-vs master.565-e0781f46 a599f4b6a7c9 447MB
docker-snmp latest 72953533ec0e 477MB
docker-snmp master.565-e0781f46 72953533ec0e 477MB
docker-teamd latest 0392627a102f 483MB
docker-teamd master.565-e0781f46 0392627a102f 483MB
docker-nat latest 61210a29630f 486MB
docker-nat master.565-e0781f46 61210a29630f 486MB
docker-router-advertiser latest dcc0e15c5463 441MB
docker-router-advertiser master.565-e0781f46 dcc0e15c5463 441MB
docker-platform-monitor latest 053ce63c0b8f 563MB
docker-platform-monitor master.565-e0781f46 053ce63c0b8f 563MB
docker-lldp latest c68597acb666 514MB
docker-lldp master.565-e0781f46 c68597acb666 514MB
docker-dhcp-relay latest badb3fb27c4e 448MB
docker-dhcp-relay master.565-e0781f46 badb3fb27c4e 448MB
docker-database latest d92f5b4cb6e0 441MB
docker-database master.565-e0781f46 d92f5b4cb6e0 441MB
docker-orchagent latest d9c215c333d9 497MB
docker-orchagent master.565-e0781f46 d9c215c333d9 497MB
docker-sonic-telemetry latest 26941527084a 511MB
docker-sonic-telemetry master.565-e0781f46 26941527084a 511MB
docker-sonic-mgmt-framework latest d92d56dac3a5 598MB
docker-sonic-mgmt-framework master.565-e0781f46 d92d56dac3a5 598MB
docker-fpm-frr latest 6c139d86ef63 500MB
docker-fpm-frr master.565-e0781f46 6c139d86ef63 500MB
docker-sflow latest 883128578286 484MB
docker-sflow master.565-e0781f46 883128578286 484MB

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

accton_as5712_54x: LLDP_MIB: DUT can't get lldpLocManAddr mib node

Description:
DUT can't get lldpLocManAddr mib node

Steps to reproduce the issue:

  1. Ethernet0 connected to Ethernet1
  2. Set ifconfig eth0 192.168.1.100
  3. The snmp server ip is 192.168.1.1
    To snmpwalk OID 1.0.8802.1.1.2.1.3.8 (The lldpLocManAddrTable), will get failed.

    snmpwalk -v2c -c public 192.168.1.100 1.0.8802.1.1.2.1.3.8
    iso.0.8802.1.1.2.1.3.8 = No Such Object available on this agent at this OID

Describe the results you received:
root@sonic:~# cat /var/log/syslog | grep snmp
Nov 3 21:07:42.780269 sonic ERR snmp#snmp-subagent [sonic_ax_impl] ERROR: Invalid local mgmt IP [u'240.127.1.1', u'fe80::ce37:abff:feec:de9c']

Describe the results you expected:
Get OID 1.0.8802.1.1.2.1.3.8 (The lldpLocManAddrTable) successfully

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

root@sonic:~# show ver
SONiC Software Version: SONiC.HEAD.7-602204f
Distribution: Debian 9.6
Kernel: 4.9.0-8-amd64
Build commit: 602204f
Build date: Sat Jan  5 01:23:05 UTC 2019
Built by: johnar@jenkins-worker-3

Docker images:
REPOSITORY                 TAG                 IMAGE ID            SIZE
docker-syncd-brcm          HEAD.7-602204f      be57a1558d80        358.4 MB
docker-syncd-brcm          latest              be57a1558d80        358.4 MB
docker-orchagent-brcm      HEAD.7-602204f      bb729a001791        282.9 MB
docker-orchagent-brcm      latest              bb729a001791        282.9 MB
docker-lldp-sv2            HEAD.7-602204f      363a50215190        271.2 MB
docker-lldp-sv2            latest              363a50215190        271.2 MB
docker-dhcp-relay          HEAD.7-602204f      dd7e83defa90        253.4 MB
docker-dhcp-relay          latest              dd7e83defa90        253.4 MB
docker-database            HEAD.7-602204f      6c76cdfd03e6        252 MB
docker-database            latest              6c76cdfd03e6        252 MB
docker-teamd               HEAD.7-602204f      b82ebbd1dd61        271.2 MB
docker-teamd               latest              b82ebbd1dd61        271.2 MB
docker-snmp-sv2            HEAD.7-602204f      facd7006c6be        290.9 MB
docker-snmp-sv2            latest              facd7006c6be        290.9 MB
docker-router-advertiser   HEAD.7-602204f      5e6311294ad9        249.7 MB
docker-router-advertiser   latest              5e6311294ad9        249.7 MB
docker-platform-monitor    HEAD.7-602204f      fa9b910f633b        283.6 MB
docker-platform-monitor    latest              fa9b910f633b        283.6 MB
docker-fpm-quagga          HEAD.7-602204f      26e65c8e83b7        278 MB
docker-fpm-quagga          latest              26e65c8e83b7        278 MB

**Attach debug file `sudo generate_dump`:**
[sonic_dump_sonic_20161103_211216.tar.gz](https://github.com/Azure/sonic-snmpagent/files/3072852/sonic_dump_sonic_20161103_211216.tar.gz)

**other info:**
   To check redis database.
root@sonic:~# redis-cli
127.0.0.1:6379> select 0
OK
127.0.0.1:6379> keys LLDP_LOC_CHASSIS
1) "LLDP_LOC_CHASSIS"
127.0.0.1:6379> hgetall "LLDP_LOC_CHASSIS"
 1) "lldp_loc_sys_cap_enabled"
 2) "28 00"
 3) "lldp_loc_chassis_id"
 4) "cc:37:ab:ec:de:9c"
 5) "lldp_loc_sys_desc"
 6) "Debian GNU/Linux 8 (jessie) Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2015-12-19) x86_64"
 7) "lldp_loc_sys_cap_supported"
 8) "28 00"
 9) "lldp_loc_chassis_id_subtype"
10) "4"
11) "lldp_loc_sys_name"
12) "sonic"
13) "lldp_loc_man_addr"
14) "[u'240.127.1.1', u'fe80::ce37:abff:feec:de9c']"
127.0.0.1:6379>

root@sonic:~# show lldp table
Capability codes: (R) Router, (B) Bridge, (O) Other
LocalPort    RemoteDevice    RemotePortID    Capability    RemotePortDescr
-----------  --------------  --------------  ------------  -----------------
Ethernet0    sonic           Ethernet26      BR
Ethernet1    sonic           Ethernet26      BR
--------------------------------------------------
Total entries displayed:  2
root@sonic:~# show lldp neighbors
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    Ethernet0, via: LLDP, RID: 1, Time: 0 day, 00:01:41
  Chassis:
	ChassisID:    mac cc:37:ab:ec:de:9c
	SysName:      sonic
	SysDescr:     Debian GNU/Linux 8 (jessie) Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2015-12-19) x86_64
	TTL:          120
	MgmtIP:       240.127.1.1
	MgmtIP:       fe80::ce37:abff:feec:de9c
	Capability:   Bridge, on
	Capability:   Router, on
	Capability:   Wlan, off
	Capability:   Station, off
  Port:
	PortID:       local Ethernet26
	PortDescr:
-------------------------------------------------------------------------------
Interface:    Ethernet1, via: LLDP, RID: 1, Time: 0 day, 00:01:41
  Chassis:
	ChassisID:    mac cc:37:ab:ec:de:9c
	SysName:      sonic
	SysDescr:     Debian GNU/Linux 8 (jessie) Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2015-12-19) x86_64
	TTL:          120
	MgmtIP:       240.127.1.1
	MgmtIP:       fe80::ce37:abff:feec:de9c
	Capability:   Bridge, on
	Capability:   Router, on
	Capability:   Wlan, off
	Capability:   Station, off
  Port:
	PortID:       local Ethernet26
	PortDescr:
-------------------------------------------------------------------------------

Value mismatch for ipAddressIfIndex?

Description
I am a bit confused about how we get information for 1.3.6.1.2.1.4.34.1.3 i.e. ipAddressIfIndex oid which connects the interface with it's assigned IP address. I can see we dont have support for this oid in snmpagent. But I see tha values for this oid. I am guessing it's taking value from snmpd function i.e. ipAddressIfIndex_get

Describe the results you received:

admin@lnos-x1-a-csw07:~$ docker exec -it snmp bash
root@lnos-x1-a-csw07:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 21:20 ?        00:00:01 /usr/bin/python /usr/bin/supervisord
root        24     1  0 21:20 ?        00:00:00 /usr/sbin/rsyslogd -n
Debian-+    34     1  0 21:20 ?        00:00:01 /usr/sbin/snmpd -f -LS4d -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf ifTable ifXTable inetCidrRouteTable ipCidr
root        42     1 12 21:20 ?        00:12:11 python3.6 -m sonic_ax_impl
root        49     0  1 22:56 ?        00:00:00 bash
root        55    49  0 22:56 ?        00:00:00 ps -ef
root@lnos-x1-a-csw07:/# gdb

(gdb) attach 34
Attaching to process 34

(gdb) b ipAddressIfIndex_get
Breakpoint 1 at 0x7f4b22739310: file ip-mib/ipAddressTable/ipAddressTable.c, line 504.

(gdb) b ip-mib/ipAddressTable/ipAddressTable.c:506
Breakpoint 2 at 0x7f4b2273931c: file ip-mib/ipAddressTable/ipAddressTable.c, line 506.

(gdb) b ip-mib/ipAddressTable/ipAddressTable.c:509
Breakpoint 3 at 0x7f4b22739325: file ip-mib/ipAddressTable/ipAddressTable.c, line 509.

(gdb) b ip-mib/ipAddressTable/ipAddressTable.c:512
Breakpoint 4 at 0x7f4b2273932e: file ip-mib/ipAddressTable/ipAddressTable.c, line 512.

(gdb) b ip-mib/ipAddressTable/ipAddressTable.c:518
Breakpoint 5 at 0x7f4b22739337: file ip-mib/ipAddressTable/ipAddressTable.c, line 518.

**After setting breakpoint, I ran snmpwalk for this oid**
(gdb) run -f -Lo
Starting program: /usr/sbin/snmpd -f -Lo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Turning on AgentX master support.
NET-SNMP version 5.7.3
Connection from UDP: [127.0.0.1]:41687->[127.0.0.1]:161

Breakpoint 1, ipAddressIfIndex_get (rowreq_ctx=rowreq_ctx@entry=0x70e860, ipAddressIfIndex_val_ptr=0x776f70) at ip-mib/ipAddressTable/ipAddressTable.c:504
504	ip-mib/ipAddressTable/ipAddressTable.c: No such file or directory.

(gdb) bt
#0  ipAddressIfIndex_get (rowreq_ctx=rowreq_ctx@entry=0x70e860, ipAddressIfIndex_val_ptr=0x776f70) at ip-mib/ipAddressTable/ipAddressTable.c:504
#1  0x00007ffff77b9579 in _ipAddressTable_get_column (column=3, var=0x776b40, rowreq_ctx=0x70e860) at ip-mib/ipAddressTable/ipAddressTable_interface.c:864
#2  _mfd_ipAddressTable_get_values (handler=<optimized out>, reginfo=<optimized out>, agtreq_info=<optimized out>, requests=0x76acd0)
    at ip-mib/ipAddressTable/ipAddressTable_interface.c:995
#3  0x00007ffff7b82e06 in _baby_steps_access_multiplexer (handler=0x6f76b0, reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x76acd0) at helpers/baby_steps.c:501
#4  0x00007ffff7b97435 in netsnmp_call_handler (requests=0x76acd0, reqinfo=0x7728d0, reginfo=0x6f7100, next_handler=0x6f76b0) at agent_handler.c:526
#5  netsnmp_call_next_handler (current=current@entry=0x6f6fd0, reginfo=reginfo@entry=0x6f7100, reqinfo=reqinfo@entry=0x7728d0, requests=requests@entry=0x76acd0)
    at agent_handler.c:640
#6  0x00007ffff7b832a0 in _baby_steps_helper (handler=0x6f6fd0, reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x76acd0) at helpers/baby_steps.c:312
#7  0x00007ffff7b97435 in netsnmp_call_handler (requests=0x76acd0, reqinfo=0x7728d0, reginfo=0x6f7100, next_handler=0x6f6fd0) at agent_handler.c:526
#8  netsnmp_call_next_handler (current=<optimized out>, reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x76acd0) at agent_handler.c:640
#9  0x00007ffff7b97435 in netsnmp_call_handler (requests=0x76acd0, reqinfo=0x7728d0, reginfo=0x6f7100, next_handler=0x6f7040) at agent_handler.c:526
#10 netsnmp_call_next_handler (current=<optimized out>, reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x76acd0) at agent_handler.c:640
#11 0x00007ffff7b8b007 in table_helper_handler (handler=0x70e860, reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x7ffff780c8f4) at helpers/table.c:712
#12 0x00007ffff7b96e9f in netsnmp_call_handler (requests=0x76acd0, reqinfo=0x7728d0, reginfo=0x6f7100, next_handler=0x6f9860) at agent_handler.c:526
#13 netsnmp_call_handlers (reginfo=0x6f7100, reqinfo=0x7728d0, requests=0x76acd0) at agent_handler.c:611
#14 0x00007ffff7ba4dce in handle_var_requests (asp=asp@entry=0x76b8a0) at snmp_agent.c:2676
#15 0x00007ffff7ba5a7f in handle_pdu (asp=asp@entry=0x76b8a0) at snmp_agent.c:3394
#16 0x00007ffff7ba5c78 in netsnmp_handle_request (asp=asp@entry=0x76b8a0, status=status@entry=0) at snmp_agent.c:3281
#17 0x00007ffff7ba6152 in handle_snmp_packet (op=<optimized out>, session=<optimized out>, reqid=<optimized out>, pdu=0x767ae0, magic=<optimized out>) at snmp_agent.c:1987
#18 0x00007ffff745bd31 in _sess_process_packet (sessp=0x7659d0, sp=0x765a00, isp=0x765690, transport=0x765740, opaque=0x7ac270, olength=<optimized out>,
    packetptr=0x7ae290 "00\002\001\001\004\006public\240#\002\004\027\227\361@\002\001", length=50) at snmp_api.c:5441
#19 0x00007ffff745ca79 in _sess_read (sessp=0x7659d0, fdset=0x7fffffffe9c0) at snmp_api.c:5876
#20 0x00007ffff745d859 in snmp_sess_read2 (sessp=sessp@entry=0x7659d0, fdset=fdset@entry=0x7fffffffe9c0) at snmp_api.c:5908
#21 0x00007ffff745d8ab in snmp_read2 (fdset=fdset@entry=0x7fffffffe9c0) at snmp_api.c:5504
#22 0x000000000040483f in receive () at snmpd.c:1328
#23 main (argc=<optimized out>, argv=<optimized out>) at snmpd.c:1115

Describe the results you expected:

I guess this is not giving correct output as the INTERGER value does not match with ifindex value which should be the case in ideal scenario.

as per net-snmp official doc,

"The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex."


admin@lnos-x1-a-csw06:~$ show ip int
Interface    IPv4 address/mask    Admin/Oper
-----------  -------------------  ------------
Ethernet0    10.2.1.0/31          up/up
Ethernet4    10.2.2.0/31          up/up

ifindex oid

root@lnos-x1-a-csw06:/#  snmpwalk -v 2c -c public 127.0.0.1 1.3.6.1.2.1.2.2.1.1
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 0
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.5 = INTEGER: 4
iso.3.6.1.2.1.2.2.1.1.7 = INTEGER: 6
iso.3.6.1.2.1.2.2.1.1.9 = INTEGER: 8

ipAddressIfIndex oid

admin@lnos-x1-a-csw06:~$ docker exec -it snmp bash
root@lnos-x1-a-csw06:/#  snmpwalk -v 2c -c public 127.0.0.1 1.3.6.1.2.1.4.34.1.3
iso.3.6.1.2.1.4.34.1.3.1.4.10.0.0.2 = INTEGER: 1
**iso.3.6.1.2.1.4.34.1.3.1.4.10.2.1.0 = INTEGER: 106**
**iso.3.6.1.2.1.4.34.1.3.1.4.10.2.2.0** = INTEGER: 108**
iso.3.6.1.2.1.4.34.1.3.1.4.127.0.0.1 = INTEGER: 1
iso.3.6.1.2.1.4.34.1.3.1.4.172.21.47.40 = INTEGER: 2
iso.3.6.1.2.1.4.34.1.3.1.4.240.127.1.1 = INTEGER: 4

UnavailableDataError: Key 'b'COUNTERS_PORT_NAME_MAP'' unavailable in database 'COUNTERS_DB'

this error could be caught and handled better:

Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent Traceback (most recent call last):
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     "__main__", mod_spec)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     exec(code, run_globals)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/__main__.py", line 74, in <module>
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     from .main import main
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/main.py", line 12, in <module>
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     from sonic_ax_impl.mibs import ieee802_1ab
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ieee802_1ab.py", line 99, in <module>
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     _lldp_updater = LLDPUpdater()
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ieee802_1ab.py", line 34, in __init__
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     self.reinit_data()
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ieee802_1ab.py", line 50, in reinit_data
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     self.oid_name_map = mibs.init_sync_d_interface_tables(self.db_conn)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/__init__.py", line 104, in init_sync_d_interface_tables
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     if_name_map = db_conn.get_all(COUNTERS_DB, COUNTERS_PORT_NAME_MAP, blocking=True)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 38, in wrapped
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     ret_data = f(inst, db_name, *args, **kwargs)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 303, in get_all
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent     raise UnavailableDataError(message, _hash)
Jun  5 22:14:48.0 str-a7050-acs-1 INFO supervisord: snmp-subagent swsssdk.exceptions.UnavailableDataError: Key 'b'COUNTERS_PORT_NAME_MAP'' unavailable in database 'COUNTERS_DB'

'PhysicalTableMIBUpdater' object has no attribute 'physical_entites'

Aug  2 06:41:21.340980 dut-testbed-225 ERR snmp#snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#012  File "
/usr/local/lib/python3.6/dist-packages/ax_interface/mib.py", line 46, in start#012    self.update_data()#012  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc2737.py", line 234, in
 update_data#012    self.physical_entites.remove(sub_id)#012AttributeError: 'PhysicalTableMIBUpdater' object has no attribute 'physical_entites'

should be โ€™physical_entitiesโ€˜

https://github.com/Azure/sonic-snmpagent/blob/70a6c7dad4fcfa750fb4d4efbf267842d19ca8ef/src/sonic_ax_impl/mibs/ietf/rfc2737.py#L234

snmp agent should check the config_db before trying to access the QUEUE OIDs

Hi Kevin,

When queue flex counter is disabled in config, it results in not populating/removal of Counter_QUEUENAME_MAP table in Counter_DB. As a part of SNMP query, when snmp_subagent process triggers MIBupdate, the internal MIB code tries to connect to Redis DB and retrieve the nonexistent COUNTER_QUEUENAME_MAP table. This results in Runtime Error and abort without updating any other MIB entities as shown in the following traceback. The problem is happening because SNMP subagent is not aware of Queue counter enablement/disablement in the config.

         I am not an expert in SNMP, but it seems like MIB code needs to check  queue flex counter status in CONFIG_DB before accessing the queue counter table. It is not a platform specific issue. I guess GIT issue should be raised against sonic snmp_subagent component. Just curious to know why explicitly queue flex counters are being disabled in config now in recent sonic-mgmt test run.

Problematic config in the config_db.json:

"QUEUE":

{ "FLEX_COUNTER_STATUS": "disable" },

Traceback of failure:

++
ERR snmp#snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during
update_data()#012Traceback (most recent call last):
#12 File "/usr/local/lib/python3.7/dist-packages/ax_interface/mib.py", line 37, in start#012 self.reinit_data()
#12 File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/vendor/cisco/ciscoSwitchQosMIB.py", line 85, reinit_data
#12 Namespace.get_sync_d_from_all_namespace(mibs*.init_sync_d_queue_tables*, self.db_conn)
#12 File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/init.py", line 590, in get_sync_d_from_all_namespace
#12 ns_tuple = per_namespace_func(db_conn)#12 File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/init
.py", line 362, in init_sync_d_queue_tables
#12 queue_name_map = db_conn.get_all(COUNTERS_DB, COUNTERS_QUEUE_NAME_MAP, blocking=True)
#12 File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1599, in get_all
#12 return dict(super(SonicV2Connector, self).get_all(db_name, _hash, blocking))
#12 File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1553, in get_all
#12 return _swsscommon.SonicV2Connector_Native_get_all(self, db_name, _hash, blocking)
#012RuntimeError: Key '{COUNTERS_QUEUE_NAME_MAP}' unavailable in database '{COUNTERS_DB}'

Code snippets:

def init_sync_d_queue_tables(db_conn):

"""
Initializes queue maps for SyncD-connected MIB(s).
:return: tuple(port_queues_map, queue_stat_map)
"""

# { Port name : Queue index (SONiC) -> sai_id }
# ex: { "Ethernet0:2" : "1000000000023" }
**queue_name_map = db_conn.get_all(COUNTERS_DB, COUNTERS_QUEUE_NAME_MAP, blocking=True)**
logger.debug("Queue name map:\n" + pprint.pformat(queue_name_map, indent=2))

Search Range "include" bit is ignored.

#3 introduced a bug where the search range bit isn't being evaluated.

        if sr.start.include: 


             # return the index of an insertion point immediately preceding any duplicate value (thereby including it) 


            sorted_start_index = bisect.bisect_left(oid_list, start_key) 


        else: 


            # return the index of an insertion point immediately following any duplicate value (thereby excluding it) 


            sorted_start_index = bisect.bisect_right(oid_list, start_key) 

... in fairness, coverage is missing asserting that this actually works.

Given a LUT with 1.1.1.1 and 1.1.1.2 (include set):
SR(1.1.1.2, 0) should return 1.1.1.2

Given a LUT with 1.1.1.1 and 1.1.1.2 (include unset):
SR(1.1.1.2, 0) should return "no such object"

see https://tools.ietf.org/html/rfc2741#section-5.2

why sonic need snmp?

I have a question, why sonic still use snmp? why not use grpc get all information?

MIBTable should be a RadixTree

Pending #8:

Currently:

  • O(1) for gets
  • O(n) for get-next

Ideally:

  • O(1) for gets
  • O(log n) for get-next (log base is length of OID)

E.g. 1.1.1.1 and 1.1.1.2 and 1.2.2.2:

  --- 2 --- 2 --- 2
1 --- 1 --- 1 --- 1
              --- 2

get-next would then be a matter of finding the next node using Depth-first Traversal.

[chassis][supervisor] snmpwalk failed on supervisor card

Description
On VOQ chassis supervisor card, snmpwalk failed to walk the mib from top. The following is failure output

cmd:  snmpwalk -v  2c -c public  152.148.151.221
SNMPv2-MIB::sysDescr.0 = STRING: SONiC Software Version: SONiC.HEAD.213232-dirty-20220120.095956 - HwSku: Nokia-IXR7250E-SUP-10-r0 - Distribution: Debian 11.2 - Kernel: 5.10.0-8-2-amd64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5759739) 15:59:57.39
SNMPv2-MIB::sysContact.0 = STRING: Azure Cloud Switch vteam <[email protected]>
Timeout: No Response from 152.148.151.221

Also the following output is shown on the the supervisor card syslog:

Jan 21 16:42:53.631232 supervisor ERR snmp#snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/mib.py", line 37, in start#012    self.reinit_data()#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/ietf/rfc2863.py", line 128, in reinit_data#012    self.vlan_oid_name_map = Namespace.get_sync_d_from_all_namespace(mibs.init_sync_d_vlan_tables, self.db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/__init__.py", line 651, in get_sync_d_from_all_namespace#012    ns_tuple = per_namespace_func(db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/__init__.py", line 341, in init_sync_d_vlan_tables#012    vlan_name_map = port_util.get_vlan_interface_oid_map(db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/swsssdk/port_util.py", line 167, in get_vlan_interface_oid_map#012    rif_name_map = db.get_all('COUNTERS_DB', 'COUNTERS_RIF_NAME_MAP', blocking=True)#012  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1751, in get_all#012    return dict(super(SonicV2Connector, self).get_all(db_name, _hash, blocking))#012  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1708, in get_all#012    return _swsscommon.SonicV2Connector_Native_get_all(self, db_name, _hash, blocking)#012RuntimeError: Key '{COUNTERS_RIF_NAME_MAP}' unavailable in database '{COUNTERS_DB}'

Steps to reproduce the issue:

  1. Using the snmpwalk command to query a supervisor card: snmpwakl -v 2c -c public
    The following output will be shown:
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5759739) 15:59:57.39
SNMPv2-MIB::sysContact.0 = STRING: Azure Cloud Switch vteam <[email protected]>
Timeout: No Response from 152.148.151.221

or
2. Also check the syslog file on supervisor card, the following backtrace is shown:

Jan 21 16:42:53.631232 supervisor ERR snmp#snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/mib.py", line 37, in start#012    self.reinit_data()#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/ietf/rfc2863.py", line 128, in reinit_data#012    self.vlan_oid_name_map = Namespace.get_sync_d_from_all_namespace(mibs.init_sync_d_vlan_tables, self.db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/__init__.py", line 651, in get_sync_d_from_all_namespace#012    ns_tuple = per_namespace_func(db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/sonic_ax_impl/mibs/__init__.py", line 341, in init_sync_d_vlan_tables#012    vlan_name_map = port_util.get_vlan_interface_oid_map(db_conn)#012  File "/usr/local/lib/python3.7/dist-packages/swsssdk/port_util.py", line 167, in get_vlan_interface_oid_map#012    rif_name_map = db.get_all('COUNTERS_DB', 'COUNTERS_RIF_NAME_MAP', blocking=True)#012  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1751, in get_all#012    return dict(super(SonicV2Connector, self).get_all(db_name, _hash, blocking))#012  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1708, in get_all#012    return _swsscommon.SonicV2Connector_Native_get_all(self, db_name, _hash, blocking)#012RuntimeError: Key '{COUNTERS_RIF_NAME_MAP}' unavailable in database '{COUNTERS_DB}'

Describe the results you received:
snmpwalk failed to query the supervisor card.

SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5759739) 15:59:57.39
SNMPv2-MIB::sysContact.0 = STRING: Azure Cloud Switch vteam <[email protected]>
Timeout: No Response from 152.148.151.221

Describe the results you expected:
MIB walk should work fine. And backtrace should no the seen in syslog file

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

Reduce verbose log about mgmt ports

Description

Steps to reproduce the issue:

  1. Running the SONiC image on a M0 switch
  2. Observe the /var/log/syslog file

Describe the results you received:

2020-10-24 12:54:22.6907595 <28>Oct 24 12:54:22 sonic_m0 snmp#snmp-subagent [sonic_ax_impl] WARNING: Invalid management IP
2020-10-24 12:54:22.6917967 <28>Oct 24 12:54:22 sonic_m0 snmp#snmp-subagent [sonic_ax_impl] WARNING: Invalid mgmt IP
2020-10-24 12:54:22.6919091 <28>Oct 24 12:54:22 sonic_m0 snmp#snmp-subagent [sonic_ax_impl] WARNING: Invalid management IP
2020-10-24 12:54:56.4343259 <28>Oct 24 12:54:56 sonic_m0 snmp#snmp-subagent [sonic_ax_impl] WARNING: No managment ports found in b'MGMT_PORT|'

Describe the results you expected:
I see multiple issues in the syslog.

  1. M0 by design has no management ports locally, so the ConfigDB has no MGMT_PORT table. We don't need to warn on this
  2. LLDP message from neighbor contains empty management port on their side. No need to warn on this

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

Any 201811 image and future

**Attach debug file `sudo generate_dump`:**

See above snippet

setup.py error

Description

We want to install snmpagent into SONiC
Following the document, we did "setup.py" script, but we couldn't complete install snmpagent.

Describe the results you received:

admin@sonic:~/tmp$ sudo python3.5 setup.py install
Traceback (most recent call last):
File "setup.py", line 1, in
from setuptools import setup, find_packages
ImportError: No module named 'setuptools'

Could you share us the way how to install snmp agent software?

Thanks,
Takayoshi

ipaddress parsing issue due to subnets present in DB

Description

Using 10f59f2 I get ton of ValueError in syslog from snmp-subagent / axinterface due to subnet mask being present in INTF_TABLE.

Steps to reproduce the issue:

  1. compile using sonic-net/sonic-buildimage@465ebba (definitely not a stable release)
  2. display snmp errors in syslog
sudo zcat /var/log/syslog.*.gz | grep snmp

Describe the results you received:
Ex of syslog output:

Nov 22 16:14:42.897183 ss11 INFO snmp/supervisord: snmp-subagent ValueError: '100.127.251.135/26' does not appear to be an IPv4 or IPv6 address
Nov 22 16:14:47.899569 ss11 ERR snmp/snmp-subagent [ax_interface] ERROR: MIBUpdater.start() caught an unexpected exception during update_data()#012Traceback (most recent call last):#012  File "/usr/local/lib/python3.6/dist-packages/ax_interface/mib.py", line 40, in start#012    self.reinit_data()#012  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc4292.py", line 36, in reinit_data#012    ipa = ipaddress.ip_address(loip)#012  File "/usr/lib/python3.6/ipaddress.py", line 54, in ip_address#012    address)#012ValueError: '100.127.251.135/26' does not appear to be an IPv4 or IPv6 address
Nov 22 16:14:47.899983 ss11 INFO snmp/supervisord: snmp-subagent ERROR:ax_interface:MIBUpdater.start() caught an unexpected exception during update_data()
Nov 22 16:14:47.900019 ss11 INFO snmp/supervisord: snmp-subagent Traceback (most recent call last):
Nov 22 16:14:47.900019 ss11 INFO snmp/supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/ax_interface/mib.py", line 40, in start
Nov 22 16:14:47.900068 ss11 INFO snmp/supervisord: snmp-subagent     self.reinit_data()
Nov 22 16:14:47.900117 ss11 INFO snmp/supervisord: snmp-subagent   File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc4292.py", line 36, in reinit_data
Nov 22 16:14:47.900117 ss11 INFO snmp/supervisord: snmp-subagent     ipa = ipaddress.ip_address(loip)
Nov 22 16:14:47.900430 ss11 INFO snmp/supervisord: snmp-subagent   File "/usr/lib/python3.6/ipaddress.py", line 54, in ip_address
Nov 22 16:14:47.900458 ss11 INFO snmp/supervisord: snmp-subagent     address)
Nov 22 16:14:47.900489 ss11 INFO snmp/supervisord: snmp-subagent ValueError: '100.127.251.135/26' does not appear to be an IPv4 or IPv6 address

Describe the results you expected:

No error logs ;)

Explanation:

$ redis-cli 
127.0.0.1:6379> keys INTF_TABLE:lo:*
1) "INTF_TABLE:lo:100.127.251.135/26"

Disclaimer:
I'm relatively new to this project, carefully read the guidelines, but feel free to report bad submission.
Can provides patches if needed, but I would prefer a community member to give advices first.

'sonic_py_common.multi_asic' has no attribute 'ROLE'" error message

Description

Error message seen in syslog: "AttributeError: module 'sonic_py_common.multi_asic' has no attribute 'ROLE'" .

Steps to reproduce the issue:

  1. Load master or 201911 image with latest snmp docker.
  2. Load configuration so that there is a default route via one of the Ethernet interfaces:
    ex:
    show ip route 0.0.0.0/0
    Routing entry for 0.0.0.0/0
    Known via "bgp", distance 20, metric 0, best
    Last update 00:44:06 ago
  • 10.0.0.57, via Ethernet0
  1. Periodically the error message comes up in the log:
    "AttributeError: module 'sonic_py_common.multi_asic' has no attribute 'ROLE'"

Describe the results you received:
Error message: "AttributeError: module 'sonic_py_common.multi_asic' has no attribute 'ROLE'" |
SNMP walk or get of Route Table (1.3.6.1.2.1.4.24.4) fails

Describe the results you expected:
SNMP walk of 1.3.6.1.2.1.4.24.4 should be successful and error message should not be visible,

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

Reuse enum XcvrInfoDB

It is better to move into a common place and shared with the repo sonic-platform-common.

@unique
class XcvrInfoDB(bytes, Enum):
    """
    Transceiver info keys
    """

    TYPE              = b"type"
    HARDWARE_REVISION = b"hardware_rev"
    SERIAL_NUMBER     = b"serial"
    MANUFACTURE_NAME  = b"manufacturer"
    MODEL_NAME        = b"model"

Implement sysName OID

Description

Steps to reproduce the issue:

  1. Make sure all the containers running well and snmp is responding query on sysName OID (1.3.6.1.2.1.1.5.0)
  2. Change the hostname in the SONiC host
  3. Verify the hostname inside snmp container are still the old hostname

Describe the results you received:
Query sysName OID and the response is still the old hostname

Describe the results you expected:
Query sysName OID and the response should be the new hostname

Additional information you deem important (e.g. issue happens only occasionally):
Currently the OID is served by snmpd default implementation, so it fetch the hostname from inside snmp container. Suggest override the implementation in sonic-snmpagent repo. The ground truth of hostname should be from ConfigDB, as below command line

redis-cli -n 4 hget "DEVICE_METADATA|localhost" "hostname"

Output of show version:

Applicable to any version

Attach debug file sudo generate_dump:

Not related

WARNING snmpd Unknown token:disk

Oct 14 01:04:45.015789 CYS04-0101-0118-11T1 WARNING snmpd[29]: /etc/snmp/snmpd.conf: line 64: Warning: Unknown token: disk.           
Oct 14 01:04:45.015821 CYS04-0101-0118-11T1 WARNING snmpd[29]: /etc/snmp/snmpd.conf: line 65: Warning: Unknown token: disk.           
Oct 14 01:04:45.015821 CYS04-0101-0118-11T1 WARNING snmpd[29]: /etc/snmp/snmpd.conf: line 66: Warning: Unknown token: includeAllDisks.

Do not crash on swsssdk.exceptions.UnavailableDataError

Should have a better way of handling such case.

Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/__main__.py", line 74, in <module>
    from .main import main
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/main.py", line 14, in <module>
    from .mibs.ietf import rfc1213, rfc2863, rfc4292, rfc4363
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc1213.py", line 337, in <module>
    class InterfacesMIB(metaclass=MIBMeta, prefix='.1.3.6.1.2.1.2'):
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc1213.py", line 342, in InterfacesMIB
    if_updater = InterfacesUpdater()
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc1213.py", line 157, in __init__
    self.update_data()
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc1213.py", line 176, in update_data
    for sai_id in self.if_id_map}
  File "/usr/local/lib/python3.6/dist-packages/sonic_ax_impl/mibs/ietf/rfc1213.py", line 176, in <dictcomp>
    for sai_id in self.if_id_map}
  File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 38, in wrapped
    ret_data = f(inst, db_name, *args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/swsssdk/interface.py", line 303, in get_all
    raise UnavailableDataError(message, _hash)
swsssdk.exceptions.UnavailableDataError: Key 'b'COUNTERS:oid:0x1000000000002'' unavailable in database 'COUNTERS_DB'

why does SNMP QOS queue not follow CLI queue or vice-versa?

Description

SNMP QOS queue doesn't follow CLI queue.
That means SNMP queues are 1-10 (can be seen via snmpwalk with oid 1.3.6.1.4.1.9.9.580.1.5.5.1)
and CLI queues are 0-9 which can be noticed via queuestat.

If I understand correctly, as per this line in ciscoSwitchQosMib.py script, it's designed in a way, the query will be 1-based.

mib_oid = (if_index, int(DirectionTypes.EGRESS), (queue % pq_count) + 1, counter_mib_id)

my question is that as source of both the queries is COUNTER DB, why can't it make it symmetrical. it will be easier to troubleshoot or collecting the metrics on whether to start from 1 or 0.

Describe the results you received:

Currently, SNMP QOS queue doesn't follow CLI queue or vice verse.

Describe the results you expected:

My question is whether we can make it the same whether it's 1 based or 0 based on both the places.

"sorted" usage should be eliminated during get-next calls

Ideally (as-implemented):

  • O(1) for gets
  • O(n) for get-next

Currently:

  • O(1) for get
  • O(n) for gets in dynamic subtrees #3
  • O(n log n) for get-next (because of sorted usage)

We can have the table maintain a sorted copy of the keys for fast get-next calls.

class MIBTable(dict):
   # ...
  def __setitem__(self, key, value):
      super().__setitem__(key, value)
      self._sorted_keys = sorted(self.keys())

  @property
  def sorted_keys():
      # make a copy -- saves OID searches "in-flight" if the table is updated
      return list(self._sorted_keys)

Test gap: add unit test of IfHighSpeed with PortChannel with no member ports

          > what is the portchannel has no member ports?

Tested on DUT, and it is working with PortChannel with no member ports.

admin@sonic:~$ sudo config portchannel add PortChannel999
admin@sonic:~$ show int port
Flags: A - active, I - inactive, Up - up, Dw - Down, N/A - not available,
       S - selected, D - deselected, * - not synced
  No.  Team Dev        Protocol     Ports
-----  --------------  -----------  --------------
  101  PortChannel101  LACP(A)(Up)  Ethernet112(S)
  102  PortChannel102  LACP(A)(Up)  Ethernet116(S)
  103  PortChannel103  LACP(A)(Up)  Ethernet120(S)
  104  PortChannel104  LACP(A)(Up)  Ethernet124(S)
  999  PortChannel999  LACP(A)(Dw)

root@sonic:/# snmpwalk -v2c -c msft 10.64.247.236 1.3.6.1.2.1.31.1.1.1.15
iso.3.6.1.2.1.31.1.1.1.15.1101 = Gauge32: 100000
iso.3.6.1.2.1.31.1.1.1.15.1102 = Gauge32: 100000
iso.3.6.1.2.1.31.1.1.1.15.1103 = Gauge32: 100000
iso.3.6.1.2.1.31.1.1.1.15.1104 = Gauge32: 100000
iso.3.6.1.2.1.31.1.1.1.15.1999 = Gauge32: 0

Originally posted by @qiluo-msft in #262 (comment)

Cannot statfs Permission denied

This issue seems to be there in S6100.
Low priority issue.

Oct 17 18:49:06.963425 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/host: Permission denied        
Oct 17 18:49:06.963425 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev: Permission denied         
Oct 17 18:49:06.963425 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev/pts: Permission denied     
Oct 17 19:21:42.345391 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/host: Permission denied        
Oct 17 19:21:42.345819 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev: Permission denied         
Oct 17 19:21:42.345819 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev/pts: Permission denied     
Oct 17 19:57:29.880832 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/host: Permission denied        
Oct 17 19:57:29.880832 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev: Permission denied         
Oct 17 19:57:29.880832 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev/pts: Permission denied     
Oct 17 20:30:55.017476 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/host: Permission denied        
Oct 17 20:30:55.017920 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev: Permission denied         
Oct 17 20:30:55.018231 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev/pts: Permission denied     
Oct 17 21:03:22.988733 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/host: Permission denied        
Oct 17 21:03:22.988733 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev: Permission denied         
Oct 17 21:03:22.988733 CYS04-0101-0118-11T1 ERR snmpd[29]: Cannot statfs /root/dev/pts: Permission denied     

The payload length of PDU cannot exceed 1500

Description

If the payload length of PDU of the oid exceeds 1500 bytes, snmpwalk will report an error:

Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.3333.2.3

ifPhysAddress MIB doesn't return Mac address

Description
SNMP walk for OID 1.3.6.1.2.1.2.2.1.6 return empty strings instead of physical address of ports.

Steps to reproduce the issue:

  1. Bring up t0 or t1 topology
  2. Trigger SNMP walk : snmpwalk -v 2c -c public 1.3.6.1.2.1.2.2.1.6

Describe the results you received:

iso.3.6.1.2.1.2.2.1.6.1 = ""
iso.3.6.1.2.1.2.2.1.6.5 = ""
iso.3.6.1.2.1.2.2.1.6.9 = ""
iso.3.6.1.2.1.2.2.1.6.13 = ""
iso.3.6.1.2.1.2.2.1.6.17 = ""
iso.3.6.1.2.1.2.2.1.6.21 = ""
iso.3.6.1.2.1.2.2.1.6.25 = ""
iso.3.6.1.2.1.2.2.1.6.29 = ""
iso.3.6.1.2.1.2.2.1.6.33 = ""
iso.3.6.1.2.1.2.2.1.6.37 = ""
iso.3.6.1.2.1.2.2.1.6.41 = ""
iso.3.6.1.2.1.2.2.1.6.45 = ""
iso.3.6.1.2.1.2.2.1.6.49 = ""
iso.3.6.1.2.1.2.2.1.6.53 = ""
iso.3.6.1.2.1.2.2.1.6.57 = ""
iso.3.6.1.2.1.2.2.1.6.61 = ""
iso.3.6.1.2.1.2.2.1.6.65 = ""
iso.3.6.1.2.1.2.2.1.6.69 = ""
iso.3.6.1.2.1.2.2.1.6.73 = ""
iso.3.6.1.2.1.2.2.1.6.77 = ""
iso.3.6.1.2.1.2.2.1.6.81 = ""
iso.3.6.1.2.1.2.2.1.6.85 = ""
iso.3.6.1.2.1.2.2.1.6.89 = ""
iso.3.6.1.2.1.2.2.1.6.93 = ""
iso.3.6.1.2.1.2.2.1.6.97 = ""
iso.3.6.1.2.1.2.2.1.6.101 = ""
iso.3.6.1.2.1.2.2.1.6.105 = ""
iso.3.6.1.2.1.2.2.1.6.109 = ""
iso.3.6.1.2.1.2.2.1.6.113 = ""
iso.3.6.1.2.1.2.2.1.6.117 = ""
iso.3.6.1.2.1.2.2.1.6.121 = ""
iso.3.6.1.2.1.2.2.1.6.125 = ""
iso.3.6.1.2.1.2.2.1.6.129 = ""
iso.3.6.1.2.1.2.2.1.6.133 = ""
iso.3.6.1.2.1.2.2.1.6.137 = ""
iso.3.6.1.2.1.2.2.1.6.141 = ""
iso.3.6.1.2.1.2.2.1.6.145 = ""
iso.3.6.1.2.1.2.2.1.6.149 = ""
iso.3.6.1.2.1.2.2.1.6.153 = ""
iso.3.6.1.2.1.2.2.1.6.157 = ""
iso.3.6.1.2.1.2.2.1.6.161 = ""
iso.3.6.1.2.1.2.2.1.6.165 = ""
iso.3.6.1.2.1.2.2.1.6.169 = ""
iso.3.6.1.2.1.2.2.1.6.173 = ""
iso.3.6.1.2.1.2.2.1.6.177 = ""
iso.3.6.1.2.1.2.2.1.6.181 = ""
iso.3.6.1.2.1.2.2.1.6.185 = ""
iso.3.6.1.2.1.2.2.1.6.189 = ""
iso.3.6.1.2.1.2.2.1.6.193 = ""
iso.3.6.1.2.1.2.2.1.6.197 = ""
iso.3.6.1.2.1.2.2.1.6.201 = ""
iso.3.6.1.2.1.2.2.1.6.205 = ""
iso.3.6.1.2.1.2.2.1.6.209 = ""
iso.3.6.1.2.1.2.2.1.6.213 = ""
iso.3.6.1.2.1.2.2.1.6.217 = ""
iso.3.6.1.2.1.2.2.1.6.221 = ""
iso.3.6.1.2.1.2.2.1.6.225 = ""
iso.3.6.1.2.1.2.2.1.6.229 = ""
iso.3.6.1.2.1.2.2.1.6.233 = ""
iso.3.6.1.2.1.2.2.1.6.237 = ""
iso.3.6.1.2.1.2.2.1.6.241 = ""
iso.3.6.1.2.1.2.2.1.6.245 = ""
iso.3.6.1.2.1.2.2.1.6.249 = ""
iso.3.6.1.2.1.2.2.1.6.253 = ""
iso.3.6.1.2.1.2.2.1.6.1001 = ""
iso.3.6.1.2.1.2.2.1.6.1002 = ""
iso.3.6.1.2.1.2.2.1.6.1003 = ""
iso.3.6.1.2.1.2.2.1.6.1004 = ""
iso.3.6.1.2.1.2.2.1.6.10000 = ""

Describe the results you expected:
Expected to receive physical address of ports instead of empty strings.

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
SONiC.master.134-dirty-20210225.114416
Distribution: Debian 10.8
Kernel: 4.19.0-12-2-amd64
Build commit: 2a339faf
Build date: Thu Feb 25 11:54:08 UTC 2021
Platform: x86_64-arista_7170_64c
HwSKU: Arista-7170-64C
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

AgentX error seen if Transceiver_info table contains bad string

Description

ERROR: Uncaught AgentX proto error is seen if TRANSCEIVER_INFO table has bad string in one of the fields.

Steps to reproduce the issue:

  1. Bring up any DUT with master image or 2021x branch.
  2. Inject bad string in any of the fields in TRANSCEIVER_DB. (redis-cli -n 6 ; HSET "TRANSCEIVER_INFO|Ethernet48" "hardware_rev" "\xff\xff")
  3. Perform snmpwalk on transceiver MIB, snmpwalk -v2c -c public 127.0.0.1 iso.3.6.1.2.1.47.1.1.1.1.

Describe the results you received:
snmpagent will restart with the below error:

ERR snmp#snmp-subagent [ax_interface] ERROR: Uncaught AgentX proto error! [b'\x01\x06\x10\x00\x00\x00\x00\x06\x00\x00/\xd4\x00\x00/\xd5\x00\x00\x00D\x08\x02\x00\x00\x00\x00\x00\x01\x00\x00\x00/\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x08;\x9a\xdb\xc6\x07\x02\x00\x00\x00\x00\x00\x01\x00\x00\x00/\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\t']#012Traceback (most recent call last):#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/protocol.py", line 138, in data_received#012    response_pdu = pdu.make_response(self.mib_table)#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/pdu_implementations.py", line 289, in make_response#012    vr = lut.get_next(sr)#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/mib.py", line 359, in get_next#012    vr = self._get_nextvalue(parent_mib_entry, start_key)#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/mib.py", line 317, in _get_nextvalue#012    vr = ValueRepresentation.from_typecast(mib_entry.value_type, oid1, val1)#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/encodings.py", line 247, in from_typecast#012    _data = OctetString.from_string(data)#012  File "/usr/local/lib/python3.7/dist-packages/ax_interface/encodings.py", line 153, in from_string#012    _string = bytes(string, 'latin-1') if type(string) is str else string#012UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-1: ordinal not in range(256)

Describe the results you expected:
AgentX should not crash due to bad string in Transceiver DB. Agentx should be stable and should validate strings that is read from DB table which is populated by external daemons.

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.