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]
<mailto:[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]
<mailto:[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] <mailto:[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
