Open Stack

Mathias,

Just to clarify: Which interface in which VM are you pinging from, and
which interface in which VM are you pinging to?

Also, if i recall correctly, in Mitaka, besides disabling port security,
you had to disable ARP spoofing prevention for a scenario like this to work.

In ml2_conf.ini:

[AGENT]

prevent_arp_spoofing = False


I would also sincerely recommend though that you update your dev
environment to use the latest version of Openstack (Pike).

Greetings,

Benjamin

On Thu, Feb 1, 2018 at 11:11 AM, Mathias Strufe (DFKI) <
mathias.strufe at dfki.de> wrote:

> Dear Benjamin, Volodymyr,
>
> good question ;) ... I like to experiment with some kind of "Firewall NFV"
> ... but in the first step, I want to build a Router VM between two networks
> (and later extend it with some flow rules) ... OpenStack, in my case, is
> more a foundation to build a "test environment" for my "own" application
> ... please find attached a quick sketch of the current network ...
> I did this already before with iptables inside the middle instance ...
> worked quite well ... but know I like to achieve the same with OVS ...
> I didn't expect that it is so much more difficult ;) ...
>
> I'm currently checking Volodymyrs answer ... I think first point is now
> solved ... I "patched" now OVSbr1 and OVSbr2 inside the VM together (see
> OVpatch file)... but I think this is important later when I really like to
> ping from VM1 to VM2 ... but in the moment I only ping from VM1 to the
> TestNFV ... but the arp requests only reaches ens4 but not OVSbr1
> (according to tcpdump)...
>
> May it have to do with port security and the (for OpenStack) unknown MAC
> address of the OVS bridge?
>
> Thanks so far ...
>
> Mathias.
>
>
>
>
>
> On 2018-02-01 14:28, Benjamin Diaz wrote:
>
>> Dear Mathias,
>>
>> Could you attach a diagram of your network configuration and of what
>> you are trying to achieve?
>> Are you trying to install OVS inside a VM? If so, why?
>>
>> Greetings,
>> Benjamin
>>
>> On Thu, Feb 1, 2018 at 8:30 AM, Volodymyr Litovka <doka.ua at gmx.com>
>> wrote:
>>
>> Dear Mathias,
>>>
>>> if I correctly understand your configuration, you're using bridges
>>> inside VM and it configuration looks a bit strange:
>>>
>>> 1) you use two different bridges (OVSbr1/192.168.120.x and
>>> OVSbr2/192.168.110.x) and there is no patch between them so they're
>>> separate
>>> 2) while ARP requests for address in OVSbr1 arrives from OVSbr2:
>>>
>>> 18:50:58.080478 ARP, Request who-has 192.168.120.10 tell
>>>>
>>> 192.168.120.6, length 28
>>>
>>>>
>>>> but on the OVS bridge nothing arrives ...
>>>>
>>>> listening on OVSBR2, link-type EN10MB (Ethernet), capture size
>>>> 262144 bytes
>>>>
>>>
>>> while these bridges are separate, ARP requests and answers will not
>>> be passed between them.
>>>
>>> Regarding your devstack configuration - unfortunately, I don't have
>>> experience with devstack, so don't know, where it stores configs. In
>>> Openstack, ml2_conf.ini points to openvswitch in ml2's
>>> mechanism_drivers parameter, in my case it looks as the following:
>>>
>>> [ml2]
>>> mechanism_drivers = l2population,openvswitch
>>>
>>> and rest of openvswitch config described in
>>> /etc/neutron/plugins/ml2/openvswitch_agent.ini
>>>
>>> Second - I see an ambiguity in your br-tun configuration, where
>>> patch_int is the same as patch-int without corresponding remote peer
>>> config, probably you should check this issue.
>>>
>>> And third is - note that Mitaka is quite old release and probably
>>> you can give a chance for the latest release of devstack? :-)
>>>
>>> On 1/31/18 10:49 PM, Mathias Strufe (DFKI) wrote:
>>> Dear Volodymyr, all,
>>>
>>> thanks for your fast answer ...
>>> but I'm still facing the same problem, still can't ping the
>>> instance with configured and up OVS bridge ... may because I'm quite
>>> new to OpenStack and OpenVswitch and didn't see the problem ;)
>>>
>>> My setup is devstack Mitaka in single machine config ... first of
>>> all I didn't find there the openvswitch_agent.ini anymore, I
>>> remember in previous version it was in the neutron/plugin folder ...
>>>
>>> Is this config now done in the ml2 config file in the [OVS]
>>> section????
>>>
>>> I'm really wondering ...
>>> so I can ping between the 2 instances without any problem. But as
>>> soon I bring up the OVS bridge inside the vm the ARP requests only
>>> visible at the ens interface but not reaching the OVSbr ...
>>>
>>> please find attached two files which may help for troubleshooting.
>>> One are some network information from inside the Instance that runs
>>> the OVS and one ovs-vsctl info of the OpenStack Host.
>>>
>>> If you need more info/logs please let me know! Thanks for your
>>> help!
>>>
>>> BR Mathias.
>>>
>>> On 2018-01-27 22:44, Volodymyr Litovka wrote:
>>> Hi Mathias,
>>>
>>> whether you have all corresponding bridges and patches between
>>> them
>>> as described in openvswitch_agent.ini using
>>>
>>> integration_bridge
>>> tunnel_bridge
>>> int_peer_patch_port
>>> tun_peer_patch_port
>>> bridge_mappings
>>>
>>> parameters? And make sure, that service "neutron-ovs-cleanup" is
>>> in
>>> use during system boot. You can check these bridges and patches
>>> using
>>> "ovs-vsctl show" command.
>>>
>>> On 1/27/18 9:00 PM, Mathias Strufe (DFKI) wrote:
>>>
>>> Dear all,
>>>
>>> I'm quite new to openstack and like to install openVSwtich inside
>>> one Instance of our Mitika openstack Lab Enviornment ...
>>> But it seems that ARP packets got lost between the network
>>> interface of the instance and the OVS bridge ...
>>>
>>> With tcpdump on the interface I see the APR packets ...
>>>
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>
>>> decode
>>> listening on ens6, link-type EN10MB (Ethernet), capture size 262144
>>>
>>> bytes
>>> 18:50:58.080478 ARP, Request who-has 192.168.120.10 tell
>>> 192.168.120.6, length 28
>>> 18:50:58.125009 ARP, Request who-has 192.168.120.1 tell
>>> 192.168.120.6, length 28
>>> 18:50:59.077315 ARP, Request who-has 192.168.120.10 tell
>>> 192.168.120.6, length 28
>>> 18:50:59.121369 ARP, Request who-has 192.168.120.1 tell
>>> 192.168.120.6, length 28
>>> 18:51:00.077327 ARP, Request who-has 192.168.120.10 tell
>>> 192.168.120.6, length 28
>>> 18:51:00.121343 ARP, Request who-has 192.168.120.1 tell
>>> 192.168.120.6, length 28
>>>
>>> but on the OVS bridge nothing arrives ...
>>>
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>
>>> decode
>>> listening on OVSbr2, link-type EN10MB (Ethernet), capture size
>>> 262144 bytes
>>>
>>> I disabled port_security and removed the security group but nothing
>>>
>>> changed
>>>
>>>
>>> +-----------------------+-----------------------------------
>> ----------------------------------------------------+
>>
>>>
>>>
>>> | Field | Value
>>> |
>>>
>>>
>>> +-----------------------+-----------------------------------
>> ----------------------------------------------------+
>>
>>>
>>>
>>> | admin_state_up | True
>>> |
>>> | allowed_address_pairs |
>>> |
>>> | binding:host_id | node11
>>> |
>>> | binding:profile | {}
>>> |
>>> | binding:vif_details | {"port_filter": true, "ovs_hybrid_plug":
>>> true} |
>>> | binding:vif_type | ovs
>>> |
>>> | binding:vnic_type | normal
>>> |
>>> | created_at | 2018-01-27T16:45:48Z
>>> |
>>> | description |
>>> |
>>> | device_id | 74916967-984c-4617-ae33-b847de73de13
>>> |
>>> | device_owner | compute:nova
>>> |
>>> | extra_dhcp_opts |
>>> |
>>> | fixed_ips | {"subnet_id":
>>> "525db7ff-2bf2-4c64-b41e-1e41570ec358", "ip_address":
>>> "192.168.120.10"} |
>>> | id | 74b754d6-0000-4c2e-bfd1-87f640154ac9
>>> |
>>> | mac_address | fa:16:3e:af:90:0c
>>> |
>>> | name |
>>> |
>>> | network_id | 917254cb-9721-4207-99c5-8ead9f95d186
>>> |
>>> | port_security_enabled | False
>>> |
>>> | project_id | c48457e73b664147a3d2d36d75dcd155
>>> |
>>> | revision_number | 27
>>> |
>>> | security_groups |
>>> |
>>> | status | ACTIVE
>>> |
>>> | tenant_id | c48457e73b664147a3d2d36d75dcd155
>>> |
>>> | updated_at | 2018-01-27T18:54:24Z
>>> |
>>>
>>>
>>> +-----------------------+-----------------------------------
>> ----------------------------------------------------+
>>
>>>
>>>
>>> maybe the port_filter causes still the problem? But how to disable
>>> it?
>>>
>>> Any other idea?
>>>
>>> Thanks and BR Mathias.
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>> [1]
>>> Post to : openstack at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>> [1]
>>>
>>> --
>>> Volodymyr Litovka
>>> "Vision without Execution is Hallucination." -- Thomas Edison
>>>
>>> Links:
>>> ------
>>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> [1]
>>>
>>
>> --
>> Volodymyr Litovka
>>  "Vision without Execution is Hallucination." -- Thomas Edison
>>
>> _______________________________________________
>>  Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>  Post to     : openstack at lists.openstack.org
>>  Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>
>> --
>>
>> BENJAMÍN DÍAZ
>> Cloud Computing Engineer
>>
>>  bdiaz at whitestack.com
>>
>> Links:
>> ------
>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
> --
> Vielen Dank und Gruß Mathias.
> Many Thanks and kind regards, Mathias.
>
> --
> Dipl.-Ing. (FH) Mathias Strufe
> Wissenschaftlicher Mitarbeiter / Researcher
> Intelligente Netze / Intelligent Networks
>
> Phone: +49 (0) 631 205 75 - 1826
> Fax:   +49 (0) 631 205 75 – 4400
>
> E-Mail: Mathias.Strufe at dfki.de
> WWW: http://www.dfki.de/web/forschung/in
>
> WWW: https://selfnet-5g.eu/
>
> --------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Trippstadter Strasse 122
> D-67663 Kaiserslautern, Germany
>
> Geschaeftsfuehrung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter
> Olthoff
>
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
>
> Amtsgericht Kaiserslautern, HRB 2313
> VAT-ID:  DE 148 646 973
> --------------------------------------------------------------
>
>


-- 

*Benjamín Díaz*
Cloud Computing Engineer

bdiaz at whitestack.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20180201/be6b4e3c/attachment.html>