Open for Voting

Cisco ISE Monitoring

Since Cisco is sunsetting ACS, I'd love to see some monitoring features for Cisco ISE added. It would be nice to be able to download the config of the ISE appliance like I can with any switch, router, or firewall. I'd also love to see some sort of template to set up monitoring for ISE. I've been working with Cisco for some time now on a ticket to get my ISE appliances to recognize SolarWinds still to no avail. Some sort of template for making this happen would be helpful.

Parents
  • I agree, this is something I'd like, too.

    Has Cisco indicated there are a small number (preferably just ONE) files in which all ISE configurations are stored, that can be read or offloaded by NCM, and compared for a daily configuration change report?

    The more things Cisco puts into appliances that look like servers, the less likely we are to be able to manage their configs with NCM.  The same goes for Cisco's applications.

    Once you move away from flat running-config and startup-config files, like those found in IOS, IOS-XE, NXOS, etc., the bigger the challenge I think Solarwinds has trying to get that data and store it and compare it for us.

    It's almost as if Cisco is trying to move their applications into the cloud, and just sell dumb switches that get their configs from the cloud.  Talk about WAN / ISP pipes being needed!  Maybe that's where Cisco should invest next.

Comment
  • I agree, this is something I'd like, too.

    Has Cisco indicated there are a small number (preferably just ONE) files in which all ISE configurations are stored, that can be read or offloaded by NCM, and compared for a daily configuration change report?

    The more things Cisco puts into appliances that look like servers, the less likely we are to be able to manage their configs with NCM.  The same goes for Cisco's applications.

    Once you move away from flat running-config and startup-config files, like those found in IOS, IOS-XE, NXOS, etc., the bigger the challenge I think Solarwinds has trying to get that data and store it and compare it for us.

    It's almost as if Cisco is trying to move their applications into the cloud, and just sell dumb switches that get their configs from the cloud.  Talk about WAN / ISP pipes being needed!  Maybe that's where Cisco should invest next.

Children
  • rschroeder​,

    Have you seen the latest hardware from Cisco? Cisco Cloud Services Platform 2100 - Cisco , you pick and choose what modules (router, switch, IPS, firewall) and licenses you want to build a device that can do what you want/need. And the configuration is pushed down to it once it registers with a controller. Meraki is similar in that it gets it's config once it registers with a cloud controller. Now let's throw into the mix the latest Vipela acquisition. So to your statement, "It's almost as if Cisco is trying to move their applications into the cloud, and just sell dumb switches that get their configs from the cloud." ... there's nothing "almost" about it. emoticons_happy.png

    D

  • We've wasted so much time & effort on ISE.  Cisco promised it was compatible with our hardware, then we spent six months proving it overloaded the CPU & memory on 400 Cisco 2960S switches.  Cisco's going to replace them for us at 25% of list--not bad.  But we really went through a lot of stress getting to this stage.  It'll take a year now, since we've a lot of 7x24 hospital sites.

    We see cases where devices, that were learned by ISE Discovery Mode, drop off the network when Enforcement Mode is applied.  It's as if the white listing doesn't work at all.

    Worse is when some devices don't even get along with Discovery Mode.  They won't pass packets even when ISE is simply observing!  And we must remove all ISE config lines from their switch ports.

    It's an interesting product idea, but deploying it has not been what we were lead to expect.  There's no going back, though.  It's already saved us from countless issues.

    On a very similar path, ACI has some parallel characteristics to ISE, and we've had that for two years.  All the security promised by Cisco through ACI in the data centers has not panned out well.  The vendors and application sales people and their in-house support experts typically don't know what protocols & ports & communications are required, so we end up not implementing all the ACI security we'd like.

    And yesterday Cisco told us "anyone using the ACI GUI has something wrong.  All management should be done via scripting."  Funny, they sold us on ACI's ability to do everything via GUI--that it was the wave of the future.  Snort.

  • Take it for what it's worth, but my sales team told me not to use ACI...dev wasn't going well and it may get pulled. They'll still provide XML/python scripting capabilities, but ACI in it current "gen1" state may go (watch for Viptela to replace it?). My ISE deployment has been solid, but I'm not a hospital and I've limited the features I use. Really hoping SGT (security group tagging) works out...that's the Holy Grail of packet pushing.

    D

  • We just upgraded to ISE 2.4; things are significantly improved.  I can't say Cisco has it all right, but it's also not all on their backs.  One product line of bar code printer we use (over a thousand of these printers) was reportedly incompatible with our standard network switchport ISE and VLAN settings, and we'd have to manually remove the Voice VLAN from every switchport connecting to one of these printers to get them to work.  And then their users would report in a few weeks that they'd hung again.  It turns out neither ISE nor VLAN configuration lines were the cause--the vendor admitted their product did not respond properly when a session to one of their ports unexpectedly was interrupted; their printer would hang until it was rebooted.  We use network security probing tools like Nexus and Nexpose and Rapid 7; and guess what they do?  Probe all ports and disconnect without any acknowledgement.  It might be our Security team was shooting us in the foot, and we were blaming Cisco when we should have blamed the printer manufacturer.