Solved: ARP packet size

hemuvenkat81 · ‎10-09-2010

what is the size of "double tagged(CTAG+STAG) ARP request packet" ?

Peter Paluch · ‎10-11-2010

Hello Hemanth,

The preamble and the start-of-frame delimiter are present for physical layer needs (or for compatibility reasons) and they are not counted towards the frame size.

The ARP message itself is 28 bytes long, exactly as you indicated. Now, with correct Ethernet implementations, the outgoing frame has to be padded to be at least 64 bytes long. There are some quirks about this, however - the device that originated this ARP message may itself be capable of sending it in an untagged frame or in 802.1Q-tagged frame. The tag size is always accounted towards the total frame size, resulting in different paddings:

If the ARP message is to be sent in an untagged frame then the frame overhead itself is 18 bytes. That would result in a frame of 28+18=46 bytes without padding. Additional 18 bytes of padding are necessary in this case to bloat the frame to the 64 byte length.
If the ARP message is to be sent in an 802.1Q-tagged frame then the frame overhead is 22 bytes, resulting in the total frame size of 28+22=50 bytes. In this case, the padding needs to be 14 bytes long.
If the ARP message is to be sent in a double-tagged frame then the frame overhead is 26 bytes, resulting in the total frame size of 54 bytes. In this case, the padding needs to be 10 bytes long.

The different size of the padding may have unpleasant consequences if the frame is untagged - some implementations of Ethernet data-link layer including selected Cisco Catalyst switches do not extend the padding after untagging a frame. As a result, a frame that was exactly 64 bytes long when tagged becomes shorter than 64 bytes after untagging, essentially becoming a runt. This is in direct violation of the IEEE 802.1Q-2005 section C.4.4.3 that explicitly states:

If untagging a given frame would result in violation of the minimum frame length requirements of CSMA/CD, the Bridge is required to adjust the PAD field to ensure that the frame length equals the minimum length of 64 octets

Unfortunately, as also indicated by you, many vendors seem to somehow not consider this fact.

I do not know of any method to increase the ARP message size, and I shall also point out that this is not a problem of the ARP message size but rather of the compulsory Ethernet frame padding. The padding is always the responsibility of the MAC/PHY layer that forwards the frame, i.e. all Ethernet controllers and cards that emit Ethernet frames must take care to properly pad it. Note that this does not apply just to the originator of a message but rather to all intermediary Ethernet devices through which the frame is being delivered.

Seeing some vendors to send ARP in frames with the total size of 60 bytes is okay - the FCS of 4 bytes is not usually displayed in Wireshark or similar sniffers because the FCS is processed in the Ethernet hardware and not forwarded to the upper layers. In other words, Wireshark always displays all Ethernet frames to be 4 bytes shorter than they really are, so a frame with 60 bytes in Wireshark is essentially a frame with 64 bytes in total.

I hope this helps - I did not try to answer all your questions because I suppose that the facts I have explained so far may already answer those or make you reconsider some of your views. You are welcome to ask further!

Best regards,

Peter

View solution in original post

Peter Paluch · ‎10-10-2010

Hello,

The Ethernet header will grow by 4 bytes for each tag, so the entire frame header with 2 802.1Q tags will be 22 bytes long. The ARP message length itself is 28 bytes. Considering the 4 byte CRC at the Ethernet frame trailer, the entire frame length without padding would be 22+28+4 = 54 bytes.

However, a station generating the ARP request is not permitted to emit a frame with total length less than 64 bytes. Assuming that the ARP is originated by a normal PC, it will be already padded to the minimal size of 64 bytes. As this frame passes over the link performing the double 802.1Q tagging, the total frame size will be increased by the 8 bytes of additional 802.1Q tagging, resulting in the size of 64+8=72 bytes.

Best regards,

Peter

hemuvenkat81 · ‎10-11-2010

During testing with multiple vendor's L3 product, found ARP packet size varies from vendor to vendor.

For example:

1. One of the Ethernet tester sends ARP request with 56bytes packet size without any tag in it.

2. I have seen some vendors send ARP with 60 bytes( with 2xTAG), so i am confused.

If Tester is sending correct ARP packet, then after addition of 2 tags... frame will become 56+8=64bytes +4(FCS)

If Vendor is sending correct ARP packet, then after removing 2 tags.... frame will become 60-8=52bytes +4(FCS)

so need to know, why there is difference in ARP packet length in different vendor products.

3. Is there any way to increase the ARP length in L3 products?

4. If padding is must for 'runt' frames then, who suppose to do the padding? ARP transmitter or ARP receiver?

5. When i send ARP request, why tester sends 56 bytes without tag? ARP is L3 protocol is the reason, it sends IP and MAC only? If so then why router sends VLAN tags also in ARP request?

Theory:

ARP = HRD + PRO + HLN + PLN + OP + SHA + SPA + THA + TPA

