I have observed some unexpected behaviour on a Nexus 7000 running 6.1(2) in respect of the Ethernet II frame generated when the Nexus 7000 is a GRE Tunnel endpoint.
The device (non Cisco) receiving the Frame is discarding it and I waiting for the vendor to confirm the reason for this discard. However in case the reason is due to the Ethernet frame being "unusual" I am seeking any insights to the Nexus 7000 behavioiur.
To generate the Frame I perform a ping (on a workstation attached to the Nexus) which the Nexus is encapsulating in a GRE tunnel. Using Wireshark on the Nexus 7000 egress interface I observed that the Frame contains the following protocols as expected; ETH:IP:GRE:IP:ICMP:data
When I issue the command "ping -l 1" on the workstation the Frame details from Wireshark are:
Frame 84 bytes on wire
Total IP payload = 53 bytes
Outer IP header (20 bytes)
GRE ( 4 bytes)
Inner IP header (20 bytes)
ICMP (header 8 bytes payload 1 byte)
Ethernet Trailer length = 17 bytes
What is curious about this Frame is that;
a) No Ethernet Trailer is needed as the IP payload exceeds 46 bytes
b) The amount of padding applied is what would be needed if the Inner IP datagram were encapsulated dircetly in an Ethernet II Frame. The Inner ip datagram is 29 bytes and therefore padding needed = 46 - 29 = 17 bytes.
By doing ping sweep from length 1 to 18 the observed padding was;
1,17
2,16
3,15
-----
-----
17,1
18,0
So it would appear that the Nexus is adding padding to the Ethernet frame as though it were containing the pre GRE payload only.
RFC 894 specifies IP encapsulation in Ethernet II frames. It states “If necessary, the data field should be padded (with octets of zero) to meet the Ethernet minimum frame size.”
