ISE 3.1 - Self Documenting or at least, easier to document?

[Lars Norman]

Hi,

I'm using ISE 3.1 in a medium-sized enterprise. I'm trying to document the existing policies, objects, endpoint groups, etc. to be used as a backup for DR purposes.

Yes, I do backup the system the normal way and do test restores, etc. But for DR and maybe audit purposes, I need a "Here's the ISE polices as of this date" type of document.

Screen shots of every endpoint group, blacklist, whitelist, dot1x, MAB, etc. is a great pain in itself, and adding my comments to each screen grab is extra painful!

I've exported the ISE XML file that is usually sent to TAC, but is there a good way to view that? Does a schema exist which I can put into VS Code, or other visualizer?

Is there some other way to document our ISE config in a way that it can be recreated via a printed, executive-readable form (i.e. not XML)? Even Excel or CSV would be helpful!

Thanks,
Lars

[ahollifield]

https://community.cisco.com/t5/security-knowledge-base/ise-high-level-design-hld/ta-p/3657418

I also manually create Visio diagrams of the ISE policy flows.

[Lars Norman]

Thanks for the info. That could help with a new deployment, but I have at least 28,000 endpoints, and other objects that I'd need to eek out and document.

I'd prefer an XLS PowerShell script that "knows" ISE and can just self-document it for me!

After all, I'd bet good money that CIsco TAC doesn't ask me to send the XML file so they can just look at it. They run it through some editor or parser that knows the schema and presents all the objects as nice, formatted data!

Thanks,

Lars

[Arne Bier]

@Lars Norman you're looking for the Holy Grail mate I also believe that TAC have some fancy tool to parse the config. This could be a nice Computer Science student challenge/assignment - take XML and generate a nice graph. I have made Visio diagrams of the functional design - e.g. how TACACS+ auth and all failure scenarios work, or Guest Portal Redirection logic - but I don't represent the diagram as an ISE Policy Set. Because I think this is self-documenting - up to a point - if someone made a mess of the ISE Policy Set then it's not fun to read.

I think documenting the functional intent is better than trying to represent how it actually looks in ISE Policy Set. That also gives you some room to re-factor/re-interpret the Policy Set to be better than what it might currently be.

[Arne Bier · Accepted solution]

I started writing some basic python code using the xml.etree library. Just to inspect the XML file and see if I could make something pretty from it. But after some time I realised that I was handling more and more issues and exceptions. Then I found this XML Editor/Viewer Online - xmlGrid.net

When I pasted my ISE Lab PolicySet XML into it, it looks pretty readable - you can expand the sections you're interested in. It's a lot more readable than raw XML