Thanks for quick reply Dan.
Here is another problem: there are some networks that show up in nova-manage 
network list command but when I delete them using nova-manage network delete 
--uuid <uuid>, I get get this error:

2012-05-02 02:43:57 TRACE nova   File 
"/opt/stack/nova/nova/network/quantum/client.py", line 196, in do_request
2012-05-02 02:43:57 TRACE nova     _("Quantum entity not found: %s"), data)
2012-05-02 02:43:57 TRACE nova QuantumNotFoundException: (u'Quantum entity not 
found: %s', '{"QuantumError": {"message": "Unable to find a network with the 
specified identifier.", "type": "NetworkNotFound", "detail": "Network 
8fdced2b-8235-4db8-b063-08e7cc9b78d8 could not be found"}}')

Whereas other networks get deleted with great ease.
Seems to be a problem with database consistency? I have tried to restart the 
stack as a whole, but get the same error...

From: [email protected]
Date: Tue, 15 May 2012 09:29:02 -0700
Subject: Re: [Openstack] Understanding Integration Bridge and MACs
To: [email protected]
CC: [email protected]

Hi Salman,
You need to delete by UUID (since if quantum is used with melange, fixed_range 
is not guaranteed to be unique).  
just use:
nova network delete --uuid <uuid>


I just yesterday noticed that this was missing from the Quantum Admin Guide and 
added it: 
http://docs.openstack.org/trunk/openstack-network/admin/content/Net-Create-dle455.html
  


Dan

On Tue, May 15, 2012 at 9:22 AM, Salman Malik <[email protected]> wrote:









Thank you both but when I try to delete any such network using nova-manage 
network delete tenant net_ID, I get the following error:



2012-05-02 01:47:59 TRACE nova   File "/opt/stack/nova/bin/nova-manage", line 
867, in delete
2012-05-02 01:47:59 TRACE nova     raise Exception("Deleting by fixed_range is 
not supported " \
2012-05-02 01:47:59 TRACE nova Exception: Deleting by fixed_range is not 
supported with the QuantumManager



How can I delete nets defined using fixed_range parameter?

Thanks,
Salman


From: [email protected]
Date: Mon, 14 May 2012 19:23:34 -0700


Subject: Re: [Openstack] Understanding Integration Bridge and MACs
To: [email protected]
CC: [email protected]





On Mon, May 14, 2012 at 3:19 PM, Salman Malik <[email protected]> wrote:











In addition to the mail that follows, I am having some problem with quantum 
networks as well. When I create a network using :

sudo nova-manage network create --label=$tenant0 --fixed_range_v4=$iprange0 
--project_id=$tenant0





I can see the network using both "quantum list_nets $tenant0" and "nova-manage 
network list", but when I delete the network using "quantum delete_net $tenant0 
$netID", the nova-manage network list still shows the network and when I try to 
use the same CIDR for another network,I get an error saying CIDR already in 
use. Shouldn't deleting "quantum list_nets" and "nova-manage network list" be 
consistent with each other ?





In Essex, when using Nova all Quantum network creation and deletion must occur 
using nova-manage.  This is because we store the IP address management data 
associated with a network is stored in the Nova database.  As Yong mentioned, 
in Folsom we are storing IP address management data in Quantum itself, in which 
case network creation can happen directly via the Quantum API and Nova VMs will 
still be able to get IPs.  




Dan
 







From: [email protected]
To: [email protected]




Subject: Understanding Integration Bridge and MACs
Date: Sun, 13 May 2012 19:42:14 -0500





Hi Dan and Others,

I am trying to understand the actions taken by Ryu when the new instance sends 
DHCP discover message to dnsmasq. When I launch new instannce it keeps on 
sending discover messages and controller keeps on dropping these messages. But 
looking at the traffic I couldn't exactly map which MAC address belonged to 
which entity. Can someone help me with my understanding of the MAC addresses. 
Using ifconfig , "ovs-ofctl show br-int" and "ovs-ofctl snoop br-int" (output 
shown after MAC addresses), I know exactly about some MAC addresses and can't 
figure out some of them:





Interfaces              |        HWAddress          |        IP-addr
---------------------------------------------------------------------------------------------
eth0                        |        08:00:27:7a:ff:65    |    10.0.3.15




eth1                        |        08:00:27:16:d5:09  |    10.0.0.10          
   <========plugged into br-int
gw-82bd3a73-dc    |        fa:16:3e:49:57:1b  |    10.0.0.1               
<========plugged into br-int (this is the --listen-address of my two dnsmasqs)




br-int                       |        08:00:27:16:d5:09 |                       
         <========why doesn't bridge have no IP ?
new-instance          |        02:d8:47:48:35:26  <====== MAC address of newly 
launched instance? (see output below)





Unkown                 |        fa:16:3e:5e:02:17   <======Seemingly unknown 
MAC address(which is related to the new instance?)




Unkown                  |        33:33:00:00:00:16   <====== MAC address 
related to multicast ?






Questions:

1. What is gw-82bd3a73-dc interface ?




2. I am kind of unsure why br-int is so useful? 
3. Why doesn't br-int don't have any IP address?
4. Why do we need to plugin a compute node's interface to br-int? (so that 
guest instances on remote host can communicate with each other?)




5. What is the relationship b/w 02:d8:47:48:35:26 and fa:16:3e:5e:02:17 MAC 
addresses in the following output?





=====================
Output of : ovs-ofctl snoop br-int 
=====================




OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload
OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload
OFPT_PORT_STATUS (xid=0x0): ADD: 7(tap76127847-b1): addr:02:d8:47:48:35:26




     config:     0
     state:      LINK_DOWN
     current:    10MB-FD COPPER
OFPT_FLOW_MOD (xid=0x491662da): DEL priority=0 buf:0x0 actions=drop
OFPT_BARRIER_REQUEST (xid=0x491662db):
OFPT_BARRIER_REPLY (xid=0x491662db):




OFPT_PORT_STATUS (xid=0x0): MOD: 7(tap76127847-b1): addr:02:d8:47:48:35:26
     config:     0
     state:      0
     current:    10MB-FD COPPER
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=7 data_len=90 buffer=0x00000167
tunnel0:in_port0007:tci(0) macfa:16:3e:5e:02:17->33:33:00:00:00:16 type86dd 
proto58 tos0 ipv6::->ff02::16 port143->0
fa:16:3e:5e:02:17 > 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=0x491662dc): in_port=7 actions_len=0 actions=drop 
buffer=0x00000167
OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=7 data_len=128 buffer=0x00000168
tunnel0:in_port0007:tci(0) macfa:16:3e:5e:02:17->ff:ff:ff:ff:ff:ff type0800 
proto17 tos0 ip0.0.0.0->255.255.255.255 port68->67




fa:16:3e:5e:02:17 > 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:5e:02:17, length 280
OFPT_PACKET_OUT (xid=0x491662dd): in_port=7 actions_len=0 actions=drop 
buffer=0x00000168




OFPT_PACKET_IN (xid=0x0): total_len=78 in_port=7 data_len=78 buffer=0x00000169
fa:16:3e:5e:02:17 > 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:5e:02:17, length 280




OFPT_PACKET_OUT (xid=0x491662e3): in_port=7 actions_len=0 actions=drop 
buffer=0x0000016e
OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=7 data_len=70 buffer=0x0000016f
tunnel0:in_port0007:tci(0) macfa:16:3e:5e:02:17->33:33:00:00:00:02 type86dd 
proto58 tos0 ipv6fe80::f816:3eff:fe5e:217->ff02::2 port133->0




fa:16:3e:5e:02:17 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: 
fe80::f816:3eff:fe5e:217 > ff02::2: ICMP6, router solicitation, length 16
OFPT_PORT_STATUS (xid=0x0): MOD: 7(tap76127847-b1): addr:02:d8:47:48:35:26




     config:     0
     state:      LINK_DOWN
     current:    10MB-FD COPPER
OFPT_PORT_STATUS (xid=0x0): DEL: 7(tap76127847-b1): addr:02:d8:47:48:35:26
     config:     0
     state:      LINK_DOWN




     current:    10MB-FD COPPER
OFPT_FLOW_MOD (xid=0x491662e5): DEL priority=0,in_port=7 actions=drop
OFPT_FLOW_MOD (xid=0x491662e6): DEL priority=0 actions=drop
OFPT_BARRIER_REQUEST (xid=0x491662e7):
OFPT_BARRIER_REPLY (xid=0x491662e7):





Thanks!
Salman
                                          
                                          

_______________________________________________

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




~~~~~~~~~~~~~~~~~~~~~~~~~~~


                                          


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: www.nicira.com
twitter: danwendlandt


~~~~~~~~~~~~~~~~~~~~~~~~~~~


                                          
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to