openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #11763
Re: Understanding Integration Bridge and MACs
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 <salmanmk@xxxxxxxx> 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: dan@xxxxxxxxxx
> Date: Mon, 14 May 2012 19:23:34 -0700
> Subject: Re: [Openstack] Understanding Integration Bridge and MACs
> To: salmanmk@xxxxxxxx
> CC: openstack@xxxxxxxxxxxxxxxxxxx
>
>
>
>
> On Mon, May 14, 2012 at 3:19 PM, Salman Malik <salmanmk@xxxxxxxx> 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: salmanmk@xxxxxxxx
> To: openstack@xxxxxxxxxxxxxxxxxxx
> 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 : openstack@xxxxxxxxxxxxxxxxxxx
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Follow ups
References
