Date: Tue, 25 Aug 2015 02:04:52 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: FreeBSD not properly padding vlan packets on several interface types. Message-ID: <20150824230452.GG21849@zxy.spb.ru> In-Reply-To: <CACpH0Me_Nem9j30CdH=q4PUppKfFZegOuUQVxOR-1m4mdWXX9g@mail.gmail.com> References: <CACpH0Me_Nem9j30CdH=q4PUppKfFZegOuUQVxOR-1m4mdWXX9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 24, 2015 at 06:48:31PM -0400, Zaphod Beeblebrox wrote: > So, as background, the minimum packet size for ethernet packets is 64 > bytes. According to at least cisco, the minimum size, then, for 802.1q > (vlan, etc) packets is 68 bytes. On at least BGE and BCE interfaces, it > seems (according to counters on my switch) that FreeBSD doesn't honour this. > > "show interface counters error" is the cisco command to check. C.4.4 Padding and frame size considerations C.4.4.1 Treatment of PAD fields in IEEE Std 802.3 frames The minimum frame size constraint placed on IEEE 802.3/Ethernet frames requires frames to carry zero or more pad octets following the MAC client data, in order to ensure that no frame of total length less than 64 octets is transmitted on the medium. This requirement means that frames whose overall length would otherwise be less than 64 octets in length have (64-len) octets of padding added after the MAC client data, where len is the size of the frame before padding. When tagged frames are transmitted by a Bridge on an IEEE Std 802.3 MAC, there are two permissible approaches (7.2), as follows: a) Keep the minimum frame size generated by the Bridge equal to 64 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would be reduced by up to 4 octets when that frame was tagged; b) Adopt a minimum tagged frame length of 68 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would not be adjusted when tagging such frames; equally, if subsequently untagged, no pad adjustment would be necessary before transmission on IEEE 802.3/Ethernet. C.4.4.2 Maximum PDU size VLAN tagging of an untagged frame, or relaying frames in tagged frame format, can result in an increase in the length of the original frame. If transmission of a given frame in tagged frame format through a given destination Port would result in violation of the maximum PDU size for the destination MAC method, the Bridge discards the frame for that destination Port. NOTE-Violation of the maximum PDU sizes for destination MAC methods can produce undefined results in networks that contain devices that adhere strictly to these maxima, or in MAC methods where these maxima are inherently constrained by the operation of the MAC method itself (e.g., constrained by timing considerations in the MAC state machines). IEEE Std 802.3ac-1998 defines an extension to the normal IEEE 802.3 maximum frame size for the specific purpose of accommodating the additional octets of the VLAN tag header. The example frame translations in this annex make use of this extension to the IEEE 802.3 frame size. C.4.4.3 Minimum PDU size VLAN untagging of a tagged frame results in the original frame decreasing in length. Where the destination MAC is CSMA/CD: a) 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 (7.2 and C.4.4.1); b) If a frame is transmitted in tagged frame format, the Bridge may adopt a minimum tagged frame length of either 64 or 68 octets, as an implementation option. If the latter is chosen, the Bridge adjusts the size of the PAD field on transmission for any tagged frame that is less than 68 octets in length (7.2, C.4.4.1).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150824230452.GG21849>