HP 1920-24g - Assigning ACL to Port error "not supported by hardware"

[-TM-]

Hi, 

I'm getting error messages on assigning any ACL to any port on a hp 1920-24G. Tried 3 different versions of firmware, including latest. 

HP 1920G Switch QOS/4/QOS_POLICY_APPLYIF_FAIL: Applying or refreshing QoS policy p1 to interface GigabitEthernet1/0/12 failed.^M
Reason: Not supported by hardware.

I wasn't yet able to solve this problem. Anyone having any suggestions?

Is it possible to set acl on an interface via web gui, or is it just possible to do it via CLI?

what i tried: reset to factory defaults, then:

%Apr 26 12:28:30:673 2000 HP 1920G Switch ACL/5/WEBOPT_CREATEACL: (by admin via web from host 192.168.178.36) Create ACL 3000.^M
%Apr 26 12:29:15:254 2000 HP 1920G Switch ACL/5/WEBOPT_ADDRULE: (by admin via web from host 192.168.178.36) Add rule 0 to ACL 3000.^M
%Apr 26 12:29:31:684 2000 HP 1920G Switch ACL/5/WEBOPT_ADDRULE: (by admin via web from host 192.168.178.36) Add rule 5 to ACL 3000.^M
%Apr 26 12:30:00:923 2000 HP 1920G Switch QOS/5/WEBOPT_CLASSIFIER_CREATE: (by admin via web from host 192.168.178.36) Create QoS classifier c1.^M
%Apr 26 12:30:12:542 2000 HP 1920G Switch WEB/4/WEBOPT_LOGOUT: admin logged out from 192.168.178.36^M
%Apr 26 12:30:25:943 2000 HP 1920G Switch QOS/5/WEBOPT_CLASSIFIER_ADDRULE: (by admin via web from host 192.168.178.36) Add rule to QoS classifier c1. Rule value: match acl 3000.^M
%Apr 26 12:30:52:133 2000 HP 1920G Switch QOS/5/WEBOPT_BEHAVIOR_CREATE: (by admin via web from host 192.168.178.36) Create QoS behavior b1.^M
%Apr 26 12:31:06:877 2000 HP 1920G Switch CFGMAN/5/CFGMAN_CFGCHANGED: -EventIndex=2-CommandSource=2-ConfigSource=4-ConfigDestination=2; Configuration is changed.^M
%Apr 26 12:31:37:583 2000 HP 1920G Switch QOS/5/WEBOPT_BEHAVIOR_ADDACTION: (by admin via web from host 192.168.178.36) Add action to QoS behavior b1. Action value: filter permit.^M
%Apr 26 12:32:00:453 2000 HP 1920G Switch QOS/5/WEBOPT_POLICY_CREATE: (by admin via web from host 192.168.178.36) Create QoS policy p1.^M
%Apr 26 12:32:16:424 2000 HP 1920G Switch QOS/5/WEBOPT_POLICY_ASSCB: (by admin via web from host 192.168.178.36) Associate classifier c1 with behavior b1 in QoS policy p1.^M
%Apr 26 12:32:42:087 2000 HP 1920G Switch QOS/4/QOS_POLICY_APPLYIF_FAIL: Applying or refreshing QoS policy p1 to interface GigabitEthernet1/0/12 failed.^M
Reason: Not supported by hardware.^M

Here's the part of my config: 

=================================================================^M
  ===============display current-configuration===============^M
=================================================================^M
#^M
 version 5.20.99, Release 1110^M
#^M
 sysname HP 1920G Switch^M
#^M
 dhcp relay server-group 1 ip 192.168.178.254^M
#^M
 domain default enable system^M
#^M
 ipv6^M
#^M
 telnet server enable^M
#^M
 password-recovery enable^M
#^M
acl number 3000^M
 description TEST Allow all Traffic^M
 rule 0 permit ip source 10.10.41.0 0.0.0.255^M
 rule 5 permit ip source 192.168.178.0 0.0.0.255^M
#^M
vlan 1^M
#^M
vlan 2^M
#^M
domain system^M
 access-limit disable^M
 state active^M
 idle-cut disable^M
 self-service-url disable^M
#^M
traffic classifier c1 operator or^M
 if-match acl 3000^M
#^M
traffic behavior b1^M
 filter permit^M
#^M
qos policy p1^M
 classifier c1 behavior b1^M
#^M
user-group system^M
 group-attribute allow-guest^M
#^M
local-user admin^M
 authorization-attribute level 3^M
 service-type telnet terminal^M
 service-type web^M
#^M
 stp mode rstp^M
 stp enable^M
#^M
interface NULL0^M
#^M
interface Vlan-interface1^M
 ip address 192.168.178.2 255.255.255.0^M
#^M
interface Vlan-interface2^M
 ipv6 address auto link-local^M
 ip address 10.10.41.1 255.255.255.0^M
 dhcp select relay^M
 dhcp relay address-check enable^M
 dhcp relay server-select 1^M
