Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-8137

OpenNMS incorrectly discovers VLANs

    XMLWordPrintable

    Details

      Description

      OpenNMS incorrectly handles discovering switch VLANs. Like described in this article:

      http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/40367-camsnmp40367.html

      to obtain information about switch connections, you have to use custom community strings in SNMP requests. OpenNMS seems to be prepared to do this:

      NodeDiscoveryBridge.java:101
      getPeer().setReadCommunity(community + "@" + entry.getKey());

      But when packets are observed in tcpdump/wireshark, there is only the "normal" community string. The same problem can be observed in enlinkd.log. Although there are multiple VLANs in my switch, OpenNMS always reads data only from the default VLAN, therefore it always gets the same results (the same MACs) ignoring other interfaces:

      ----------------------------------------------------------------------
      2016-01-21 04:23:58,801 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 00012249b001: vlan 10: on port 1 ifindex 10101
      2016-01-21 04:23:58,802 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 000dbc9b5302: vlan 10: on port 1 ifindex 10101
      2016-01-21 04:23:58,830 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 001f6cb86403: vlan 10: on port 2 ifindex 10102
      ----------------------------------------------------------------------
      2016-01-21 04:23:58,197 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 00012249b001: vlan 22: on port 1 ifindex 10101
      2016-01-21 04:23:58,197 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 000dbc9b5302: vlan 22: on port 1 ifindex 10101
      2016-01-21 04:23:58,224 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 001f6cb86403: vlan 22: on port 2 ifindex 10102
      ----------------------------------------------------------------------
      2016-01-21 04:23:57,682 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 00012249b001: vlan 3: on port 1 ifindex 10101
      2016-01-21 04:23:57,683 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 000dbc9b5302: vlan 3: on port 1 ifindex 10101
      2016-01-21 04:23:57,724 DEBUG [DefaultUDPTransportMapping_0.0.0.0/0] o.o.n.e.NodeDiscoveryBridge: processDot1dTpFdbRow: found mac 001f6cb86403: vlan 3: on port 2 ifindex 10102
      ----------------------------------------------------------------------

      To replicate this issue: Setup a Cisco switch with multiple VLANs. Configure OpenNMS so that it doscovers the device. Setup tcpdump to catch outgoing SNMP packets:

      sudo tcpdump -s 0 -i <your interface> udp and dst <switch IP> -w snmp.pcap

      Rescan the switch. Tcpdump should catch all outging packets. Then you can examine snmp.pcap in Wireshark and check community strings. During my tests OpenNMS was always using the basic, not modified community string and that is a bug. It results in not discovering any connected device from other VLANs.

        Attachments

          Activity

            People

            • Assignee:
              rssntn67 Antonio Russo
              Reporter:
              simoncs Szymon Wieloch
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: