Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
a3498881-aa5d-4
Participant
Jump to solution

Switch Trunk Configuration Question on Clusters

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.

 

1 Solution

Accepted Solutions
Tobias_Moritz
Advisor

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.

View solution in original post

5 Replies
Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE
Tobias_Moritz
Advisor

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

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
a3498881-aa5d-4
Participant

Thanks everyone for the great feedback. Much appreciated.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events