Comment 1 for bug 1398382

The problem appears to be with the backend code that processes ELINK prefixes and inserts these into the topology graph.

An ELINK peer is a node that is not monitored by NAV, so the code will insert a stubbed ELINK node into the graph it is constructing. The stub code, located in nav.netmap.stubs, consists of stub classes representing Netboxes, GwPortPrefixes and Interfaces. However, the __hash__ implementation of the GwPortPrefix and Interface classes do not ensure uniqueness across all nodes. The biggest problem is for the GwPortPrefix stub class, which uses only the gw_ip for hashing. This would be fine if actual IPs were used, but for stub classes, the peer name (derived from the netident) is inserted as the gw_ip. If this peer appears multiple times in the graph, the data will be fudged, since the GwPortPrefix is supposed to represent individual router ports of this peer.

(In effect, all the GwPortPrefixes of this ELINK peer would hash to the same value, and there will be conflicts).