ISE 2.2p4 using 172.27.0.0 /16 for the NAD, ISE is not finding the NAD

[Richard Wakefield]

ISE 2.2p4 using 172.27.0.0 /16 for the NAD, ISE is not finding the NAD.

If I put in a specific address, 172.27.0.254/32 it works fine.

If I put in a subnet, 172.27.0.0/16, ISE log shows "unknown network device"

I think I am hitting this: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg56391

I tried to pen a TAC case and 2 days later I have not heard anything from them, even after a re-queue. Seems lie an easy question. Is doing /16 or something like that supported? If I'm hitting this bug, is there a hotfix for it?

I get this:

I see the entry 172.27.0.0  /16 here:

So, I created a one-off rule for 172.27.0.254/32 and that worked fine.

In doing some research, they are suggesting that ISE will only allow up to a /24 in the format 172.26.0.1-255/32, I can’t confirm that.

https://communities.cisco.com/message/254809

I tried the above “172.26.0.1-255/32”, and it did work. I left it like that for now until I can get a firm answer on why 172.27.0.0/16 is not working (if it is supported) and if there is a hotfix.

[hslai · Accepted solution]

Many thanks for confirming IP ranges in the form of N1.N2.N3.1-255/32.

There is no hot patch available for ISE 2.2 release yet. Since the issue is not present in ISE 2.3, it might take time to fix it in ISE 2.2 and prepare a hot patch. If you still desire a hot patch, please ask Cisco TAC to request for it.

[Richard Wakefield]

Thank you for the quick reply.

[Richard Wakefield]

From TAC:

--------

I got a confirmation from bug submitter that there is no hot fix available but upgrade to 2.3 will resolve the issue.

There are some other bugs as well which are also pointing to same scenario:

CSCvd69046 CSCvg42588

Possible causes:

-There is another NAD defined with *.*.*.*/24 which is also falling under a subnet range which is defined as other NAD, this creates a conflict and doesn’t recognize the device.

-Use of unsupported browser to add/remove NADs.

-Database corruption.

Action plan:

-Need to validate the above possibilities and fix.

-There is no hotfix available and I confirmed it from the Developer team and they have suggested to upgrade the ISE verison instead.

---------

Upgrading to 2.3 is not acceptable at ths time.

[Jason Kunst]

Unfortunately you will need to either use the workarounds or request an escalation and a fix in 2.2 through a BEMs case with the escalation team.

[Jason Kunst]

Also keep in mind they might consider this an enhancement and that’s why they require you to upgrade. Recommend escalating the issue

[Richard Wakefield]

It should not be considered an enhancement, since doing 172.16.0.0 /16 worked in previous versions of ISE, I have a 172.17.0.0/12 running with 2.0p5 in production right now. It is a documented Sev3 bug.

If /32 was the only acceptable mask, why is it configurable?

[Jason Kunst]

Ok then please escalate

[hslai]

Since TAC able to confirm the bug(s), please ask for a hot patch. It would take some time to find the root cause since the issue is not present in ISE 2.3.

[Richard Wakefield]

I've asked, they are pushing back telling me to upgrade to 2.3.

[hslai]

If you share the TAC case number, then I can take a look.

[Richard Wakefield]

683447406, thank you

[riwakefi]

Two months later the BU is still pushing back on doing a hotfix or patch for 2.2 to resolve this, the only excuse is that "it isn't broken in 2.3 so I should be using that", which isn't an acceptable answer.

[Jason Kunst]

You can ask for escalation thru the tac if its critical to your business or reach out to the Product management team to see if they will include in prior release. Provide them the tac case. We can’t guarantee all bugs are fixed in prior releases but we do our best depending on the effort involved.

[riwakefi]

All of the above was already done (case escalated, sales team involved to address the BU), most of which was documented in this thread including the TAC case number.