64000 Chassis - capture traffic on BPEthX interface

[Gennady]

Hi, everyone!

We have a strange problem in a customer environment. There are rx_length_errors constantly increasing on BPEth0 and BPEth1 interfaces. We can see that there are no rx_undersize or rx_oversize in the output of ethtool -S BPEthX.

#ethtool -S BPEth1 | grep 'port.rx_undersize\|port.rx_oversize\|port.rx_length_erro

     rx_length_errors: 172188

     port.rx_length_errors: 172188

     port.rx_undersize: 0

     port.rx_oversize: 0

#ethtool -S BPEth1 | grep 'port.rx_undersize\|port.rx_oversize\|port.rx_length_erro

     rx_length_errors: 172192

     port.rx_length_errors: 172192

     port.rx_undersize: 0

     port.rx_oversize: 0

I have tried to capture traffic on BPEthX interface of our lab Chassis 64000. 99% of traffic is CCP and ARPs. There is no production traffic in tpcdump or cppcap. It looks like SecureXL doing the same thing as with VSX wrpj interfaces.

What is the procedure to capture all frames which are passing via back-plane interfaces?

What may be the reason for the strange rx_length_errors?

[PhoneBoy]

I'd consult with TAC here.

[Timothy_Hall]

Believe it or not, this may be related to a bug in the icen driver not properly computing the Length field of the generated Ethernet frame.  See here: sk183040: HealthCheck Point reports "rx_length_errors" for Security Group Members in a Maestro clust...

[Gennady]

Good day!

I have written an email to our customer as soon as I saw the SK. It was not accepted as a valid explanation.

On the bright side, I was able to capture all packets on a BPEthX interface on our test chassis. The next step will be to gather another set of pcaps from BPEthX and then look for malformed packets in wireshark. The concern is that the chassis itself may calculates the length field wrong, and I need to disprove it.