Maestro buffer Size Change

[Tapvir9000]

We are seeing some RX drops in hcp and tac recommended to change buffer values on the physical interfaces. The physical interfaces are part of a bond, After changing the rx and tx ringsize , the changes are not taking effect. Does this require a reboot ?

[Global] IRVMONMIDFWLSG100-s01-01> asg stat

--------------------------------------------------------------------------------
| System Status - Maestro |
--------------------------------------------------------------------------------
| Up time | 49 days, 12:15:05 hours |
| Members | 3 / 3 |
| Version | R82 (Build Number 777)

[Global] IRVMONMIDFWLSG100-s01-01> set interface eth1-10 rx-ringsize 4096
1_01:
success

1_02:
success

1_03:
success
[Global] IRVMONMIDFWLSG100-s01-01> save config
1_01:
success

1_02:
success

1_03:
success
[Global] IRVMONMIDFWLSG100-s01-01> show interface eth1-10 rx-ringsize
1_01:
Receive buffer ring size:512
Maximum receive buffer ring size:4096

1_02:
Receive buffer ring size:512
Maximum receive buffer ring size:4096

1_03:
Receive buffer ring size:512
Maximum receive buffer ring size:4096

[Timothy_Hall]

Does ethtool -S (interface) from expert mode show that they are rx_length errors?  If so they are a bug in the driver and only a cosmetic issue: 

sk183948: "rx_length_errors" on Maestro Cluster After Hardware Upgrade

sk183040: HealthCheck Point reports "rx_length_errors" for Security Group Members

Also not all RX-DRPs are "real" traffic that the gateway could process: sk166424: Number of RX packet drops on interfaces increases on a Security Gateway R80.30 and higher ...

If you are using a Quantum force appliance (3900/9XXX/19XXX/29XXX) that implements UPPAK, DPDK has taken control of the ring buffer sizes and you probably should not change them: sk181564: Differences using the 'ethtool' command with SecureXL Kernel Mode (KPPAK) and User Mode (U...

Not a fan in general of tampering with ring buffer sizes except as a last resort.

[Tapvir9000]

Hi Timothy,

Thanks for the reply, we are seeing RX drops in hcp report 

Interface BPEth0 have issues with: RX-DRP: 29271026 |
| Interface bond0.xxx have issues with: RX-DRP: 821805 |
| Interface bond0.xxx have issues with: RX-DRP: 4353469 |
| Interface bond0.xxxx have issues with: RX-DRP: 4663103 |
| Interface ethsBP2-01 have issues with: RX-DRP: 29271000



RX length errors are zero

[Global] IRVMONMIDFWLSG100-s01-01> ethtool -S ethsBP1-01
-*- 3 blades: 1_01 1_02 1_03 -*-

rx_length_errors.nic: 0

[Timothy_Hall]

RX-DRPs on the bond interface (not the underlying physical interface) are almost certainly junk traffic that the firewall cannot process anyway, please post ethtool -S for all underlying physical interfaces used by one of your bonds.

[Tapvir9000]

[Expert@IRVMONMIDMAE100A:0]# ethtool -S eth1-05
NIC statistics:
a_symbol_error_during_carrier: 0
a_frame_check_sequence_errors: 0
a_in_range_length_errors: 2843
a_out_of_range_length_field: 0
a_frame_too_long_errors: 0
symbol_errors: 0
[Expert@IRVMONMIDMAE100A:0]# ethtool -S eth1-06
NIC statistics:
a_symbol_error_during_carrier: 0
a_frame_check_sequence_errors: 0
a_in_range_length_errors: 0
a_out_of_range_length_field: 0
a_frame_too_long_errors: 0
symbol_errors: 0


[Expert@IRVMONMIDMAE100B:0]# ethtool -S eth2-05
NIC statistics:
a_symbol_error_during_carrier: 0
a_frame_check_sequence_errors: 0
a_in_range_length_errors: 3329
a_out_of_range_length_field: 0
a_frame_too_long_errors: 0
symbol_errors: 0
[Expert@IRVMONMIDMAE100B:0]# ethtool -S eth2-06
NIC statistics:
a_symbol_error_during_carrier: 0
a_frame_check_sequence_errors: 0
a_in_range_length_errors: 1
a_out_of_range_length_field: 0
a_frame_too_long_errors: 0
symbol_errors: 0

[Timothy_Hall]

That doesn't seem to be the full output of ethtool -S, but based on what you posted the RX-DRPs are junk traffic such as improperly pruned VLAN tags and unknown EtherTypes.  If you don't see any nonzero fifo/missed counters in ethtool -S, the traffic being dropped can't be processed by the firewall anyway.  See  sk166424: Number of RX packet drops on interfaces increases on a Security Gateway R80.30 and higher ...

[emmap]

As this is Maestro the improperly pruned VLANs should be dropped at the MHO. 

Remember here that the uplinks are virtual interfaces at the SGMs, the only real interfaces are the ethsBP-XXX interfaces forming the BPEthY bonds doing the downlinks. I suggest that you investigate those real interfaces primarily. 

[Tapvir9000]

Hi emmap,

thanks for the reply, does the change on BPEthx interfaces affect the uplink interfaces from MHO to network switch? I thought the BPEth interfaces is only for backplane between SGMs and MHO.


This is what I am seeing for the BPEthx interfaces

[Global] xxxxx-s01-01> show interface BPEth0 all
1_01:
state on
mac-addr 00:1c:7f:01:00:fe
type ethernet
link-state link up
mtu 1500
auto-negotiation off
speed 25G
ipv6-autoconfig Not configured
monitor-mode Not configured
duplex full
link-speed Not configured
comments
ipv4-address Not Configured
ipv6-address Not Configured
ipv6-local-link-address Not Configured

Statistics:
TX bytes:3770848420420 packets:7605586184 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:6982138939681 packets:14153834116 errors:485189 dropped:743256 overruns:0 frame:0

SD-WAN: Not Configured

1_02:
state on
mac-addr 00:1c:7f:02:00:fe
type ethernet
link-state link up
mtu 1500
auto-negotiation off
speed 25G
ipv6-autoconfig Not configured
monitor-mode Not configured
duplex full
link-speed Not configured
comments
ipv4-address Not Configured
ipv6-address Not Configured
ipv6-local-link-address Not Configured

Statistics:
TX bytes:4557625767607 packets:7331722533 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:10432522555483 packets:14170807015 errors:152238 dropped:240500 overruns:0 frame:0

SD-WAN: Not Configured

1_03:
state on
mac-addr 00:1c:7f:03:00:fe
type ethernet
link-state link up
mtu 1500
auto-negotiation off
speed 25G
ipv6-autoconfig Not configured
monitor-mode Not configured
duplex full
link-speed Not configured
comments
ipv4-address Not Configured
ipv6-address Not Configured
ipv6-local-link-address Not Configured

Statistics:
TX bytes:8383426732368 packets:13726148990 errors:0 dropped:4 overruns:0 carrier:0
RX bytes:7017518243620 packets:15554497033 errors:450372 dropped:51121 overruns:0 frame:0

[emmap]

They are the backplane for all packets that hit all uplink interfaces that then travel down to the SGMs. So they're basically all the uplinks together. 

[Tapvir9000]

Thanks for reply, I will update the buffer setting on BPEth interfaces.

The admin guide for R82 suggest that ethtool command should work, but not having much success with it on security group

[Expert@XXXX-s01-01:0]# ethtool -g BPEth1

Ring parameters for BPEth1:

Cannot get device ring settings: Operation not supported

[Expert@XXXX:0]# ethtool -g BPEth0

Ring parameters for BPEth0:

Cannot get device ring settings: Operation not supported

[Tapvir9000]

this is the SK to upgrade buffer setting on Maestro platform

sk156132 - "Cannot get device ring settings: Operation not supported" error when changing the ring s...

I have a ticket opened with TAC to figure out the Tx and Rx errors we are seeing.