Hello Nav Users have a question. Netmap with L2 Switches. I have changed topology, but old links are still there on the map.
How to remove from map old connections (grayed out)
[cid:image001.png@01D5E0CF.BBD79EA0]
Best Regards Sebastian Marzec
On Tue, 11 Feb 2020 10:38:12 +0000 "Marzec, Sebastian" Sebastian.Marzec@saint-gobain.com wrote:
Hello Nav Users have a question. Netmap with L2 Switches. I have changed topology, but old links are still there on the map.
How to remove from map old connections (grayed out)
Hi Sebastian,
I just want to clarify that a grayed out link in Netmap only means Netmap has no traffic data for that link.
You asked the same question on IRC, but I'll re-iterate and expound on my answer here, since this will remain in the archives :-)
If you physically disconnect a link between A:1 and B:1, but both A and B remain active and monitored by NAV, NAV will assume the link loss is a temporary error situation, and will not remove the topology information (it might likely generate a linkDown alert).
NAV should remove topology data for a port that lost its link (ifoperstatus != up) if:
1. The port is shutdown by the admin (its ifAdminStatus=down), indicating this link is down on purpose. 2. The neighboring port still seems to be up (which usually indicates the other port has been linked to something else).
I'm not 100% sure both ends of a link will be actually removed from the topology if only one end is placed in shutdown, but generally, the topology analyzer required both ends of a link to point to each other (but under some circumstances, the neighbor can be identified, but does not provide an SNMP agent that can verify the other end of the connection).
However, as described in the topology debugging guide [1] in the documentation, it's best to refer to the topology information as seen from the involved ports' detail pages in ipdevinfo when debugging, rather than trying to rely on what Netmap says. Ipdevinfo shows the direct registrations in the database, while Netmap may put interpretations on top of those. If Netmap and ipdevinfo disagree, the bug might simply be that the data is correct, but Netmap interprets it incorrectly.
So, at the very least, I would suggest you shutdown one or both ports involved in the old link, wait until the ipdevpoll statuscheck job has run for both devices (this job collects port link states, among other things), and run the topology analyzer anew: `navtopology --l2`. And present the data as seen from ipdevinfo, not Netmap.
[1] https://nav.uninett.no/doc/latest/howto/debugging-topology.html [2] https://github.com/Uninett/nav/issues/2106
I have follower provided tip and here's my feedback
I have disabled/shutdown interface A:1 Waited several hours and link was still there, Then I have disabled also interface B1. Ater this operation I got desired result. Link has cleared.
So I you want to remove old link from Netmap you have to disable for some time all associated inferfaces for both connected devices. Thank you.
-----Original Message----- From: Morten Brekkevold morten.brekkevold@uninett.no Sent: Tuesday, February 11, 2020 1:15 PM To: Marzec, Sebastian Sebastian.Marzec@saint-gobain.com Cc: nav-users@uninett.no Subject: Re: L2 Link delete from Netmap
On Tue, 11 Feb 2020 10:38:12 +0000 "Marzec, Sebastian" Sebastian.Marzec@saint-gobain.com wrote:
Hello Nav Users have a question. Netmap with L2 Switches. I have changed topology, but old links are still there on the map.
How to remove from map old connections (grayed out)
Hi Sebastian,
I just want to clarify that a grayed out link in Netmap only means Netmap has no traffic data for that link.
You asked the same question on IRC, but I'll re-iterate and expound on my answer here, since this will remain in the archives :-)
If you physically disconnect a link between A:1 and B:1, but both A and B remain active and monitored by NAV, NAV will assume the link loss is a temporary error situation, and will not remove the topology information (it might likely generate a linkDown alert).
NAV should remove topology data for a port that lost its link (ifoperstatus != up) if:
1. The port is shutdown by the admin (its ifAdminStatus=down), indicating this link is down on purpose. 2. The neighboring port still seems to be up (which usually indicates the other port has been linked to something else).
I'm not 100% sure both ends of a link will be actually removed from the topology if only one end is placed in shutdown, but generally, the topology analyzer required both ends of a link to point to each other (but under some circumstances, the neighbor can be identified, but does not provide an SNMP agent that can verify the other end of the connection).
However, as described in the topology debugging guide [1] in the documentation, it's best to refer to the topology information as seen from the involved ports' detail pages in ipdevinfo when debugging, rather than trying to rely on what Netmap says. Ipdevinfo shows the direct registrations in the database, while Netmap may put interpretations on top of those. If Netmap and ipdevinfo disagree, the bug might simply be that the data is correct, but Netmap interprets it incorrectly.
So, at the very least, I would suggest you shutdown one or both ports involved in the old link, wait until the ipdevpoll statuscheck job has run for both devices (this job collects port link states, among other things), and run the topology analyzer anew: `navtopology --l2`. And present the data as seen from ipdevinfo, not Netmap.
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__nav.uninett.no_doc_late... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Uninett_nav_...
-- sincerely, Morten Brekkevold Uninett
-
Marzec, Sebastian -
Morten Brekkevold