Saw the same problem again. Recreate network, attach to router and launch VM, problem is gone. Probably some glitch happened during the early deployment. Any hints how to look into it?
Thanks! Tony > -----Original Message----- > From: discuss <ovs-discuss-boun...@openvswitch.org> On Behalf Of Tony > Liu > Sent: Friday, October 16, 2020 6:48 PM > To: ovs-discuss <ovs-discuss@openvswitch.org> > Subject: [ovs-discuss] [ovn] no tunnel from GW to compute > > Hi, > > I am seeing an interesting issue today. > When ping a FIP from external, request arrives on GW, but no tunnel from > GW to compute. > When ping from VM to external, egress works fine, request goes through > tunnel from compute to GW, then to external. > Reply arrives at GW, no tunnel from GW back to compute. > > I checked DP flows on GW and compared working vs. non-working. > > non-working, no tunnel > ======================== > recirc_id(0),in_port(3),ct_state(-new-est-rel-rpl-inv- > trk),ct_label(0/0x1),eth(src=e8:1c:ba:9f:b7:c6,dst=fa:16:3e:67:5c:d9),et > h_type(0x0800),ipv4(src=128.0.0.0/192.0.0.0,dst=10.59.53.18,proto=1,ttl= > 63,frag=no),icmp(type=8/0xf8), packets:8, bytes:784, used:0.992s, > actions:ct_clear,ct(zone=20,nat),recirc(0x6e1) > > recirc_id(0x6e1),in_port(3),ct_state(+new-est-rel-rpl- > inv+trk),ct_label(0/0x1),eth(),eth_type(0x0800),ipv4(dst=10.59.53.18,fra > g=no), packets:29, bytes:2842, used:0.992s, > actions:ct(commit,zone=21,nat(dst=192.168.1.8)),recirc(0x6e2) > > recirc_id(0x6e2),in_port(3),ct_state(+new-est-rel-rpl- > inv+trk),ct_label(0/0x1),eth(src=e8:1c:ba:9f:b7:c6,dst=fa:16:3e:67:5c:d9 > ),eth_type(0x0800),ipv4(dst=192.168.1.8,proto=1,ttl=63,frag=no),icmp(typ > e=8/0xf8), packets:8, bytes:784, used:0.992s, actions:ct_clear > ======================== > > working, with tunnel > ======================== > recirc_id(0),in_port(3),ct_state(-new-est-rel-rpl-inv- > trk),ct_label(0/0x1),eth(src=e8:1c:ba:9f:b7:c6,dst=fa:16:3e:67:5c:d9),et > h_type(0x0800),ipv4(src=128.0.0.0/192.0.0.0,dst=10.59.53.14,proto=1,ttl= > 63,frag=no),icmp(type=8/0xf8), packets:2, bytes:196, used:3.427s, > actions:ct_clear,ct(zone=20,nat),recirc(0x716) > > recirc_id(0x716),in_port(3),ct_state(+new-est-rel-rpl- > inv+trk),ct_label(0/0x1),eth(),eth_type(0x0800),ipv4(dst=10.59.53.14,fra > g=no), packets:2, bytes:196, used:3.428s, > actions:ct(commit,zone=21,nat(dst=192.168.1.5)),recirc(0x717) > > recirc_id(0x717),in_port(3),ct_state(+new-est-rel-rpl- > inv+trk),ct_label(0/0x1),eth(src=e8:1c:ba:9f:b7:c6,dst=fa:16:3e:67:5c:d9 > ),eth_type(0x0800),ipv4(dst=192.168.1.5,proto=1,tos=0/0x3,ttl=63,frag=no > ),icmp(type=8/0xf8), packets:0, bytes:0, used:never, > actions:ct_clear,set(tunnel(tun_id=0x139,dst=10.6.30.63,ttl=64,tp_dst=60 > 81,geneve({class=0x102,type=0x80,len=4,0x2000a}),flags(df|csum|key))),se > t(eth(src=fa:16:3e:aa:2a:5d,dst=fa:16:3e:a6:79:6f)),set(ipv4(ttl=62)),1 > ======================== > > The difference is on the third flow (0x6e2 and 0x717). > In non-working case, "set(tunnel..." is missing. > Note, the working VM and non-working VM are on the same compute. > I want to trace the root cause. Any hints or comments where and how I > should look into it? > > > Thanks! > Tony > > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss