[ovs-discuss] OVS
Ammu
ammukeerthu at gmail.com
Wed Apr 3 12:41:03 UTC 2019
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/20190403/87a1d962/attachment-0001.html>
More information about the discuss
mailing list