From owner-freebsd-stable@FreeBSD.ORG Wed Jul 25 18:42:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D8C16A41F for ; Wed, 25 Jul 2007 18:42:23 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id 05A0313C4A5 for ; Wed, 25 Jul 2007 18:42:22 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so200359wra for ; Wed, 25 Jul 2007 11:42:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cRe28VFjrEtmDKKq9/JMT97MWrkOxsKNx3XA/RqaCBcrpdR2k210K1tewMjXnqzlJ1GNz2kUQw4e5DCK4xO0OsEdFecU+WQAhtThPEnvY87RlxIA4UlCTmDZ+lvaiU3UFWOLQ71RNqCfKAhYt7iLJohunYCmsbuMc3kiVS3oNVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oKI8By4xJI2D4PG8e4HamEdHX6qsTu/0xRpB9iMDSvhd8hmmTHWdSAOFQWNdKQ4ENxa4FLjfstnFD4lYM3kZaJp+6+ejkPEnrJkalOmQ4eiuugMCGTRDtZzYmmJQwJ7qMn8Pz8Uyt0UMhhW+aw4cTxR7iXaSxRFIIDQo+zhIvP8= Received: by 10.90.90.3 with SMTP id n3mr998800agb.1185388941782; Wed, 25 Jul 2007 11:42:21 -0700 (PDT) Received: by 10.64.53.17 with HTTP; Wed, 25 Jul 2007 11:42:21 -0700 (PDT) Message-ID: Date: Wed, 25 Jul 2007 22:42:21 +0400 From: "Alexey Karagodov" To: "Andrew Thompson" In-Reply-To: <20070725004402.GA13665@heff.fud.org.nz> MIME-Version: 1.0 References: <469624D1.20108@seclark.us> <4696823B.9020107@seclark.us> <46969129.60409@seclark.us> <3C09F7E4-C15A-4B9E-94A3-C4997C73C0BD@mac.com> <20070725004402.GA13665@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Stephen.Clark@seclark.us, freebsd-stable@freebsd.org Subject: Re: pmtud + ipnat RELENG_6_2 appears to be broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 18:42:23 -0000 patch did not help ... ifconfig: # ifconfig em0: flags=8843 mtu 1500 options=1b ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 em1: flags=8843 mtu 1500 options=1b ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 pfsync0: flags=0<> mtu 2020 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=141 mtu 33160 lagg0: flags=8843 mtu 1500 inet 10.0.0.1 netmask 0xffff0000 broadcast 10.0.255.255 inet 10.0.0.2 netmask 0xffff0000 broadcast 10.0.255.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c vlan302: flags=8843 mtu 1496 inet 192.168.111.7 netmask 0xffffff00 broadcast 192.168.111.255 inet 192.168.111.1 netmask 0xffffff00 broadcast 192.168.111.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active vlan: 302 parent interface: lagg0 vlan150: flags=8843 mtu 1496 inet 192.168.150.1 netmask 0xffffff00 broadcast 192.168.150.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active vlan: 150 parent interface: lagg0 and other VLANs ..... all on lagg0 interface i was tried to change laggproto, it doesn't help. i can NOT increase MTU on lagg interface above 1500 and on vlan interface above lagg's MTU -4 . also i've increased MTU on both ems to 9000 and after that i still can't increase MTU on lagg interface above 1500 please, HELP ... and VERY LITTLE part of dmesg: vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 > max 1510) 2007/7/25, Andrew Thompson : > > On Wed, Jul 25, 2007 at 03:15:17AM +0400, Alexey Karagodov wrote: > > is there any progress? > > just one "me too" > > > > this problem appeared for me when i try to use vlan over lagg ( to em > NICs > > ) > > lagg on RELENG_6 is currently broken due to subtle differences that > wernt taken into account when it was MFCd. Can you please test this > patch. > > > Index: if_lagg.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_lagg.c,v > retrieving revision 1.11.2.3 > diff -u -p -r1.11.2.3 if_lagg.c > --- if_lagg.c 12 Jul 2007 20:40:24 -0000 1.11.2.3 > +++ if_lagg.c 25 Jul 2007 00:43:24 -0000 > @@ -319,6 +319,7 @@ lagg_lladdr(struct lagg_softc *sc, uint8 > if (memcmp(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN) == 0) > return; > > + bcopy(lladdr, IFP2ENADDR(ifp), ETHER_ADDR_LEN); > bcopy(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN); > /* Let the protocol know the MAC has changed */ > if (sc->sc_lladdr != NULL) > > > > > 2007/7/13, Chuck Swiger : > > > > > >On Jul 12, 2007, at 1:38 PM, Stephen Clark wrote: > > >>> The MTU is actually defined in reference to a network segment such > > >>> as an "ethernet collision domain", and applies to all machines > > >>> sending traffic to that segment. If the MTU is really 1280, > > >>> nobody else should be sending larger packets, and the drivers > > >>> will drop any larger packets they receive and generate the > > >>> appropriate ICMP error.... > > >> > > >> First thanks for responding but thats the problem, > > >> this did't generate an icmp when the packet was dropped. > > >> > > >> kernel: rl0: discard oversize frame (ether type 800 flags 3 len > > >> 1514 > max > > >> 1294) > > >> > > >> This message did not result in any icmp packet. > > >> > > >> I was running tcpdump looking for them. > > > > > >Taking a quick look at ether_input() in src/sys/net/if_ethersubr.c > > >suggests that you are right-- if the incoming packet exceeds the MTU > > >being set, the input errors count for that interface is incremented, > > >but no ICMP_UNREACH_NEEDFRAG is generated even if DF flag is set. > > > > > >You might file a PR and see whether you can get Andre or one of the > > >other networking gurus interested in fixing this. Or maybe I'll give > > >it a try myself if I can get some free time.... :-) > > > > > >-- > > >-Chuck > > > > > > > > >_______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe @ > freebsd.org" > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@ > freebsd.org" >