Hi guys, I don't know if this is the best way to submit an issue, so please point me in the right direction if I'm mistaking.
Here's my configuration:
[root@KVM ~]# uname -a
Linux KVM.bogdan.local 3.10.0-229.14.1.el7.x86_64 #1 SMP Tue Sep 15 15:05:51
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@KVM ~]# ovs-vsctl show
c47a48ec-d0ec-46b2-8f80-eefb58feb524
Bridge "ovsbr0"
Port "vlan1"
tag: 1
Interface "vlan1"
type: internal
Port "bond0"
trunks: [399, 1050]
Interface "p4p1"
Interface "em1"
Port "vnic0"
tag: 1
Interface "vnic0"
type: internal
Port "vlan1050"
tag: 1050
Interface "vlan1050"
type: internal
Port "ovsbr0"
Interface "ovsbr0"
type: internal
Port "vnic1"
tag: 1
Interface "vnic1"
type: internal
Port "vlan399"
tag: 399
Interface "vlan399"
type: internal
ovs_version: "2.4.0"
[root@KVM ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: balance-tcp
bond may use recirculation: yes, Recirc-ID : 1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 5912 ms
lacp_status: negotiated
active slave mac: f8:b1:56:aa:32:a4(em1)
slave em1: enabled
active slave
may_enable: true
slave p4p1: enabled
may_enable: true
hash 185: 20 kB load
NOTE : I've attached the ifconfig print to this e-mail in case it's necessary.
So 2 x physical NICs configured in "balance-tcp".
Pretty simple.
Your documentation states :
balance-tcp
Balances flows among slaves based on L2, L3, and L4 protocol
information such as destination MAC address, IP address, and TCP port.
Source:
http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html
However, when I initiate a single large file transfer (~1GB) between this
machine and a Windows client via SCP, the TCP session seems to be spread
literally 50/50 between the 2 physical NICs, ignoring the fact that this is a
single TCP session.
Here's how it looks in tcpdump:
[root@KVM ~]# tcpdump -i p4p1 tcp port 62297
tcpdump: WARNING: p4p1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p4p1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:59:47.083200 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
3938497263:3938497375, ack 2900220118, win 32759, length 112
17:59:47.085657 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
112:192, ack 81, win 32758, length 80
17:59:47.089082 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
192:272, ack 177, win 32758, length 80
17:59:47.091809 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
272:512, ack 177, win 32758, length 240
17:59:47.091824 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
3097, win 32768, length 0
17:59:47.094497 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
512:592, ack 4337, win 32758, length 80
17:59:47.094508 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
7257, win 32768, length 0
17:59:47.094662 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
10177, win 32768, length 0
17:59:47.094930 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
13097, win 32768, length 0
17:59:47.095460 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
16017, win 32768, length 0
17:59:47.096738 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
592:752, ack 16721, win 32762, length 160
17:59:47.096874 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [.], ack
19641, win 32768, length 0
17:59:47.099184 IP 172.16.198.189.62297 > KVM.bogdan.local.ssh: Flags [P.], seq
752:912, ack 20881, win 32758, length 160
[root@KVM ~]# tcpdump -i em1 tcp port 62297
tcpdump: WARNING: em1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:59:47.085935 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [P.], seq
2900220198:2900220294, ack 3938497455, win 157, length 96
17:59:47.089450 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
96:3016, ack 81, win 157, length 2920
17:59:47.089465 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [P.], seq
3016:4256, ack 81, win 157, length 1240
17:59:47.092257 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
4256:7176, ack 321, win 167, length 2920
17:59:47.092266 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
7176:10096, ack 321, win 167, length 2920
17:59:47.092271 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
10096:13016, ack 321, win 167, length 2920
17:59:47.092275 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
13016:15936, ack 321, win 167, length 2920
17:59:47.092279 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [P.], seq
15936:16640, ack 321, win 167, length 704
17:59:47.094757 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [.], seq
16640:19560, ack 401, win 167, length 2920
17:59:47.094764 IP KVM.bogdan.local.ssh > 172.16.198.189.62297: Flags [P.], seq
19560:20800, ack 401, win 167, length 1240
Based on the definition in your official documentation, I was assuming that
bond0 would keep a TCP session on one NIC and initiate the next TCP session
through the 2nd NIC, and so on.
So a stickiness of TCP sessions if you will :)
However, what I'm seeing is that OVS is using both physical interfaces for the
data transfer itself on 1 x NIC and control information (TCP ACKs) on the other
NIC for the same TCP session.
Am I wrong in interpreting your documentation?
Is there any other LOG I could provide you with?
Thank you very much for your effort.
Best Regards,
[Description: cid:116511014@30092011-08A6]
Bogdan DANCU
Datacenter Technical Specialist
Orange/IMT/OINIS/ITE Romania
Tel:
Mobile: (+40)744445044
[email protected]<mailto:[email protected]>
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this
message was modified, changed or falsified.
Thank you.
ip_addr_add_txt_extension
Description: ip_addr_add_txt_extension
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
