[ovs-discuss] OVS

Ammu ammukeerthu at gmail.com
Thu Apr 11 03:35:53 UTC 2019


Sure. Thank you, Greg!

-
Keerthana

On Thu, Apr 11, 2019 at 4:47 AM Gregory Rose <gvrose8192 at gmail.com> wrote:

>
>
> On 4/6/2019 2:32 AM, Ammu wrote:
>
> Hey Greg,
>
> Sincere apologies.
>
> I can completely understand. Take care.
>
> In the meantime, I will try my best to debug the issue.
>
> Will update you if I could narrow it down.
>
> Catch you in the next weekend's time.
>
> Thank you :)
>
> -
> Keerthana
>
>
> Thank you!  I'm back and getting caught up.
>
> I'll be looking at this again tomorrow - I need to replicate your
> configuration in which you place a tunneling
> port and a network device in promiscuous mode on the same bridge.  This is
> not usually what i see when
> looking at tunneling configurations and just seems odd to me so maybe
> there's something going on there.
>
> I'll update after I've had a chance to look into it more.
>
> - Greg
>
>
> On Fri, Apr 5, 2019 at 4:20 AM Gregory Rose <gvrose8192 at gmail.com> wrote:
>
>> I'm out for a while due to a family matter and will not have a chance to
>> look at this until next week.
>>
>> - Greg
>>
>> On 4/3/2019 5:41 AM, Ammu wrote:
>>
>> Hello,
>>
>> Do you have any update on this?
>>
>> -
>> Keerthana
>>
>> On Mon, Apr 1, 2019 at 5:27 PM Ammu <ammukeerthu at gmail.com> wrote:
>>
>>> Hello Greg,
>>>
>>> Sorry for the late reply.
>>>
>>> I tried move the source interface to another bridge. But, after the
>>> configurations made, the expectation is not met.
>>>
>>> I facing few hurdles. The configuration in the attachment.
>>>
>>> Kindly help me with the configuration if I have missed something.
>>>
>>> And, I just have a question, why is it that the source interface should
>>> not be in the same bridge (according to my earlier configuration).
>>> Is there any limitation?
>>>
>>> -
>>> Keerthana
>>>
>>> On Fri, Mar 29, 2019 at 9:18 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
>>>>
>>>>
>>>> Please move this interface to a different bridge and then retry.  If
>>>> you check my configuration I do not have any
>>>> other interface on the bridge where the tunnel is located.
>>>>
>>>> Thanks,
>>>>
>>>> - 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/20190411/4167a4ed/attachment-0001.html>


More information about the discuss mailing list