On Sat, Jan 4, 2014 at 7:43 PM, Faisal Ali <justhu...@gmail.com> wrote:
> Hi Justin, > > I am starting out with a simple flow at this point. Here are what the > flows look like. > > 1(gre11): addr:2e:dd:e9:28:64:8e > 2(gre7): addr:26:85:c8:b6:c8:55 > 6(vif4.1): addr:fe:ff:ff:ff:ff:ff > > ovs-ofctl add-flow sdc1-br 'priority=65000 in_port=6 > dl_dst='01:00:00:00:00:00/01:00:00:00:00:00' actions='normal'' > ovs-ofctl add-flow sdc1-br 'priority=50000 > dl_dst='01:00:00:00:00:00/01:00:00:00:00:00' actions=output:6' > ovs-ofctl add-flow sdc1-br 'priority=49999 in_port=1 > dl_dst='01:00:00:00:00:00/01:00:00:00:00:00' actions='drop'' > ovs-ofctl add-flow sdc1-br 'priority=49998 in_port=2 > dl_dst='01:00:00:00:00:00/01:00:00:00:00:00' actions='drop'' > These last two flows flows won't ever match, since they'll always be consumed by the rule with priority 50000. > Using the above flow I am to forward broadcasts just to the VMs(vif4.1). > It works but I think its not ideal solution as ARP reply in this case is > going to out both gre tunnels. > Based on the commands above, I imagine you still have a lower priority, default rule that process all packets with "normal". That should be handling all your unicast packets, which would include the ARP replies. Learning only happens with the "normal" action, so I'd expect your replies to traffic that matched the priority 50000 flow to be initially flooded. --Justin
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
