hi, i saw a message a few days ago about supporting macvlans within uci. i'm interested in doing some stuff with macvlans, so i'd like to start up this conversation again.
i'd actually like to argue that a vlan-style naming convention (like eth0#5) makes sense, because of the way macvlans work and interact with bridges. one might like to think that a macvlan is just a virtual interface that happens to be internally bridged with a physical one. this isn't exactly the case. say i have macvlan eth0#5 on my physical eth0. then: * if i add eth0 to a bridge, no packets ever arrive on eth0#5. * if i add eth0#5 to a bridge, unicast packets from eth0 will never arrive on the bridge. in particular, the only way to have multiple virtual mac addresses in a bridge (this is what i want to do) is to create the macvlan devices from the bridge device. i don't think this implementation makes a huge amount of sense, but apparently this is the way it has worked for years. the rules are also somewhat similar to the rules for vlans: it doesn't make sense to work with eth0.5 while eth0 is on bridge br0. the correct thing to do in that case is to work with br0.5. since the topology of a macvlan influences how (or whether) it works, i think it's handy to have the base device reflected in the name. a convention like eth0#5 also simplifies configuration somewhat: an interface named eth0#5 would be known to be a macvlan with base device eth0. i picked the convention eth0#5 because that's the convention used in a single example line on the old macvlan maintainer's page: http://www.candelatech.com/~greear/vlan.html . i couldn't find any other precedent. i'd therefore like to propose that an interface of the form 'eth0#anything' is implicitly understood to be a macvlan with eth0 as its base device, to be brought up under the same conditions (probably in the same code) where vlan interface 'eth0.1' would be brought up. thoughts? ~steve _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
