[PNP]Unable to accept EULA when adding PNP rule in GUI

[zlantz]

According to the the 1.3.2 release notes, the issue where you are unable to accept the EULA when adding a rule has been fixed, however, I just ran into this issue in 1.3.2.37. For reference,CSCvc13812. Also, my team and I are unable to actually look at these bug IDs in detail. We click the links and it tells us that we have insufficient permissions to view these bugs. That goes for all bug IDs in the recent APIC-EM release notes. This was also working fine yesterday with the same version and nothing has really be done since yesterday when I deployed a new rule successfully.

[aradford]

Hi Zak,

I tried a few times and it is working for me,  Can you show a screen shot of the rule and then the error when you try to convert it to a stack please?

Adam

[zlantz]

This was actually a rule for a single switch and I will get you a screenshot tomorrow as we rebooted the box to see if that would help and the services have not yet fully started yet.

[aradford]

The initial bug was editing a single device rule and converting it to a stack.

Are you saying that you are trying to edit a single device rule and getting the same error?

[zlantz]

What we are seeing is when initially making a single device rule not editing a single device rule, I will not be able to accept the EULA. I'll be doing more to reproduce the issue today.

[zlantz]

Just confirmed that I can not add a single device rule because I can not accept the EULA, but a multiple device rule works with no issues. I am using a 3650-24PS/ 3650-48PS. For example, I can make a complete rule or I can just put in the bare minimum information and no configuration. Both of these break with the "you must accept the EULA" error when attempting to add the rule. A stack works fine with the same configurations that I was using for the single device rule.

However, I just found a work around and the possible cause of the problem. The single device rule will be added if you do not choose a license type. Choosing any license type breaks the rule for single devices.

[aradford]

Hi Zak,

the only way you can specify a license it to choose a stack.

All of the parameters in the red box are stacking parameters.  If you select a licence, then that implies a stack.  If you do not specify a member count then it defaults to 7.

[zlantz]

Ah, now I understand why this was so confusing. We had been using the stack configuration section on all deployments, even single switches because we have always been told that even single stack wise switches are a stack, just a stack of 1. Since there was no "1" in the expected member count, we have just been leaving that blank.

When doing this in the latest version, it would tell me that I had to accept the EULA. The previous versions did not do this, hence why I thought this was standard procedure for 1 switch deployments and a bug. Still may be nice to spit out a different error message if someone leaves the expected member count blank and fills out the license/EULA.

[aradford]

Hi Zak,

yeap, this is correct.  The current behaviour is to set member count to 7 if you leave it blank.

I agree on the error message.  I will chat with engineering.

Adam

[zlantz]

The solution above did resolve our issues.

So currently, we are not able to change the license of a single switch during deployment? Or is there another work around for this?

[aradford]

Hi Zak,

there are a couple of things here.

1) for switch stacks, if you have different licenses on the members, the stack will be split in two, so we need to have licence changes for stacks and stack members.

2) In order to do this for non-stack, we need to support all devices, routers, switches etc.  Currently there are different mechanisms on routers for licensing and enforcement

3) For the 3850 and 3650 (common stacks) licensing is RTU, which makes it much simpler to change in the stack scenario.

We are looking at more general license integration in future.

Adam