openstack team mailing list archive

[Salman Malik <salmanmk@xxxxxxxx>]

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 ?



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