topic Re: Switch Trunk Configuration Question on Clusters in Firewall and Security Management

Switch Trunk Configuration Question on Clusters

a3498881-aa5d-4 — Thu, 07 Oct 2021 21:41:06 GMT

Hello CP community,

I have a question about switch trunk configurations which are connected to Check Point firewalls. I've come across a few instances where the switch trunk is set to pass all VLANs. The Check Point clusters however does not have all the VLANs defined as those missing are specific to subnets that belong to another cluster downstream. That being said, both Cluster A and Cluster B connect to the same two distribution switches. We normally hardcode the trunks on the switch port to match those on the firewall as seen below.

interface GigabitEthernet2/48 description trunk to xxxxNFW01C switchport trunk allowed vlan 22,32,42 switchport mode trunk

In this instance, the trunk configuration is set as follows:

interface GigabitEthernet2/48 switchport mode trunk spanning-tree portfast trunk

I am not seeing any issues with the latter switch config but wondering if there is any impact. My assumption based on logic is that any traffic such as multicast/broadcast going out the trunk port for VLANs not defined on the cluster would simply be dropped due to the rulebase. The config is simply adding unnecessary noise but poses no risk.

Any input would be greatly appreciated.

Regards.

Re: Switch Trunk Configuration Question on Clusters

Chris_Atkinson — Thu, 07 Oct 2021 23:47:46 GMT

Pruning the VLANs is good practice and avoids unecessary processing.

Portfast / Edge port config is also recommended to ensure ports quickly transition to their forwarding state to avoid recovery delays.

Re: Switch Trunk Configuration Question on Clusters

Tobias_Moritz — Fri, 08 Oct 2021 11:23:28 GMT

The traffic received from vlans which are not defined on firewall are not dropped by rulebase. They are dropped far more earlier at OS level (Gaia). In fact, these are ethernet frames which carry dot1q tags with IDs, you do not have VLAN interfaces configured for in Gaia. The OS does not know what to do with these frames and drops them.

Like Tim wrote in his books "Max Power", these kind of drops increase the RX-DRP counter on the affected firewall interface.

So while this should not cause any load issues with firewall workers, traffic load on interface might be a problem depending on the amount of broadcast traffic in these not-needed vlans. And the increasing RX-DRP counter due to this misconfiguration may hide some other problems which would otherwise be visible by seeing RX-DRP increasing (like real load issues).

As you and Chris already said: The vlan lists should match as best practice.

Re: Switch Trunk Configuration Question on Clusters

Timothy_Hall — Fri, 08 Oct 2021 14:49:43 GMT

To further elaborate on Tobias's excellent post, even the output of ethtool -S does not have a counter indicating these types of unexpected VLAN tag drops, yet RX-DRP is still incremented. So to determine what is actually going on with RX-DRP you have to look for the rx_missed_errors counter in ethtool -S; I believe some other relevant counters might be rx_no_buffer or rx_fifo_errors depending on the specific NIC driver. These counters account for frames arriving that have nowhere to go because the Gaia interface ring buffer is full; if you see a higher RX-DRP counter than all the rx_* error counters added together in ethtool -S, the "missing" RX drops are almost certainly invalid/unexpected VLAN tags being received due to a lack of pruning.

Re: Switch Trunk Configuration Question on Clusters

a3498881-aa5d-4 — Fri, 15 Oct 2021 14:39:20 GMT

Thanks everyone for the great feedback. Much appreciated.

Re: Switch Trunk Configuration Question on Clusters

Timothy_Hall — Thu, 21 Oct 2021 17:38:37 GMT

I just discovered that brand new for R81.10, the RX-DRP counter will not be incremented for bad VLAN tags (and some other situations) due to the Gaia sysctl variable rx_drops_stat_enable being set to 0 by default. The following updated SK describes all this and also provides a debug procedure to enable logging for precisely what frames incremented the RX-DRP counter if rx_drops_stat_enable is set to 1:

sk166424: Number of RX packet drops on interfaces increases on a Security Gateway R80.30 and higher with Gaia kernel 3.10

Apparently this variable existed in Gaia 3.10 R81 and earlier but was hidden from view, now revealed in R81.10 and later.