Modify

Opened 11 years ago

Closed 6 years ago

#1321 closed enhancement (fixed)

patch: extend network/config.sh to support mtu and mac per bridge member

Reported by: framer99 Owned by: developers
Priority: low Milestone: Features Paradise
Component: base system Version: Kamikaze trunk
Keywords: mac mtu config.sh bridge Cc:

Description

Basically, this patch extends the macaddr and mtu options to apply to individual bridge members. It also corrects the sequence of events in config.sh so it will set the MAC of the bridge members and as a result, the MAC of the bridge psuedo-device.

Of course 99.9% of the usage of the macaddr option will be to set the MAC of the wan device connected to ISPs, so this patch is really only for the other 1% of uses.

The new macaddr and mtu options will look like this:

config interface     eastwest
option type          bridge
option ifname        "eth3 eth4"
#option macaddr      "useless for bridge device"
option macaddr_eth3  00:01:aa:bb:cc:01"
option macaddr_eth4  00:01:aa:bb:cc:02"
option mtu           1500
option mtu_eth3      1500
option mtu_eth4      9000

For bridge type config sections the plain unsuffixed option will apply to the psuedo-device such as br-lan. Obviously, the interface suffixed options will apply to the actual bridge members indicated by the suffix. Non bridge type interfaces will just use the normal "mtu" and "macaddr" as they do currently.

The current config.sh will try to set the MAC of a bridge psuedo-device(br-lan) if the user includes the macaddr option in the config section, which will not work. In this patch, the un-suffixed "macaddr" option is ignored for the bridge interface config sections.

Essentially all the patch does is function'ize the current ifconfig command that sets MTU and MAC into if_mac_mtu() and call it from a point before any bridge work is done(currently done just after bridge work).

Two more calls to if_mac_mtu() on the bridge pseudo-device are added, one after each place a interface can get added to a bridge. The 2.6 bridge MTU code explaination below explains why those 2 calls are needed.

This patch has been tested on an x86 initramfs build with multiple bridges and it boots and ifup/ifdown's cleanly with the proper mac, mtu etc.


MAC Setting with Bridges

You can set the MAC of the member interfaces and effectively control the MAC of the bridge psuedo-device itself (br-lan, br0, etc.) The lowest MAC of the bridge members is used as the MAC of the bridge psuedo-device. This bridge MAC is also used in the Root Bridge ID in STP


2.6 Bridge MTU Code

The bridging code in 2.6(but not 2.4) does work with different MTUs on bridge interfaces. The bridge psuedo-device will use the the smallest MTU configured on any of the member interfaces. The add interface routine in the 2.6 bridge code( br_add_if() ) checks the MTU of the "to be added" interface and the MTUs of all the current bridge members and sets the bridge psuedo-device's MTU to the smallest MTU found. It does this at every bridge member addition. Therefore, having MTU options for a bridge interface in /etc/config/network like:

option mtu      1496
option mtu_eth3 1500
option mtu_eth4 9000

could only be configured this way if you called ifconfig to set the MTU of the bridge psuedo-device after adding the last bridge member. The attached patch simply sets the psuedo-device's MTU after each member is added. This is easier than trying to track when all members have been added and then making a final call to set the psuedo-device MTU at a small overhead cost.

Now as to _why_ someone would want the psuedo-device MTU lower than all member interfaces I have no idea, but it's apparently possible( I only tested as far as configuring it) so to be complete, I put it in.


Different MTUs on Bridge Ports

For simply having differing MTUs on bridge ports, as I understand it the relevant 802 standard addresses it and the correct action for a too-large packet needing to go out a too-small MTU interface, is to simply drop it. Bridging a gigE lan and a 100mbit lan is an example of a possible use. Local traffic to/from the bridging host could use jumbo frames on the gigE port, but any frames bridged from gigE to fastE of course would need to fit in the MTu of the fastE port or they would get dropped by the bridging code.


Interaction with 2.4 Builds

As for no differing MTUs allowed on 2.4 kernel bridge code(and I'm not exaclty sure how 2.4 handles things), well, short of uname checks and preventing attempts to set the MTU on 2.4 kernel, the easy solution is "don't use unequal mtu options on a 2.4 kernel build". Although, the MAC setting portion would still be valid so this patch is not entirely useless on 2.4

Attachments (2)

10-network_config.sh_multi_mac_mtu.patch (2.8 KB) - added by framer99 11 years ago.
20-docs_multi_mac_mtu.patch (2.0 KB) - added by framer99 11 years ago.
patch to network.tex to add info on per interface macaddr and mtu settings

Download all attachments as: .zip

Change History (4)

Changed 11 years ago by framer99

Changed 11 years ago by framer99

patch to network.tex to add info on per interface macaddr and mtu settings

comment:1 Changed 8 years ago by thepeople

  • Milestone changed from Kamikaze to Kamikaze Features Paradize
  • Priority changed from normal to low
  • Version set to Kamikaze trunk

comment:2 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

supported in netifd by creating 'config device' sections for the individual ethernet devices and setting the mtu there.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.