Hi Tuna, Thanks for your reply. It's really helpful to me!
Active the STP function on ovs bridge will prevent the storm effectively but it will need large of CPU resource in a large amount of networks scenario. Maybe there are other solutions to solve it easily? (Might be adding more flow rules or else.) Chandler 2013/12/11 Nguyen Anh Tu <t...@apache.org> > Hi Chandler, > > This update will help you prevent the storm. > > > http://blog.scottlowe.org/2013/11/22/an-update-on-using-gre-tunnels-with-open-vswitch/ > > I'm taking care about GRE controller in CloudStack. Checking lastest master > branch now. > > Cheers, > > --Tuna > > > On Wed, Dec 11, 2013 at 3:16 PM, Chandler Li <lichandler...@gmail.com > >wrote: > > > Hi, > > > > I am trying to learn the procedure of multi-tenancy network created by > GRE > > tunnel in CloudStack and trying to establish one in Xenserver 6.2 > > environment step by step. > > > > According to the sourcecode in ovstunnel, CloudStack need to prevent > > broadcast storm by generating some flow rules on openvswitch. I create a > > full mash topology using GRE tunnel, create some VMs, and set broadcast > > storm prevent rules on each ovs. Unfortunately, amount of ARP reply > storm > > packet flow between all hosts after one VM pings the other VM in another > > Host. (https://www.dropbox.com/s/vy1opm7plho9dzs/arp%20reply%20storm.PNG > ) > > > > In this case, IP 10.0.0.1's VM is on IP 10.0.75.9's Host, IP 10.0.0.2's > VM > > is on IP 10.0.75.14's Host. The ARP request broadcast packets were > dropped > > successfully by the broadcast storm prevent rules excepted the real > target > > IP 10.0.75.14's Host, but ARP reply packets seems cannot be filtered by > the > > rules, so the ARP reply storm happened in this loop topology. > > > > Could anyone tell me how CloudStack ovs tunnel avoid ARP reply storm or > did > > I miss something important? Thanks! > > > > BRs, > > Chandler Li > > >
