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 On Fri, Apr 5, 2019 at 4:20 AM Gregory Rose <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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@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@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@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 >>>>>> >>>>>> >>>> >>> >
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
