[Openstack] [ovsdb-dev] No IP assigned to Instances
Silvia Fichera
fichera.sil at gmail.com
Thu Nov 19 15:05:41 UTC 2015
Hi Sam,
I'm still trying to assign addresses to the VM. I was reading carefully
your slides and I noticed, if I'm not wrong, that br-int should have a tap
inerface for the connection to the dhcp agent. Is it true?
In my configuration I noticed that:
- Without instances in the controller node I have:
neutron port-list
+--------------------------------------+------+-------------------+-----------------------------------------------------------------------------------+
| id | name | mac_address |
fixed_ips
|
+--------------------------------------+------+-------------------+-----------------------------------------------------------------------------------+
| 927db2be-5106-451d-95d1-5c1459d1a271 | | fa:16:3e:40:7f:a0 |
{"subnet_id": "547881c1-c4aa-4144-819a-64bc211f181b", "ip_address":
"10.10.10.2"} |
That I suppose is the port related to the dhcp agent. But
sudo ovs-vsctl show
a450ea16-a6c0-4f1b-ac49-5167b8c105ac
Manager "tcp:10.30.3.234:6640"
is_connected: true
Bridge br-ex
Controller "tcp:10.30.3.234:6653"
is_connected: true
fail_mode: secure
Port br-ex
Interface br-ex
type: internal
Port "eth1"
Interface "eth1"
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-ext}
Bridge br-int
Controller "tcp:10.30.3.234:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port patch-ext
Interface patch-ext
type: patch
options: {peer=patch-int}
Port "vxlan-10.0.0.2"
Interface "vxlan-10.0.0.2"
type: vxlan
options: {key=flow, local_ip="10.0.0.1",
remote_ip="10.0.0.2"}
ovs_version: "2.3.2"
so there is no port associated in br-int. That's right?
I also tried to follow the dhcp request when I do udhcpc from an instance.
I've done a capture in the tap port related to the vm and I can see that
the dhcp request is sent broadcast and then is lost.
what is the next step?
thank you.
Silvia
2015-11-17 23:27 GMT+01:00 Sam Hague <shague at redhat.com>:
> Silvia,
>
> yeah, only need odl-ovsdb-openstack. Make sure to delete the data and
> snapshot dirs when you restart ODL otherwise those other features will be
> loaded again. Also, somewhere in there l2switch was loaded because I can
> see those flows in your output. You can't run l2switch with ovsdb. You
> should totally clean your setup in-between runs.
>
> The thought about the port being down is not a problem. The LOCAL port is
> normally down and only enabled if you actually add an IP to it but that is
> rarely needed.
>
> This capture today with the port output is different than the flows dumped
> before. In the flows you can see that tunnel ports were created. In this
> capture today the tunnel ports are not there. Might be easiest to go to a
> single compute+control node and see that work. Then add the compute only
> node. Also the demo vm I mentioned is an easy way to see everything working.
>
> Thanks, Sam
>
> On Tue, Nov 17, 2015 at 2:57 PM, Silvia Fichera <fichera.sil at gmail.com>
> wrote:
>
>> Hi Sam,
>> the ODL features that I have installed are:
>>
>> odl-base-all odl-aaa-authn odl-restconf odl-nsf-all odl-adsal-northbound
>> odl-mdsal-apidocs odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core
>>
>> Are those correct?
>>
>> I didn't dowloaded yet your demo, maybe tomorrow I'll talk to whom is
>> providing me the VMs to download it and set up the enviroment so I can
>> check it and compare it with mine.
>>
>> I'll let you know! :)
>>
>> Thank you
>>
>> 2015-11-17 15:28 GMT+01:00 Sam Hague <shague at redhat.com>:
>>
>>> Silvia,
>>>
>>> looks like you also have the l2switch feature loaded. l2switch should
>>> not be used with the openstack integration since both apps want to own the
>>> openflow tables.
>>>
>>> I would disable l3 for now, until you get basic l2 working.
>>>
>>> I have added some comments below. Look for [sh] below.
>>>
>>> Normally when the dhcp fails it is because some path to the neutron dhcp
>>> namespace failed. Typically a tunnel wasn't built back to the control node
>>> or the flows to get there were not added. Or the packets failed to get back
>>> to the dhcp node. in the flows below, it looks like the tunnels are there
>>> and it looks like the dhcp requests are sent from the vms, but the dhcp
>>> requests are not making it into the control node's tunnel port. Is the
>>> local_ip address the right address to reach the nodes via the tunnels? I
>>> would run tcpdump on the tunnel ports to see why the packts are not going
>>> from node to node.
>>>
>>> These slides walk through how the flows and ports should look. You
>>> should be able to match them to what you have in your setup to see where
>>> the failure is.
>>>
>>>
>>> https://docs.google.com/presentation/d/1KIuNDuUJGGEV37Zk9yzx9OSnWExt4iD2Z7afycFLf_I/edit#slide=id.p95
>>>
>>> Also curious, did you download the all-in-on setup off the main ovsdb
>>> wiki? You should be able to simply fire that up and see a working setup. It
>>> goes with the slides to help troubleshoot. Then see all the flows and
>>> config. From there you can expand to a larger setup as you have.
>>>
>>> Thanks, Sam
>>>
>>> On Tue, Nov 17, 2015 at 3:38 AM, Silvia Fichera <fichera.sil at gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>> These are my output:
>>>> neutron agent-list
>>>>
>>>> +--------------------------------------+----------------+-----------+-------+----------------+------------------------+
>>>> | id | agent_type | host |
>>>> alive | admin_state_up | binary |
>>>>
>>>> +--------------------------------------+----------------+-----------+-------+----------------+------------------------+
>>>> | df34892b-4e00-4504-a9c2-6d73b89e7be7 | Metadata agent | devstack1 |
>>>> :-) | True | neutron-metadata-agent |
>>>> | e6497bd3-d34d-413d-8d99-c34df2d4de7e | DHCP agent | devstack1 |
>>>> :-) | True | neutron-dhcp-agent |
>>>>
>>>> +--------------------------------------+----------------+-----------+-------+----------------+------------------------+
>>>>
>>>> br-int Controller/Compute node:
>>>>
>>>> sudo ovs-ofctl dump-flows br-int -O Openflow13
>>>> OFPST_FLOW reply (OF1.3) (xid=0x2):
>>>> cookie=0x0, duration=64916.193s, table=0, n_packets=9, n_bytes=1458,
>>>> in_port=7,dl_src=fa:16:3e:cf:fd:30
>>>> actions=set_field:0x40e->tun_id,load:0x1->NXM_NX_REG0[],goto_table:20
>>>>
>>> [sh] guessing this is the dhcp port
>>>
>>>> cookie=0x0, duration=66408.764s, table=0, n_packets=3, n_bytes=180,
>>>> priority=0 actions=goto_table:20
>>>> cookie=0x0, duration=64916.188s, table=0, n_packets=0, n_bytes=0,
>>>> priority=8192,in_port=7 actions=drop
>>>>
>>> cookie=0x2b00000000000047, duration=64906.395s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=7 actions=output:5,output:6,CONTROLLER:65535
>>>>
>>> cookie=0x2b0000000000003e, duration=64996.333s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=3
>>>> actions=output:4,output:5,output:2,output:1,output:6,CONTROLLER:65535
>>>> cookie=0x2b00000000000046, duration=64906.395s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=6 actions=output:5,output:7,CONTROLLER:65535
>>>> cookie=0x2b00000000000045, duration=64906.400s, table=0,
>>>> n_packets=3517, n_bytes=211377, priority=2,in_port=5
>>>> actions=output:6,output:7
>>>> [sh] anything with this cookie=0x2b0000... is an l2switch flow. in
>>>> this one here it is grabbing packets. Possibly they are the dhcp ones. For
>>>> anything in the netvirt pipeline to work the packets have to go through the
>>>> whole pipeline. Packets are marked in table 0 and go all the way to table
>>>> 110 before they are l2-forwarded. Some l3 will exit earlier, but the point
>>>> is that they packets have to get to table 110 to get forwarded correctly.
>>>> cookie=0x2b0000000000003f, duration=64996.332s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=1
>>>> actions=output:4,output:5,output:2,output:3,output:6,CONTROLLER:65535
>>>> cookie=0x2b0000000000003b, duration=64996.335s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=4
>>>> actions=output:5,output:2,output:3,output:1,output:6,CONTROLLER:65535
>>>> cookie=0x2b0000000000003d, duration=64996.333s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=2
>>>> actions=output:4,output:5,output:3,output:1,output:6,CONTROLLER:65535
>>>> cookie=0x0, duration=64916.143s, table=0, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,in_port=6 actions=load:0x2->NXM_NX_REG0[],goto_table:20
>>>>
>>> [sh] this should be the tunnel into the node, so that is good. What
>>> isn't good is I don't see any packets hitting it. So if dhcp is on this
>>> node, then dhcp requests from the other nodes should be hitting this flow
>>> as they are trying to reach the dhcp server.
>>>
>>>> cookie=0x0, duration=66411.533s, table=0, n_packets=1189,
>>>> n_bytes=124845, dl_type=0x88cc actions=CONTROLLER:65535
>>>> cookie=0x2b00000000000007, duration=66411.622s, table=0, n_packets=0,
>>>> n_bytes=0, priority=100,dl_type=0x88cc actions=CONTROLLER:65535
>>>>
>>>
>>> cookie=0x0, duration=66408.756s, table=20, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:30
>>>>
>>> [sh] little weird, I conly count 12 packets in earlier flows that could
>>> have made it here, so surprised to see 48
>>>
>>>> cookie=0x0, duration=66408.749s, table=30, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:40
>>>> cookie=0x0, duration=64916.203s, table=40, n_packets=0, n_bytes=0,
>>>> priority=36001,ip,in_port=7,dl_src=fa:16:3e:cf:fd:30,nw_src=10.10.10.7
>>>> actions=goto_table:50
>>>> cookie=0x0, duration=66408.743s, table=40, n_packets=33, n_bytes=2520,
>>>> priority=0 actions=goto_table:50
>>>> cookie=0x0, duration=66086.470s, table=40, n_packets=15, n_bytes=4950,
>>>> priority=61012,udp,tp_src=68,tp_dst=67 actions=goto_table:50
>>>> cookie=0x0, duration=64916.203s, table=40, n_packets=0, n_bytes=0,
>>>> priority=61011,udp,in_port=7,tp_src=67,tp_dst=68 actions=drop
>>>> cookie=0x0, duration=66408.737s, table=50, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:60
>>>> cookie=0x0, duration=66408.732s, table=60, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:70
>>>> cookie=0x0, duration=66408.727s, table=70, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:80
>>>> cookie=0x0, duration=66408.722s, table=80, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:90
>>>> cookie=0x0, duration=66408.717s, table=90, n_packets=48, n_bytes=7470,
>>>> priority=0 actions=goto_table:100
>>>> cookie=0x0, duration=64916.217s, table=90, n_packets=0, n_bytes=0,
>>>> priority=61006,udp,dl_src=fa:16:3e:48:27:5a,tp_src=67,tp_dst=68
>>>> actions=goto_table:100
>>>> cookie=0x0, duration=66408.713s, table=100, n_packets=48,
>>>> n_bytes=7470, priority=0 actions=goto_table:110
>>>> cookie=0x0, duration=64916.151s, table=110, n_packets=0, n_bytes=0,
>>>> priority=8192,tun_id=0x40e actions=drop
>>>> cookie=0x0, duration=66408.687s, table=110, n_packets=3, n_bytes=180,
>>>> priority=0 actions=drop
>>>>
>>> [sh] macthes the 3 from table 0 that are not from the dhcp port or the
>>> tunnel port so they are dropped.
>>>
>>>> cookie=0x0, duration=64916.178s, table=110, n_packets=0, n_bytes=0,
>>>> priority=16384,reg0=0x2,tun_id=0x40e,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
>>>> actions=output:7
>>>> cookie=0x0, duration=64916.164s, table=110, n_packets=9, n_bytes=1458,
>>>> priority=16383,reg0=0x1,tun_id=0x40e,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
>>>> actions=output:7,output:6
>>>>
>>> [sh] flood packets. Matches the 9 from the dhcp port
>>>
>>>> cookie=0x0, duration=64916.183s, table=110, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,dl_dst=fa:16:3e:cf:fd:30 actions=output:7
>>>> cookie=0x0, duration=64914.605s, table=110, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,dl_dst=fa:16:3e:7e:0c:43 actions=output:6
>>>> cookie=0x0, duration=64914.763s, table=110, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,dl_dst=fa:16:3e:ef:2a:29 actions=output:6
>>>>
>>>>
>>>> br-int Compute node:
>>>>
>>>> sudo ovs-ofctl dump-flows br-int -O Openflow13
>>>> OFPST_FLOW reply (OF1.3) (xid=0x2):
>>>> cookie=0x0, duration=64953.73s, table=0, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,in_port=1 actions=load:0x2->NXM_NX_REG0[],goto_table:20
>>>>
>>> [sh] tunnel port. this is good. but no packets hitting the port so no
>>> dhcp replies are coming back or the dhcp requests were never sent.
>>>
>>>> cookie=0x0, duration=64953.782s, table=0, n_packets=9, n_bytes=1458,
>>>> in_port=2,dl_src=fa:16:3e:ef:2a:29
>>>> actions=set_field:0x40e->tun_id,load:0x1->NXM_NX_REG0[],goto_table:20
>>>> cookie=0x0, duration=64953.633s, table=0, n_packets=9, n_bytes=1458,
>>>> in_port=4,dl_src=fa:16:3e:7e:0c:43
>>>> actions=set_field:0x40e->tun_id,load:0x1->NXM_NX_REG0[],goto_table:20
>>>>
>>> [sh] guess you ahve two vms spawned. two flows above will filter traffic
>>> coming from the vm.
>>>
>>>> cookie=0x2b00000000000048, duration=64945.347s, table=0,
>>>> n_packets=2859, n_bytes=171540, priority=2,in_port=3
>>>> actions=output:2,output:4,output:1
>>>> cookie=0x2b0000000000004b, duration=64945.346s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=1
>>>> actions=output:3,output:2,output:4,CONTROLLER:65535
>>>> cookie=0x0, duration=64953.777s, table=0, n_packets=0, n_bytes=0,
>>>> priority=8192,in_port=2 actions=drop
>>>> cookie=0x2b00000000000049, duration=64945.347s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=2
>>>> actions=output:3,output:4,output:1,CONTROLLER:65535
>>>> cookie=0x0, duration=64953.617s, table=0, n_packets=0, n_bytes=0,
>>>> priority=8192,in_port=4 actions=drop
>>>> cookie=0x2b0000000000004a, duration=64945.347s, table=0, n_packets=0,
>>>> n_bytes=0, priority=2,in_port=4
>>>> actions=output:3,output:2,output:1,CONTROLLER:65535
>>>> cookie=0x0, duration=65039.282s, table=0, n_packets=954,
>>>> n_bytes=100170, dl_type=0x88cc actions=CONTROLLER:65535
>>>> cookie=0x2b00000000000009, duration=65039.291s, table=0, n_packets=0,
>>>> n_bytes=0, priority=100,dl_type=0x88cc actions=CONTROLLER:65535
>>>> cookie=0x0, duration=65035.376s, table=0, n_packets=12, n_bytes=858,
>>>> priority=0 actions=goto_table:20
>>>> cookie=0x0, duration=65035.37s, table=20, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:30
>>>> cookie=0x0, duration=65035.367s, table=30, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:40
>>>> cookie=0x0, duration=64953.798s, table=40, n_packets=0, n_bytes=0,
>>>> priority=36001,ip,in_port=2,dl_src=fa:16:3e:ef:2a:29,nw_src=10.10.10.8
>>>> actions=goto_table:50
>>>> cookie=0x0, duration=64953.639s, table=40, n_packets=0, n_bytes=0,
>>>> priority=36001,ip,in_port=4,dl_src=fa:16:3e:7e:0c:43,nw_src=10.10.10.9
>>>> actions=goto_table:50
>>>> cookie=0x0, duration=65035.361s, table=40, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:50
>>>> cookie=0x0, duration=64953.808s, table=40, n_packets=0, n_bytes=0,
>>>> priority=61011,udp,in_port=2,tp_src=67,tp_dst=68 actions=drop
>>>> cookie=0x0, duration=64953.656s, table=40, n_packets=0, n_bytes=0,
>>>> priority=61011,udp,in_port=4,tp_src=67,tp_dst=68 actions=drop
>>>> cookie=0x0, duration=65035.356s, table=50, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:60
>>>> cookie=0x0, duration=65035.352s, table=60, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:70
>>>> cookie=0x0, duration=65035.347s, table=70, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:80
>>>> cookie=0x0, duration=65035.343s, table=80, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:90
>>>> cookie=0x0, duration=65035.339s, table=90, n_packets=25, n_bytes=3356,
>>>> priority=0 actions=goto_table:100
>>>> cookie=0x0, duration=64953.813s, table=90, n_packets=0, n_bytes=0,
>>>> priority=61006,udp,dl_src=fa:16:3e:48:27:5a,tp_src=67,tp_dst=68
>>>> actions=goto_table:100
>>>> cookie=0x0, duration=65035.335s, table=100, n_packets=25,
>>>> n_bytes=3356, priority=0 actions=goto_table:110
>>>> cookie=0x0, duration=64953.738s, table=110, n_packets=0, n_bytes=0,
>>>> priority=8192,tun_id=0x40e actions=drop
>>>> cookie=0x0, duration=64953.611s, table=110, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,dl_dst=fa:16:3e:7e:0c:43 actions=output:4
>>>> cookie=0x0, duration=64953.768s, table=110, n_packets=0, n_bytes=0,
>>>> tun_id=0x40e,dl_dst=fa:16:3e:ef:2a:29 actions=output:2
>>>> cookie=0x0, duration=64953.762s, table=110, n_packets=0, n_bytes=0,
>>>> priority=16384,reg0=0x2,tun_id=0x40e,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
>>>> actions=output:2,output:4
>>>> cookie=0x0, duration=64953.756s, table=110, n_packets=18,
>>>> n_bytes=2916,
>>>> priority=16383,reg0=0x1,tun_id=0x40e,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
>>>> actions=output:2,output:1,output:4
>>>>
>>> [sh] this is good, since it says the broadcast packets are flooded. The
>>> tunnel port should be in this list also. 18 packets to match the 9 from
>>> each vm. Maybe these were the dhcp requests going out.
>>>
>>>> cookie=0x0, duration=65035.33s, table=110, n_packets=7, n_bytes=440,
>>>> priority=0 actions=drop
>>>>
>>>> Thanks
>>>>
>>>> 2015-11-17 8:42 GMT+01:00 Janki Chhatbar <jankihchhatbar at gmail.com>:
>>>>
>>>>> Hi
>>>>>
>>>>> Check for flows in both the bridges. Check if DHCP agent is running. I
>>>>> faced the same issue but I was using GRE tunnels and manual installation.
>>>>>
>>>>> Thanks
>>>>> Janki
>>>>>
>>>>> Sent from my BlackBerry 10 smartphone.
>>>>> *From: *Silvia Fichera
>>>>> *Sent: *Tuesday, 17 November 2015 13:09
>>>>> *To: *Janki Chhatbar
>>>>> *Cc: *<ovsdb-dev at lists.opendaylight.org>;
>>>>> openstack at lists.openstack.org
>>>>> *Subject: *Re: [Openstack] No IP assigned to Instances
>>>>>
>>>>> Hi Janki,
>>>>> I'm using vxlan and I have both br-int and br-ex (but by now I'm not
>>>>> caring about external connection, I think that if it is not able to ping
>>>>> internally it won't be able to reach internet).
>>>>>
>>>>> Thanks,
>>>>> Silvia
>>>>>
>>>>> 2015-11-16 16:27 GMT+01:00 Janki Chhatbar <jankihchhatbar at gmail.com>:
>>>>>
>>>>>> Hi Silvia
>>>>>>
>>>>>> Could you check flows in ovs bridges. If you are using GRE tunnels,
>>>>>> there should be only 1 bridge - br-int in compute and Neutron node each.
>>>>>> You will need to configure IP of the end point for tunnel.
>>>>>>
>>>>>> Thanks
>>>>>> Janki
>>>>>>
>>>>>> Sent from my BlackBerry 10 smartphone.
>>>>>> *From: *Silvia Fichera
>>>>>> *Sent: *Monday, 16 November 2015 20:16
>>>>>> *To: *<ovsdb-dev at lists.opendaylight.org>;
>>>>>> openstack at lists.openstack.org
>>>>>> *Subject: *[Openstack] No IP assigned to Instances
>>>>>>
>>>>>> Hi all,
>>>>>> I'm going to integrate Opendaylight with Openstack via Devstack.
>>>>>> In a server I have 5 VMs:
>>>>>>
>>>>>> VM1: eth0 10.30.3.231
>>>>>> eth1 10.0.0.1
>>>>>> This is my OpenStack Controller+compute.
>>>>>>
>>>>>> VM2: eth0 10.30.3.232
>>>>>> eth1 10.0.0.2
>>>>>> Compute node
>>>>>>
>>>>>> VM3: eth0 10.30.3.233
>>>>>> eth1 10.0.0.3
>>>>>> Compute node
>>>>>>
>>>>>> VM4: eth0 10.30.3.234
>>>>>> ODL Controller
>>>>>>
>>>>>> VM7: eth0 10.30.3.237
>>>>>> eth1
>>>>>> eth2
>>>>>> eth3
>>>>>> This is my OpenVSwitch
>>>>>>
>>>>>> I was able to build up the setup, but when I create instances the IP
>>>>>> address is not assigned so I can't ping them.
>>>>>>
>>>>>> It seems that dhcp fails
>>>>>>
>>>>>> Starting network...
>>>>>> udhcpc (v1.20.1) started
>>>>>> Sending discover...
>>>>>> Sending discover...
>>>>>> Sending discover...
>>>>>> Usage: /sbin/cirros-dhcpc <up|down>
>>>>>> No lease, failing
>>>>>>
>>>>>> I've checked the neutron agent-list and there are the metadata agent
>>>>>> and the dhcp agent.
>>>>>>
>>>>>> In my local. conf I have disabled the l3 agent:
>>>>>>
>>>>>> disable_service q-l3
>>>>>> Q_L3_ENABLED=True
>>>>>> ODL_L3=True
>>>>>>
>>>>>>
>>>>>> Could you please help me?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Silvia Fichera
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Silvia Fichera
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Silvia Fichera
>>>>
>>>> _______________________________________________
>>>> ovsdb-dev mailing list
>>>> ovsdb-dev at lists.opendaylight.org
>>>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>>>>
>>>>
>>>
>>
>>
>> --
>> Silvia Fichera
>>
>
>
--
Silvia Fichera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20151119/50265fa5/attachment.html>
More information about the Openstack
mailing list