Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add note about broadcom switches and ingress input chains.

...

  • The order of operations for how rules are processed is not perfectly maintained when you compare how iptables and the switch silicon process packets. The switch silicon reorders rules when switchd writes to the ASIC, whereas traditional iptables executes the list of rules in order.
  • All rules are terminating. This means once a rule is matched, the action is carried out, and no more rules are processed. The exception to this is when a SETCLASS rule is placed immediately before another rule; this exists multiple times in the default ACL configuration.
    In the example below, the SETCLASS action applied with the --in-interface option, creates the internal ASIC classification, and continues to process the next rule, which does the rate-limiting for the matched protocol:

    Code Block
    languagetext
    -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
    Warning
    If multiple contiguous rules with the same match criteria are applied to --in-interface, only the first rule gets processed and then terminates processing. This would also be a misconfiguration, because there is no reason to have duplicate rules with different actions.
  • When processing traffic, rules affecting the FORWARD chain that specify an ingress interface are performed prior to rules that match on an egress interface. As a workaround, rules that only affect the egress interface can have an ingress interface wildcard (currently, only swp+ and bond+ are supported as wildcard names; see below) that matches any interface applied so that you can maintain order of operations with other input interface rules. Take the following rules, for example:

    Code Block
    languagetext
    -A FORWARD -i $PORTA -j ACCEPT
    -A FORWARD -o $PORTA -j ACCEPT   <-- This rule is performed LAST (because of egress interface matching)
    -A FORWARD -i $PORTB -j DROP

    If you modify the rules like this, they are performed in order:

    Code Block
    languagetext
    -A FORWARD -i $PORTA -j ACCEPT
    -A FORWARD -i swp+ -o $PORTA -j ACCEPT   <-- These rules are performed in order (because of wildcard match on ingress interface)
    -A FORWARD -i $PORTB -j DROP
  • When using rules that do a mangle and a filter lookup for a packet, Cumulus Linux does them in parallel and combines the action.
  • If a switch port is assigned to a bond, any egress rules must be assigned to the bond.
  • When using the OUTPUT chain, rules must be assigned to the source. For example, if a rule is assigned to the switch port in the direction of traffic but the source is a bridge (VLAN), the traffic won't be affected by the rule and must be applied to the bridge.
  • If all transit traffic needs to have a rule applied, use the FORWARD chain, not the OUTPUT chain.
  • ebtables
    Scroll Indexterm
    secondarymemory spaces
    primaryebtables
    rules are put into either the IPv4 or IPv6 
    Scroll Indexterm
    secondaryebtables
    primarymemory spaces
    memory space depending on whether the rule utilizes IPv4 or IPv6 to make a decision. Layer 2-only rules, which match the MAC address, are put into the IPv4 memory space.
Note

On Broadcom switches, the ingress INPUT chain rules match layer 2/layer 3 multicast packets before multicast packet replication has occurred; hence, having a DROP rule affects all copies.

Rule Placement in Memory

INPUT and ingress (FORWARD -i) rules occupy the same memory space. A rule counts as ingress if the -i option is set. If both input and output options (-i and -o) are set, the rule is considered as ingress and occupies that memory space. For example:

...