> Hi all,
> 
> This issue has been resolved by re-installing quantum database.
> I think there was something wrong on quantum database.
> 
> There is another question,
> I found that the flow tables on compute node and network node disappear
> when ryu-manager restarts.
> It seems ryu-manager stores the flow tables on memory.
> How can store the flow tables permanently so that the flow tables can be
> recovered even if ryu-manager restarts?

afaik, there's currently no easy way to recover without
cleaning up manually and restarting neutron.

YAMAMOTO Takashi

> 
> Thanks in advance.
> 
> 
> 〓〓〓〓〓/Thanks
> Janghoon Sim/Paul
> M: 82-10-2887-2421
> 
> 
> On Fri, Nov 15, 2013 at 1:37 PM, [〓〓, Paul] <[email protected]> wrote:
> 
>> Hello,
>>
>> Can somebody help me?
>> I'm setting up openstack(Grizzily) + Ryu controller (gre tunneling)
>> But, VMs are unable to get IP address from DHCP server on network node
>> through GRE tunnel.
>>
>> my environment is the following
>> Three nodes installation.
>>
>> 1) controller node : Quantum-server
>> 2) network node : quantum-l3, dhcp,meta-agent, Ryu-controller,
>> quantum-plugin-ryu-agent
>> 3) compute node : nova-compute, quantum-plugin-ryu-agent
>>
>> VM/network/subnet/router creation work fine without any error.
>>
>> I started ryu-manager with the following configuration.
>>
>> - ryu.conf
>> [DEFAULT]
>>
>> app_lists =
>> ryu.app.quantum_adapter,ryu.app.rest,ryu.app.rest_conf_switch,ryu.app.rest_quantum,ryu.app.rest_tunnel,ryu.app.tunnel_port_updater,ryu.app.gre_tunnel
>>
>> wsapi_host = 0.0.0.0
>> wsapi_port = 8080
>> ofp_listen_host = 0.0.0.0
>> ofp_tcp_listen_port = 6633
>>
>> quantum_url=http://192.168.20.10:9696
>> quantum_admin_username=quantum
>> quantum_admin_password=service_pass
>> quantum_admin_tenant_name=service
>> quantum_admin_auth_url=http://192.168.20.10:35357/v2.0
>> quantum_auth_strategy=keystone
>> quantum_controller_addr = tcp:192.168.20.11:6633
>>
>> GRE tunnel port creation also works fine on network node and compute node.
>> - Network node
>>     Bridge br-int
>>         Controller "tcp:192.168.20.11:6633"
>>             is_connected: true
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>         Port "tap73d64500-87"
>>             Interface "tap73d64500-87"
>>                 type: internal
>>         Port "grec0a80a0c-c0"
>>             Interface "grec0a80a0c-c0"
>>                 type: gre
>>                 options: {key=flow, local_ip="192.168.10.11",
>> remote_ip="192.168.10.12"}
>>
>> - Compute node
>> 3172aa48-bfcc-466e-ab0e-bb6da2fac401
>>     Manager "ptcp:6634"
>>     Bridge br-int
>>         Controller "tcp:192.168.20.11:6633"
>>             is_connected: true
>>         Port "tap78a20670-5b"
>>             Interface "tap78a20670-5b"
>>         Port "grec0a80a0b-c0"
>>             Interface "grec0a80a0b-c0"
>>                 type: gre
>>                 options: {key=flow, local_ip="192.168.10.12",
>> remote_ip="192.168.10.11"}
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>
>>
>> the following is flow table
>> - network node
>> NXST_FLOW reply (xid=0x4):
>>  cookie=0x0, duration=176.893s, table=0, n_packets=0, n_bytes=0,
>> priority=16384,in_port=3 actions=drop
>>  cookie=0x0, duration=176.893s, table=0, n_packets=2, n_bytes=644,
>> tun_id=0xe,in_port=3 actions=resubmit(,2)
>>  cookie=0x0, duration=176.893s, table=1, n_packets=0, n_bytes=0,
>> tun_id=0xe,dl_dst=fa:16:3e:98:bf:53 actions=output:3,resubmit(,2)
>>  cookie=0x0, duration=176.893s, table=1, n_packets=0, n_bytes=0,
>> priority=16384,tun_id=0xe,dl_dst=ff:ff:ff:ff:ff:ff
>> actions=output:3,resubmit(,2)
>>
>> - compute node
>> NXST_FLOW reply (xid=0x4):
>>  cookie=0x0, duration=41.187s, table=0, n_packets=0, n_bytes=0,
>> priority=16384,in_port=1 actions=drop
>>  cookie=0x0, duration=40.988s, table=0, n_packets=0, n_bytes=0,
>> priority=16384,in_port=2 actions=drop
>>  cookie=0x0, duration=40.988s, table=0, n_packets=0, n_bytes=0,
>> tun_id=0xe,in_port=2 actions=resubmit(,2)
>>  cookie=0x0, duration=41.187s, table=0, n_packets=0, n_bytes=0,
>> in_port=1,dl_src=fa:16:3e:98:bf:53 actions=set_tunnel:0xe,resubmit(,1)
>>  cookie=0x0, duration=41.187s, table=1, n_packets=0, n_bytes=0,
>> priority=8192,tun_id=0xe actions=resubmit(,2)
>>  cookie=0x0, duration=40.988s, table=1, n_packets=0, n_bytes=0,
>> tun_id=0xe,dl_dst=fa:16:3e:a5:79:f4 actions=output:2,resubmit(,2)
>>  cookie=0x0, duration=40.988s, table=1, n_packets=0, n_bytes=0,
>> priority=16384,tun_id=0xe,dl_dst=ff:ff:ff:ff:ff:ff
>> actions=output:2,resubmit(,2)
>>  cookie=0x0, duration=40.988s, table=1, n_packets=0, n_bytes=0,
>> tun_id=0xe,dl_dst=fa:16:3e:ca:44:a1 actions=output:2,resubmit(,2)
>>  cookie=0x0, duration=41.187s, table=2, n_packets=0, n_bytes=0,
>> priority=8192,tun_id=0xe actions=drop
>>  cookie=0x0, duration=41.187s, table=2, n_packets=0, n_bytes=0,
>> tun_id=0xe,dl_dst=fa:16:3e:98:bf:53 actions=output:1
>>  cookie=0x0, duration=41.187s, table=2, n_packets=0, n_bytes=0,
>> priority=16384,tun_id=0xe,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1
>>
>> if you look at the second entry of flow table on network node, the actions
>> is resubmit(,2) but there is no table=2.
>> I guess this is the cause that my VM's DHCP request  is unable to reach to
>> DHCP server.
>>
>> is this normal?  or Am I missing anything?
>>
>> Thanks
>>
>>

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to