{"action":"created","issue":{"url":"https://api.github.com/repos/netdisco/netdisco/issues/436","repository_url":"https://api.github.com/repos/netdisco/netdisco","labels_url":"https://api.github.com/repos/netdisco/netdisco/issues/436/labels{/name}","comments_url":"https://api.github.com/repos/netdisco/netdisco/issues/436/comments","events_url":"https://api.github.com/repos/netdisco/netdisco/issues/436/events","html_url":"https://github.com/netdisco/netdisco/issues/436","id":354155132,"node_id":"MDU6SXNzdWUzNTQxNTUxMzI=","number":436,"title":"Neighbors on maps with one-side info only randomly skipped","user":{"login":"Linwood-F","id":13143855,"node_id":"MDQ6VXNlcjEzMTQzODU1","avatar_url":"https://avatars3.githubusercontent.com/u/13143855?v=4","gravatar_id":"","url":"https://api.github.com/users/Linwood-F","html_url":"https://github.com/Linwood-F","followers_url":"https://api.github.com/users/Linwood-F/followers","following_url":"https://api.github.com/users/Linwood-F/following{/other_user}","gists_url":"https://api.github.com/users/Linwood-F/gists{/gist_id}","starred_url":"https://api.github.com/users/Linwood-F/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Linwood-F/subscriptions","organizations_url":"https://api.github.com/users/Linwood-F/orgs","repos_url":"https://api.github.com/users/Linwood-F/repos","events_url":"https://api.github.com/users/Linwood-F/events{/privacy}","received_events_url":"https://api.github.com/users/Linwood-F/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-08-27T02:08:33Z","updated_at":"2018-08-27T12:52:27Z","closed_at":null,"author_association":"NONE","body":"We have a bunch of AP's (Aerohives) that do LLDP just fine, but apparently their neighbor information is not visible in the SNMP requests from them, at least it does not appear in the ports list.\r\n\r\nOn the other hand, it conveys that information to the connected device (Cisco switches in this case) just fine.\r\n\r\nWhat happens is the query in DeviceLinks.pm checks the left IP against the right to avoid duplicates. The result is that randomly, the neighbor display works, or fails, depending on whether the AP happens to be on the left, or on the right.\r\n\r\nIdeally this might be fixed by putting the relevant data from the AP's, but no idea if that's even possible in their SNMP responses.  A simple fix, however, appears to be to choose a different way to tell which to pick -- use the resulting port's existence for a comparison, so that if one is null, you always pick the other.  At least it seems to work -- in a few hundred nodes I see no bad effects so far.\r\n\r\n## Expected Behavior\r\n\r\nIdeally, chose the left/right side from the pair which has the most info, rather than (effectively) randomly based on IP.\r\n\r\n## Current Behavior\r\nChosen by the bigger IP.\r\n\r\n## Possible Solution\r\n\r\nIn the SQL, remove the IP comparison, and add a HAVING statement on the port info as below.  I'm not all that comfortable at the various alternatives of having an array as a comparison, but this does seem to work.  Maybe there's a better comparison, like the name\r\n\r\n```\r\n WHERE dp.remote_port IS NOT NULL\r\n   AND dp.port !~* 'vlan'\r\n   AND (dp.descr IS NULL OR dp.descr !~* 'vlan')\r\n   AND (dp.type IS NULL OR dp.type !~* '^(53|ieee8023adLag|propVirtual|l2vlan|l3ipvlan|135|136|137)\\$')\r\n   AND (dp.is_master = 'false' OR dp.slave_of IS NOT NULL)\r\n--   AND dp.ip <= di.ip\r\n GROUP BY left_ip, left_dns, left_name, right_ip, right_dns, right_name\r\n\thaving array_agg(dp.port) <= array_agg(dp.remote_port)\r\n ORDER BY dp.ip\r\n```\r\n\r\n## Steps to Reproduce (for bugs)\r\n\r\nI have no idea how to reproduce this outside of having this gear, but here is some output that may help understand.\r\n\r\nTwo AP's are 10.108.1.214 (d8:54:a2:9d:69:40) and 10.108.1.224 (88:5b:dd:57:df:c0).  When I run \r\n\r\n```\r\n$ ~netdisco/bin/netdisco-do show -d 10.108.1.214 -e c_id\r\n[56291] 2018-08-27 01:54:07  info App::Netdisco version 2.039031 loaded.\r\n[56291] 2018-08-27 01:54:08  info show: [10.108.1.214]/c_id started at Sun Aug 26 20:54:08 2018\r\nundef\r\n[56291] 2018-08-27 01:54:20  info show: finished at Sun Aug 26 20:54:20 2018\r\n[56291] 2018-08-27 01:54:20  info show: status done: Showed c_id response from 10.108.1.214\r\n```\r\n\r\nThese are connected, respectively, to switches at 10.108.1.2 and 192.168.168.2.  When I run the same for them:\r\n\r\n```\r\n$ ~netdisco/bin/netdisco-do show -d 10.108.1.2 -e c_id\r\n[61982] 2018-08-27 01:54:43  info App::Netdisco version 2.039031 loaded.\r\n[61982] 2018-08-27 01:54:43  info show: [10.108.1.2]/c_id started at Sun Aug 26 20:54:43 2018\r\n\\ {\r\n   stuff...\r\n    0.2.13    \"d8:54:a2:9d:69:40\",\r\n   more stuff...\r\n}\r\n```\r\n\r\n```\r\n~$ ~netdisco/bin/netdisco-do show -d 10.108.1.1 -e c_id\r\n[3723] 2018-08-27 01:55:20  info App::Netdisco version 2.039031 loaded.\r\n[3723] 2018-08-27 01:55:20  info show: [192.168.168.2]/c_id started at Sun Aug 26 20:55:20 2018\r\n\\ {\r\n    stuff...(lots of it)\r\n    0.143.82   \"88:5b:dd:57:df:c0\",\r\n   stuff....\r\n}\r\n[3723] 2018-08-27 01:55:27  info show: finished at Sun Aug 26 20:55:27 2018\r\n[3723] 2018-08-27 01:55:27  info show: status done: Showed c_id response from 192.168.168.2\r\n```\r\n\r\nThe first of these (10.108.1.214) works, but the second (10.108.1.224) does not, solely due to the luck of the draw in comparing against the associated neighbor IP as best I can tell.\r\n\r\n## Context\r\n\r\nWe have about 200 AP's, and this causes 95 of them not to show neighbor informaiton.  \r\n\r\n## Your Environment\r\nAlmost all cisco, various switches.\r\nAerohive AP's\r\nNetdisco 2.39.31\r\nUbuntu 18.04.01\r\nSNMP 3.61\r\nPostgresql 10.00.4\r\nPerl 5.26.1\r\n"},"comment":{"url":"https://api.github.com/repos/netdisco/netdisco/issues/comments/416216294","html_url":"https://github.com/netdisco/netdisco/issues/436#issuecomment-416216294","issue_url":"https://api.github.com/repos/netdisco/netdisco/issues/436","id":416216294,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNjIxNjI5NA==","user":{"login":"Linwood-F","id":13143855,"node_id":"MDQ6VXNlcjEzMTQzODU1","avatar_url":"https://avatars3.githubusercontent.com/u/13143855?v=4","gravatar_id":"","url":"https://api.github.com/users/Linwood-F","html_url":"https://github.com/Linwood-F","followers_url":"https://api.github.com/users/Linwood-F/followers","following_url":"https://api.github.com/users/Linwood-F/following{/other_user}","gists_url":"https://api.github.com/users/Linwood-F/gists{/gist_id}","starred_url":"https://api.github.com/users/Linwood-F/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Linwood-F/subscriptions","organizations_url":"https://api.github.com/users/Linwood-F/orgs","repos_url":"https://api.github.com/users/Linwood-F/repos","events_url":"https://api.github.com/users/Linwood-F/events{/privacy}","received_events_url":"https://api.github.com/users/Linwood-F/received_events","type":"User","site_admin":false},"created_at":"2018-08-27T12:52:27Z","updated_at":"2018-08-27T12:52:27Z","author_association":"NONE","body":"@inphobia I see that (now), but the query I referenced does not appear to enforce that requirement.  That some of the aerohives (for us) appear and some do not would also seem to discount it somewhat.\r\n\r\nI think the query is asymmetric in the tests for each pair (pair being a->b and b->a).  It needs to find the port on the right side that it has received in the LLD poll on the left, it doesn't appear to try to match that the right side at the same time to see that it sees the left the same way.\r\n\r\nPerhaps a better example of that lack of symmetry is in the test (in the code as written) for dp.ip <= di.ip.  If I ran it with the code as written I get 368 rows (it's 367 if equality is excluded which I I think is because we have a loop on one device).   If I remove the test entirely it is 687 rows, not the 736 you would expect if all the tests were applied equally to left and right side.\r\n\r\nI don't think the Aerohive issue (at least for us) is lack of matching ports, it's lack of any ports being returned by SNMP from the LLDP status in the aerohive itself (does yours show any with the debug statement in my original post?).  So far from not matching on eth0 vs. mgmt, I don't think it has any remote port info (i.e. identifying the cisco) from the aerohive at all.  This means in the query it finds the aerohive when it's on the right side of the query, but not when it's on the left.  And that's OK -- except that the dp.ip <= di.ip presumes it will have found it both times, and it doesn't. \r\n\r\nThat's why I think a more specific test here would be better to eliminate the pair based on whether it finds something, not just the device IP.\r\n\r\nTry changing the query, see if all your aerohives don't appear (and look and see if anything bad does appear)."}}
{"actor":{"display_login":"Linwood-F"}}