#^M
interface GigabitEthernet1/0/1^M
 port auto-power-down^M
 stp edged-port enable^M
#^M
interface GigabitEthernet1/0/2^M
 port auto-power-down^M
 stp edged-port enable^M
#^M
interface GigabitEthernet1/0/3^M
 port auto-power-down^M
 stp edged-port enable^M
#^M
interface GigabitEthernet1/0/4^M
 port access vlan 2^M
 port auto-power-down^M
 stp edged-port enable^M
#^M
interface GigabitEthernet1/0/5^M
 port auto-power-down^M
 stp edged-port enable^M
#^M
interface GigabitEthernet1/0/6^M
 port auto-power-down^M
 stp edged-port enable^M
#^M

... all ports are 'unconfigured' and look the same ...

interface GigabitEthernet1/0/28^M
 stp edged-port enable^M
#^M
 undo info-center logfile enable^M
#^M
 snmp-agent^M
 snmp-agent local-engineid 383030303633413236353133453846373234314644393530^M
 snmp-agent sys-info version v3^M
#^M
 dhcp enable^M
#^M
 load xml-configuration^M
#^M
user-interface aux 0^M
 authentication-mode scheme^M
user-interface vty 0 15^M
 authentication-mode scheme^M
#^M
return^M
===============================================================

[16again · Accepted solution]

Probably, the "permit" function isn't allowed in a policy. 
Undocumented, but you can apply ACL directly to interface using CLI:
"packet-filter 3333 inbound"
I already noticed this breaks DHCP relay on the used port.

[-TM-]

Hi 16again, 

thank you for your advice. I was about to use "unlocked" CLI to get it working, because limiteed CLI doesn't support commands 'interface' or 'packet-filter'. Doesn't this break warranty?

I'm almost sure, this is an error in firmware to comware translation, because I've already reproduced it on two devices. HP Support didn't yet help.

A broken dhcp-relay functionality would probably be acceptable.

TM

[-TM-]

BTW. I already tried permit or deny settings. But those were ignored, according to documentation, if you apply it to a Traffic Behavior.

[-TM-]

Hi 16again, 

have u tried this rule for your dhcp relay to get it working again? This seems to fix the problem.

rule 5 permit udp source-port range bootps bootpc destination-port range bootps bootpc

[16again]

As I recall, I was testing with a rules like below, so specifically allowing DHCP packets shouldn't matter:

deny ip dest 8.8.8.8
permit ip any any
However, recently I upgraded to R1111, so I will re-try this weekend.

[-TM-]

dhcp enable
dhcp relay server-group 1 ip 10.10.10.10

interface Vlan-interface 20
ip address 10.10.20.1 24
dhcp relay server-select 1 
dhcp select relay
dhcp relay address-check enable

acl number 3310 match-order config
acl number 3310
rule 5 permit udp source-port range bootps bootpc destination-port range bootps bootpc
rule 10 permit ip source 10.10.20.0 0.0.0.255 destination 10.10.20.0 0.0.0.255 
rule 20 deny ip destination 10.10.0.0 0.0.255.255 
rule 30 permit ip destination 0.0.0.0 0.0.0.0 

 jg924a-cmw520-r1110

[16again]

I just tried your access-list with version 5.20.99, Release 1111 .

Applying your access-list with commands:
interface GigabitEthernet1/0/5
packet-filter 3310 inbound

doesn't throw an error......but:  displaying the config doesn't show this ACL applied to the config!  Since no filter is introduced,  DHCP relay obviously  isn't broken.

An ACL like below, does apply correctly, but still breaks DHCP relay:

acl number 3176
 rule 5 permit udp source-port eq bootpc destination-port eq bootps
 rule 10 deny ip destination 8.8.8.8 0
rule 20 permit ip

[-TM-]

'Actually i see some differences: 

 rule 5 permit udp source-port range bootps bootpc destination-port range bootps bootpc

I used a range instead of equality for source, as for destination port. I choosed it to not get into trouble on both, the server and the client port, as it also has to be applied to the server port.

 rule 10 permit ip source 10.10.10.0 0.0.0.255 destination 10.10.10.0 0.0.0.255

Need to allow the traffic to the corresponding VLAN Interface of my VLAN for any communication because of later deny statement. You might not need it. Btw why are you disabling access to google DNS? Why didn't you disable second one 8.8.4.4. too?

Have u removed all other acls from those ports?

I see all of my acls by using 'display acl all'

My Version is just 1 patch earlier. The update shouldn't break the CLI.

I'm quite sure I've checked the ACL assignement with 'display packet-filter all'. But as I am trying some Multicast settings atm. I've disabled any ACL at the moment. So I cannot verify it for now.

[16again]

-TM-
The ACL I tried first, was an exact copy of yours.  (including the ranges). 

Also , In my case this is just a test ACL.  I don't use Google DNS , but it's pingable so it's a nice target for testing  ACLs.
Yes I removed other ACL  and QoS  policy on port I tested.