0

I have two server linked to each other. I tried to send a pcap from one of the servers via direct link using tcpreplay command. The pcap contains an HTTP POST session which size of some frames is 1518 bytes [Ethernet header(14 bytes)][payload(1500 bytes)][fcs(4 bytes)], but the receiver server's interface drops packets with size over 1514 bytes.

Everything works correctly when I remove last 4 bytes(FCS) of all packets and send pcap. Or when I change MTU of the sender and receiver interface from 1500 to 1504. I can understand why the sender's interface MTU needs to be 1504. But why does the receiver's interface MTU need to be 1504? I expect the receiver's interface doesn't consider FCS bytes just like Ethernet header, because This is what is happening when the actual Ethernet frame of size 1518 is coming toward receiver's interface from internet.

Is there any difference between when the receiver consumes Ethernet frames from internet and when two servers are linked and one is sending to another by tcpreplay?

Thanks in advance.

  • What you see is an ethernet frame with a VLAN tag embedded in the frame header. That adds four octets to the frame size, and most hosts, by default, do not recognize such frames. Some host ethernet interfaces and OSes (especially servers) can be configured to recognize that and use a trunk link (multiple VLANs, all but one of which must be tagged). Both ends of a trunk link must be configured to trunk rather than as the default host (access) interfaces. – Ron Maupin Mar 26 '23 at 16:04
  • Thanks. How can I know if your opinion is right or not? what I tried is I checked sent pcap and captured received pcap. I opened both of them using wireshark and there is not any byte representing VLAN tag. Is it enough? @RonMaupin – sajjad valaei Mar 28 '23 at 11:48
  • A maximum standard ethernet frame is 1514 octets, but with the four added octets of the 802.1Q VLAN tag, it becomes 1518 octets. The TPID following the source MAC address should be `0x8100` and the EtherType field is moved four octets in order to insert the VLAN tag just before it. – Ron Maupin Mar 28 '23 at 13:35
  • 1
    "_Is there any difference between when the receiver consumes Ethernet frames from internet and when two servers are linked and one is sending to another by tcpreplay?_" You do not receive ethernet frames from the Internet. The frames are stripped off at a router, and the packets are forwarded to the next network, where a new frame is built. Frames are only ever seen and used on the local network. – Ron Maupin Mar 28 '23 at 13:37
  • There is not any VLAN tag in pcap I tried to send. Thank you for clarification. – sajjad valaei Mar 28 '23 at 17:18

1 Answers1

1

Everything works correctly when I remove last 4 bytes(FCS) of all packets and send pcap

So, the send function recalculates and re-adds the FCS. With a bad or missing FCS the destination (or an intermediate switch) would drop the frame.

Thus, remove FCS before submitting to send. Alternatively, don't include the FCS field in your capture.

Zac67
  • 2,761
  • 1
  • 10
  • 21
  • Thank you for this reply. I captured received packets on the receiver side using tcpdump and they were not containing FCS, so I guess you're scenario is wrong. Surprisingly, I tried to send wrong FCS packets and the receiver didn't drop them. For more clarification there is not any switch or such things. The sender and receiver are linked with direct attach ethernet cable. – sajjad valaei Mar 28 '23 at 11:39
  • 1
    `[Ethernet header(14 bytes)][payload(1500 bytes)][fcs(4 bytes)]` was the premise in your question. Whatever you connect, any L2 node drops frames with bad FCS as malformed. – Zac67 Mar 28 '23 at 12:23
  • Now I got what you said and it's most probable scenario. I tried to calculate FCS and add it to pcap, but It's network card interface job to do it and my efforts were pointless to add wrong FCS. I didn't know that FCS is automatically added on sender side and stripped on receiver side before I can monitor it. I'll check and when I am sure I'll close this question. thanks. – sajjad valaei Mar 28 '23 at 17:24