Welcome to note number 2 in my series of things I just figured out the hard way and thought might be share-worthy.
Network device groups are awesome, but they have one very important gotcha. Although you can define a network device by subnet or by IP range, adding them to a device group results in unexpected behaviour.
I have a separate device group for my WLAN controllers at each campus. Until recently they contained several individual devices with single IPs. I use them as match conditions on certain services, and also to provide some campus specific enforcement profiles.
I recently brought a cluster online at one of the campuses, and did what seemed the obvious thing and changed the IP address of the existing controller from an IP (10.10.10.10) to a range (10.10.10.10-14) to cover the controllers and VIPs.
This does NOT work in a group context - in other words, you cannot use "Connection:NAD-IP-Address BELONGS_TO_GROUP xxx", if the device group xxx contains any entries with a specified IP range. The condition will still match for any single IP devices though.
The puzzling part was that the same group continued to work fine in the enforcement policy.
OK then, so let's change the device definition for the cluster to use a subnet instead. 10.10.10.10-14 changed to 10.10.10.8/29, and lo and behold, the service definition matched again.
Done and dusted, right? Nope. Now the enforcement profile was no longer being applied. <<sigh>>
I was finally able to get both the service definition and enforcement profile to work by using a device group to declare the subnet.
At the end of the day, I went back and created an individual device for each controller and VIP, and made a couple of device groups for them for maximum flexibility.
Anyway, I hope this helps someone.