[SNMP4SDN-16] Results of calling rpc get-node-connector-list and rpc get-edge-list in branch stable/beryllium are null. Created: 26/Feb/16  Updated: 19/Oct/17  Resolved: 01/Apr/16

Status: Resolved
Project: snmp4sdn
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Nanfei Chen Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5433

 Description   

Branch: stable/beryllium.

There are three switches in my experiment, and their connections are as follows.
s1(GE1/0/1)-----(GE1/0/1)s2(GE1/0/2)-----(GE1/0/1)s3

File snmp4sdn_swdb.csv is as follows, and there are only s1 and s2 in this file.
MAC,IP,SNMP_Community,CLI_Username,CLI_Password,Model
74:25:8a:e4:11:be,17.0.2.104,public,admin,admin,H3C_VSR
74:25:8a:e3:56:b4,17.0.3.105,public,admin,admin,H3C_VSR

Firstly, I use command snmp4sdn:readdb to read device information about s1 and s2. The result is as follows.
MAC_address (sid) IP_address SNMP_community CLI_username CLI_password Model_name
=======================================================================
00:00:74:25:8a:e3:56:b4 (127704592766644 ) 17.0.3.105 public admin admin H3C_VSR
00:00:74:25:8a:e4:11:be (127704592814526 ) 17.0.2.104 public admin admin H3C_VSR
MAC_address (sid) IP_address SNMP_community CLI_username CLI_password Model_name
=======================================================================
00:00:74:25:8a:e3:56:b4 (127704592766644 ) 17.0.3.105 public admin admin H3C_VSR
00:00:74:25:8a:e4:11:be (127704592814526 ) 17.0.2.104 public admin admin H3C_VSR

Secondly, I use command snmp4sdn:topodiscover to discover the switches and the edges between them.

And then, I call rpc get-node-list to get the nodes, and the result is right, as follows.
rpc get-node-list is called, node list:
SNMP|127704592766644
SNMP|127704592814526

But when I call rpc get-node-connector-list and rpc get-edge-list, I find the results of calling those rpcs are null. And I find some ERROR logs also, as follows.

2016-02-26 08:45:03,312 | INFO | l for user karaf | Controller | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | Add switch(00:00:74:25:8a:e3:56:b4) to the Controller
2016-02-26 08:45:03,322 | INFO | l for user karaf | OFStatisticsManager | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | Added Switch 00:00:74:25:8a:e3:56:b4 to target pool
2016-02-26 08:45:03,380 | ERROR | l for user karaf | Controller | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | ERROR: scanAndAddPort(): portStateTable has no entry for port 17
2016-02-26 08:45:03,390 | INFO | l for user karaf | Controller | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | Add switch(00:00:74:25:8a:e4:11:be) to the Controller
2016-02-26 08:45:03,391 | INFO | l for user karaf | OFStatisticsManager | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | Added Switch 00:00:74:25:8a:e4:11:be to target pool
2016-02-26 08:45:03,445 | ERROR | l for user karaf | Controller | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | ERROR: scanAndAddPort(): portStateTable has no entry for port 17
2016-02-26 08:45:45,223 | ERROR | opologyDiscovery | SwitchHandler | 242 - org.opendaylight.snmp4sdn - 0.3.0.Beryllium | ERROR: setPhysicalPortState(): given portState is null, for SNMPPhysicalPort phyPort whose portID is 17

 Comments   
Comment by Nanfei Chen [ 26/Feb/16 ]

I have committed two changes for this bug.

For branch stable/beryllium: https://git.opendaylight.org/gerrit/#/c/35086/.

For branch master: https://git.opendaylight.org/gerrit/#/c/35091/.

Comment by Nanfei Chen [ 29/Feb/16 ]

There are some problems in method readPortStateEntries of class SNMPHandler when dealing with tableVars.

Because the valid port number in tableVars does not begin from 1 always. And the valid port number in tableVars does not be continuous always.

For example, as to a device whose model is H3C S6800-4C, when the second slot is used only, the valid port number in tableVars will be 33~57, 61, 26446. There are also other similar situations.

In those cases, there will be some problems when using tmpCount for decision.

Comment by Christine Hsieh [ 01/Apr/16 ]

Naifei provided fix is merged now, https://git.opendaylight.org/gerrit/#/c/35091/
Thanks!

Generated at Wed Feb 07 20:39:18 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.