Symptom
+ This is a placeholder bug for CSCvs10395 and other related bugs regarding the fabric track feature.
+ Basically when fabric track is enabled, in the background the fabric track script is querying API for MOs every 1 sec.
+ If the API fails to query MOs, then the script seems to bring down all the downlinks assuming no fabric links are up ( so that the data traffic can be rerouted).
+ But this is not true since the fabric links are up, but the moquery has failed.
+ Bug to be used to address the fix.
+ When port tracking fails to read the MO for number of up fabric links, the code returns zero which is incorrect as zero is valid number value indicating no fabric links are up and the downstream ports are brought down.
Conditions
Just API failed (might be due to nginx ), not a genuine (uplink down, ISIS down etc.) failure :
fabric_track.py.dbg§§§§§§
INFO:root:2022-12-08T00:28:34.154187 Reading l1PhysIf Mos of fabric links to check number of up fabric links
ERROR:root:URLError: HTTPConnectionPool(host='127.0.0.1', port=7777): Request timed out. (timeout=113)
INFO:root:2022-12-08T00:30:27.250014 Invalid Error: URL: /api//class/l1PhysIf.xml?&rsp-subtree=children&query-target-filter=and(anybit(l1PhysIf.usage,"fabric"),eq(l1PhysIf.switchingSt,"enabled"))&rsp-subtree-filter=eq(ethpmPhysIf.operSt,"up")&rsp-subtree-include=count,required&query-target=subtree
Code: None
Output: None
Data Posted:
None
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (169): 127.0.0.1
INFO:root:2022-12-08T00:31:56.435768 Bringdown: 0 Fabric links left up <========= trigger fabrictrack to bring down front panel ports..
Workaround
Disable Fabric Track feature as mentioned in CSCvs10395
