[ovs-discuss] OVS

Ammu ammukeerthu at gmail.com
Tue Apr 16 08:48:52 UTC 2019


Hey Greg,

Thank you for the detailed update.

I will work on a work-around.

Thank you for the support!

-
Keerthana

On Thu, Apr 11, 2019 at 10:54 PM Gregory Rose <gvrose8192 at gmail.com> wrote:

>
>
> On 3/27/2019 10:33 PM, Ammu wrote:
>
> Hi Greg,
>
> *ens256:*
>
>    - Source interface which is intended to receive all traffic (the
>    reason why promisc mode is ON)
>    - Trying to tunnel all traffic that I receive in this interface
>
>
> *Output for* *ip addr show ens256:*
>
> 4: ens256: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UP group default qlen 1000
>     link/ether 00:50:56:95:ed:4f brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::26b9:a4a6:c518:8738/64 scope link noprefixroute
>        valid_lft forever preferred_lft forever
>
>
> I have replicated your results on my own systems by just adding the VM
> ethernet interface to the same
> bridge as the vxlan tunnel is on.  As soon as I move the Ethernet
> interface onto that bridge the DF bit
> becomes set in this frame I captured:
>
> Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
> Ethernet II, Src: ba:c4:f3:2f:06:48 (ba:c4:f3:2f:06:48), Dst:
> f6:7e:73:1e:ba:44 (f6:7e:73:1e:ba:44)
> Internet Protocol Version 4, Src: 171.31.1.109, Dst: 171.31.1.102
>     0100 .... = Version: 4
>     .... 0101 = Header Length: 20 bytes (5)
>     Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
>     Total Length: 60
>     Identification: 0x1251 (4689)
>     Flags: 0x4000, Don't fragment
>         0... .... .... .... = Reserved bit: Not set
>         .1.. .... .... .... = Don't fragment: Set  <----------------- set
> even though the vxlan tunnel has default off
>         ..0. .... .... .... = More fragments: Not set
>         ...0 0000 0000 0000 = Fragment offset: 0
>     Time to live: 64
>     Protocol: TCP (6)
>     Header checksum: 0xcf59 [validation disabled]
>     [Header checksum status: Unverified]
>     Source: 171.31.1.109
>     Destination: 171.31.1.102
> Transmission Control Protocol, Src Port: 36996, Dst Port: 5001, Seq: 0,
> Len: 0
>
> The fix is simple - move the Ethernet interface to a different bridge.
> You cannot have the Ethernet interface
> on the same bridge as the vxlan tunnel.  That is a misconfiguration.
>
> VXLAN is a way of extending an L2 network across the IP network.  When you
> put it on the same bridge as a
> promiscuous mode Ethernet interface then the underlying Linux network sees
> this and begins sending packets
> over the Ethernet interface instead of the VXLAN tunnel.  As you can see
> in my frame capture, the frame is
> not VXLAN.  Even though I'm sending via the VXLAN IP addresses!  Because
> in Linux the IP address belongs to
> the system and not to the interface.  Once the system sees your Ethernet
> device on the bridge it will use that
> for sending/receiving traffic rather than the vxlan tunnel - *with the
> same IP addresses even though they
> don't belong to the Ethernet interfaces*.
>
> You'll have find another way to do this.  I suggest moving the Ethernet
> interface to a different bridge
> and then using a patch port from the Ethernet bridge to the VXLAN bridge.
>
> As I mentioned before I have never seen your type of configuration before
> so I doubt it's supported or will be
> supported in the future.  It would take changes to the core Linux
> networking components and I don't see that
> happening.
>
> - Greg
>
>
> -
> Keerthana
>
> On Wed, Mar 27, 2019 at 11:39 PM Gregory Rose <gvrose8192 at gmail.com>
> wrote:
>
>>
>>
>> On 3/27/2019 2:30 AM, Ammu wrote:
>>
>> Hello Greg,
>>
>> I still don't see any change to my previous results.
>>
>> I am attaching the results along with the configurations made.
>>
>> I have attached first few packets of the capture.
>>
>> Kindly let me know if I am missing something or I am obscure in my
>> explanation.
>>
>>
>> I'm curious - why do you do this in your configuration?
>>
>> ovs-vsctl add-port br0 ens256
>> ip link set ens256 up
>> ip link set ens256 promisc on
>>
>> Can you provide the output of 'ip addr show ens256'?
>> And what is the source of that interface?
>>
>> Thanks,
>>
>> - Greg
>>
>>
>> -
>> Keerthana
>>
>>
>>
>> On Tue, Mar 26, 2019 at 12:24 PM Ammu <ammukeerthu at gmail.com> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you for the update!
>>>
>>> Yeah, we are all in the same page.
>>>
>>> Maybe I will update the OS version to 7.5 and get back on the result at
>>> the earliest.
>>>
>>> -
>>> Keerthana
>>>
>>> On Tue, Mar 26, 2019 at 2:34 AM Gregory Rose <gvrose8192 at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 3/25/2019 9:03 AM, Gregory Rose wrote:
>>>> >
>>>> > On 3/23/2019 2:28 AM, Ammu wrote:
>>>> >> Hey Greg,
>>>> >>
>>>> >> The recent check with OVS 2.10.1 version was done with CentOS Linux
>>>> >> release 7.3.1611
>>>> >>
>>>> >> But, I will have to support the solution with distributions
>>>> >> CentOS/Red Hat/Ubuntu.
>>>> >>
>>>> >> Currently giving you the output of distribution CentOS alone.
>>>> >>
>>>> >> [root at localhost ~]# modinfo openvswitch
>>>> >> filename:
>>>> >>
>>>>  /lib/modules/3.10.0-514.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
>>>> >> license:        GPL
>>>> >> description:    Open vSwitch switching datapath
>>>> >> rhelversion:    7.3
>>>> >> srcversion:     B31AE95554C9D9A0067F935
>>>> >> depends:
>>>> >> nf_conntrack,nf_nat,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6
>>>> >> intree:         Y
>>>> >> vermagic:       3.10.0-514.el7.x86_64 SMP mod_unload modversions
>>>> >> signer:         CentOS Linux kernel signing key
>>>> >> sig_key: D4:88:63:A7:C1:6F:CC:27:41:23:E6:29:8F:74:F0:57:AF:19:FC:54
>>>> >> sig_hashalgo:   sha256
>>>> >
>>>> > OK, I wanted to make sure that's the case before I do the repro
>>>> > attempt today.  I'm using a 7.5 based
>>>> > driver but it should be substantially the same.  I'll update in a bit
>>>> > after I try it out.
>>>> >
>>>>
>>>> Hi Ammu,
>>>>
>>>> I have tried your setup but am not seeing the same results.
>>>>
>>>> Here is my configuration on machine A:
>>>>
>>>> [root at localhost ovs-test-scripts]# ovs-vsctl show
>>>> a83453d5-27f8-4873-9356-e94b0d488797
>>>>      Bridge "br0"
>>>>          Port "vxlan1"
>>>>              Interface "vxlan1"
>>>>                  type: vxlan
>>>>                  options: {df_default="false", key="100",
>>>> remote_ip="200.0.0.102"}
>>>>          Port "br0"
>>>>              Interface "br0"
>>>>                  type: internal
>>>>      ovs_version: "2.10.1"
>>>>
>>>> I have the identical configuration on Machine B, with the tunnel
>>>> pointing back
>>>> to machine A:
>>>>
>>>> [root at localhost ovs-test-scripts]# ovs-vsctl show
>>>> bd184ee4-6e36-415b-ab90-e447046470c9
>>>>      Bridge "br0"
>>>>          Port "vxlan1"
>>>>              Interface "vxlan1"
>>>>                  type: vxlan
>>>>                  options: {df_default="false", key="100",
>>>> remote_ip="200.0.0.109"}
>>>>          Port "br0"
>>>>              Interface "br0"
>>>>                  type: internal
>>>>      ovs_version: "2.10.1"
>>>>
>>>> Both machines are running RHEL 7.5 which should be equivalent to CentOS
>>>> 7.5.
>>>>
>>>> I ran an iperf session and captured the first 500 packets.  I have
>>>> attached the
>>>> packet capture file.
>>>>
>>>> On Frame # 4 below we see the outer IPv4 header does not have the DF
>>>> bit
>>>> set on the
>>>> outer IPv4 UDP encapsulating frame.
>>>>
>>>> Frame 4: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112
>>>> bits)
>>>> Ethernet II, Src: RealtekU_a3:69:97 (52:54:00:a3:69:97), Dst:
>>>> RealtekU_3a:a4:cd (52:54:00:3a:a4:cd)
>>>> Internet Protocol Version 4, Src: 200.0.0.102, Dst: 200.0.0.109
>>>>      0100 .... = Version: 4
>>>>      .... 0101 = Header Length: 20 bytes (5)
>>>>      Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
>>>>      Total Length: 1500
>>>>      Identification: 0xd87c (55420)
>>>>      Flags: 0x0000
>>>>          0... .... .... .... = Reserved bit: Not set
>>>>          .0.. .... .... .... = Don't fragment: Not set <---------------
>>>> not set
>>>>          ..0. .... .... .... = More fragments: Not set
>>>>          ...0 0000 0000 0000 = Fragment offset: 0
>>>>      Time to live: 64
>>>>      Protocol: UDP (17)
>>>>      Header checksum: 0x0bc1 [validation disabled]
>>>>      [Header checksum status: Unverified]
>>>>      Source: 200.0.0.102
>>>>      Destination: 200.0.0.109
>>>> User Datagram Protocol, Src Port: 34290, Dst Port: 4789
>>>>      Source Port: 34290
>>>>      Destination Port: 4789
>>>>      Length: 1480
>>>>      [Checksum: [missing]]
>>>>      [Checksum Status: Not present]
>>>>      [Stream index: 2]
>>>>
>>>> CentOS 7.3 is pretty old - could you try upgrading to Centos 7.5 or
>>>> higher and then
>>>> see if the issue is resolved?  Or is there perhaps some step you're
>>>> doing that I'm
>>>> missing?
>>>>
>>>> Here is my modinfo for openvswitch:
>>>> filename:
>>>>
>>>> /lib/modules/3.10.0-862.el7.x86_64/kernel/net/openvswitch/openvswitch.ko.xz
>>>> alias:          net-pf-16-proto-16-family-ovs_packet
>>>> alias:          net-pf-16-proto-16-family-ovs_flow
>>>> alias:          net-pf-16-proto-16-family-ovs_vport
>>>> alias:          net-pf-16-proto-16-family-ovs_datapath
>>>> license:        GPL
>>>> description:    Open vSwitch switching datapath
>>>> retpoline:      Y
>>>> rhelversion:    7.5
>>>> srcversion:     E70A19E64B8AC42B9A7641F
>>>> depends:
>>>> nf_conntrack,nf_nat,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6
>>>> intree:         Y
>>>> vermagic:       3.10.0-862.el7.x86_64 SMP mod_unload modversions
>>>> signer:         Red Hat Enterprise Linux kernel signing key
>>>> sig_key: 51:73:02:3B:F8:16:37:D7:BF:3C:51:50:13:4E:EC:84:1B:96:FD:0B
>>>> sig_hashalgo:   sha256
>>>>
>>>> Thanks,
>>>>
>>>> - Greg
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190416/75d3775a/attachment-0001.html>


More information about the discuss mailing list