Date: Wed, 05 Jul 2000 13:46:53 +0100 From: Tim Priebe <tim@polytechnic.edu.na> To: David Gilbert <dgilbert@velocet.ca> Cc: Kevin Oberman <oberman@es.net>, "Louis A. Mamakos" <louie@TransSys.COM>, Joerg Micheel <joerg@cs.waikato.ac.nz>, freebsd-stable@FreeBSD.ORG Subject: Re: Ethernet MTUs > 1500? Message-ID: <39632E3D.1E1258A@polytechnic.edu.na> References: <200007040508.BAA59763@whizzo.transsys.com> <200007042325.e64NPCn20451@ptavv.es.net> <14690.37799.546582.824877@trooper.velocet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
David Gilbert wrote: > > >>>>> "Kevin" == Kevin Oberman <oberman@es.net> writes: > > Kevin> Louis has it exactly right. 802.3 was modified a couple of > Kevin> years ago to allow for a maximum frame size of 1522 octets, up > Kevin> from the original 1518. This was to allow the VLAN information > Kevin> to fit in the frame. Exactly, my point also we must update our code to conform to the new standard. > Kevin> Since the terminating switch/router should be removing this > Kevin> information, the end system (and MTU) should be unaffected, but > Kevin> many nets seem to not fully support the longer frames in their > Kevin> infrastructure and probably lots of Internet routers don't > Kevin> either. This is often a hardware issue, so the only fixes > Kevin> available are to upgrade all hardware to support the added > Kevin> octets or to reduce the MTU so that the frame size does not > Kevin> exceed 1518. I am not sure that this is the case entirely the additional 4 bytes were for both VLAN and priority information. The priority information would often be sent by the host, and should probably also be recieved by it, so that it has the possibility of using the priority information for local prioratisation. And beyond this I have many applications where a host will be on multiple LANs. > Kevin> In an enterprise, the upgrade is feasible, but in the Internet > Kevin> backbone, if you are not extremely lucky to have all VLAN > Kevin> supporting equipment along the path, the packet is fragmented > Kevin> or dropped. And there is a LOT of equipment out there that does > Kevin> not support VLANs. I think this is a bit confused. The VLAN tags are for the LAN. They are for switching, not routing. That information should not be sent by the routers. The equivilant on a routed IP packet is the network part of the IP address. VLANs are logically separate LANs, which share the same physical network equipment. The point of the VLAN tag is so that multiple VLANs can use the same connection, and the equipment at both ends will be able to switch individual frames to the appropriate ports for that VLAN. FreeBSD since 3.0 mostly supports VLANs, but some NICs do not. For those NICs that are able to support the new standard, we should allow it, and not force them not to. I am right now getting ready to by new NICs that support VLANs nativly, to get around the software problem. > In this case, the BSD box is meant to be the terminator of the VLAN > trunks. In this case, Linux (to use the awful L word) forwards 1500 > byte packets into the VLANs. I just want my FreeBSD router to do the > same. I suppose I had best not show this to my boss, the VLAN support in FreeBSD, which was not available in Linux, was the only reason he let me install FreeBSD. I suppose if the new NICs do not solve the problems, I will have no choice. Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39632E3D.1E1258A>