dan at nicira
May 15, 2012, 11:06 AM
Post #9 of 11
(129 views)
Permalink
|
|
Re: Understanding Integration Bridge and MACs
[In reply to]
|
|
On Tue, May 15, 2012 at 10:19 AM, Salman Malik <salmanmk [at] live> wrote:
> 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...
>
It looks like your system is probably inconsistent due to the actions you
described in the previous email (i.e., deleting networks directly via
quantum, rather than using nova-manage network delete). The network likely
still exists in nova, even though you deleted it via Quantum (hence the 404
exception from quantum).
You'll probably need to reset your nova database and the ovs_quantum
database (assuming you're using the OVS plugin). If you're using devstack,
simply re-running stack.sh should do it.
dan
>
>
> ------------------------------
> From: dan [at] nicira
> Date: Tue, 15 May 2012 09:29:02 -0700
>
> Subject: Re: [Openstack] Understanding Integration Bridge and MACs
> To: salmanmk [at] live
> CC: openstack [at] lists
>
> 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 [at] live> 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 [at] nicira
> Date: Mon, 14 May 2012 19:23:34 -0700
> Subject: Re: [Openstack] Understanding Integration Bridge and MACs
> To: salmanmk [at] live
> CC: openstack [at] lists
>
>
>
>
> On Mon, May 14, 2012 at 3:19 PM, Salman Malik <salmanmk [at] live> 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 [at] live
> To: openstack [at] lists
> 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 [at] lists
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
