Bug 169824 - Problems with bridging and MTU parameters
Problems with bridging and MTU parameters
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-04 03:50 EDT by Enrique Arizón Benito
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 20:28:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrique Arizón Benito 2005-10-04 03:50:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Description of problem:
 While trying to setup OpenVPN I add next lines to /etc/rc.local:

brctl addbr br0
brctl addif br0 tap0
brctl addif br0 eth1
                                                                                                                          ifconfig tap0 0.0.0.0 promisc up
ifconfig eth1 0.0.0.0 promisc up
                                                                                                                          
ifconfig eth1 mtu 1500
ifconfig br0 mtu 1500
ifconfig tap0 mtu 512

 In other fedora versions it works out of the box, and I get a the desired MTU for each network interface (1500 for br0, 1500 for eth1 and 512 for tap0).

 But in FC4 whenever I change the tap0 MTU, it get changed in br0, so I have some problems (if I set tap0/br0 to 1500 "VoIP" stop working, but if I set tap0/br0 < 1500 (512) some Windows machines can't authenticate to the Domain Controler on the "other side" of the VPN).

Version-Release number of selected component (if applicable):
2.6.11-1.1369_FC4smp

How reproducible:
Always

Steps to Reproduce:
1. See description.
  

Actual Results:  See description.

Expected Results:   I expected to be able to separately setup MTU for br0 and tap0.

Additional info:

 ~# ifconfig
  ...
br0       Link encap:Ethernet  HWaddr 00:C0:26:A0:75:36
          inet addr:192.168.0.7  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:390202 errors:0 dropped:0 overruns:0 frame:0
          TX packets:79355 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:46633409 (44.4 MiB)  TX bytes:30694576 (29.2 MiB)
                                                                                                                            
eth1      Link encap:Ethernet  HWaddr 00:C0:26:A0:75:36
          inet6 addr: fe80::2c0:26ff:fea0:7536/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:683762 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1784711 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:326934922 (311.7 MiB)  TX bytes:284276118 (271.1 MiB)
          Interrupt:185 Base address:0xd400
                                                                                                                            
tap0      Link encap:Ethernet  HWaddr CA:0F:FC:8F:74:4B
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1289065 errors:0 dropped:0 overruns:0 frame:0
          TX packets:168313 errors:0 dropped:26 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:103390298 (98.6 MiB)  TX bytes:40009592 (38.1 MiB)
Comment 1 Dave Jones 2005-10-04 03:59:37 EDT
hmm, can you make sure you can reproduce this on the latest errata kernel please
? I just realised you're two point releases behind, and a lot has changed since
then.
Comment 2 David Miller 2005-10-05 20:28:58 EDT
This is correct behavior, the bridge device must inherit the MTU
restrictions of any device contained underneath it.

This new behavior is a bug fix, not a bug.

Note You need to log in before you can comment on or make changes to this bug.