Thursday, 2020-05-21

*** armax has quit IRC00:06
*** ihrachys has quit IRC02:15
*** ihrachys has joined #openvswitch02:16
*** markmcclain has quit IRC02:25
*** markmcclain has joined #openvswitch02:49
*** anilvenkata has joined #openvswitch02:50
*** itandops has quit IRC03:08
*** anilvenkata has quit IRC03:39
*** anilvenkata has joined #openvswitch03:55
*** mmirecki has joined #openvswitch05:22
*** mmirecki has quit IRC05:27
*** links has joined #openvswitch05:56
*** jraju__ has joined #openvswitch06:05
*** links has quit IRC06:06
*** jraju__ has quit IRC06:06
*** Kamilion has quit IRC06:25
*** Kamilion has joined #openvswitch06:35
*** acidfoo has quit IRC06:51
*** acidfoo has joined #openvswitch06:52
*** mmirecki has joined #openvswitch06:56
*** slaweq has joined #openvswitch06:57
*** jaicaa has quit IRC08:17
*** jaicaa has joined #openvswitch08:20
*** timothy has joined #openvswitch09:10
*** dceara has joined #openvswitch09:29
*** dceara has quit IRC09:29
*** itandops has joined #openvswitch09:33
*** mmirecki has quit IRC09:38
*** mmirecki has joined #openvswitch10:20
*** mmirecki has quit IRC10:29
*** itandops has quit IRC10:34
*** zhouhan_ has quit IRC11:01
*** zhouhan has joined #openvswitch11:01
*** timothy has quit IRC11:12
*** timothy has joined #openvswitch11:19
*** acidfoo has quit IRC11:22
*** acidfoo has joined #openvswitch11:23
*** darkemon has quit IRC11:36
*** darkemon has joined #openvswitch11:38
*** ihrachys has quit IRC11:51
*** ihrachys has joined #openvswitch11:51
*** acidfoo has quit IRC11:53
*** acidfoo has joined #openvswitch11:53
*** acidfu_ has joined #openvswitch11:56
*** acidfoo has quit IRC11:58
*** aconole has joined #openvswitch12:34
*** bostondriver has joined #openvswitch12:44
*** mmirecki has joined #openvswitch13:00
*** acidfoo_ has joined #openvswitch13:05
*** acidfu_ has quit IRC13:07
*** ktraynor has quit IRC13:08
*** ktraynor has joined #openvswitch13:12
*** mmirecki has quit IRC13:34
*** FH_thecat has joined #openvswitch13:34
*** darkemon has quit IRC13:43
*** troulouliou_div2 has quit IRC13:56
*** mmirecki has joined #openvswitch13:57
*** troulouliou_div2 has joined #openvswitch14:09
*** darkemon has joined #openvswitch14:11
*** armax has joined #openvswitch14:21
*** timothy has quit IRC15:02
*** timothy has joined #openvswitch15:16
*** mmirecki has quit IRC15:33
*** darkemon1 has joined #openvswitch15:38
*** darkemon has quit IRC15:38
*** darkemon1 is now known as darkemon15:38
*** troulouliou_div2 has quit IRC16:29
*** troulouliou_div2 has joined #openvswitch16:40
*** timothy has quit IRC16:47
*** donhw has quit IRC16:52
*** troulouliou_div2 has quit IRC16:55
*** donhw has joined #openvswitch16:57
*** acidfoo_ has quit IRC16:57
*** ryzhyk has joined #openvswitch17:05
*** troulouliou_div2 has joined #openvswitch17:07
zhouhanHello17:19
flaviofo/17:20
ryzhykhi17:20
pandahello17:20
_lore_hi all17:20
* flaviof waves at numans mmichelson 17:22
imaximetsHi. FYI, mmichelson, dceara and numans are not here today.  Someone needs to take the lead on this meeting.17:22
flaviof#startmeeting ovn-community-development-discussion17:23
openstackMeeting started Thu May 21 17:23:12 2020 UTC and is due to finish in 60 minutes.  The chair is flaviof. Information about MeetBot at http://wiki.debian.org/MeetBot.17:23
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:23
openstackThe meeting name has been set to 'ovn_community_development_discussion'17:23
flaviofwell then, I know that much. ;)17:23
zhouhanthx flaviof17:23
flaviofanyone want to go first?17:23
zhouhanI can go first17:23
zhouhanI sent a fix for the dp_hash issue. imaximets: could you take a look: #link https://patchwork.ozlabs.org/project/openvswitch/patch/1589527067-91901-1-git-send-email-hzhou@ovn.org/17:24
zhouhanI did some reviews, most for numans's I-P17:25
zhouhanI had a question on _lore_'s patch for the SRC_IP_POLICY17:25
_lore_zhouhan: sure17:25
zhouhanby GW router, do you mean the non-distributed GW router, or a distributed router with a distributed gateway port?17:26
_lore_'distributed router with a distributed gateway port'17:26
_lore_gw router port on a given chassis17:27
zhouhan_lore_: ok, then the ARP is sent from which component to that router?17:27
_lore_yes17:27
*** aginwala has joined #openvswitch17:27
_lore_for non-FIP case17:27
_lore_this is what we want to avoid17:28
_lore_for this reason we need to chage reg1/eth.src after table=9,10,1117:28
zhouhanSorry, my question was: from which component is the ARP sent to the distributed router with DGP?17:28
_lore_zhouhan: I did not get you17:29
zhouhan_lore_: I am still not clear about the scenario, before going to the solution.17:29
zhouhan_lore_: Let's discuss in the email offline :)17:29
zhouhanThat's my update17:29
_lore_zhouhan: sure, but the scenario is this one:17:30
_lore_the chassis where we have the FIP has a direct connection to the underlay network using a localnet port17:30
_lore_so we want to send the ARP out to that port17:31
_lore_agree?17:31
zhouhanwell, depends on the logical topology. I am not sure what's the source and destination, and the logical components connecting them.17:32
_lore_local chassis has a direct connection to the ToR17:32
_lore_switch17:32
_lore_OpenStack want the possibility to send traffic directly avoid going through the tunnel since the chassis has a direct connection to the external world17:33
zhouhan_lore_: yes, if there is just a single localnet logical switch connecting a VIF and the TOR, then it should work, without worrying about logical routers and distributed gateway ports. But I guess your scenario is more complex than that.17:33
_lore_on the local chassis you mean?17:34
zhouhan_lore_: I wasn't sure if it is for the typical k8s scenario or openstack. If it is for openstack, maybe I have some clue now.17:34
_lore_I think k8s does not use FIP so far, just OpenStack17:35
*** acidfoo_ has joined #openvswitch17:35
_lore_I guess17:35
_lore_not sure17:35
zhouhan_lore_: let's see if some else wants to report. After that we can continue. Or discuss offline.17:36
_lore_the goal is: if you have a FIP associated to a given logical switch port you want to send traffic directly and not going through the tunnel to the gw router17:36
_lore_ack17:36
* _lore_ is on mute17:37
zhouhanso, anyone else?17:37
_lore_it seems not :)17:38
zhouhanok, let's continue17:38
pandaI can go last17:38
zhouhanok, panda please go ahead17:38
pandazhouhan: thanks.17:38
pandamine is not an update, but a presentation, I'd like to start contributing to the project. I already studied the architecture and I'm now studying the code17:38
pandaI plan to propose a patch on the documentation with my the list of task that helped me to start. But I'll have some questions for the mailing list.17:39
zhouhanpanda: welcome!17:39
pandaIn the meantime I'm looking for low hanging fruit bugs or tasks to give a direction to my studies. If you have anything to propose I'd like to hear17:39
panda_lore_ already helped me to bootstrap, and I have a long term tasks from him.17:39
pandazhouhan: thanks :)17:39
flaviofwelcome panda!17:40
pandaflaviof: thanks!17:40
flaviofI can go in next, really quick.17:40
flaviofI have not been doing a lot on core OVN, but have been implementing a cool functionality in Openstack that is based on OVN.17:40
flaviofIt is called port forwarding. For folks who don't know, it uses OVN load balancers to carve out a single FIP into multiple internal VM based on proto+port.17:41
flaviofHave POC running great and now moving onto integration tests.17:41
flaviof#link https://review.opendev.org/#/c/723863/23/doc/source/ovn/port_forwarding.rst Port forwarding functionality from ML2/OVN17:41
flaviofIf any of you have interest on that or any other OVN related integration matters with Openstack, please do not be shy to say hi!17:41
flaviofIncluding you, panda ! ;)17:41
flaviofThat is all from me.17:41
zhouhanflaviof: very cool!17:42
flaviofzhouhan: thanks. It mostly works because of people like you, so thanks to _you_!17:42
pandaflaviof: interesting :)17:43
flaviofanyone got something he/she want to say here?17:44
_lore_zhouhan: do you think we can proceed?17:45
zhouhan_lore_: sure17:45
_lore_:)17:46
* panda will reserve the questions for the mailing list.17:46
zhouhan_lore_: firstly, how does the normal IP traffic work?17:46
_lore_non-FIP?17:46
zhouhan_lore_: in the email you said IP traffic works as expect but just ARP doesn;t work17:47
_lore_e.g. for external world? going through the gw router17:47
_lore_ah ok17:47
_lore_normal FIP traffic is going through the localnet port17:47
_lore_like IP using FIP as src IP17:48
zhouhanlogically, it is going through the LR, and SNAT is done by the LR, right?17:48
_lore_yes, locally17:48
_lore_s/locally/logically17:49
zhouhanwhen the VM send the packets to external, the nexthop is the LR, and LR's next hop is the external GW (on the TOR)17:49
_lore_yes17:50
zhouhannow the ARP is for the LR's IP, why should it be sent out through localnet?17:50
zhouhanor do you mean the ARP from LR to the TOR's IP?17:51
*** anilvenkata has quit IRC17:51
_lore_nope, the ARP has src IP the FIP17:51
_lore_not the LR external IP17:52
zhouhanSo you mean the ARP from LR to the TOR, right?17:52
_lore_yes17:53
_lore_let' say your VM is pinging 1.1.1.117:54
_lore_the external network from logical router to the external network is 172.16.0.0/24 and you have associated the FIP 172.16.0.100 to the VM17:55
_lore_you want system sends an ARP req to the gw of the network using 172.16.0.100 as src IP and dnat_snat external mac as src mac17:56
_lore_sending the ARP using the localnet port on the chassis17:56
_lore_the scenario is a little bit tricky, I agree :)17:57
zhouhanIn the logical pipeline, the IP packet from VM should first hit the LR, which then triggers the ARP to the external GW IP. Now which packet is observed on the tunnel?17:57
flaviof_lore_: if you don't mind also add the next hop (TOR's) mac address in your example.17:57
_lore_flaviof: sure17:57
_lore_zhouhan: this is the point17:58
_lore_no packet on the tunnel17:58
_lore_the local logical router pipeline magaes the arp17:58
_lore_whitout sending the packet to gw router17:58
_lore_flaviof: let's the next hop is 172.16.0.25417:59
zhouhan_lore_: but you said the problem is some packets were seen on the tunnel, and the patch is to avoid that, right? My question is, which packet was on the tunnel? The IP packet? Or just ARP packets?17:59
_lore_zhouhan: before the commit that introduce the issue you reported17:59
_lore_with the patch I send this week no packets are sent to the tunnel18:00
zhouhan_lore_: yes I am talking about the original patch, not the later one.18:00
_lore_zhouhan: even with the origianl one no packets are sent to the tunnel18:00
zhouhan_lore_: still trying to understand the original problem :)18:00
_lore_you are right, I have not been so clear :)18:00
_lore_the orignal case is:18:01
_lore_in the scenario I described before the packet for 172.16.0.254 is sent to the gw router and the gw router is sending the ARP18:01
_lore_right?18:01
_lore_then when the ARP reply arrives the packets start flowing18:03
_lore_this is the behaviour before the offending commit18:03
zhouhanok, do you mean when ARP reply arrives to the GW node, the IP packets start being sent through local chassis directly?18:04
_lore_correct18:05
_lore_this is the original FIP behaviour18:05
_lore_with the offending commit or the last patch the ARP is sent by the local node and not by the GW18:06
zhouhanSo before the ARP is sent, which packet is sent through the tunnel to the GW node? The IP packet or the ARP packet?18:06
_lore_the first IP packet that triggers the ARP18:06
zhouhanok, that's clear now. Thanks18:07
_lore_just this packet18:07
zhouhanAnd all these nodes are on same L2 (e.g. under the TOR), right?18:07
_lore_yes18:07
_lore_the issue that when the ARP arrives this first IP packet is re-inhected but on the GW18:07
_lore_while the second is sent by the local device so the ToR is confused18:08
_lore_are we on the same page now?18:08
zhouhanYes, I think so.18:08
_lore_ok, cool18:08
flaviof+1 ;)18:08
_lore_sorry to be not so clear18:08
zhouhanSo the actual problem is the reinjection that confuses TOR18:08
_lore_anyway18:09
_lore_yes18:09
zhouhanIf there is no reinjection (sacrifice the first packet), then there is no real problem, but can be optimized to avoid the tunnel for the first packet.18:09
_lore_yes, I think so18:10
_lore_but I am not 100% sure18:10
zhouhanI see. Let me revisit your patch. Thanks for the explain!18:10
_lore_sure, thank to you for be so patient :)18:10
_lore_another possible solution could be add nat info to port_binding table18:11
_lore_but the issue is we have no access to the db in pinctrl thread18:11
_lore_so we came up adding a new stable to logical router pipeline in order to overwrite reg1/eth.src just for FIP18:12
_lore_doing so we can manage even ARP and first IP packet locally18:13
_lore_last this week I added the possibility to attach strace or perf to ovn-scale-test18:14
zhouhan"doing so" you mean the current patch, right?18:14
_lore_zhouhan: yes18:14
zhouhan_lore_: cool. I will take look. Thanks!18:15
_lore_zhouhan: basically in the last patch I reverted offending commit and added this new stage18:15
_lore_I think now we are all the same page :)18:16
zhouhan_lore_: yes, I think so.18:16
zhouhanflaviof: are we still in the meeting?18:17
flaviofyes. but we can end if you think we should18:17
flaviof_lore_: that is the table called S_ROUTER_IN_IP_SRC_POLICY, right?18:17
_lore_flaviof: right18:17
_lore_maybe the name is not the best one :)18:17
flaviofack. just wanted to mentioning it here to have a quick way to search for it. This discussion is an integral part of it. ;)18:18
flaviofgood discussion. Thank you both for doing it here. Anything else to talk about or shall we call it a meeting?18:18
zhouhanflaviof: I think maybe we are done18:19
_lore_I guess si18:19
_lore_*so18:19
*** aginwala has quit IRC18:19
flaviofyeah. si ! ;)18:19
zhouhanbye everyone :)18:20
flaviofbye all18:20
_lore_si == yes in Italian :)18:20
flaviof<318:20
flaviof#endmeeting18:20
openstackMeeting ended Thu May 21 18:20:19 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:20
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-21-17.23.html18:20
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-21-17.23.txt18:20
openstackLog:            http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-21-17.23.log.html18:20
_lore_by all and thx18:20
_lore_*bye18:20
*** ryzhyk has quit IRC18:37
*** donhw has quit IRC18:50
*** ihrachys has quit IRC18:53
*** donhw has joined #openvswitch18:55
*** ihrachys has joined #openvswitch19:01
*** zhouhan_ has joined #openvswitch19:01
*** zhouhan has quit IRC19:05
*** mmirecki has joined #openvswitch19:05
*** donhw has quit IRC19:41
*** donhw has joined #openvswitch19:46
*** mmirecki has quit IRC19:58
*** dcbw has joined #openvswitch20:05
*** zhouhan_ has quit IRC20:35
*** mmirecki has joined #openvswitch20:36
*** mmirecki has quit IRC20:43
*** mmirecki has joined #openvswitch20:43
*** mmirecki has quit IRC20:51
*** zhouhan_ has joined #openvswitch20:53
*** troulouliou_div2 has quit IRC21:02
*** troulouliou_div2 has joined #openvswitch21:14
*** zhouhan_ has quit IRC21:29
*** zhouhan has joined #openvswitch21:29
*** zhouhan has quit IRC21:30
*** zhouhan has joined #openvswitch21:30
*** slaweq has quit IRC22:02
*** rcernin has quit IRC22:23
*** rcernin has joined #openvswitch22:24
*** itandops has joined #openvswitch22:24
*** bostondriver has quit IRC22:27
*** zhouhan_ has joined #openvswitch22:39
*** zhouhan has quit IRC22:43
*** itandops has quit IRC22:52
*** itandops has joined #openvswitch22:53
*** donhw has quit IRC23:10
*** donhw has joined #openvswitch23:10
*** lynxis has quit IRC23:57

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!