[ovs-discuss] OVS
Gregory Rose
gvrose8192 at gmail.com
Thu Apr 4 22:50:50 UTC 2019
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 <ammukeerthu at gmail.com
> <mailto:ammukeerthu at gmail.com>> 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 <gvrose8192 at gmail.com
> <mailto:gvrose8192 at gmail.com>> 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
>> <gvrose8192 at gmail.com <mailto:gvrose8192 at gmail.com>> 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
>>> <ammukeerthu at gmail.com <mailto:ammukeerthu at gmail.com>>
>>> 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
>>> <gvrose8192 at gmail.com <mailto:gvrose8192 at gmail.com>>
>>> 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 at 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 at 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 at 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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190404/0d19f80b/attachment-0001.html>
More information about the discuss
mailing list