[Openstack] OpenVSwitch inside Instance no ARP passthrough
Volodymyr Litovka
doka.ua at gmx.com
Fri Feb 2 14:32:44 UTC 2018
Hi Mathias,
the fact that you've seen ARP request-reply says that connectivity
itself is correct. I think the problem with flows configuration inside
bridge, which is controlled by ODL. Unfortunately, I never had an
experience with ODL and can't comment what it do and how. You can print
flows config using command
ovs-ofctl dump-flows <bridge_name>
and there you can try to find whether some rules block some traffic.
On 2/2/18 4:14 PM, Mathias Strufe (DFKI) wrote:
> Dear Volodymyr, Benjamin,
>
> thanks a lot for your tipps and patience ... but still facing the same
> problem :/
> So I need to bother you again ...
> I think its something totally stupid, basic I do wrong ...
>
> Let me summarize what I did so far:
>
> - Update OpenStack to pike (devstack All in Single VM using default
> local.conf)
> [following this https://docs.openstack.org/devstack/latest/index.html]
> - Set prevent_arp_spoofing = False in ml2_config.ini
> - Disable Port Security of the TestNFV
>
> +-----------------------+------------------------------------------------------------------------------+
>
> | Field | Value |
> +-----------------------+------------------------------------------------------------------------------+
>
> | admin_state_up | UP |
> | allowed_address_pairs | |
> | binding_host_id | None |
> | binding_profile | None |
> | binding_vif_details | None |
> | binding_vif_type | None |
> | binding_vnic_type | normal |
> | created_at | 2018-01-31T07:50:40Z
> |
> | data_plane_status | None |
> | description | |
> | device_id | 97101c9b-c5ea-47f5-aa50-4a6ffa06c2a2
> |
> | device_owner | compute:nova |
> | dns_assignment | None |
> | dns_name | None |
> | extra_dhcp_opts | |
> | fixed_ips | ip_address='192.168.120.5',
> subnet_id='b88f21e0-55ce-482f-8755-87a431f43e52' |
> | id | 5e97ea14-2555-44fc-bbfa-61877e93ae69
> |
> | ip_address | None |
> | mac_address | fa:16:3e:55:80:84
> |
> | name | |
> | network_id | 67572da9-c1e1-4330-84f6-79b64225c070
> |
> | option_name | None |
> | option_value | None |
> | port_security_enabled | False |
> | project_id | ec8680e914a540e59d9d84dec8101ba5
> |
> | qos_policy_id | None |
> | revision_number | 56 |
> | security_group_ids | |
> | status | ACTIVE |
> | subnet_id | None |
> | tags | |
> | trunk_details | None |
> | updated_at | 2018-02-02T13:40:26Z
> |
> +-----------------------+------------------------------------------------------------------------------+
>
>
> In this state everything works fine and as expected ... I can ping
> from VM1 (192.168.120.10) to Test NVF VM (192.168.120.5) and get a
> response ... I have access to the outside world ...
>
> BUT
>
> As soon as I bring the OVS up inside of the Test NVF ... now as
> Volodymyr proposed with a "special patch port"
>
> Database config:
> 59aca356-8f37-4c6f-8c9a-504c66c65648
> Bridge "OVSbr2"
> Controller "tcp:192.168.53.49:6633"
> is_connected: true
> fail_mode: secure
> Port "OVSbr2-patch"
> Interface "OVSbr2-patch"
> type: patch
> options: {peer="OVSbr1-patch"}
> Port "OVSbr2"
> Interface "OVSbr2"
> type: internal
> Port "ens5"
> Interface "ens5"
> Bridge "OVSbr1"
> Controller "tcp:192.168.53.49:6633"
> is_connected: true
> fail_mode: secure
> Port "OVSbr1"
> Interface "OVSbr1"
> type: internal
> Port "OVSbr1-patch"
> Interface "OVSbr1-patch"
> type: patch
> options: {peer="OVSbr2-patch"}
> Port "ens4"
> Interface "ens4"
> ovs_version: "2.5.2"
>
>
> the ping stops ... and again with tcpdump I can only see ARP requests
> on ens4 but not on the OVSbr1 bridge ...
>
> But I see now some LLDP packets on the ens4 and OVSbr1 ....
>
> Then I tried following ... I stopped the ping from source to TestNFVVM
> And start pinging from the TestNFV (192.168.120.5) to the Source
> (192.168.120.10)
> Again I didnt get any response ...
> And again looked at the tcpdump of OVSbr1 and ens4 ...
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on OVSbr1, link-type EN10MB (Ethernet), capture size 262144
> bytes
> 13:59:18.245528 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 286, length 64
> 13:59:19.253513 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 287, length 64
> 13:59:20.261487 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 288, length 64
> 13:59:21.269499 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 289, length 64
> 13:59:21.680458 LLDP, length 110: openflow:214083694506308
> 13:59:22.277524 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 290, length 64
> 13:59:23.285531 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 291, length 64
> 13:59:24.293631 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 292, length 64
> 13:59:25.301529 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 293, length 64
> 13:59:26.309588 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 294, length 64
> 13:59:26.680238 LLDP, length 110: openflow:214083694506308
> 13:59:27.317591 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 295, length 64
> 13:59:28.325524 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 296, length 64
> 13:59:29.333618 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 297, length 64
> 13:59:30.341515 IP 192.168.120.5 > 192.168.120.10: ICMP echo request,
> id 1839, seq 298, length 64
>
>
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
> 13:59:16.680452 LLDP, length 99: openflow:214083694506308
> 13:59:21.680791 LLDP, length 99: openflow:214083694506308
> 13:59:26.680532 LLDP, length 99: openflow:214083694506308
> 13:59:31.680503 LLDP, length 99: openflow:214083694506308
> 13:59:36.680681 LLDP, length 99: openflow:214083694506308
> 13:59:41.391777 ARP, Request who-has 192.168.120.10 tell
> 192.168.120.5, length 28
> 13:59:41.392345 ARP, Reply 192.168.120.10 is-at fa:16:3e:84:5c:29 (oui
> Unknown), length 28
> 13:59:41.680626 LLDP, length 99: openflow:214083694506308
> 13:59:46.680692 LLDP, length 99: openflow:214083694506308
>
>
>
> This is a bit confusing for me ...
> First why does the echo request only appear on the OVSbr1 bridge and
> not also on the ens4 ... is this correct behaviour?
> and second why I got suddenly a ARP reply on ens4 which is indeed the
> correct mac of the VM1 interface ...
> and why the LLDP packets shown on both interfaces ...
>
> Is now something wrong with the FlowController?
> I use ODL with odl-l2switch-all feature enabled ...
>
> puhhh ... what do I miss??? I didn't get this ...
>
> Thx a lot Mathias.
>
>
>
>
>
>
>
> On 2018-02-01 23:49, Volodymyr Litovka wrote:
>> Hi Mathias,
>>
>> I'm not so fluent with OVS, but I would recommend to join bridges
>> using special "ports" like
>>
>> Port ovsbr1-patch
>> Interface ovsbr1-patch
>> type: patch
>> options: {peer=ovsbr2-patch}
>> and vice versa, keeping "native" configuration of "port OVSbr1" and
>> "port OVSbr2"
>>
>> And keep in mind that ARP scope is broadcast domain and, if using
>> just ARP (not routing), from VM1 you will be able to ping hosts,
>> belonging to OVSbr1, particularly - OVSbr1's IP.
>>
>> On 2/1/18 4:11 PM, Mathias Strufe (DFKI) 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]
>>> [1]
>>> Post to : openstack at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>> [1]
>>> [1]
>>>
>>> --
>>> Volodymyr Litovka
>>> "Vision without Execution is Hallucination." -- Thomas Edison
>>>
>>> Links:
>>> ------
>>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> [1]
>>> [1]
>>
>> --
>> Volodymyr Litovka
>> "Vision without Execution is Hallucination." -- Thomas Edison
>>
>> _______________________________________________
>> 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]
>>
>>
>> --
>>
>> BENJAMÍN DÍAZ
>> Cloud Computing Engineer
>>
>> bdiaz at whitestack.com
>>
>> Links:
>> ------
>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
>>
>>
>> --
>> Volodymyr Litovka
>> "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>> Links:
>> ------
>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20180202/5a556035/attachment.html>
More information about the Openstack
mailing list