Re: [Openstack] Quantum DHCP support.
I think we've isolated the problem. Until we can get the patch posted, try this workaround: 1) create the subnets 2) kill dnsmasq instance for the network 3) restart dhcp_agent If this does not work, let me know, mark On Sep 4, 2012, at 6:47 PM, Takaaki Suzuki wrote: > Thank you for investigate this problem. > >> 1. Can you send me the results of ps aux |grep dnsmasq > nobody 12592 0.0 0.0 28812 1084 ?SSep03 0:00 > dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces > --interface=tapbd10a19b-a6 --except-interface=lo > --domain=openstacklocal > --pid-file=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/pid > --dhcp-hostsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/host > --dhcp-optsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/opts > --leasefile-ro --dhcp-range=set:tag0,192.168.10.0,static,120s > >> 2. Can you also please send the ifconfig. The tap devices for also ip >> address. Can you please send me ip addr. (my gut feeling is that we do not >> configure 192.168.30.2 but rather 192.168.10.2. > > - ifconfig > tap0118eb34-42 Link encap:Ethernet HWaddr de:fe:b2:24:cc:0f > inet6 addr: fe80::dcfe:b2ff:fe24:cc0f/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:33 errors:0 dropped:0 overruns:0 frame:0 > TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:4770 (4.7 KB) TX bytes:4770 (4.7 KB) > > tap0e74b599-a1 Link encap:Ethernet HWaddr 36:42:91:96:44:14 > inet6 addr: fe80::3442:91ff:fe96:4414/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:7129 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7140 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:1763458 (1.7 MB) TX bytes:1699484 (1.6 MB) > > tap0fb10fc2-62 Link encap:Ethernet HWaddr 92:bf:8b:95:b2:7b > inet6 addr: fe80::90bf:8bff:fe95:b27b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:27 errors:0 dropped:0 overruns:0 frame:0 > TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:4302 (4.3 KB) TX bytes:3804 (3.8 KB) > > tap38bea316-b0 Link encap:Ethernet HWaddr fa:68:38:20:63:60 > inet6 addr: fe80::f868:38ff:fe20:6360/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:7091 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7009 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:1761232 (1.7 MB) TX bytes:1692872 (1.6 MB) > > - ipaddr > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >inet 127.0.0.1/8 scope host lo >inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc mq state UP qlen > 1000 >link/ether d4:ae:52:67:54:a0 brd ff:ff:ff:ff:ff:ff >inet *.*.*.*/* brd 192.168.100.255 scope global eth0 >inet6 fe80::d6ae:52ff:fe67:54a0/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc noop state DOWN qlen 1000 >link/ether d4:ae:52:67:54:a1 brd ff:ff:ff:ff:ff:ff > 4: eth2: mtu 1500 qdisc noop state DOWN qlen 1000 >link/ether 00:1b:21:d8:ef:38 brd ff:ff:ff:ff:ff:ff > 5: eth3: mtu 1500 qdisc noop state DOWN qlen 1000 >link/ether 00:1b:21:d8:ef:39 brd ff:ff:ff:ff:ff:ff > 6: virbr0: mtu 1500 qdisc noqueue > state DOWN >link/ether 9e:9f:7d:e9:66:f9 brd ff:ff:ff:ff:ff:ff >inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 > 18: tap8f8a93a5-68: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 3a:2c:83:b2:a6:1f brd ff:ff:ff:ff:ff:ff > 19: tap4002a239-42: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 16:f5:da:f9:ad:a7 brd ff:ff:ff:ff:ff:ff > 21: tap1be70123-2e: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 52:4d:f8:0c:5e:8c brd ff:ff:ff:ff:ff:ff > 22: tapbc94fdb2-97: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 62:9a:d5:74:32:53 brd ff:ff:ff:ff:ff:ff > 25: tap2142521d-5f: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether c2:5e:48:0a:7b:20 brd ff:ff:ff:ff:ff:ff > 27: tap0c3e2dff-86: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 76:8c:30:bc:f8:e4 brd ff:ff:ff:ff:ff:ff > 28: tapcffed6f3-c7: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 42:b4:fb:5e:48:05 brd ff:ff:ff:ff:ff:ff > 31: tapb4d4ef2a-ae: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether 9a:03:a6:fc:b2:30 brd ff:ff:ff:ff:ff:ff > 32: tap78dbef47-a5: mtu 1500 qdisc pfifo_fast > state DOWN qlen 500 >link/ether c6:29:cc:f1:bb:53 brd ff:ff:ff:ff:ff:ff > 33: tap1abc032d-e3: mtu 1500 qdisc pfifo_fast > state DOWN q
Re: [Openstack] Quantum DHCP support.
Forgot to reply to all for others following this thread. Suzuki- This patch should fix your issue when using multiple subnets: https://review.openstack.org/#/c/12397/ If it does not, let me know. mark On Sep 5, 2012, at 1:58 AM, Dan Wendlandt wrote: > yes > > On Tue, Sep 4, 2012 at 10:40 PM, Takaaki Suzuki wrote: >> Hi Mark. >> >> Thank you for your comment. >> I'll try again. >> >> So, I just want to make sure. >> Is this function support in Quantum folsom release? >> >> Thanks! >> Suzuki >> >> On Wed, Sep 5, 2012 at 8:12 AM, Mark McClain >> wrote: >>> I think we've isolated the problem. Until we can get the patch posted, try >>> this workaround: >>> >>> 1) create the subnets >>> 2) kill dnsmasq instance for the network >>> 3) restart dhcp_agent >>> >>> If this does not work, let me know, >>> >>> mark >>> >>> On Sep 4, 2012, at 6:47 PM, Takaaki Suzuki wrote: >>> >>>> Thank you for investigate this problem. >>>> >>>>> 1. Can you send me the results of ps aux |grep dnsmasq >>>> nobody 12592 0.0 0.0 28812 1084 ?SSep03 0:00 >>>> dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces >>>> --interface=tapbd10a19b-a6 --except-interface=lo >>>> --domain=openstacklocal >>>> --pid-file=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/pid >>>> --dhcp-hostsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/host >>>> --dhcp-optsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/opts >>>> --leasefile-ro --dhcp-range=set:tag0,192.168.10.0,static,120s >>>> >>>>> 2. Can you also please send the ifconfig. The tap devices for also ip >>>>> address. Can you please send me ip addr. (my gut feeling is that we do not >>>>> configure 192.168.30.2 but rather 192.168.10.2. >>>> >>>> - ifconfig >>>> tap0118eb34-42 Link encap:Ethernet HWaddr de:fe:b2:24:cc:0f >>>> inet6 addr: fe80::dcfe:b2ff:fe24:cc0f/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:33 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:500 >>>> RX bytes:4770 (4.7 KB) TX bytes:4770 (4.7 KB) >>>> >>>> tap0e74b599-a1 Link encap:Ethernet HWaddr 36:42:91:96:44:14 >>>> inet6 addr: fe80::3442:91ff:fe96:4414/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:7129 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:7140 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:500 >>>> RX bytes:1763458 (1.7 MB) TX bytes:1699484 (1.6 MB) >>>> >>>> tap0fb10fc2-62 Link encap:Ethernet HWaddr 92:bf:8b:95:b2:7b >>>> inet6 addr: fe80::90bf:8bff:fe95:b27b/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:27 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:500 >>>> RX bytes:4302 (4.3 KB) TX bytes:3804 (3.8 KB) >>>> >>>> tap38bea316-b0 Link encap:Ethernet HWaddr fa:68:38:20:63:60 >>>> inet6 addr: fe80::f868:38ff:fe20:6360/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:7091 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:7009 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:500 >>>> RX bytes:1761232 (1.7 MB) TX bytes:1692872 (1.6 MB) >>>> >>>> - ipaddr >>>> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN >>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>>> inet 127.0.0.1/8 scope host lo >>>> inet6 ::1/128 scope host >>>> valid_lft forever preferred_lft forever >>>> 2: eth0: mtu 1500 qdisc mq state UP qlen >>>> 1000 >>>> link/ether d4:ae:52:67:54:a0 brd ff:ff:ff:ff:ff:ff >>>> inet *.*.*.*/* brd 192.168.100.255 scope global eth0 >>>> inet6 fe80::d6ae:52ff:fe67:54a0/64 scope link >>>> valid_lft f
Re: [Openstack] Quantum bridge mapping dhcp default route (optsfile tag:tag0 setting?)
Robert-
Yes the tag setting should be in the opts file. What version of dnsmasq are
you running? Also can you get a tcpdump of the DHCP traffic?
(tcpdump -vvv -n -i port 67 or port 68)
Thanks,
mark
On Nov 30, 2012, at 4:31 AM, Robert van Leeuwen
wrote:
> Hi,
>
> I'm having some trouble with getting a specified default route to the clients
> with Quantum, DHCP, dnsmasq and bridge mappings.
> The DHCP config is created, the opts file has the following content:
> tag:tag0,option:router,10.0.0.1
>
> However, the tag option seems to prevent this from working.
> The client get the IP of the dhcp server as the default route in stead of the
> config from the opts file.
> (the quantum bridge mapping and dhcp itself work fine)
> When I manually remove the "tag:tag0" from the opts file it starts working
> correctly.
>
> Any clue what could be going on?
> Does the tag setting belong in the opt file and if so, what could be
> preventing the gateway address from propagating to the client?
>
> The setup is as follows:
> * Quantum, bridge_mapping, Namespaces disabled
> * Runs on Folsom, Scientific Linux 6.3 with openvswitch 1.7.1 kernel module
>
> * quantum net-show
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | id| 3921b212-4c67-4dd7-ae5f-dd2709e183ab |
> | name | Physical_Nova_Segment|
> | provider:network_type | vlan |
> | provider:physical_network | default |
> | provider:segmentation_id | 20 |
> | router:external | False|
> | shared| True |
> | status| ACTIVE |
> | subnets | eb98af42-27d4-4709-b0fd-1695d65e4a26 |
> | tenant_id | d4b773abd5204531819a29f909f5c653 |
> +---+--+
>
> * quantum subnet-show
> +--++
> | Field| Value |
> +--++
> | allocation_pools | {"start": "10.0.1.100", "end": "10.0.1.200"} |
> | cidr | 10.0.1.0/24 |
> | dns_nameservers ||
> | enable_dhcp | True |
> | gateway_ip | 10.0.1.1 |
> | host_routes ||
> | id | eb98af42-27d4-4709-b0fd-1695d65e4a26 |
> | ip_version | 4 |
> | name | Nova network |
> | network_id | 3921b212-4c67-4dd7-ae5f-dd2709e183ab |
> | tenant_id| d4b773abd5204531819a29f909f5c653 |
> +--++
>
> * quantum.conf:
> [DEFAULT]
> verbose = True
> debug = False
> use_syslog= True
> syslog_log_facility= LOG_LOCAL1
>
> bind_host = 0.0.0.0
> bind_port = 9696
> core_plugin =
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> api_paste_config = api-paste.ini
> auth_strategy = keystone
> allow_overlapping_ips = False
> rpc_backend = quantum.openstack.common.rpc.impl_kombu
> control_exchange = quantum
> rabbit_host = rabbit.local
> notification_driver = quantum.openstack.common.notifier.list_notifier
> list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier
> [QUOTAS]
>
> * dhcp_agent.ini:
> [DEFAULT]
> debug = False
> state_path = /var/lib/quantum
> interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
> dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq
> use_namespaces = False
> root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf
>
>
> Thanks,
> Robert van Leeuwen
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum bridge mapping dhcp default route (optsfile tag:tag0 setting?)
I'm glad it works with the newer version. I was thinking that might be case. I've filed a bug, so that we can document the minimum dnsmasq version. mark On Nov 30, 2012, at 6:14 PM, Robert van Leeuwen wrote: >>> What version of dnsmasq are you running? >> dnsmasq-2.48-6.el6.x86_64 > > Mark, > > Thanks for pointing me in the right direction. > It had to do with the older dnsmasq version. > Just installed the dnsmasq 2.63 and it works like a charm :) > > Cheers, > Robert van Leeuwen > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum DHCP Agent does not put hostnames in dnsmasq config file
Thomas- You are not missing anything. The DHCP hostname is auto generated because Nova does not currently provide this information to Quantum when creating the port and Quantum does not have the ability to query the Nova API. Quantum and Nova should not directly access the other component's database, so changes would be needed in API interaction between Nova and Quantum to make this work. mark On Jan 3, 2013, at 4:52 AM, Thomas Kärgel wrote: > Hello, > > i noticed that Quantum DHCP agent does not put the instance-name in > dnsmasq configuration files. > This was working fine under Essex using Quantum/Nova-network. > > I found the lines of source which generate the "-"-separated hostname in > quantum/agent/linux/dhcp.py, but i'm not sure why it is generated this way. > Is there any concern about accessing the database from > quantum/agent/linux/dhcp.py to retrieve the correct instance-name? > > Or am I missing some configuration details? > > Kind regards > thomas > > > -- > Thomas Kärgel > Linux Consultant > Mail: kaer...@b1-systems.de > B1 Systems GmbH > Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] VMs not able to contact metadata service
Will- The metadata service in Folsom will only work when overlapping IP ranges are disabled (see: http://docs.openstack.org/trunk/openstack-network/admin/content/ch_limitations.html). For Grizzly, we have added metadata service for overlapping networks. This feature is currently available in devstack when you enable the q-meta service. mark On Jan 2, 2013, at 11:10 PM, Willard Dennis wrote: > Hello all, > > I am running Folsom with Quantum v2, via Devstack. Am trying to use Ubuntu > UEC image to spawn VMs, but when the VM instance boots, it is not able to > contact the metadata server in order to (among other things) inject the > public key needed in order for me to be able to SSH into the instance. See > http://paste.openstack.org/show/28764/ for a log snippet if needed. > > Following the (incorrect, bug reported) instructions found at > http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-openstack-compute-basics.html#enabling-access-to-vms-on-the-compute-node > (search for "If you want to use the 10.04 Ubuntu Enterprise Cloud images" to > get to the instructions, and change the metadata port from the incorrect > '8773' to the correct '8775') I added the rule into iptables, with no luck… I > still cannot reach the metadata server at 169.254.169.254:80. When I dump the > iptables rules for the 'nat' table, I see that my added rule is being hit, > but it's still not working: > > $ sudo iptables -t nat -L -v -n > Chain PREROUTING (policy ACCEPT 982 packets, 159K bytes) > pkts bytes target prot opt in out source > destination > 210 27054 nova-compute-PREROUTING all -- * * 0.0.0.0/0 >0.0.0.0/0 > 17 1020 DNAT tcp -- * * 0.0.0.0/0 > 169.254.169.254 tcp dpt:80 to:xxx.xx.xx.xx:8775 < (target IP addr > redacted) > 3078 520K nova-api-PREROUTING all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > I searched and found this thread from this list: > http://www.mail-archive.com/openstack@lists.launchpad.net/msg16569.html > Does this mean that the Nova metadata service cannot be used with Quantum > when using multiple tenant networks (L3 arch)? (this is the model that > Devstack implements in my setup) > If the above is true, can I revert to another supported configuration (and > kindly give me a pointer as to how?) > Finally, any plans to fix the metadata service so that it will work with > Quantum's L3 service, and enable this out of the box with Devstack? (dare to > dream :) > > Thanks and regards, > Will > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Quantum is changing its name to...
All- The OpenStack Networking team is happy to announce that the Quantum project will be changing its name to Neutron. You'll soon see Neutron in lots of places as we work to implement the name change within OpenStack. mark ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
