Hey Greg, Thank you for the detailed update.
I will work on a work-around. Thank you for the support! - Keerthana On Thu, Apr 11, 2019 at 10:54 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 > > > I have replicated your results on my own systems by just adding the VM > ethernet interface to the same > bridge as the vxlan tunnel is on. As soon as I move the Ethernet > interface onto that bridge the DF bit > becomes set in this frame I captured: > > Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) > Ethernet II, Src: ba:c4:f3:2f:06:48 (ba:c4:f3:2f:06:48), Dst: > f6:7e:73:1e:ba:44 (f6:7e:73:1e:ba:44) > Internet Protocol Version 4, Src: 171.31.1.109, Dst: 171.31.1.102 > 0100 .... = Version: 4 > .... 0101 = Header Length: 20 bytes (5) > Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) > Total Length: 60 > Identification: 0x1251 (4689) > Flags: 0x4000, Don't fragment > 0... .... .... .... = Reserved bit: Not set > .1.. .... .... .... = Don't fragment: Set <----------------- set > even though the vxlan tunnel has default off > ..0. .... .... .... = More fragments: Not set > ...0 0000 0000 0000 = Fragment offset: 0 > Time to live: 64 > Protocol: TCP (6) > Header checksum: 0xcf59 [validation disabled] > [Header checksum status: Unverified] > Source: 171.31.1.109 > Destination: 171.31.1.102 > Transmission Control Protocol, Src Port: 36996, Dst Port: 5001, Seq: 0, > Len: 0 > > The fix is simple - move the Ethernet interface to a different bridge. > You cannot have the Ethernet interface > on the same bridge as the vxlan tunnel. That is a misconfiguration. > > VXLAN is a way of extending an L2 network across the IP network. When you > put it on the same bridge as a > promiscuous mode Ethernet interface then the underlying Linux network sees > this and begins sending packets > over the Ethernet interface instead of the VXLAN tunnel. As you can see > in my frame capture, the frame is > not VXLAN. Even though I'm sending via the VXLAN IP addresses! Because > in Linux the IP address belongs to > the system and not to the interface. Once the system sees your Ethernet > device on the bridge it will use that > for sending/receiving traffic rather than the vxlan tunnel - *with the > same IP addresses even though they > don't belong to the Ethernet interfaces*. > > You'll have find another way to do this. I suggest moving the Ethernet > interface to a different bridge > and then using a patch port from the Ethernet bridge to the VXLAN bridge. > > As I mentioned before I have never seen your type of configuration before > so I doubt it's supported or will be > supported in the future. It would take changes to the core Linux > networking components and I don't see that > happening. > > - 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
