Great, thanks for testing.
Intyeresting side effect of the patch appears to be that I am getting 25%
*lower* throughput on my ether connections between two machines plugged into
the same switch. Not what I expected! I assume this is something to do with
the behaviour of the switches as the BSD
Please test this attached patch, note it includes the previous change
too.
I just tested this, and it lets me enable jumbo frames on the lagg
interface as well as fixing the previous zero MAC problem as
well. Currently running one of our production machines on it as a
test (in a farm so it
YES. thank you! your latest patch solved my problems.
going to test it tomorrow in production.
2007/7/26, Andrew Thompson [EMAIL PROTECTED]:
On Wed, Jul 25, 2007 at 10:42:21PM +0400, Alexey Karagodov wrote:
patch did not help ...
ifconfig:
lagg0:
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.
Erp! Do you have any mor einfo on tyhis - what kinds of things does
this break ? Since lagg arrived I have deployed it on all our production
machines.
On Thu, Jul 26, 2007 at 01:02:06AM +0100, Pete French wrote:
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
...and now all my outgoing packets have the correct MAC address as expected
on them. I alos notice that
On Wed, Jul 25, 2007 at 10:42:21PM +0400, Alexey Karagodov wrote:
patch did not help ...
ifconfig:
lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.1 netmask 0x broadcast 10.0.255.255
inet 10.0.0.2 netmask 0x broadcast
Most people didnt see a problem which is why this slipped through.
tcpdump on another host with the -e flag and see what the src mac is.
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
thanks,
-pete.
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
...and now all my outgoing packets have the correct MAC address as expected
on them. I alos notice that I am now only seeing packets destined for the
appropriate machine
On Wed, Jul 25, 2007 at 12:54:30PM +0100, Pete French wrote:
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.
Erp! Do you have any mor einfo on tyhis - what kinds of things does
this break ?
patch did not help ...
ifconfig:
# ifconfig
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING
ether XX:XX:XX:XX:XX:XX
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
lagg: laggdev
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 )
thanx
kernel: vlan301: discard oversize frame (ether type 800 flags 3 len
1514 max 1510)
2007/7/13, Chuck Swiger [EMAIL PROTECTED]
is there any progress?
just one me too
this problem appeared for me when i try to use vlan over lagg ( to em NICs
)
thanx
kernel: vlan301: discard oversize frame (ether type 800 flags 3 len 1514
max 1510)
2007/7/13, Chuck Swiger [EMAIL PROTECTED]:
On Jul 12, 2007, at 1:38 PM, Stephen
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
Hi List,
When using ipnat, part of ipfilter 4.1.13, I don't see any
icmp packets being returned saying:
Host Unreachable, frag needed and DF set.
type 3, code 4
It does work if I am not using ipnat.
Any ideas?
Thanks,
Steve
--
They that give up essential liberty to obtain temporary safety,
Stephen Clark wrote:
Hi List,
When using ipnat, part of ipfilter 4.1.13, I don't see any
icmp packets being returned saying:
Host Unreachable, frag needed and DF set.
type 3, code 4
It does work if I am not using ipnat.
Any ideas?
Thanks,
Steve
Sorry for the noise - this seems to be OK.
On Jul 12, 2007, at 12:34 PM, Stephen Clark wrote:
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incoming packet.
Nothing changed; that is the expected behavior.
(Modulo support for 4-byte VLAN tags.)
kernel: rl0: discard oversize frame (ether type 800
Chuck Swiger wrote:
On Jul 12, 2007, at 12:34 PM, Stephen Clark wrote:
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incoming packet.
Nothing changed; that is the expected behavior.
(Modulo support for 4-byte VLAN tags.)
kernel: rl0: discard
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
18 matches
Mail list logo
