From owner-freebsd-net Tue Aug 28 9:54:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E31FD37B405 for ; Tue, 28 Aug 2001 09:54:20 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7SGsIF38299; Tue, 28 Aug 2001 12:54:18 -0400 (EDT) (envelope-from wollman) Date: Tue, 28 Aug 2001 12:54:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Runt frames = broken VLAN ? In-Reply-To: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Can anyone tell me why the VLAN code might be causing my switches (ciscos) > to see a lot of runt frames when the interface is in 802.1q trunking mode ? It's possible that the Cisco is (bogusly, IMHO) trying to enforce the Ethernet minimum frame length on the *de*capsulated frames. If you send a frame that's less than 60 octets long, it gets encapsulated (adding another four octets) and then padded by the interface up to 64 octets. After the encapsulation is removed by the receiver, the frame appears to only be 60 octets long. I'd call it a Cisco bug. The minimum frame length in Ethernet arises from the electrical parameters of the original CSMA/CD Ethernet design; what matters is the number of clocks the transmitter is active, not the length of the payload. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message