On 2013/12/4 13:24, Ben Pfaff wrote: > On Wed, Dec 04, 2013 at 10:24:28AM +0800, jerry wrote: >> On 2013/12/3 13:08, Ben Pfaff wrote: >>> On Tue, Dec 03, 2013 at 10:18:43AM +0800, jerry wrote: >>>> It may be easily supported to forward unicast packets. But I'm not sure >>>> how to set OpenFlow rules when transferring multicast packets. >>>> It's described as follows: >>>> Firstly, multicast packets from VM1 will be sent out by up-link netdevice >>>> and >>>> be loop backed to up-link netdevice by physical switch. >>>> Secondly, we should avoid multicast packets being sent to VM1. Here we need >>>> to gather every VM MAC addresses and add rules for each VM. >>>> >>>> Could you share with me some opinions on such problems? >>> >>> Can you point me to a description of how this is done in a conventional >>> VEPA bridge implementation? >>> >> Hi Ben >> >> Now MACVLan in Linux kernel has implemented VEPA. You can read related codes >> or >> the patch as follows: >> https://lists.linux-foundation.org/pipermail/virtualization/2009-November/014409.html > > It's rather hard to follow in detail without existing knowledge of the > macvlan code, which I don't have. > > I'm still willing to help. Your statement was: "Secondly, we should > avoid multicast packets being sent to VM1. Here we need to gather every > VM MAC addresses and add rules for each VM." Can you describe that in > more detail? Perhaps with examples? > OK, VEPA is defined in IEEE 802.1Qbg specifications. One example of transferring ARP packets can be described in detail by following four points: 1) We have three VMs and a physical NIC eth0 in host OS. These backend or physical net device have been connected to br-0(OVS). 2) Let's supposed that VM1 sent out an ARP broadcast packet by its backend net device and give handle to br-0. 3) With VEPA enabled, br-0 can only just forward this packet to physical net device(eth0). 4) Then the outer physical switch will sent that ARP packet back to other VMs on this host. 5) When the packet comes, br-0 will try to flood this packet to all it's connected net devices. 6) But VM1 shouldn't receive this ARP packet because that's from itself! So only VM2 and VM3 can be flooded to handle this ARP packets. 7) So br-0 should make sure whether the packet is from other port by looking at this packet's source MAC address and MAC learning tables. If that's true, br-0 doesn't need to flood the packet to that original port.
In addition, we also need implement VDP protocols used to discovery VM ports dynamically on outer physical switch for VEPA. This may need lots of works to do. So maybe reusing lldpad in OVS is a proper solution. But I'm not sure how to hook them without writing any codes. I'm interesting to the hook method if Kyle'd like to share this. Thanks Jerry > Thanks, > > Ben. > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
