Package: bridge-utils
Version: 1.0.4-1
Severity: wishlist
The documentation for bridge-utils does not address the topic of MTU
values for the bridge and its interfaces.
My limited experiments seem to show that the MTU of the bridge
interface is hardwired to be the minimum MTU of the bridged
interfaces, and that all traffic through the bridge uses the bridge's
MTU, even if the source and destination of a packet are on an
interface that has a higher MTU. I could find no documentation to
confirm these guesses, nor any discussion of how it may or may not be
possible to use an MTU higher than the minimum when the source and
destination interfaces both support the higher MTU.
Especially as Gigabit ethernet becomes more popular, this topic will
become more relevant for more users.
Here is a motivating situation.
I use a bridge in combination with openvpn and samba to allow remote
VPN clients to participate in the Samba LAN on the physical ethernet
adapter eth0. This involves bridging eth0 with tap0 into br0 and
pointing samba and dnsmasq at br0. Everything works fine with a 100BT
LAN and the default MTU of 1500 on all three interfaces. Recently I
updated the LAN (eth0) to Gigabit-capable adapters and switch.
Changing the MTU of eth0 to 8000 does not increase the packet size for
traffic which originates and ends on eth0. I get an error if I try to
change the MTU of br0 to a number greater than the minimum MTU of the
bridge participants. I can't increase the MTU of tap0 above 1500, so
the bridge seems to be limited to 1500 as well, which means that
samba is limited to 1500 MTU. I can show that the limitation is in
the bridge by removing the bridge and pointing samba directly at
eth0. In this case, tcpdump will confirm that packet size increases
with the MTU of eth0 (for example, MTU=8000 and packet size=8014).
It seems to me it ought to be possible to use jumbo packets for
traffic within eth0 (MTU=8000) and normalsize packets for traffic
involving tap0 (MTU=1500). I don't know a lot about this aspect of
networking, so I may be wrong. If MTU issues were discussed in the
documentation of bridge-utils, I could expect to learn the answers.
If there were such documentation, I might also know how to evaluate
the following problems, which could be deserving of actual (i.e.,
non-wishlist) bug reports:
When I change the MTU of an interface participating in a bridge
without first deleting the bridge, I get an onslaught of page
allocation failure message from the kernel, from any/all processing
running at the time. Here is an example one:
Jan 24 16:04:15 beth kernel: XFree86: page allocation failure. order:3,
mode:0x20
Jan 24 16:04:15 beth kernel: [__alloc_pages+760/880]
__alloc_pages+0x2f8/0x370
Jan 24 16:04:15 beth kernel: [__get_free_pages+31/64]
__get_free_pages+0x1f/0x40
Jan 24 16:04:15 beth kernel: [kmem_getpages+31/208] kmem_getpages+0x1f/0xd0
Jan 24 16:04:15 beth kernel: [cache_grow+186/384] cache_grow+0xba/0x180
Jan 24 16:04:15 beth kernel: [cache_alloc_refill+362/544]
cache_alloc_refill+0x16a/0x220
Jan 24 16:04:15 beth kernel: [add_interrupt_randomness+49/64]
add_interrupt_randomness+0x31/0x40
Jan 24 16:04:15 beth kernel: [__kmalloc+116/128] __kmalloc+0x74/0x80
Jan 24 16:04:15 beth kernel: [alloc_skb+71/240] alloc_skb+0x47/0xf0
Jan 24 16:04:15 beth kernel: [e1000_alloc_rx_buffers+101/272]
e1000_alloc_rx_buffers+0x65/0x110
Jan 24 16:04:15 beth kernel: [e1000_clean_rx_irq+261/1136]
e1000_clean_rx_irq+0x105/0x470
Jan 24 16:04:15 beth kernel: [__mod_timer+264/368] __mod_timer+0x108/0x170
Jan 24 16:04:15 beth kernel: [e1000_watchdog+453/1008]
e1000_watchdog+0x1c5/0x3f0
Jan 24 16:04:15 beth kernel: [e1000_clean+65/192] e1000_clean+0x41/0xc0
Jan 24 16:04:15 beth kernel: [net_rx_action+116/256]
net_rx_action+0x74/0x100
Jan 24 16:04:15 beth kernel: [__do_softirq+123/128] __do_softirq+0x7b/0x80
Jan 24 16:04:15 beth kernel: [do_softirq+39/48] do_softirq+0x27/0x30
Jan 24 16:04:15 beth kernel: [do_IRQ+251/304] do_IRQ+0xfb/0x130
Jan 24 16:04:15 beth kernel: [common_interrupt+24/32]
common_interrupt+0x18/0x20
These errors persist until I delete the bridge with "ifdown br0".
Under some circumstances, I can successfully change the MTU of a
bridged interface if I do it while the bridge is down, then
re-establish the bridge.
I can do that if I use an MTU of 8000, but if I try an MTU of 8982, I
get the same page allocation errors whenever I try to bring up the
bridge.
If you think this last problem should be reported to another location,
such as the maintainer of the e1000 module, please let me know. Right
now, my analysis is stuck because I do not know how bridge-utils ought
to handle MTU.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-beth.10
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages bridge-utils depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libsysfs1 1.1.0-1 Interface library to sysfs
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
