Hello,
These link do not exist:
Interface N/A ??
Copper0/25 at GRA-A-CPD-HP1905
To IP device 172.30.3.30 http://10.10.0.96/ipdevinfo/172.30.3.30/
And the click on Direct neighborship candidates http://10.10.0.96/report/topology_candidates
on Copper0/25 returns empty list !
On 172.30.3.30 has no reference to GRA-A-CPD-HP1905
Maybe an database corrupt?
On Mon, 8 May 2023 22:51:21 -0300 Marcos Tadeu marcos@telecom.uff.br wrote:
Copper0/25 at GRA-A-CPD-HP1905
To IP device MailScanner detectou uma possível tentativa de fraude de "10.10.0.96" 172.30.3.30
And the click on DMailScanner detectou uma possível tentativa de fraude de "10.10.0.96" irect neighborship candidates
on Copper0/25 returns empty list !
On 172.30.3.30 has no reference to GRA-A-CPD-HP1905
All this means is that NAV has resolved 172.30.3.30 as a neighbor on port Copper0/25, but has not been able to detect which port is connected on the other end. Typical if this topology was detected using CAM data with no reciprocity.
The question is: What is *actually* on the other end of Copper0/25 ?
This resolve by self. With more uptime, it could learning.
Other similar issues has appear.
Could I remove an erroneous neighbor? I will try on interface table ;)
Ok. The better solution is turn on LLDP on all sw and this trunk ports...
Em 22/05/2023 10:44, Morten Brekkevold escreveu:
On Mon, 8 May 2023 22:51:21 -0300 Marcos Tadeu marcos@telecom.uff.br wrote:
Copper0/25 at GRA-A-CPD-HP1905
To IP device 172.30.3.30
And the click on Direct neighborship candidates
on Copper0/25 returns empty list !
On 172.30.3.30 has no reference to GRA-A-CPD-HP1905
All this means is that NAV has resolved 172.30.3.30 as a neighbor on port Copper0/25, but has not been able to detect which port is connected on the other end. Typical if this topology was detected using CAM data with no reciprocity.
The question is: What is *actually* on the other end of Copper0/25 ?
On Wed, 24 May 2023 00:38:31 -0300 (3 hours, 38 minutes, 8 seconds ago) Marcos Tadeu marcos@telecom.uff.br wrote:
This resolve by self. With more uptime, it could learning.
Time tends to help.
Could I remove an erroneous neighbor? I will try on interface table ;)
There isn't an easy way to do it that will work universally. Just remember that NAV tends to be very conservative when it comes to removing stale topology: If you physically disconnect a link between two devices, NAV will assume this is an error situation and change nothing (but make an alert). Only if you shutdown the involved interfaces will NAV realize that you meant to remove this link.
Ok. The better solution is turn on LLDP on all sw and this trunk ports...
LLDP is always more accurate than CAM-based guesswork. Definitely recommended.
-
Marcos Tadeu -
Morten Brekkevold