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