= 2 + 2 + 1 + 1 + 2 + 6 + 4 + 6 + 4

= 28bytes = Datalength

Ethernet Header = 7+1+6+6+2 = 22 bytes

CTAG=802.1q=4bytes
STAG=802.1ad=4bytes

22+28+4=54 bytes

After padding it will be 64 bytes

CTAG= 4

STAG= 4

64+4+4=72

Peter Paluch · ‎10-11-2010

Hello Hemanth,

The preamble and the start-of-frame delimiter are present for physical layer needs (or for compatibility reasons) and they are not counted towards the frame size.

The ARP message itself is 28 bytes long, exactly as you indicated. Now, with correct Ethernet implementations, the outgoing frame has to be padded to be at least 64 bytes long. There are some quirks about this, however - the device that originated this ARP message may itself be capable of sending it in an untagged frame or in 802.1Q-tagged frame. The tag size is always accounted towards the total frame size, resulting in different paddings:

If the ARP message is to be sent in an untagged frame then the frame overhead itself is 18 bytes. That would result in a frame of 28+18=46 bytes without padding. Additional 18 bytes of padding are necessary in this case to bloat the frame to the 64 byte length.
If the ARP message is to be sent in an 802.1Q-tagged frame then the frame overhead is 22 bytes, resulting in the total frame size of 28+22=50 bytes. In this case, the padding needs to be 14 bytes long.
If the ARP message is to be sent in a double-tagged frame then the frame overhead is 26 bytes, resulting in the total frame size of 54 bytes. In this case, the padding needs to be 10 bytes long.

The different size of the padding may have unpleasant consequences if the frame is untagged - some implementations of Ethernet data-link layer including selected Cisco Catalyst switches do not extend the padding after untagging a frame. As a result, a frame that was exactly 64 bytes long when tagged becomes shorter than 64 bytes after untagging, essentially becoming a runt. This is in direct violation of the IEEE 802.1Q-2005 section C.4.4.3 that explicitly states:

If untagging a given frame would result in violation of the minimum frame length requirements of CSMA/CD, the Bridge is required to adjust the PAD field to ensure that the frame length equals the minimum length of 64 octets

Unfortunately, as also indicated by you, many vendors seem to somehow not consider this fact.

I do not know of any method to increase the ARP message size, and I shall also point out that this is not a problem of the ARP message size but rather of the compulsory Ethernet frame padding. The padding is always the responsibility of the MAC/PHY layer that forwards the frame, i.e. all Ethernet controllers and cards that emit Ethernet frames must take care to properly pad it. Note that this does not apply just to the originator of a message but rather to all intermediary Ethernet devices through which the frame is being delivered.

Seeing some vendors to send ARP in frames with the total size of 60 bytes is okay - the FCS of 4 bytes is not usually displayed in Wireshark or similar sniffers because the FCS is processed in the Ethernet hardware and not forwarded to the upper layers. In other words, Wireshark always displays all Ethernet frames to be 4 bytes shorter than they really are, so a frame with 60 bytes in Wireshark is essentially a frame with 64 bytes in total.

I hope this helps - I did not try to answer all your questions because I suppose that the facts I have explained so far may already answer those or make you reconsider some of your views. You are welcome to ask further!

Best regards,

Peter

hemuvenkat81 · ‎10-11-2010

Dear Peter,

Thank you very much for detailed explaination. It helps me lot to understand the padding concept.

Now it is very much clear to me.

Thanks,

Hemanth

hemuvenkat81 · ‎10-15-2010

I have observed within Cisco some L3 products supports minimum 64(60+4FCS) bytes for all frames. Some supports 68 bytes for tagged frames(64+4fcs+4Ctag). Why is this difference within same company?

Why cant we make it as user/manual configurable for both options like 64bytes and 68 bytes?

Standard says:

c) In some existing implementations, the decision as to whether pad octets are needed will be made at a

point where it is impractical to distinguish between tagged and untagged frames. In these cases, the

end station will use a minimum frame size of 64 octets for all frames;

d) In other cases, the padding decision will be taken at a point before it is known whether the frame will

be transmitted tagged or untagged. In these cases, the end station will use a minimum tagged frame

size of 68 octets and a minimum of 64 octets for untagged frames.

Peter Paluch · ‎10-15-2010

Hello Hemanth,

You have very good questions that unfortunately I cannot comment on, as these are too involved for an "outsider" to know.

I would say that the differences are actually hardware-dependent. Many NICs today have hardware support for 802.1Q tag processing, and thus offload the operating system from taking care about that. However, the different NIC/ASIC designs may eventually lead to discrepancies even among different products of the same vendor, and I have a feeling that this is what you are observing yourself. Unfortunately, I do not know if there is anything to be done about it from our part.

Perhaps you could raise a TAC case to make this issue known and taken care of.

Best regards,

Peter