ACL using NCLU on Cumulus VX 3.4.0


I have been trying to implement an ACL to block the icmp traffic using NCLU "net add acl" command. However, the ACL does not seem to function.

What seems to be the Problem ?

However, when I tried a MAC ACL using the NCLU, it works fine. So do I need to activate "ip routing" on the switch just like cisco L3 switches to make able to handle layer3/4 access lists? if yes? how? if not, then what might be the problem?

Regards
Omar


8 replies

Hi Omar,

I dont see anything wrong with the ACL configuration. Either of the configured acls provided look like they ought to prevent forwarding of icmp towards 192.168.11.33 when they are received on swp2 or swp3.

I have made a similar configuration on my switch..

net show configuration acl
acl ipv4 TESTACL priority 10 drop source-ip any dest-ip 20.20.0.2/32

acl ipv4 check priority 10 drop icmp

interface swp49s1
acl ipv4 TESTACL inbound
acl ipv4 check inbound

interface swp51s1
acl ipv4 TESTACL inbound
acl ipv4 check inbound

Prior to applying the acl's. I was able to ping from 20.20.0.1 (swp49s1) to 20.20.0.2 (swp51s1). After applying the config, the icmp messages were drop by acls. What does "cl-acltool -L ip" show in your case? For my test, when the acls are configured, I can observe the drop counters on the forward chain...

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- swp+ any 240.0.0.0/5 anywhere
0 0 DROP all -- swp+ any loopback/8 anywhere
0 0 DROP all -- swp+ any base-address.mcast.net/4 anywhere
0 0 DROP all -- swp+ any 255.255.255.255 anywhere
7 742 DROP all -- swp49s1 any anywhere 20.20.0.2 <------
0 0 DROP icmp -- swp49s1 any anywhere anywhere
0 0 DROP all -- swp51s1 any anywhere 20.20.0.2
0 0 DROP icmp -- swp51s1 any anywhere anywhere

In the above case, the pak was dropped due to the dest-ip. I also tried removing the acl with dest-ip and used just the icmp acl called "check". In that case, I observed the paks were also dropped...

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- swp+ any 240.0.0.0/5 anywhere
0 0 DROP all -- swp+ any loopback/8 anywhere
0 0 DROP all -- swp+ any base-address.mcast.net/4 anywhere
0 0 DROP all -- swp+ any 255.255.255.255 anywhere
2 212 DROP all -- swp49s1 any anywhere 20.20.0.2
224 23744 DROP icmp -- swp49s1 any anywhere anywhere <-------
0 0 DROP all -- swp51s1 any anywhere 20.20.0.2
0 0 DROP icmp -- swp51s1 any anywhere anywhere

Here is what my /etc/network/interfaces looks like...note that my layer 3 configuration for the bridge
interface is vlan20, not bridge.20. I dont think this is causing an issue with your acl, but you may want to change your bridge.20 accordingly ... (suspect nclu was not used to create the bridge interface in your connfig)

auto swp49s1
iface swp49s1
link-speed 10000
link-duplex full
link-autoneg off

auto swp51s1
iface swp51s1
link-speed 10000
link-duplex full
link-autoneg off

auto bridge
iface bridge
bridge-ports swp49s1 swp51s1
bridge-stp off
bridge-vids 20
bridge-vlan-aware yes

auto vlan20
iface vlan20
address 20.20.0.9/24
vlan-id 20
vlan-raw-device bridge

As a final thought, the acl's are expected to drop on the FORWARD chain, but they will not drop icmp to the CPU in this case.

Paul

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it still did not work, once I've applied the command "sudo cl-acltool -L ip" I do not see the ACL installed just like yours, even though the ACL was created. When I create a MAC ACL, it works, yet it works on all interfaces, even thought, I didn't applied on all. I don't get what's happening,is it because, I'm using GNS3? this time I used the NCLU to create everything, except for the "bridge-access" command which I've added manually, if don't add the mentioned command, I won't be able to ping. The following screenshots are for the configurations.



Regards
Omar

Userlevel 4
Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

Not sure whether we have 1:1 feature parity on ACLs installed between Vx and Cumulus Linux installed on a hardware switch. You may want to try using iptables directly to install your rules. I.E. take the rules created by NCLU and use IPTABLES to install them instead of cl-acltool.
Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

Hi Omar,

I looks like this is an issue specific to VX. Normally, acl rules are installed in HW, but when VX is used the rules are not programmed in HW. I am able to observe similar results as you using VX. I eliminated nclu altogether in my test bed and installed rules to block icmp on both FORWARD and INPUT chains. Form my experiment, it seems that the ACLs are installed, but they are not being matched...

-A INPUT --in-interface swp+ -j DROP -p icmp
-A FORWARD --in-interface swp2 -j DROP -p icmp
-A FORWARD --in-interface swp6 -j DROP -p icmp

root@rut:~# cl-acltool -L ip
warning: Detected platform is Cumulus VX
warning: Running in no-hw-sync mode. No rules will be programmed in hw
-------------------------------
Listing rules of type iptables:
-------------------------------
TABLE filter :
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP icmp -- swp+ any anywhere anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP icmp -- swp2 any anywhere anywhere
0 0 DROP icmp -- swp6 any anywhere anywhere

Next step is I will talk to our development team to understand current expected behavior for acls when using VX in this case. In the meantime, it is safe to say the acls appear correct and they work as expected on real HW.

Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

Hi Omar,

I followed up with our development team. Answer is that bridge member match will not work in iptables context in Linux Kernel at all. That is the way linux kernel works in general, so in VX, it is not possible to support iptables for bridge interfaces. iptables for bridge interfaces can only be supported in HW on real switches. Consequently, it is not possible to test iptable ACLs for bridge interfaces using VX. If these acls are needed in VX, ebtables are the way to do it. If you are testing iptable acls for a deployment on real HW, it would be best to use a real switch. Expectation is that the ACL's you are using are correct and will work on a real switch.
Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

Hi Paul,

I suspected so, However, why would the MAC ACLs partially function? I tried iptables as well, didn't seem to work in my case on GNS3 or Virtualbox, I'll keep run test and see if manage to make the iptables work as mentioned by your colleague. Thank you for the effort. However my aim is to test the Cumulus switch programming functionality within an SDN network for my Master thesis. Is there any other option that I could use for testing? any recommendations?

Regards
Omar
Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

hi Paul,

Thanks a lot. Okay, and if I wanna purchase a switch that runs Cumulus as an OS, how should I do that? do you any options and pricing that I could show to my superiors and supervisors ?

Regards
Omar

Userlevel 4
Omar Al-Rubaye wrote:

Hi Paul,

Thanks for the reply, I've applied the configurations again as stated above, however it...

Omar, fill out this form to have someone reach out to you. https://cumulusnetworks.com/contact/

The easiest way to get started is to use the Hardware Compatibility List and look for gear that is "CX Ready" --> https://cumulusnetworks.com/products/hardware-compatibility-list/

Reply