2 Replies Latest reply on Mar 3, 2017 9:24 AM by prezes

    IPAM V4.2 Neighbor Discovery disappointment with Cisco

    foonly

      I was really excited to hear that the latest IPAM, v4.2, had added automatic discovery of IPv6 addresses from neighbor tables. Without this, IPv6 is impossible to manage in any medium to large Enterprise. DHCPv6 doesn't list all the addresses a client may have, and there's no way to discover IPv6 via ping, unless you have an extra few decades per subnet to wait.

       

      In particular, the DMZ off of most of our firewalls is the greatest black hole in IP management. Devices in the DMZ are seldom in Active Directory, and they don't usually use DHCP for assignment. It's bad enough trying to do a ping discovery through a firewall. ASA's Attack Guard will swat down packets that exceed a certain rate, even if you have an ACL allowing it - and won't even tell you it did so till it exceeds a specific threshold. Attack Guards are poorly documented at best.

       

      So I was really disappointed to find out that IPAM couldn't get anything from any of our devices in the datacenter that we really care about - core switches or firewalls. It's not IPAM's fault. It's clearly Cisco's. I spent a few tedious hours testing a variety of devices, using various SolarWinds SNMP tools. IPAM can only use a few well known OIDs, documented in the online manual:

       

      http://www.solarwinds.com/documentation/en/flarehelp/ipam/#ipv6monitoring.htm

       

      "IPv6 Scanning

       

      IPAM IPv6 address discovery is based on the NDP protocol and information is obtained from routers based on the following MIBs / OIDs:

       

      •   IPv6 MIB, OID 1.3.6.1.2.1.55.1.12.1.2 (ipv6NetToMediaTablePhysicalAddress)
      •   IP MIB, OID 1.3.6.1.2.1.4.35 (ipNetToPhysicalTable)
      • ipv6NetToMediaValid - 1.3.6.1.2.1.55.1.12.1.6
      •   Cisco proprietary CISCO-IETF-IP-MIB , OID 1.3.6.1.4.1.9.10.86.1.1.3 (cInetNetToMediaTable)

      Note: For troubleshooting purposes verify the device OIDs with those listed above."The devices we have that failed to pass muster were:

      • ASA 5585's running 9.1(1)4 - no of the above OIDs were supported or returned anything
      • Nexus 7009's running NX-OS 6.2(8a) - (collapsed core) - only OID 1.3.6.1.2.1.4.35
      • 6513 running IOS 12.2(33)SXI13 - (collapsed core) - only OID 1.3.6.1.4.1.9.10.86.1.1.3

       

      It's bad enough that NX-OS has been out for over 5 years, yet still has no RA Guard, which is required on many federal networks. It only recently got DHCPv6 Relay. ASA doesn't have RA Guard, either. Most DMZ's use the ASA as the router, and are the likely attack target. The 6513's are old, and soon to be replaced with more Nexus flagships.

       

      We've got some ideas on how to handle the RA Guard, but the total lack of IPv6 manageability via Cisco flagship devices is appalling. They've only had 15 years to get ready. None of this is even mentioned in the many IPv6 webinars I've attended, nor the Best Practices documents. Such webinars and docs are clearly not in touch with the real world.

       

      I would be happy to hear of experience with HP and Juniper in regard to IPv6, IPAM OIDs, and RA Guard (First Hop Security in general).

       

      The only other way to automatically pull Neighbor tables is via an SSH session. So we'll be having a look at the API again. Maybe the IPAM developers could, too.

       

      "parse on, son!"

      =seymour=