Commit fccb21b
authored
[RFC1213]: Initialize lag oid map in reinit_data instead of (sonic-net#232)
- What I did
Initialize lag oid map in reinit_data instead of
updating in update_data. Updating lag oid map in update_data
can cause descrepancy as interface oid map is updated in
reinit_data.
There could be a scenario when lag oid map has lag oids updated in update_data but interfaces oid map is not updated as interfaces oid map is updated in reinit_data. When SNMP service comes up, there could be a short instance of time when interfaces oid map (oid_sai_map) is empty or not complete but lag oid map (oid_lag_name_map) is updated with lag oids and lag members. At this short span, if a SNMP query is done to get interfaces counters, current code will try to get LAG counters and will fail at https://github.com/Azure/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/ietf/rfc1213.py#L383 when trying to get oid of lag members' oid. This can lead to key error : sai_id = self.oid_sai_map[oid]#012KeyError.
This change is to avoid this scenario.
- How I did it
init_sync_d_lag_tables in reinit_data instead of invoking in update_data.
- How to verify it
unit-test pass.
SNMP walk of interface MIB output is complete.1 parent 43b5e1a commit fccb21b
1 file changed
Lines changed: 5 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
235 | 235 | | |
236 | 236 | | |
237 | 237 | | |
| 238 | + | |
| 239 | + | |
| 240 | + | |
| 241 | + | |
| 242 | + | |
238 | 243 | | |
239 | 244 | | |
240 | 245 | | |
| |||
246 | 251 | | |
247 | 252 | | |
248 | 253 | | |
249 | | - | |
250 | | - | |
251 | | - | |
252 | | - | |
253 | | - | |
254 | 254 | | |
255 | 255 | | |
256 | 256 | | |
| |||
0 commit comments