Highlighted
Frequent Visitor.
422 views

NNM creates incorrect connections.

Hello.

I use NNM 10.20.280. I have many devices with two ethernet ports and one mac for both ports. No cdp or LLDP like functions. Sometimes the NNM creates links with down port (pic1), and never checks or change them. If i delete the device and add it again, the connection will be correct. How NNM choose which interface use to create link?
The next question is about FDB connections. Initially, the devices didn't support dot1dBasePort and the connections were with the clouds. I added support dot1dBasePort and dot1dBasePortIfIndex to them and now:
collect.BaseCollectHandler] (pool-1-thread-18) DDTable= dot1dBasePort dot1dBasePortIfIndex
----------------------------------------
13 13
14 14 TalkStatus=NULL.
After that, some links became correct. But most of the devices remain without any connections. They have status  "Not Polled". Can anyone answer what information is needed for the NNM to make the correct connections?

Sample log, two device

local
id: 2147561461
downlink: 14
mac: 001349A4508F
port id: 2147561498

remote
id: 38655169894
uplink: 13
mac: 0019CB081026
port id: 38655169927

analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of Dot1dportDTO on switch 2147561461: 2
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) adding 2147561461 to switchIDs list.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of FdbDTO on switch 2147561461 port 13: 9
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of FdbDTO on switch 2147561461 port 14: 2
..skipped
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of Dot1dportDTO on switch 38655169894: 2
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) adding 38655169894 to switchIDs list.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of FdbDTO on switch 38655169894 port 13: 8
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of FdbDTO on switch 38655169894 port 14: 1
..skipped
analyzer.l2.SwitchFdbToConns] # of Dot1dportDTO on switch 2147561461: 2
analyzer.l2.SwitchFdbToConns] adding 2147561461 to switchIDs list.
analyzer.l2.SwitchFdbToConns] # of FdbDTO on switch 2147561461 port 13: 9
analyzer.l2.SwitchFdbToConns] # of FdbDTO on switch 2147561461 port 14: 2
..skipped
analyzer.l2.SwitchFdbToConns] Starting on switch 2147561461
bean.NmsConnectionBean] Found connected ifaces 0
analyzer.l2.SwitchFdbToConns] Found 0 currently existing connections on switch 2147561461.
analyzer.l2.SwitchFdbToConns] Starting on port 13
analyzer.l2.SwitchFdbToConns] # of FdbDTO on port 13: 9
analyzer.l2.SwitchFdbToConns] Node/Switch FDB: 0/9
analyzer.l2.SwitchFdbToConns] Fdb record com.hp.ov.nms.disco.bean.FdbDTO@edefff8d points to an unusable MAC address, so we are skipping it.
..skipped
analyzer.l2.SwitchFdbToConns] Fdb record com.hp.ov.nms.disco.bean.FdbDTO@4390c669 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] local 2147561461 remote 2149628482...
analyzer.l2.SwitchFdbToConns] ...found potential interswitch 17179960728, checking for meshes
analyzer.l2.SwitchFdbToConns] ...local switch does not hear interswitch 17179960728
analyzer.l2.SwitchFdbToConns] ...remote switch hears interswitch 17179960728 on same port as local
analyzer.l2.SwitchFdbToConns] ...interswitch 17179960728 is valid
analyzer.l2.SwitchFdbToConns] Starting on port 14
analyzer.l2.SwitchFdbToConns] # of FdbDTO on port 14: 2
analyzer.l2.SwitchFdbToConns] Node/Switch FDB: 0/2
analyzer.l2.SwitchFdbToConns] Fdb record com.hp.ov.nms.disco.bean.FdbDTO@bdf49760 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] Fdb record com.hp.ov.nms.disco.bean.FdbDTO@bb7d409b points to an unusable MAC address, so we are skipping it.
..skipped
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Starting on switch 38655169894
bean.NmsConnectionBean] (pool-1-thread-28) Found connected ifaces 0
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Found 0 currently existing connections on switch 38655169894.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Starting on port 13
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) # of FdbDTO on port 13: 8
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Node/Switch FDB: 0/8
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@e8ac1891 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@eeb0cd00 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@f117d356 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@4ec28231 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) local 38655169894 remote 2149628482...
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...found potential interswitch 2147561461, checking for meshes
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...local switch does not hear interswitch 2147561461
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...remote switch hears interswitch 2147561461 on same port as local
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...interswitch 2147561461 is valid
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@4eeb3a26 points to an unusable MAC address, so we are skipping it.
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) local 38655169894 remote 2147573635...
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...found potential interswitch 2147561461, checking for meshes
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...local switch does not hear interswitch 2147561461
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...remote switch does not hear interswitch 2147561461
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) ...interswitch 2147561461 is valid
analyzer.l2.SwitchFdbToConns] (pool-1-thread-28) Fdb record com.hp.ov.nms.disco.bean.FdbDTO@edf4cc2b points to an unusable MAC address, so we are skipping it.

bean.NmsDiscoFdbBean] Unchanged FDB (pid: 36507265673) for Node (pid): 2147561461
Port: com.hp.ov.nms.disco.model.Dot1dPort{class = class com.hp.ov.nms.disco.model.Dot1dPort, id = 36507265662, ifIndex = 14, ifPid = 2147561498, ifType = 6, mac = 001349A4508F, nodeId = 2147561461, port = 14, tenantUUID = 1b96011e-8829-4e5d-8ab7-f93b7b10ac79, uuid = 29794858-0ad2-4ac3-a04f-9fa7d9f302d4}
VLAN: 900 MAC: 0019CB081026 RESOLVED to Remote Node (pid): 38655169894
Type: Switch Interface (pid): 38655169927 (shared mac)

How can i check why some mac is unusable? 

Thanks!

0 Likes
2 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: NNM creates incorrect connections.

FDB relies on the ARP tables on both sides of the connection, so your results can change and will upon its expiration and next poll. the ARP table only lists the source of its last reception.

Have a nice day 🙂

Andy Kemp
I've lasted longer in the technology industry than most certifications.
0 Likes
Highlighted
Frequent Visitor.

Re: NNM creates incorrect connections.

I can't retrieve the arp table via snmp from my devices, they don't support it =( They works on layer 2, and in arp table can be only one arp record from the gateway. Is it really so necessary? I think it should be something more substantial. Or it so looks for an uplink interface?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.