Bug 1879241
Summary: | [OVN] Pods always lose one multicast packets | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Weibin Liang <weliang> |
Component: | OVN | Assignee: | Dumitru Ceara <dceara> |
Status: | CLOSED NOTABUG | QA Contact: | Jianlin Shi <jishi> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | FDP 20.E | CC: | aconstan, ctrautma, dceara, dmellado |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-04-06 12:37:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Weibin Liang
2020-09-15 18:22:40 UTC
==== 4.5.0-rc.1 [weliang@weliang FILE]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.5.0-rc.1 True False 9m22s Cluster version is 4.5.0-rc.1 [weliang@weliang FILE]$ oc exec ovnkube-master-8bjkq -- rpm -qa | grep ovn Defaulting container name to northd. Use 'oc describe pod/ovnkube-master-8bjkq -n openshift-ovn-kubernetes' to see all of the containers in this pod. ovn2.13-2.13.0-32.el7fdp.x86_64 ovn2.13-host-2.13.0-32.el7fdp.x86_64 ovn2.13-vtep-2.13.0-32.el7fdp.x86_64 ovn2.13-central-2.13.0-32.el7fdp.x86_64 [weliang@weliang FILE]$ ==== 4.6.0-0.nightly-2020-09-22-073212 [weliang@weliang FILE]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.0-0.nightly-2020-09-22-073212 True False 134m Cluster version is 4.6.0-0.nightly-2020-09-22-073212 [weliang@weliang FILE]$ oc exec ovnkube-master-jd9q7 -- rpm -qa | grep ovn Defaulting container name to northd. Use 'oc describe pod/ovnkube-master-jd9q7 -n openshift-ovn-kubernetes' to see all of the containers in this pod. ovn2.13-20.06.2-3.el8fdp.x86_64 ovn2.13-host-20.06.2-3.el8fdp.x86_64 ovn2.13-central-20.06.2-3.el8fdp.x86_64 ovn2.13-vtep-20.06.2-3.el8fdp.x86_64 [weliang@weliang FILE]$ Change to priority to high because this bug block QE OVN multicast automation testing. I'm not sure this is a bug. It seems to me that omping on P1 immediately starts sending multicast traffic after the remote P2 has sent the IGMP Join report. It can happen that the IP multicast packet from P1 reaches OVN before the report from P2 has been processed in which case the packet will be dropped because the IGMP group record doesn't include P2 yet. On a 4.8.0-0.ci-2021-04-02-081203 cluster, when switching to iperf instead of omping, start an IP multicast listener for 224.3.3.3 on pod P1 and a multicast sender on pod P2: 1000650000@mcast-rc-cwpgz:/$ iperf -s -B 224.3.3.3 -u -T 2 -t 10 -i 5 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 224.3.3.3 Joining multicast group 224.3.3.3 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 224.3.3.3 port 5001 connected with 10.128.6.8 port 59161 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 5.0 sec 640 KBytes 1.05 Mbits/sec 0.020 ms 0/ 446 (0%) [ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec 0.018 ms 0/ 447 (0%) 1000650000@mcast-rc-gkn4h:/$ iperf -c 224.3.3.3 -u -T 2 -t 5 -i 5 ------------------------------------------------------------ Client connecting to 224.3.3.3, UDP port 5001 Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) Setting multicast TTL to 2 UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.6.8 port 59161 connected with 224.3.3.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec [ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec [ 3] Sent 447 datagrams Number of sent packets equals number of received packets. On the other hand, on openshift-sdn, AFAIU IP multicast traffic is forwarded like any broadcast traffic to all pods in the namespace so that would explain why there are no drops with omping on openshift-sdn. What do you think? Thanks, Dumitru Tested in 4.8.0-0.nightly-2021-04-03-092337 using iperf, start multicast client first then start multicast source, there are no multicast traffic lost. Could this bug as this issue is shown when use omping but not iperf. |