Messages in this thread | | | From | Štefan Gula <> | Date | Mon, 23 Jan 2012 15:44:49 +0100 | Subject | Re: [patch v1, kernel version 3.2.1] Source mode for macvlan interaface |
| |
2012/1/23 Eric Dumazet <eric.dumazet@gmail.com>: > Le lundi 23 janvier 2012 à 13:30 +0100, Stefan Gula a écrit : >> From: Stefan Gula <steweg@gmail.com> >> >> New mode of macvlan interface called "source" allows one to specify, >> which frames are allowed to be received by given macvlan interface. >> This logic is used only on received frames on underlaying interface. >> The ability to send frames from macvlan interface through underlaying >> interface is not modified. This feature allows one to simulate 802.1x >> mac based VLAN bahaviour by using proper netlink message to configure >> this behavior with utililty such as "ip link" from iproute2 suite. >> >> Signed-off-by: Stefan Gula <steweg@gmail.com> > > Please limit line lengths to 70 chars. > > I dont understand your patch description at all, and reading its body I > still dont understand its purpose. > > Is it sort of firewall rules (ebtable) or bridging code ? Probably partially both of them. Today to achieve the same you need 2/3 things in kernel: - veth module (optional) - bridge module - ebtables module
In real life scenarios, where 802.1x is deployed with mac based authentication feature usually in wireless networks, but sometimes also in wired ones, RADIUS message includes part which instruct NAS to set given user to proper VLAN. As nature of having multiple clients behind the same physical interface, there is a need to separate the incoming traffic from clients based on their MAC address (source MAC addresses in incoming frames). That can be achieved by two ways. One way is that driver of physical interface allows that directly (usually not true) or by using virtualization on network layer by: - incoming interface and all possible outgoing interfaces into one huge bridge - creating ebtables set of rules that permits given traffic back and forth through this bridge - to maintain certain level of segmentation and easy of maintenance sometime people do (optional steps): - creating one veth per VLAN - creating one small bridge per VLAN - putting one end of veth link into the small bridge with all possible physical outgoing interfaces for given VLAN - putting second end of veth link into the huge bridge instead of physical outgoing interfaces for given VLAN - in case that some MAC address resides on multiple VLANs (e.g. some HW L3 switch used to route traffic), you will end up with problem due the process of learning on that huge bridge, will allows it to exists only behind of one port, which is not true as it can exists behind multiple ports in different VLANs
My patch simple removes this need for using of the huge bridge with ebtables rules and solves the problem of residing MAC address in multiple VLANs.
>> +static void macvlan_hash_del_sources(struct macvlan_source_list *list, >> + bool sync) >> +{ >> + hlist_del_rcu(&list->hlist); >> + kfree_rcu(list, rcu); >> + if (sync) >> + synchronize_rcu(); >> +} >> + > > Please explain why are you using synchronize_rcu() here, as there must > be a good reason, but I missed it. I though so, but I was not sure whether that should be removed or not so I rather leave it there as I followed the original code structure of macvlan driver. So should I remove it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |