Switch Trunk Configuration Question on Clusters

[a3498881-aa5d-4]

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.

[Chris_Atkinson]

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.

[Tobias_Moritz · Accepted solution]

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.

[Timothy_Hall]

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.

[Timothy_Hall]

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 ...

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

[a3498881-aa5d-4]

Thanks everyone for the great feedback. Much appreciated.