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
