Difference between IPv4 and IPv6 in default ACL rules


For some reason, the default rules for IPv4 and IPv6 are formatted differently. For IPv4, there are two rules: one to set class and matching the input interface and one to police. The documentation says the two rules are bound together in the ASIC. But for IPv6, only a police rule is used and it uses the --set-class argument to achieve a similar result.

-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p udp --dport $BFD_ECHO_PORT -j SETCLASS --class 7
-A $INGRESS_CHAIN -p udp --dport $BFD_ECHO_PORT -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000

-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p udp --dport $BFD_ECHO_PORT -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000 --set-class 7

Why the difference?

Also, there is no counters attached to the rules. Is there a way to check if policing is happening or not? I have some packet drop and I want to know if this is because of policing. I am on a Mellanox SN2100. It's also unclear if these default rules also apply when using VRF and VLAN. I have stuff like that:

auto bridge.181
iface bridge.181
vrf private-1

And Quagga listening on the VRF. Do the BGP policing rules apply in this case? I am worried I am hitting the more restrictive catch-all rules.

9 replies

Documentation says counters are not incremented on Spectrum ASIC. This makes debugging quite harder.

Even if I don't put an interface name, these rules have no effect:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
0 0 POLICE tcp -- any any anywhere anywhere tcp dpt:bgp POLICE mode:pkt rate:5000 burst:2000 class:7
0 0 POLICE tcp -- any any anywhere anywhere tcp spt:bgp POLICE mode:pkt rate:5000 burst:2000 class:7

If I generate a 10 Mbits/s flow (1000 pkts/s), BGP sessions are shutting down because, I suppose, the BGP traffic is classified as part of the catch-all rule. Moreover, cl-resource-query says no resources are used for ACLs, is that expected?
Userlevel 4
Thanks for asking @vbernat I've run this by our engineering team and hopefully someone can get you the best answer soon.
Userlevel 4
Hi @vbernat I heard back from engineering. They said that for IPv4, in general, the class is set in ingress and the policing is done at egress; this just reflects how Broadcom switches work. For IPv6 it is all done in ingress. Hence, the default rules are set up like this to accomodate a common set of default rules. Does this help?
Hey @Pete B!,

Yes, I understand better.

I have still a hard time setting appropriate control plane rules for matching BGP traffic. Would you know how to get counters for the dropped/accepted packets of a policer on the Spectrum platform? The documentation says they are not visible in the output of cl-acltool, but maybe there are other ways to get them?
Userlevel 4
Hi @vbernat Control plane counters are not available in Mellanox Spectrum. There are many limitations in setting up control plane policers per rule on Mellanox. BGP packets are probably getting policed by the IPROUTER rule. Can you change that policer and check please?
From my experiments, they are getting policied by the LOCAL rule just before the IPROUTER rule. But it also means they are not classified correctly: they are in class 0 instead of class 7 and they don't get their own policer. A simple UDP flood will make BGP sessions go down. I don't seem to be able to add more matchers. As soon as I try to add "-p tcp --destination-port 179", the policer does not work anymore. Is there a way around that?
Userlevel 4
Maybe you can try increasing the LOCAL policer value?
Yes, it works, but the BGP traffic is not protected. If I push to 10000 pkts/s this policer, someone can UDP flood the same destination at this rate and the BGP session will be impacted since this policer applies on any traffic. This also defeats the purpose of the policer which is to protect the control plane.
Userlevel 4
Sorry I don't have a better answer for you at this time, but engineering is aware of this and is looking into what can be done.