Hi. Alex Wang First, thankyou very much for your reply.
As your reply, I think that stp_enable is currently the solution for my issue. But, I have a question, the openstack's quantum supports multi-computing nodes and network node full-mesh connectivity for the tenant using gre feature. How does the quantum support gre full-mesh connectivity between multi-computing nodes and network node for a tenant, Do you know that? Thankyou very much Best Regards, Soomyung Park 2013. 9. 4., 오전 8:56, Alex Wang <[email protected]> 작성: > Hi Park, > > Sorry for this very delayed reply, > > After experimenting myself and asking around, enable stp is the correct > solution. > > To my knowledge, ovs does not support full-mesh topology as you described. > The controller need to make sure that there is no loop in the logical network. > > Kind Regards, > Alex Wang, > > > On Thu, Aug 29, 2013 at 4:43 PM, Soomyung Park <[email protected]> wrote: > > 2013. 8. 30., 오전 6:57, Alex Wang <[email protected]> 작성: > >> Hi Park, >> >> >> My answer is your question as below;. >> My assumption is that 3 nodes are in a same tenant network, so are >> connected with the full-meshed tunnels with the same key. >> >> Yes, this makes sense. >> >> >> I have other question in openstack's quantum network with GRE based >> multi-tenant. >> I know that openstack has the full-meshed tunnels(same key) for multi >> virtual machines connectivity with same tenant network(means same key) on >> multi computing nodes. May I misunderstand? >> >> >> Could you describe more about the 'loop error'? Is that all links are >> congested? >> >> When you setup multiple tunnels between same pair of nodes at the same time. >> There may be broadcast packets (e.g. IPv6 broadcast) sent through each >> tunnel. And such broadcast packet will loop among the multiple tunnels. > > ==> Your word is alright. All links are congested... > >> >> Could you provide the "ovs-dpctl dump-flows" output at any pair of nodes? > > ==> Yes. > > [Node A] > [root@idc173-172 ~]# ovs-dpctl dump-flows > tunnel(tun_id=0x5,src=192.168.1.174,dst=192.168.1.172,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:16442, bytes:690564, used:0.329s, > actions:3,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.173,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.174,dst=192.168.1.172,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:43:99:d9,dst=52:54:00:de:4e:7c),eth_type(0x0806),arp(sip=20.20.20.174,tip=20.20.20.172,op=2,sha=52:54:00:43:99:d9,tha=52:54:00:de:4e:7c), > packets:9783574, bytes:410910108, used:0.001s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.173,tos=0x0,ttl=64,flags(df,key))),2 > in_port(3),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:46, bytes:1932, used:0.418s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.174,tos=0x0,ttl=64,flags(df,key))),2,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.173,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.173,dst=192.168.1.172,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:59218, bytes:2487156, used:0.375s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.174,tos=0x0,ttl=64,flags(df,key))),2,3 > > [Node B] > [root@idc173-173 ~]# ovs-dpctl dump-flows > tunnel(tun_id=0x5,src=192.168.1.172,dst=192.168.1.173,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:14762, bytes:620004, used:1.859s, > actions:3,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.174,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.172,dst=192.168.1.173,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:43:99:d9,dst=52:54:00:de:4e:7c),eth_type(0x0806),arp(sip=20.20.20.174,tip=20.20.20.172,op=2,sha=52:54:00:43:99:d9,tha=52:54:00:de:4e:7c), > packets:7386269, bytes:310223298, used:0.000s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.174,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.174,dst=192.168.1.173,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:40161, bytes:1686762, used:1.369s, > actions:3,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.172,tos=0x0,ttl=64,flags(df,key))),2 > > [Node C] > [root@idc173-174 ~]# ovs-dpctl dump-flows > tunnel(tun_id=0x5,src=192.168.1.173,dst=192.168.1.174,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:14506, bytes:609252, used:1.153s, > actions:1,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.172,tos=0x0,ttl=64,flags(df,key))),2 > in_port(1),eth(src=52:54:00:43:99:d9,dst=52:54:00:de:4e:7c),eth_type(0x0806),arp(sip=20.20.20.174,tip=20.20.20.172,op=2,sha=52:54:00:43:99:d9,tha=52:54:00:de:4e:7c), > packets:7666, bytes:321972, used:1.031s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.172,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.173,dst=192.168.1.174,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:43:99:d9,dst=52:54:00:de:4e:7c),eth_type(0x0806),arp(sip=20.20.20.174,tip=20.20.20.172,op=2,sha=52:54:00:43:99:d9,tha=52:54:00:de:4e:7c), > packets:5148414, bytes:216233388, used:0.000s, > actions:set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.172,tos=0x0,ttl=64,flags(df,key))),2 > tunnel(tun_id=0x5,src=192.168.1.172,dst=192.168.1.174,tos=0x0,ttl=64,flags(key)),in_port(2),eth(src=52:54:00:de:4e:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=20.20.20.172,tip=20.20.20.174,op=1,sha=52:54:00:de:4e:7c,tha=00:00:00:00:00:00), > packets:27008, bytes:1134336, used:1.031s, > actions:1,set(tunnel(tun_id=0x5,src=0.0.0.0,dst=192.168.1.173,tos=0x0,ttl=64,flags(df,key))),2 > > > >> >> Also, could you try setting the 'fail-mode' of bridges to 'secure'? using >> "ovs-vsctl set bridge [bridge_name] fail-mode=secure" and see if there is >> still loop? > > ==> Yes. on going still loop.... > > But, there is a solution for protecting the loop. That is stp > enable(#ovs-vsctl set Bridge $bridge stp_enable=true) on a bridges. The > solution is not proper for the full-meshed configured network topology. > >> >> Thanks, >> Alex Wang, > > > Anyway, I am looking for the solution for it. > > Thankyou very much. > > Best Regards, > > Soomyung Park >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
