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>