HP 5800-24G Switch (JC100A) applies layer 3 acl to layer 2 traffic

[Anonymous]

Hello,

I just debugged an issue in my network where an esx server was unable to reach an iscsi target in the same subnet.

The problem was an ACL that is applied on a layer 3. However the 5800-24G applies this ACL also to layer 2

traffic that is passing through it. SInce it is my core, the traffic passed through it.

The problem was that 10.101.0.11 could not reach 10.101.0.4 via TCP with this acl applied on interface vlan 101:

acl number 3101 name restricted-v101-v4
 rule 0 permit tcp established
 rule 5 deny udp destination-port eq snmp logging
 rule 10 permit icmp
 rule 15 permit tcp destination-port eq domain
 rule 20 permit udp destination-port eq dns
 rule 25 permit udp source 10.101.0.2 0 source-port eq dns
 rule 30 permit udp destination-port eq ntp
 rule 35 permit udp destination-port eq bootpc
 rule 40 permit udp destination-port eq bootps
 rule 45 permit ip source 10.101.0.0 0.0.255.255 destination 10.10.10.1 0
 rule 50 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.4.0 0.0.0.255
 rule 55 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.1 0
 rule 60 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.2 0
 rule 65 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.3 0
 rule 70 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.4 0
 rule 75 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.5 0
 rule 80 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.6 0
 rule 85 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.7 0
 rule 90 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.8 0
 rule 95 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.9 0
 rule 100 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.10 0
 rule 105 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.11 0
 rule 110 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.12 0
 rule 115 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.13 0
 rule 120 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.14 0
 rule 125 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.15 0
 rule 130 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.16 0
 rule 135 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.17 0
 rule 140 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.18 0
 rule 145 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.19 0
 rule 150 permit ip source 10.101.0.0 0.0.255.255 destination 10.100.1.20 0
 rule 155 deny ip source 10.101.0.0 0.0.255.255 destination 192.168.0.0 0.0.255.255 logging
 rule 160 deny ip source 10.101.0.0 0.0.255.255 destination 172.16.0.0 0.15.255.255 logging
 rule 165 deny ip source 10.101.0.0 0.0.255.255 destination 10.0.0.0 0.255.255.255 logging
 rule 170 permit ip source 10.101.0.0 0.0.255.255
 rule 175 deny ip logging

 After adding an explicit rule which allows within the subnet, it works again.

rule 151 permit ip source 10.101.0.0 0.0.255.255 destination 10.101.0.0 0.0.255.255

 I consider this a grave bug because an ACL applied to a Layer 3 interface _should_ not apply to Layer 2. I'll also

file a bug report against this. The ACL was applied on a Layer 3 interface like that:

interface Vlan-interface101
 packet-filter name restricted-v101-v4 inbound

I used netcat and tcpdump to verify that I only see newly created traffic on the target when the ACL is removed or

extended as mentioned above.

09:09:24.621966 IP 10.101.0.11.51354 > 10.101.0.4.12345: S 4234412273:4234412273(0) win 65535 <mss 1460,nop,wscale 9,sackOK,timestamp 467357 0>
09:09:24.621990 IP 10.101.0.4.12345 > 10.101.0.11.51354: R 0:0(0) ack 4234412274 win 0

Otherwise I see _nothing_ in tcpdump but a lot of acl logging which of course is useless, because it doesn't tell which

source ip to destionatio ip triggered the rule:

Jan 11 08:09:45 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 165 deny ip source 10.101.0.0 0.0.255.255 destination 10.0.0.0 0.255.255.255 logging  1255 packet(s)

 As always with the lastest firmware available:

HP Comware Platform Software
Comware Software, Version 5.20.105, Release 1808P16
Copyright (c) 2010-2013 Hewlett-Packard Development Company, L.P.
HP A5800-24G Switch uptime is 0 week, 1 day, 18 hours, 17 minutes

HP A5800-24G Switch with 2 Processors
512M    bytes SDRAM
4M      bytes Nor Flash Memory
512M    bytes Nand Flash Memory
Config Register points to Nand Flash

Hardware Version is Ver.B
CPLD Version is 003
BootRom Version is 220
[SubSlot 0] 24GE+4SFP Plus Hardware Version is Ver.B
[SubSlot 1] No Module

Cheers,

     Thomas

[Apachez-]

I agree with you however there seem to exist two schools regarding this matter.

One shool is the one you explained above - setting an ACL to an vlan-int should only apply to traffic that is designated towards this interface (for example traffic with dstmac == vlanint_mac).

That is traffic sent between two physical interfaces (like gi 1/0/1 and gi 1/0/2) which are part of the same vlan wont pass through this ACL. But traffic leaving this vlan will pass through this ACL (clients having the ip of vlan-int as default gateway for example).

The second school is that the ACL will be applied to all packets traversing the VLAN itself (and not just the vlan-int).

I know that Allied Telesis older AlliwedWare (havent played with the newer AlliedWare yet) used the first school described above.

And your experience seems like HP Comware applies to the second school above.

I have tried to dig through the manuals to find what should apply to HP Comware but only thing I found was this (Page 17 in "HP 5820X & 5800 Switch Series ACL and QoS Configuration Guide"):

"

An ACL on a VLAN interface filters packets forwarded at Layer 3 and multicast packets forwarded at Layer 2 in the VLAN.

"

and that could be interpreted that second school applies.

Personally I like first school better. That is if you want an ACL to apply for the intra-VLAN traffic then it should be this configuration one should apply:

vlan 100

packet-filter acl 3001

while if you want it to apply only for inter-VLAN traffic it would be:

int vlan 100

packet-filter acl 3001