Question about service object-group usage in ACLs on a Catalyst3650?

[hemmerling]

What would be an object-group equivalent for the following ACL in a Catalyst 3650 running 16.x when using service group-objects?

 ip access-list extended TEST_ACL
 permit tcp 192.168.0.0 0.0.0.255 eq 332 host 172.16.0.1 eq 41
 permit tcp 192.168.0.0 0.0.0.255 eg 332 host 172.16.0.2 eq 41

I'm thinking it would be:

object-group service PORTS
 tcp 41
 tcp source 332
!
object-group network NETWORK_1
192.168.0.0 255.255.255.0
!
object-group network SERVERS
host 172.16.0.1
host 172.16.0.2
!
ip access-list extended TEST_ACL
 permit object-group PORTS object-group NETWORK_1 object-group SERVERS

Is this correct?

Is this how you define the destination port "41" in a service object-group? By not adding anything in front of it?
The documentation isn't really clear that it's a destination only port if a source isn't defined. (obscured further by the fact it goes in front of the source object and the CLI doesn't say so.)

I'm trying to get away from using statements like this:

permit tcp object-group NETWORK_1 eq 332 object-group SERVERS eq 41

Thank you.

[pieterh]

on the ASA service groups are defined like:

object service service-tcp-4567
    service tcp destination eq 4567

object service sg_hsrp
   service udp destination eq 1985

object-group icmp-type sg_icmp-replies
   icmp-object echo-reply
   icmp-object source-quench
   icmp-object time-exceeded
   icmp-object unreachable

and rule is like

   access-list ACLname extended deny object sg_hsrp object source1-objectname  object dest-objectname ( log disable)
  access-list ACLname extended permit icmp any object source2-objectname object-group sg_icmp-replies 

The network and server objects look ok,
but you can also use a friendly hostname for it's IP-address and add those hostnames to a group

object network amsterdam
   host 172.16.0.1
object network rotterdam
   host 172.16.0.2
object-group network SERVERS
   network-object amsterdam
   network-object rotterdam

your translation of 
   permit tcp object-group NETWORK_1 eq 332 object-group SERVERS eq 41
to
   permit object-group PORTS object-group NETWORK_1 object-group SERVERS
will behave differently from the original as the original only allows 332 as the source port
and the translation allows both 41 and 332 as the source port (both in the group PORTS) etc.

[hemmerling]

The 3650 definitely behaves differently than an ASA.
I thought the feature was almost useable before (in that being able to declare a service group of ports for either the source or destination separately would have made it useful for cleaning up ACLs).
Upon trying to actually use it I can say that it is not really useful on a 3650 for anything other than maybe QOS.

For example, switch A (192.168.1.3) cannot ping switch B (192.168.1.4) if the following is applied to switch B

object-group network NETWORK-DEVICES
 host 192.168.1.3
 host 192.168.1.4
!
object-group service ICMP_PORTS
 icmp
 icmp echo
 icmp echo-reply
 ip
!
ip access-list extended ACCESS_ACL
 10 permit icmp object-group NETWORK-DEVICES object-group NETWORK-DEVICES
 20 permit icmp object-group NETWORK-DEVICES object-group NETWORK-DEVICES echo
 30 permit icmp object-group NETWORK-DEVICES object-group NETWORK-DEVICES echo-reply
 40 permit ip object-group NETWORK-DEVICES object-group NETWORK-DEVICES
 50 permit object-group ICMP_PORTS object-group NETWORK-DEVICES object-group NETWORK-DEVICES
 60 deny icmp any any
!
interface vlan 100
 ip address 192.168.1.4 255.255.255.0
 ip access-group ACCESS_ACL in

even in the various ways I tried (variations 10-50 and every type of icmp in the service group), it never works, the ping is always denied.

I'm guessing it's because of this restriction listed in the documentation.

"ACL statements using object groups will be ignored on packets that are sent to RP for processing."

The same documentation says it works on VLAN interfaces, but clearly it must not mean its own. It ignores anything directed to the device it's configured on, so it's pretty worthless. I'm mean it will work on traffic passing through to other switches in the same vlan as itself, just not itself, so pretty much useless.

Unless I'm wrong, please correct me if I am, I was really looking forward to making all ACLs more manageable.