[ISE2.2] Originating Policy Services Node behavior

[masyamad]

I'm testing "Originating Policy Services Node" setting with ISE2.2 distributed topology.

With some best practice guidance, I changed the setting from "Auto" to nearest PSN on the setting. 

It works as expected first. But it the PSN goes offline, SNMP query node will not fallback to other PSNs.

Is it expected behavior?

My customer's expectation is as follows.

- Configured PSN always sends SNMP Query to the NAD if the PSN is active

- If the PSN becomes offline, next PSN is randomly selected. Then the next PSN sends SNMP Query instead till original PSN is recovered.

[masyamad]

2nd try. Could someone take a look on this?

[hslai]

That might be expected. I am checking on it.

[Craig Hyps · Accepted solution]

Yes. This is expected behavior.  Once a specific PSN is selected for polling, the only way to force an association with another PSN is to de-register the original PSN.  I believe the behavior is same for Auto, but would be interested to hear if seeing different behavior with Auto selected.

I recommend filing a defect to help address the caveat.  I thought there may have already been one opened, but not finding it.  In past I requested enhancements to provide fallback, to allow source PSN value to be set in bulk via UI, as well as to auto-select PSN based on location.  Today the only option is to use ERS API to script such changes. 

/Craig

[masyamad]

Thanks hslai, chyps,

> Once a specific PSN is selected for polling, the only way to force an association with another PSN is to de-register the original PSN.

OK. But re-configuring originating parameter on NAD setting (from a certain PSN to another, or back to auto) doesn't effect?
The de-registering PSN from PAN is an impact for existing deployment. So I'd like to make sure.

> I believe the behavior is same for Auto, but would be interested to hear if seeing different behavior with Auto selected.

OK. I'll ask my customer to test the "Auto" behavior.

> I recommend filing a defect to help address the caveat.

OK. But I'd like to confirm what the current caveat is. Does it mean "need de-registering for PSN change"?

Could you let me know about 1) what the current caveat, and 2) what the desired produce behavior is?

[Craig Hyps]

The issue is that we do not auto-assign a different PSN upon failure of current designated poller.  This coincides with your initial report.  The desired behavior is for ISE to more gracefully handle the PSN failure.   There are many possible scenarios and solutions, but they do not currently exist so that is why I propose open TAC case and have bug filed.   Yes, de-registering the failed PSN should resolve, but I will admit this is not a desirable solution and only a workaround.   If temporary failure of PSN, then this generally should not have a major impact as the SNMP poller is primarily used as a catch all mechanism whereas RADIUS Accounting should trigger active endpoints entering and leaving network.  If expect PSN to be down for extended period, then you could de-register.

Craig

[masyamad]

I see. I'll try to open with account team's help. Thanks!