No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FAQ - Explanation of how frame errors appears on the S9300 interfaces

Publication Date:  2012-07-27 Views:  89 Downloads:  9
Issue Description
The traffic is transmitted through Eth-Trunk interfaces which consist of two 10G interfaces.

When the Eth-Trunk is in access mode everything works without any problems but when Eth-Trunk is switched to trunk mode the frame errors starts to appear.

802.3 Ethernet frame structure
             
MAC destination MAC source 802.1Q tag (optional) Ethertype or length Payload Frame check sequence (32-bit CRC)
6 octets 6 octets (4 octets) 2 octets 46–1500 octets 4 octets
64–1522 octets
                     
 
 
 
The minFrameSize of 802.3 Ethernet frame is 64 bytes. So this is the minimal size of the Ethernet frame which can be send through a network.
 
When we have “payload” smaller than 46 bytes in such case we have to use padding to fill the rest free space to 46 bytes.
For example when we wish to send 40 bytes of payload then 6 bytes will be added as padding to the payload in order to receive 46 bytes of Ethernet payload. Then such payload is encapsulated by Ethernet frame header and tailor. Total size is increasing by 18 bytes when not using VLAN tagging or by 22 bytes when VLAN tagging is used.
 
In a case when the device receives a untagged frame whith total size 64 bytes (minFrameSize) it means that the padding size must be >= 0, and the “length field” should be  <= the “computed length” of the data field which is the “payload” size.
 If the “length field” is greater than the “computed DATA length” that means the length field has error and frame error counter increase
 
When the device receives a tagged or untagged frame, which total size of the frame is greater than minFrameSize (greater than 64 bytes) in such case device assumes that the padding size must be zero (no padding is used).
Additionally the “length field” should be equal to the “computed DATA length” (payload size). Otherwise the length field is not correct and the frame error counter increase.
 
Alarm Information
The traffic is transmitted through Eth-Trunk interfaces which consist of two 10G interfaces.

When the Eth-Trunk is in access mode everything works without any problems but when Eth-Trunk is switched to trunk mode the frame errors starts to appear.
 
Eth-Trunk1 current state : UP
Line protocol current state : UP
Description:HUAWEI, Quidway Series, Eth-Trunk1 Interface
Switch Port, PVID :   16, Hash arithmetic : According to SIP-XOR-DIP,Maximal BW: 20G, Current BW: 20G, The Maximum Frame Length is 9216
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 80fb-06c1-fa14
    Input bandwidth utilization  : 0.01%
    Output bandwidth utilization : 0.01%
-----------------------------------------------------
PortName                      Status      Weight
-----------------------------------------------------
XGigabitEthernet6/0/0         UP          1
XGigabitEthernet6/0/1         UP          1
-----------------------------------------------------
The Number of Ports in Trunk : 2
The Number of UP Ports in Trunk : 2
 
 
 
XGigabitEthernet6/0/0 current state : UP
Line protocol current state : UP
Description:HUAWEI, Quidway Series, XGigabitEthernet6/0/0 Interface
Switch Port, TPID : 8100(Hex), The Maximum Frame Length is 9216
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 80fb-06c1-fa14
..........
Input:  254133167 packets, 136022869367 bytes
  Unicast:                  199484419,  Multicast:                    28259186
  Broadcast:                 25047284,  Jumbo:                             157
  Discard:                          0,  Total Error:                   1342121
 
  CRC:                              4,  Giants:                              0
  Jabbers:                        521,  Fragments:                           0
  Runts:                            0,  DropEvents:                          0
  Alignments:                       0,  Symbols:                             0
  Ignoreds:                         0,  Frames:                        1341596
 
Output:  202996431 packets, 44869236933 bytes
  Unicast:                  197977169,  Multicast:                      743153
  Broadcast:                  4276109,  Jumbo:                               0
  Discard:                          0,  Total Error:                         0
 
  Collisions:                       0,  ExcessiveCollisions:                 0
  Late Collisions:                  0,  Deferreds:                           0
  Buffers Purged:                   0
 
    Input bandwidth utilization threshold : 100.00%
    Output bandwidth utilization threshold: 100.00%
    Input bandwidth utilization  : 0.01%
    Output bandwidth utilization : 0.01%
 
 
XGigabitEthernet6/0/1 current state : UP
Line protocol current state : UP
Description:HUAWEI, Quidway Series, XGigabitEthernet6/0/1 Interface
Switch Port, TPID : 8100(Hex), The Maximum Frame Length is 9216
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 80fb-06c1-fa14
.........
Input:  281971802 packets, 156629900596 bytes
  Unicast:                  221832695,  Multicast:                    23376603
  Broadcast:                 33920612,  Jumbo:                              57
  Discard:                          0,  Total Error:                   2841835
 
  CRC:                              0,  Giants:                              0
  Jabbers:                        156,  Fragments:                           0
  Runts:                            0,  DropEvents:                          0
  Alignments:                       0,  Symbols:                             0
  Ignoreds:                         0,  Frames:                        2841679
 
Output:  192049782 packets, 40958922603 bytes
  Unicast:                  178371902,  Multicast:                      816705
  Broadcast:                 12861174,  Jumbo:                               1
  Discard:                          0,  Total Error:                         0
 
  Collisions:                       0,  ExcessiveCollisions:                 0
  Late Collisions:                  0,  Deferreds:                           0
  Buffers Purged:                   0
 
    Input bandwidth utilization threshold : 100.00%
    Output bandwidth utilization threshold: 100.00%
    Input bandwidth utilization  : 0.01%
    Output bandwidth utilization : 0.01%

Handling Process
When frame errors appears it does not states that we are loosing traffic. The traffic is send through network although frame error counters increase.
This behavior is a result of how our chip works and cannot be changed.

Root Cause
In our case sometimes 40 bytes packets are sent through the network. In this case additional 6 bytes of padding are added to the packet in order to have 46 bytes Ethernet payload.
When we wish to send this packet through access interface the switch will add 18 bytes of Ethernet header and tailor (FCS). The size of the Ethernet frame is equal to 64 bytes.
Receiving switch will check the size of the frame and will realize that the size is 64 bytes. Then the frame has to be checked whether
length field <= the computed length.
In our case is as follow 40B <= 46B. This equation is true so no frame errors will appear.
 
When the same 40 bytes packet is sent through a network but through a trunk port then:
  • Switch is adding 6 bytes of padding to have 46 bytes of Ethernet payload
  • Such payload is encapsulated by 22 bytes of Ethernet header and tailor (6B for MAC address destination, 6B for MAC address source, 4 bytes for 802.1Q which is VLAN tag, 2B for EtherType/Length, 4B for FCS)
As a result we have 6 bytes Ethernet frame with padding.
When receiving switch receive such frame then it checks total size of a frame which is 68 bytes. Because the size is not minFrameSize it will check whether
                “length field” = “computed DATA length”
In our case we have 40B = 46B. This equation is false so the frame error counter increase.
This frame error appears even-though we are using the smallest frame size with VLAN tagging.

Suggestions
When frame errors appears it does not states that we are loosing traffic. The traffic is send through network although frame error counters increase.
This behavior is a result of how our chip works and cannot be changed.

END