Date: Sun, 6 Aug 2000 15:00:30 +0300 From: Pavel Gulchouck <gul@gul.kiev.ua> To: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca> Cc: freebsd-net@freebsd.org Subject: Re: VLAN MTU? 1500? 1504? Why? Message-ID: <20000806150029.A26345@lucky.carrier.kiev.ua> In-Reply-To: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA>; from Tarik Alj on Fri, Aug 04, 2000 at 04:44:59PM %2B0300 References: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! On Fri, Aug 04, 2000 at 04:44:59PM +0300, Tarik Alj writes: > >Louie, Thanks for your comments and for framing the question more > >clearly. > > > >Let's assume we do want to do 1500-byte frames on the virtual interfaces > >and go on to an ugly aspect of implementing it. > > > >Longer frames seem to require that the physical interface "know" that > >1504-byte frames should be allowed when the VLAN or 802.1p driver is > >above it but prohibited otherwise. Conversely, the VLAN driver should > >"ask" before assuming that the physical interface can handle the larger > >frames so that it can fail the open in those cases where the driver can't > >handle them? > > > >Is there any existing mechanism for "negotiation" of MTU between the > >physical layer and virtual layer? If not, should there be? I suppose we > >could crank the MTU of all physical interfaces up to whatever they can > >really handle instead of artificially limiting them to 1500 bytes, but > >that sounds icky. > > > >In short, it seem kind of gross to have to hack the source code of the > >physical driver when you intend to use it with a virtual driver above it. > >Is it worth making an elegant solution to this or should we just let the > >few who need longer frames continue futzing the source of the physical > >drivers? > > Well the actual solution isn't very elegant, is it? But there doesn't seem to be > a simple way to fix this. A _new_ MTU will require the existing drivers to be > modified anyways, but as things go more and more NICs should support 802.1Q > tagging. > > In my opinion VLANs are most useful (and were designed, I believe) for bridging > segments (that includes trunking), thus 802.1Q tagging should be done by the > bridge module. > > If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame > Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that > gets bigger, not the IP packet that gets smaller. (my 2c :). Now I have 802.1Q trunk on FreeBSD 4.1-stable with Catalyst 3548. And I don't know how I can solve the MTU problem. 1500-bytes ping does not pass, but 1400-bytes does. 'ifconfig vlan0 mtu 1500' has no effect. 'ifconfig fxp0 mtu 1504' responds "Invalid argument". Catalyst says "% Interface FastEthernet0/2 does not support user settable mtu.". I cannot decrease ip mtu at all interfaces of all devices on the vlans in the network, because here's colocation servers. What should I do? And I found one curious feature: if I'm running tcpdump on fxp0, all packets passes ok. Without tcpdump they drops. Now I'm thinking about run tcpdump as daemon. ;-) Here's tcpdump out on vlan interface with running tcpdump on fxp0: 13:46:05.231569 zeus.call > isida.call: icmp: echo request (frag 13715:1472@0+) 13:46:05.231580 zeus.call > isida.call: (frag 13715:36@1472) 13:46:05.233872 isida.call > zeus.call: icmp: echo reply (frag 13715:1480@0+) 13:46:05.233880 isida.call > zeus.call: (frag 13715:28@1480) 13:46:06.241441 zeus.call > isida.call: icmp: echo request (frag 13738:1472@0+) 13:46:06.241450 zeus.call > isida.call: (frag 13738:36@1472) 13:46:06.243809 isida.call > zeus.call: icmp: echo reply (frag 13738:1480@0+) 13:46:06.243818 isida.call > zeus.call: (frag 13738:28@1480) 13:46:07.251321 zeus.call > isida.call: icmp: echo request (frag 13758:1472@0+) 13:46:07.251331 zeus.call > isida.call: (frag 13758:36@1472) 13:46:07.253628 isida.call > zeus.call: icmp: echo reply (frag 13758:1480@0+) 13:46:07.253636 isida.call > zeus.call: (frag 13758:28@1480) 13:46:08.261198 zeus.call > isida.call: icmp: echo request (frag 13777:1472@0+) 13:46:08.261207 zeus.call > isida.call: (frag 13777:36@1472) 13:46:08.263541 isida.call > zeus.call: icmp: echo reply (frag 13777:1480@0+) 13:46:08.263549 isida.call > zeus.call: (frag 13777:28@1480) And here's without dumping fxp0: 13:46:42.390477 zeus.call > isida.call: icmp: echo request (frag 14372:1472@0+) 13:46:42.390486 zeus.call > isida.call: (frag 14372:36@1472) 13:46:42.392800 isida.call > zeus.call: (frag 14372:28@1480) 13:46:43.397059 zeus.call > isida.call: icmp: echo request (frag 14397:1472@0+) 13:46:43.397065 zeus.call > isida.call: (frag 14397:36@1472) 13:46:43.399602 isida.call > zeus.call: (frag 14397:28@1480) 13:46:44.406963 zeus.call > isida.call: icmp: echo request (frag 14415:1472@0+) 13:46:44.406970 zeus.call > isida.call: (frag 14415:36@1472) 13:46:44.409305 isida.call > zeus.call: (frag 14415:28@1480) 13:46:45.411392 zeus.call > isida.call: icmp: echo request (frag 14434:1472@0+) 13:46:45.411399 zeus.call > isida.call: (frag 14434:36@1472) 13:46:45.413675 isida.call > zeus.call: (frag 14434:28@1480) 13:46:46.426710 zeus.call > isida.call: icmp: echo request (frag 14448:1472@0+) 13:46:46.426717 zeus.call > isida.call: (frag 14448:36@1472) 13:46:46.429018 isida.call > zeus.call: (frag 14448:28@1480) Zeus (FreeBSD) sends to isida (Cisco router) packets fragmented to 1472 bytes. Isida responds packets fragmented to 1480 bytes. This 1480-bytes packets drops without tcpdump and reaches the destination with tcpdump running. Ping between cisco routers via trunk link are always ok (mtu 1500). Any comments? gul@zeus;~>ifconfig fxp0 fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:d0:b7:60:67:7e media: autoselect (100baseTX <full-duplex>) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP gul@zeus;~>ifconfig vlan2 vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255 ether 00:d0:b7:60:67:7e vlan: 1 parent interface: fxp0 -- Lucky carrier, Pavel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000806150029.A26345>