When configuring firewall filters on QFX5k devices, you may observe that there is no support for the action "next-term" as indicated by the "unsupported platform" warning.

This article explains why the next-term option is not supported on these devices and how users can work around this limitation.

When configuring firewall filters on QFX5k devices, you see the following "unsupported platform" warning for the next-term action.

user@host# set firewall family inet filter TEST1 term next then ?

Possible completions:
  accept               Accept the packet
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  clear-policy-map     Clear the policy marking
  count                Count the packet in the named counter
> decapsulate          Terminate a tunnel
> discard              Discard the packet
  dscp                 Set Differentiated Services (DiffServ) code point
  forwarding-class     Classify packet to forwarding class
  log                  Log the packet
  loss-priority        Packet's loss priority
  pkt-trace            Trace the packet
  policer              Name of policer to use to rate-limit traffic
  policy-map           Policy map action
  port-mirror          Port-mirror the packet
  port-mirror-instance  Port-mirror the packet to specified instance
> reject               Reject the packet
> routing-instance     Packets are directed to specified routing instance
  skip-services        Skip the services
  syslog               System log (syslog) information about the packet
> three-color-policer  Police the packet using a three-color-policer
{master:0}[edit]

user@host# show firewall
family inet {
filter TEST1 {
term next {
##
## Warning: statement ignored: unsupported platform (qfx5200-32c-32q)
##
then next term;
}
}

This was tested in the lab and it was found to be the same across multiple versions and multiple QFX5k devices, including QFX5100-48s-6q and QFX5200-32c-32q.

The filter action "next-term" is not implemented for Broadcom-based QFX5K platforms. It is a platform limitation. Other platforms such as MX, PTX, and QFX10K, which use hardware block filters in FLT memory support this option.

Workaround

On QFX5K platforms, you can try applying filters by using input-list because there is no option for nested firewall filter configurations. The only available option is an input-list where multiple firewall filters can be matched on the same interface and the evaluation is done in the order in which the filter names appear in the list.

set interfaces <interface_name>  family inet filter input-list [.. filter_names .. ]

How Filter Lists Evaluate Packets When the List Includes Protocol-Independent and IP Firewall Filters

On a single interface that is associated with a protocol-independent (family any) firewall filter and a protocol-specific (family inet or family inet6) firewall filter simultaneously, the protocol-independent firewall filter executes first. The terminating action of the first filter determines whether the second filter also evaluates the packet.

• If the first filter terminates by executing the accept action, the second filter also evaluates the packet.

• If the first filter terminates without any terms matching the packet (an implicit discard action), the second filter also evaluates the packet.

• If the first filter terminates by executing an explicit discard action, the second filter does not evaluate the packet.

Applying the Configuration

An example on how to apply multiple filters is detailed as follows. Each filter contains a single term that evaluates IPv4 packets and accepts packets based on the value of the destination port field in the TCP header.

Note: The Junos OS uses the filters in a list in the order in which the filter names appear in the list.

user@host# show firewall
family inet {
    filter filter_FTP {
        term 0 {
            from {
                protocol tcp;
                destination-port 21;
            }
            then {
                count pkts_FTP;
                accept;
            }
        }
    }
    filter filter_SSH {
        term 0 {
            from {
                protocol tcp;
                destination-port 22;
            }
            then {
                count pkts_SSH;
                accept;
            }
        }
    }
    filter filter_discard {
        term 1 {
            then {
                count pkts_discarded;
                discard;
            }
        }
    }
}

user@host# show interfaces
ge-1/3/0 {
    unit 0 {
        family inet {
            filter {
                input-list [ filter_FTP filter_SSH filter_discard ];
            }
            address 172.16.1.2/30;
        }
    }
}

To verify that input packets are accepted according to the three filters:

• From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a packet with destination port number 21 in the header. The packet should be accepted.

• From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a packet with destination port number 22 in the header. The packet should be accepted.

• From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a packet with a destination port number other than 21 or 22. The packet should be discarded.

2022-05-31: Initial version