Odd activity identified and a packet capture performed in which the packets had not L2 information with minimal L3 information. I was not aware that such a packet would be allowed to traverse ethernet switches. The unit was sending approximately 5,000,000 packets at a rate of 30,000pps within 3 minutes and repeating at a very regular interval of every 30 minutes. Has anyone observed the type of behavior? asked 20 Feb '14, 11:19  Bolton edited 26 Feb '14, 12:44  Guy Harris ♦♦ showing 5 of 8 show 3 more comments |
One Answer:
I guess that feature strips off the link-layer header, and supplies packets that begin with the IP header; you'll need to ask Cisco whether there's any way not to do so. ("RAW IP" refers to the pcap/pcap-ng link-layer header type that's used when there are no link-layer headers and the packet begins with the IP header.) answered 25 Feb '14, 17:25 Guy Harris ♦♦ |
I am not familiar with RAW IP. If this is the case, any links to relevant documents would be appreciated.
On which operating system did you do this capture, and what was the name of the network interface on which you captured it? The capture mechanisms libpcap and WinPcap use (those are the libraries used by Wireshark to capture traffic) sometimes supply packets without L2 headers, even if the packets had L2 headers when they arrived from the network.
Using Cisco Embedded Packet Capture (EPC) feature. The capture was performed via a Cisco 2911 capturing all IP CEF packets traversing the interface for L2 (ip subnet) connectivity, in this case it was BVI10 that is L2 bridged to Gi0/0.
Can you post a small sample file somewhere (Google drive, dropbox, etc.)?
FYI:
I have captured MANY conversations via the EPC function of Cisco routers over the past several years and it does capture all data on the wire.
I have seen hundreds of captures during my 20+ years of application troubleshooting via Sniffer, Protocol Expert and Wireshark and this is the first I have ever observed RAW IP.
One other odd behavior, that may be a limitation of Cisco EPC, is that the timestamps are "similar" 1 - 9 are .722398 10-20 are .726398 21-31 are .730398 32-42 are .734398 etc... through .xxx387 to .xxx396 to .xxx404 and so on.
Can you post a small sample file somewhere?
The capture is available via https://drive.google.com/file/d/0By11RswYXZ8eNWtiUWVuOTg1MU0/edit?usp=sharing
Maybe you never before this happened to do the capture under the conditions in which a Cisco box writes out a LINKTYPE_RAWIP/DLT_RAW capture rather than, for example, a LINKTYPE_ETHERNET/DLT_EN10MB capture.
It's not a common link-layer header type, but it's existed for at least a couple of decades.
In any case, this is NOT a Wireshark issue:
the standard UN*X
filecommand reports that it's a raw IP capture:$ file Lancaster201402201017.cap Lancaster201402201017.cap: tcpdump capture file (big-endian) - version 2.4 (raw IP, capture length 1518)tcpdumpreports that it's a "raw IP" capture and doesn't show any link-layer information:$ tcpdump -e -n -r Lancaster201402201017.cap | head reading from file Lancaster201402201017.cap, link-type RAW (Raw IP) 08:14:17.722398 ip: 10.74.96.188.20 > 0.0.0.1.0: Flags [.E], ack 0, win 15012, length 0 08:14:17.722398 ip: 10.74.96.188.20 > 0.0.0.1.0: Flags [.E], ack 1, win 15012, length 0Wireshark is just processing what it's been handed.
So, again, as I said in my answer, you will have to ask Cisco why it's not putting the link-layer information out in this particular situation.