Sure. Thank you, Greg! - Keerthana
On Thu, Apr 11, 2019 at 4:47 AM Gregory Rose <[email protected]> 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 <[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
