Comware

I get an error when I try to apply a QOS policy to a port as per the user guide. Switch is a HP 1920-24G

I select my policy as per the user guide instructions below, I then select inbound

It fails and displays this message -

"Applying or refreshing QoS policy policy to interface GigabitEthernet1/0/19 failed.  Reason: Not supported by hardware"

How can I fix this??

What does the policy look like?
Note:  No need for screen shots, you can download config file from switch

#
acl number 3000
rule 50 permit udp destination-port eq bootps
rule 55 permit udp destination-port eq bootpc
rule 60 permit ip source 10.10.30.0 0.0.0.255 destination 192.168.99.0 0.0.0.252
rule 65 deny ip logging
#

#
traffic classifier classifier_1 operator and
if-match acl 3000
#
traffic behavior behavior_1
filter deny
#
qos policy policy
classifier classifier_1 behavior behavior_1
#

I'd try to get rid of the "logging" statement in the ACL.
Note:Are you trying to block DHCP,  block traffic between the 2 subnets, and allow all other traffic?

Thanks for your response. I need some help with my ACLS.. Overall I would like internet only on VLAN 30 - no access to other VLANS.

I want to allow DHCP requests to VLAN 1 from VLAN 30 ONLY, block all traffic out of VLAN 30 (My DHCP server is in vlan1)

With that being said, I will need to allow all traffic to/from VLAN 99 from VLAN 30 (this is my uplink to the internet)

Any ideas?

I was unsuccessfull with config below:
The permit rules in ACL match all private ranges, on permit rules, policy applies and traffic is blocked. This works OK

The deny rules in ACL (40 50 60) are exclusions for private stuff I want to access. This part doesn't work. Seems like ACL processing doesn't stop at matching deny , but continues processing, finds permit, applies policy, blocking wanted traffic.

acl number 3176
 description Allow DHCP & Internet access
 rule 40 deny ip destination 10.0.0.0 0.255.255.255
 rule 50 deny udp destination-port eq bootps
 rule 60 deny udp destination-port eq bootpc
 rule 80 permit ip destination 10.0.0.0 0.255.255.255
 rule 90 permit ip destination 192.168.0.0 0.0.255.255
 rule 100 permit ip destination 172.16.0.0 0.15.255.255

as i understand it, what you write is correct when using qos for traffic filtering. the traffic behavior (in your exampl - deny) is the action that is taken, weather or not you have permit or deny in the actual acl. all that does is define/match the interesting traffic

so ive attempted creating two acls, two classifiers,  and two corresponding permit and deny behaviors and atteching them to a single policy but once complete i can't assign the policy to an interface..... again the dreaded

 "Applying or refreshing QoS policy policy to interface GigabitEthernet1/0/19 failed.  Reason: Not supported by hardware"

i still can't get it to do what i wan't which is why i was hoping to use the packet-filter command which does do what i want however ..................this isnt availble on my switch for vlan interfaces only physical interfaces.  (see my other post here: http://community.hpe.com/t5/Comware-Based/hp-1910-vs-hp-1920-switch-and-packet-filtering/m-p/6826418 )

If i can get confirmation it's an option on VLAN interfaces on the 1910 series, I will return my 1920 and buy that.

So at this point I've pretty much stuck... 

afaik, policy commands are limited, you can only apply a single action, so your multiple action policy won't work.

I can confirm the hp1910 has packet filter command on vlan interfaces. (and a noisy fan which I don't want at home)

[HP V1910 Switch]int vlan 1
[HP V1910 Switch-Vlan-interface1]?
Vlan-interface interface view commands:
..
  packet-filter  Specify packet filter
..


Maybe construction like this is workaround to block access to subnet but allowing DHCP relay from that subnet.
This way only permit rules in ACL are required, ACL is used in block QoS policy
rule 10 permit udp destination 10.0.0.0 0.255.255.255 destination-port neq bootp
rule 20 permit tcp destination 10.0.0.0 0.255.255.255
rule 30 permit icmp destination 10.0.0.0 0.255.255.255

Have you ever solved this issue?