Hi Bing,

This restriction is only enforced by the UI. It is therefore possible to create such a setup through scripting or to end up in this situation by changing the definition of an existing parent instance after child instances have already been created.

I suspect the UI restriction was added simply because such a setup does not make much sense in practice. When selecting the child instance in the UI, you will only see the parameters belonging to the child's definition and not the parameters belonging to the definition of the parent instance.

That said, I don't expect this setup by itself to cause issues, provided that the scripting logic handling these instances can deal with it. Methods such as ProfileParameterEntryHelper.GetNodeProfileParameterEntries (and similar methods used in PLS) can also return parameter values defined on the parent instance, so the scripting logic needs to take that into account.

In this particular case, it looks like there are no parameter values defined on the parent instance, so I don't expect that to cause any problems.

Nevertheless, since the current setup is confusing and there does not seem to be a reason for having the parent and child linked to different definitions, I would recommend changing the parent back to the correct definition (assuming the NAT FW Mapping instance should apply to the definition with the same name).