netdev - Re: MACVLANs really best solution? How about a bridge with multiple bridge virtual interfaces? (was Re: [PATCH] macvlan: Support creating macvlans from macvlans)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 09 Mar 2009 16:02:11 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Mark Smith 
	<nanog@...5b20a518b8f6864949bd940457dc124746ddc.nosense.org>,
	greearb@...delatech.com, David Miller <davem@...emloft.net>,
	netdev@...r.kernel.org, shemminger@...ux-foundation.org
Subject: Re: MACVLANs really best solution? How about a bridge with multiple
 bridge virtual interfaces? (was Re: [PATCH] macvlan: Support creating macvlans
 from macvlans)

Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
> 
>> I agree on most points. There is one fundamental operational difference
>> however. With macvlan, all MAC addresses are known are therefore can be
>> programmed as secondary unicast addresses, while a bridge always uses
>> promiscous mode and for unknown addresses needs to flood forward them.
>>
>> This could be changed in the bridging code of course for bridges
>> consisting purely of local devices. Most of the bridging stuff isn't
>> needed for macvlans though, so its probably easier to simply perform
>> a lookup for local devices in macvlan on transmit, similar to what
>> is done on reception.
> 
> What I haven't figured out is how you handle the transmit path for
> broadcast and multicast ethernet traffic.  How do you test to see if
> you have already preformed local transmission?

I'm not sure I understand the problem. Whats wrong with doing
the same as on transmit, i.e.:

- for multicast/broadcast, deliver everywhere (except self)

- for unicast, deliver to matching local macvlan device or
   underlying device

> +static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> +	const struct macvlan_dev *vlan = netdev_priv(dev);
> +	const struct macvlan_port *port = vlan->port;
> +	const struct macvlan_dev *dest;
> +	const struct ethhdr *eth;
>  
> -	skb->dev = dev;
> -	skb->pkt_type = PACKET_HOST;
> +	skb->protocol = eth_type_trans(skb, dev);
> +	eth = eth_hdr(skb);
>  
> -	netif_rx(skb);
> -	return NULL;
> +	dst_release(skb->dst);
> +	skb->dst = NULL;
> +	skb->mark = 0;
> +	secpath_reset(skb);
> +	nf_reset(skb);
> +
> +	if (is_multicast_ether_addr(eth->h_dest)) {
> +		macvlan_broadcast(skb, port, dev);
> +		return macvlan_xmit_world(skb, dev);
> +	}
> +
> +	dest = macvlan_hash_lookup(port, eth->h_dest);
> +	if (dest)
> +		return macvlan_unicast(skb, dest);
> +			
> +	return macvlan_xmit_world(skb, dev);
>  }

Pretty much like this :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html