Sorry for spamming the list: the old topology detector has been removed, so please ignore this.
We're still having problems with the topology not updating.
Is this related to the way we handle linkdown status messages? Should they be cleared or acknowledged when the topology has changed?
best regards Andreas Dobloug USIT/UiO
-----Original Message----- From: Andreas Dobloug Sent: Thursday, August 24, 2017 10:22 AM To: Andreas Dobloug andreas.dobloug@usit.uio.no; Morten Brekkevold morten.brekkevold@uninett.no Cc: nav-users@uninett.no Subject: RE: Outdated cam records
We've tried this, and nothing is logged other than "topo for <switch>
completed
in ..."
Should we try to activate the old topology detector (/usr/lib/nav/network- discovery)?
Sorry, this last part is probably unrelated: the topology is also not updating.
best regards Andreas Dobloug USIT/UiO
On Thu, 24 Aug 2017 09:05:28 +0000 Andreas Dobloug andreas.dobloug@usit.uio.no wrote:
We're still having problems with the topology not updating.
Is this related to the way we handle linkdown status messages? Should they be cleared or acknowledged when the topology has changed?
Maybe. The topology detector will not update topology information for ports that are operDown - the assumption being that operDown is a temporary error situation. If, however you shutdown the port (admDown), topology will be updated - this is taken as a signal that the down state was deliberate.
Maybe. The topology detector will not update topology information for ports that are operDown - the assumption being that operDown is a temporary error situation. If, however you shutdown the port (admDown), topology will be updated - this is taken as a signal that the down state was deliberate.
Thanks. We'll try that :)
best regards Andreas Dobloug USIT/UiO
Maybe. The topology detector will not update topology information for ports that are operDown - the assumption being that operDown is a temporary error situation. If, however you shutdown the port (admDown), topology will be updated - this is taken as a signal that the down state was deliberate.
Thanks. We'll try that :)
This did not work. Topology is not updating - even when the port is in shutdown. (Two cisco switches).
best regards Andreas Dobloug USIT/UiO
On Wed, 30 Aug 2017 06:18:36 +0000 Andreas Dobloug andreas.dobloug@usit.uio.no wrote:
This did not work. Topology is not updating - even when the port is in shutdown. (Two cisco switches).
I'm still assuming the issue here is that NAV still says that X is connected to Y. So now you have shutdown X. Is Y shutdown also, or has it been connected to something else?
I'm still assuming the issue here is that NAV still says that X is connected to Y. So now you have shutdown X. Is Y shutdown also, or has it been connected to something else?
Y is connected to a different port or different switch. X is in shutdown. Topology still shows the old port even though the port on switch X is in shutdown.
best regards, Andreas Dobloug USIT/UiO
On Wed, 30 Aug 2017 09:11:45 +0000 Andreas Dobloug andreas.dobloug@usit.uio.no wrote:
I'm still assuming the issue here is that NAV still says that X is connected to Y. So now you have shutdown X. Is Y shutdown also, or has it been connected to something else?
Y is connected to a different port or different switch. X is in shutdown. Topology still shows the old port even though the port on switch X is in shutdown.
In the report system, there is a report titled "Direct neighborship candidates". Can you find any candidate neighbors for port X there?
The switch shouldn't provide any, since the port is shut down, but if they still are reported by the switch (or not being removed from NAV), then resulting topology may be stale.
There is an idea, that hasn't been implemented, that the topology detector should remove topology information for a port that is down, if the old neighboring port is still up - which would be an indicator of your case, where the link has been taken away and one of the ports reused for another link.
OTOH, we know of several weaknesses in the topology detector come from simply using the same topology deduction algorithm for LLDP and CDP data as is used for CAM-based data. We are working on a rewrite of the topology detector to use more reasonable algorithms with data provided from LLDP and CDP [1], which should hit NAV 4.8 sometime this fall.
[1] https://github.com/UNINETT/nav/pull/1549
In the report system, there is a report titled "Direct neighborship candidates". Can you find any candidate neighbors for port X there?
No.
There is an idea, that hasn't been implemented, that the topology detector should remove topology information for a port that is down, if the old neighboring port is still up - which would be an indicator of your case, where the link has been taken away and one of the ports reused for another link.
Ok, what if the 'clear the alerts' action removed the link from the topology? Acknowledge the alert would indicate that the link-down is temporary.
OTOH, we know of several weaknesses in the topology detector come from simply using the same topology deduction algorithm for LLDP and CDP data as is used for CAM-based data. We are working on a rewrite of the topology detector to use more reasonable algorithms with data provided from LLDP and CDP [1], which should hit NAV 4.8 sometime this fall.
Looking forward to it :).
Thanks for the clarifications.
best regards Andreas Dobloug USIT/UiO
On Thu, 31 Aug 2017 10:09:37 +0000 Andreas Dobloug andreas.dobloug@usit.uio.no wrote:
Ok, what if the 'clear the alerts' action removed the link from the topology? Acknowledge the alert would indicate that the link-down is temporary.
Possibly. I just added an issue for topology staling investigation at [1], but perhaps you would post a separate issue for this idea, so we could evaluate it separately.
[1] https://github.com/UNINETT/nav/issues/1574
-
Andreas Dobloug -
Morten Brekkevold