- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Check Point Proactive support
Free trial available for 90 Days!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
The 2022 MITRE Engenuity ATT&CK®
Evaluations Results Are In!
Now Available: SmartAwareness Security Training
Training Built to Educate and Engage
MITRE ATT&CK
Inside Check Point products!
CheckFlix!
All Videos In One Space
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.
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.
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.
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.
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.
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:
Apparently this variable existed in Gaia 3.10 R81 and earlier but was hidden from view, now revealed in R81.10 and later.
Thanks everyone for the great feedback. Much appreciated.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY