RX-DRP Culprit 1: Unknown or Undesired Protocol Type
In every Ethernet frame is a header field called “EtherType”. This field specifies the OSI
Layer 3 protocol that the Ethernet frame is carrying. A very common value for this
header field is 0x0800, which indicates that the frame is carrying an Internet Protocol
version 4 (IPv4) packet. Look at this excerpt from Stage 6 of “A Millisecond in the life
of a frame”:
Stage 6: At a later time the CPU begins SoftIRQ processing and looks in the ring
buffer. If a descriptor is present, the CPU retrieves the frame from the associated
receive socket buffer, clears the descriptor referencing the frame in the ring
buffer, and sends the frame to all “registered receivers” which will be the
SecureXL acceleration driver. If a tcpdump capture is currently running,
libpcap will also be a “registered receiver” in that case and get a copy of the
frame as well. The SoftIRQ processing continues until all ring buffers are
completely emptied, or various packet count or time limits have been reached.
During hardware interrupt processing, the NIC driver will examine the EtherType
field and verify there is a “registered receiver” present for the protocol specified in the
frame header. If there is not, the frame is discarded and RX-DRP is incremented.
Example: an Ethernet frame arrives with an EtherType of 0x86dd indicating the
presence of IPv6 in the Ethernet frame. If IPv6 has not been enabled on the firewall (it is
off by default), the frame will be discarded by the NIC driver and RX-DRP incremented.
What other protocols are known to cause this effect in the real world? Let’s take a look
at a brief sampling of other possible rogue EtherTypes you may see, that is by no means
complete:
- Appletalk (0x809b)
- IPX (0x8137 or 0x8138)
- Ethernet Flow Control (0x8808) if NIC flow control is disabled
- Jumbo Frames (0x8870) if the firewall is not configured to process jumbo frames
The dropping of these protocols for which there is no “registered receiver” does
cause a very small amount of overhead on the firewall during hardware interrupt
processing, but unless the number of frames discarded in this way exceeds 0.1% of all
inbound packets, you probably shouldn’t worry too much about it. An easy way to
confirm that the lack of a registered receiver is the cause of RX-DRPs is to perform the
following test:
1. In a SSH or terminal window, run watch -d netstat -ni and confirm the constant incrementing of RX-DRP on (interface).
2. In a second SSH session, run tcpdump -ni (interface) host 1.1.1.1
Does the near constant incrementing of RX-DRP on that interface suddenly stop as
long as the tcpdump is still running, and resume when the tcpdump is stopped? If so,
the lack of a registered receiver is indeed the cause of the RX-DRPs. The specified filter
expression (host 1.1.1.1 in our example) does not actually matter, since libpcap will
register to receive all protocols on behalf of the running tcpdump, and then filter the
packets based on the provided tcpdump expression. So as long as the tcpdump is
running, there is essentially a registered received for everything.
But how can we find out what these rogue protocols are, and more importantly figure
out where they are coming from? Run this tcpdump command to show every frame not
carrying IPv4 traffic or ARP traffic based on the EtherType header field:
tcpdump -c100 -eni (iface) not ether proto 0x0800 \
and not ether proto 0x0806 and not stp
(Note the ‘\’ at the end of line 1 of this command is a backslash and allows us to
continue the same command on a new line)
.png "Wolfgang"){kind=avatar}
