Hi.
Although I can't deny the possibility of bug, the work around is

- While keep VM running,
- restart the daemons in this order (this order is important)
  - ryu-manager
  - quantum-server
  - ryu_quantum_agent

If dnsmasq went wrong state, the way to recover is
to shutdown related VMs and to delete the network and re-create
it again.

Which repository are you using? master or ryu-gre-dev?

thanks,

On Tue, May 01, 2012 at 04:58:00PM -0500, Salman Malik wrote:
> 
> 
> Hi Yamahata,
> 
> I am having problem using Ryu quantum plugin. Instances are not getting IP
> addresses from the DHCP server. After some digging into the problem, it seems
> that the Ryu is dropping the DHCP requests. Here is the output that I got by
> ovs-ofctl snoop br-int:
> ================================================================
> OFPT_FLOW_MOD (xid=0x463fc2e): ADD in_port=1,dl_src=08:00:27:00:08:0e,dl_dst=
> 01:00:5e:7f:ff:fa flags:0x1 actions=drop
> OFPT_PACKET_OUT (xid=0x463fc2f): in_port=1 actions_len=0 actions=drop buffer=
> 0x00000b61
> OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload
> OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload
> OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 
> buffer=0x00000b62
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->33:33:00:00:00:16 type86dd
> proto58 tos0 ipv6::->ff02::16 port143->0
> fa:16:3e:6f:5f:c2 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: 
> >
> ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 
> 28
> OFPT_PACKET_OUT (xid=0x463fc30): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b62
> OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=
> 0x00000b63
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->ff:ff:ff:ff:ff:ff type0800
> proto17 tos0 ip0.0.0.0->255.255.255.255 port68->67
> fa:16:3e:6f:5f:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128:
> truncated-ip - 194 bytes missing! 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from fa:16:3e:6f:5f:c2, length 280
> OFPT_PACKET_OUT (xid=0x463fc31): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b63
> OFPT_PACKET_IN (xid=0x0): total_len=78 in_port=33 data_len=78 
> buffer=0x00000b64
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->33:33:ff:6f:5f:c2 type86dd
> proto58 tos0 ipv6::->ff02::1:ff6f:5fc2 port135->0
> fa:16:3e:6f:5f:c2 > 33:33:ff:6f:5f:c2, ethertype IPv6 (0x86dd), length 78: :: 
> >
> ff02::1:ff6f:5fc2: ICMP6, neighbor solicitation, who has
> fe80::f816:3eff:fe6f:5fc2, length 24
> OFPT_PACKET_OUT (xid=0x463fc32): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b64
> OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 
> buffer=0x00000b65
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->33:33:00:00:00:02 type86dd
> proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2->ff02::2 port133->0
> fa:16:3e:6f:5f:c2 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70:
> fe80::f816:3eff:fe6f:5fc2 > ff02::2: ICMP6, router solicitation, length 16
> OFPT_PACKET_OUT (xid=0x463fc33): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b65
> OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=
> 0x00000b66
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->ff:ff:ff:ff:ff:ff type0800
> proto17 tos0 ip0.0.0.0->255.255.255.255 port68->67
> fa:16:3e:6f:5f:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128:
> truncated-ip - 194 bytes missing! 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from fa:16:3e:6f:5f:c2, length 280
> OFPT_PACKET_OUT (xid=0x463fc34): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b66
> OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 
> buffer=0x00000b67
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->33:33:00:00:00:16 type86dd
> proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2->ff02::16 port143->0
> fa:16:3e:6f:5f:c2 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90:
> fe80::f816:3eff:fe6f:5fc2 > ff02::16: HBH ICMP6, multicast listener report v2,
> 1 group record(s), length 28
> OFPT_PACKET_OUT (xid=0x463fc35): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b67
> OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 
> buffer=0x00000b68
> tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2->33:33:00:00:00:02 type86dd
> proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2->ff02::2 port133->0
> fa:16:3e:6f:5f:c2 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70:
> fe80::f816:3eff:fe6f:5fc2 > ff02::2: ICMP6, router solicitation, length 16
> OFPT_PACKET_OUT (xid=0x463fc36): in_port=33 actions_len=0 actions=drop buffer=
> 0x00000b68
> 
> Here is the output of brctl show br-int:
> ===================================================================
> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:000008002716d509
> n_tables:1, n_buffers:256
> features: capabilities:0x87, actions:0xfff
>  1(eth1): addr:08:00:27:16:d5:09
>      config:     0
>      state:      0
>      current:    1GB-FD COPPER AUTO_NEG
>      advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>      supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>  2(gw-f3eda887-fd): addr:fa:16:3e:28:e2:1b
>      config:     0
>      state:      0
>  33(tap66377ec5-bb): addr:96:3e:0d:2d:68:23
>      config:     0
>      state:      0
>      current:    10MB-FD COPPER
>  LOCAL(br-int): addr:08:00:27:16:d5:09
>      config:     PORT_DOWN
>      state:      LINK_DOWN
> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
> =======================================================================
> Also, not that I am not seeing any messages on gw-* interface. (as they are
> dropped by OVS?)
> 
> How can I resolve this problem ?
> 
> Thanks,
> Salman
> 
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: [email protected]
> Date: Tue, 1 May 2012 14:40:58 -0700
> Subject: Re: [Openstack] Instance IP assignment problem
> To: [email protected]
> CC: [email protected]; [email protected];
> [email protected]
> 
> 
> 
> On Tue, May 1, 2012 at 12:00 PM, Salman Malik <[email protected]> wrote:
> 
>     Hi,
> 
>     Here is the error log: http://pastebin.com/KrNZDrvD
>     and nova.conf: http://pastebin.com/Fvd6dSZs
> 
>     Emilien, I am trying to get an understanding of how different Quantum
>     plugins work with OpenStack. Ryu plugin is particularly interesting as it
>     uses an OpenFlow controller to configure Vswitches.
> 
>     The problem I am faced with is  (I think ) that I already have a private
>     network and Quantum should assign IP addresses to instances using DHCP. 
> But
>     instances send out discover message on laucnh but never find a DHCP server
>     (although there are 2 dnsmasqs running).
> 
> 
> I would first try this out with something like the OVS plugin
> (which incidentally uses OpenFlow as wel).  This is a pretty commonly used
> configuration, and will help determine if the problem is in your 
> configuration,
> or the Ryu plugin in particular. 
> 
> I would also try and see if dnsmasq is actually getting the request and 
> sending
> a reply.  You should be able to tcpdump on the linux device that dnsmasq is
> bound to (should start with gw-*).  Alternately, you could look in /var/log/
> syslog (i think?) to see if dnsmasq if logging that is correctly receiving the
> DHCP requests. 
> 
> Dan
> 
>  
> 
> 
>     Any ideas?
> 
>     Thanks,
>     Salman
> 
> 
>     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>     Date: Tue, 1 May 2012 20:43:44 +0200
> 
>     Subject: Re: [Openstack] Instance IP assignment problem
>     From: [email protected]
>     To: [email protected]
>     CC: [email protected]; [email protected]
> 
> 
>     Hi Emilien and Salman,
>     Please, could you upload all the files, errors and conf in pastebin or
>     something like that?
>     I have troubles to open in phone :)
>     Thank you
>     El 01/05/2012 20:39, "Emilien Macchi" <[email protected]> 
> escribi
>      :
> 
>         Hi,
> 
> 
>         I have a similar problem when I create a network per project_id with
>         Quantum.
> 
> 
>         My VMs don't get IP and I can't understand why today.
> 
>         But when I create a private network for all projects, VMs get an IP 
> and
>         all is working well.
>         Do you have the same problem ?
> 
> 
>         Salman, I'm interesting about your nova.conf. I can see you are using
>         Ryu ?
>         Can you tell me more about your "use case" or architecture ?
> 
> 
>         Thanks
> 
> 
>         Le mardi 01 mai 2012   12:28 -0500, Salman Malik a 馗rit :
> 
>             Hi Jorge,
> 
>             Thanks for looking into the post.
>             I have made changes to the nova.conf file so that I only use
>             10.0.0.x network (but the problem is still the same). For this
>             configuration, I assume that it will give out IPs to instances
>             starting from 10.0.0.11. And just to inform you, my eth1 is
>             configured to be 10.0.0.10 (which is a VM itself, and eth1 is
>             configured as a host-only network with no DHCP) and this interface
>             is plugged in the integration bridge used by quantum plugins.
> 
>             Thanks,
>             Salman
> 
>             PS: Error log of a launched instance is also attached.
> 
> 
> 
> 
> 
>             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>            
>             Date: Tue, 1 May 2012 19:03:49 +0200
>             Subject: Re: [Openstack] Instance IP assignment problem
>             From: [email protected]
>             To: [email protected]
>             CC: [email protected]
> 
>             Im not really sure but you are using range for your environment
>             10.0.3.x and 10.0.0.x for fixed.
>             Can you attach a nova network conf?
>             Regards
> 
>             El 01/05/2012 18:56, "Salman Malik" <[email protected]> escribi :
> 
>                 Hi Guys,
> 
>                 Can anyone provide any insight to the following question:
>                 https://answers.launchpad.net/nova/+question/195439
> 
>                 Thanks,
>                 Salman
> 
> 
> 
>                 _______________________________________________
>                 Mailing list: https://launchpad.net/~openstack
>                 Post to     : [email protected]
>                 Unsubscribe : https://launchpad.net/~openstack
>                 More help   : https://help.launchpad.net/ListHelp
> 
> 
>             _______________________________________________
>             Mailing list: https://launchpad.net/~openstack
>             Post to     : [email protected]
>             Unsubscribe : https://launchpad.net/~openstack
>             More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     Post to     : [email protected]
>     Unsubscribe : https://launchpad.net/~openstack
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt 
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 

> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ryu-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ryu-devel


-- 
yamahata

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to