Re: [ovs-dev] HA: SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
On Wed, Feb 13, 2019 at 7:25 AM Rostyslav Fridman < rostyslav_frid...@epam.com> wrote: > Okay, I have managed to make it work, however I do not know if this is how > it is supposed to work. > > > > Basically, I reduced OVN scheme from > > container – internal switch – (container subnet gateway) internal router – > interconnect switch – external router (NAT IP address) – external switch > > to > > container – internal switch – (container subnet gateway) external router > (NAT IP address) – external switch > > The difference being that local subnet for NAT resides on the same external > router as an external NAT IP address. In this case both ICMP and TCP/UDP > NAT translations work. It did not work for TCP when local subnet and > external IP resided on different OVN routers. > Assuming the rules requested are not L4 protocol specific, TCP having different flow generation than ICMP does not look right to me. afaik container – internal switch – (container subnet gateway) internal router – interconnect switch – external router (NAT IP address) – external switch is supported However, I think it is probably better for someone actively working on this aspect of OVN at the moment to answer this; I added a couple of people to the thread. > > > This behavior seems strange, am I missing something here? > > > > *От:* Darrell Ball [mailto:dlu...@gmail.com] > *Отправлено:* 13 февраля 2019 г. 17:11 > *Кому:* Rostyslav Fridman > *Копия:* Darrell Ball ; Ben Pfaff ; > ovs-dev@openvswitch.org; Vasyl Samoilov > *Тема:* Re: [ovs-dev] HA: SNAT on OVN logical_router in userspace works > for ICMP but not TCP or UDP > > > > > > > > On Wed, Feb 13, 2019 at 5:16 AM Rostyslav Fridman via dev < > ovs-dev@openvswitch.org> wrote: > > Hi Darrel, > > I've reduced the amount of traffic. Here is dump-flows for ICMP traffic: > ovs-appctl dpif/dump-flows br-int > ct_state(-new+est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:6, bytes:588, used:0.994s, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), > packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) > recirc_id(0x1),dp_hash(0x9eeb76ae/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), > packets:7, bytes:714, used:0.994s, actions:4 > ct_state(+new-est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:0, bytes:0, used:never, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > > ct_state(+new-est-rel-inv+trk),recirc_id(0x303a),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), > packets:7, bytes:686, used:0.994s, > actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src= > 10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62) > ),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0x303b) > > ct_state(+new-est-rel-inv+trk),recirc_id(0x3039),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:7, bytes:686, used:0.994s, > actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src= > 10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63) > ),ct(zone=2,nat),recirc(0x303a) > > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:7, bytes:686, used:0.994s, > actions:ct_clear,ct(zone=5,nat),recirc(0x3039) > > > Here is dump-flows for TCP traffic: > ovs-appctl dpif/dump-flows br-int > ct_state(-new-est-rel+inv+trk),recirc_id(0x3038),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:2, bytes:148, used:3.064s, flags:S, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), > packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) > recirc_id(0x1),dp_hash(0x5be46ea1/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), > packets:2,
Re: [ovs-dev] HA: SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
On Wed, Feb 13, 2019 at 5:16 AM Rostyslav Fridman via dev < ovs-dev@openvswitch.org> wrote: > Hi Darrel, > > I've reduced the amount of traffic. Here is dump-flows for ICMP traffic: > ovs-appctl dpif/dump-flows br-int > ct_state(-new+est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:6, bytes:588, used:0.994s, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), > packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) > recirc_id(0x1),dp_hash(0x9eeb76ae/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), > packets:7, bytes:714, used:0.994s, actions:4 > ct_state(+new-est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:0, bytes:0, used:never, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > > ct_state(+new-est-rel-inv+trk),recirc_id(0x303a),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), > packets:7, bytes:686, used:0.994s, > actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src= > 10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62) > ),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0x303b) > > ct_state(+new-est-rel-inv+trk),recirc_id(0x3039),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:7, bytes:686, used:0.994s, > actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src= > 10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63) > ),ct(zone=2,nat),recirc(0x303a) > > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:7, bytes:686, used:0.994s, > actions:ct_clear,ct(zone=5,nat),recirc(0x3039) > > > Here is dump-flows for TCP traffic: > ovs-appctl dpif/dump-flows br-int > ct_state(-new-est-rel+inv+trk),recirc_id(0x3038),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), > packets:2, bytes:148, used:3.064s, flags:S, > actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), > packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) > recirc_id(0x1),dp_hash(0x5be46ea1/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), > packets:2, bytes:156, used:3.064s, flags:S, actions:5 > > ct_state(-new-est-rel+inv+trk),recirc_id(0x3037),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), > packets:2, bytes:148, used:3.064s, flags:S, > actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src= > 10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62) > ),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0x3038) > > ct_state(-new-est-rel+inv+trk),recirc_id(0x3036),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:2, bytes:148, used:3.064s, flags:S, > actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src= > 10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63) > ),ct(zone=2,nat),recirc(0x3037) > > ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src= > 10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), > packets:2, bytes:148, used:3.064s, flags:S, > actions:ct_clear,ct(zone=5,nat),recirc(0x3036) > This flow looks particularly wrong; it would appear the flow generation has a problem. ct_state(-new-est-rel+inv+trk),recirc_id(0x3037),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src= 10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), packets:2,
[ovs-dev] HA: SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
Hi Darrel, I've reduced the amount of traffic. Here is dump-flows for ICMP traffic: ovs-appctl dpif/dump-flows br-int ct_state(-new+est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), packets:6, bytes:588, used:0.994s, actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) recirc_id(0x1),dp_hash(0x9eeb76ae/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), packets:7, bytes:714, used:0.994s, actions:4 ct_state(+new-est-rel-inv+trk),recirc_id(0x303b),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) ct_state(+new-est-rel-inv+trk),recirc_id(0x303a),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src=10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), packets:7, bytes:686, used:0.994s, actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src=10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62)),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0x303b) ct_state(+new-est-rel-inv+trk),recirc_id(0x3039),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:7, bytes:686, used:0.994s, actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src=10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63)),ct(zone=2,nat),recirc(0x303a) ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:7, bytes:686, used:0.994s, actions:ct_clear,ct(zone=5,nat),recirc(0x3039) Here is dump-flows for TCP traffic: ovs-appctl dpif/dump-flows br-int ct_state(-new-est-rel+inv+trk),recirc_id(0x3038),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:148, used:3.064s, flags:S, actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.3.253,op=1/0xff,sha=0a:00:00:00:00:03,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:userspace(pid=0,slow_path(action)) recirc_id(0x1),dp_hash(0x5be46ea1/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), packets:2, bytes:156, used:3.064s, flags:S, actions:5 ct_state(-new-est-rel+inv+trk),recirc_id(0x3037),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src=10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), packets:2, bytes:148, used:3.064s, flags:S, actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src=10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62)),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0x3038) ct_state(-new-est-rel+inv+trk),recirc_id(0x3036),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:2, bytes:148, used:3.064s, flags:S, actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src=10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63)),ct(zone=2,nat),recirc(0x3037) ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:2, bytes:148, used:3.064s, flags:S, actions:ct_clear,ct(zone=5,nat),recirc(0x3036) As can be seen from output no conntrack entry is created for new state. -Исходное сообщение- От: Darrell Ball [mailto:db...@vmware.com] Отправлено: 9 февраля 2019 г. 0:29 Кому: Rostyslav Fridman ; Ben Pfaff Копия: ovs-dev@openvswitch.org; Vasyl Samoilov Тема: Re: [ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP If TCP packets do not go thru conntrack, then that would explain why the TCP traffic is not natted (since you don't have any other rules that could do that) You need to
[ovs-dev] HA: SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
I have sent TCP traffic. It does not show up in dump-conntrack for some reason. However, I see it on the external server. -Исходное сообщение- От: Darrell Ball [mailto:db...@vmware.com] Отправлено: 8 февраля 2019 г. 23:29 Кому: Rostyslav Fridman ; Ben Pfaff Копия: ovs-dev@openvswitch.org; Vasyl Samoilov Тема: Re: [ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP I thought the problem was with TCP/UDP traffic ? Did you send TCP traffic for this test ?; if not, can you run the test with TCP ? On 2/8/19, 12:53 PM, "Rostyslav Fridman" wrote: # ovs-appctl dpif/dump-flows br-int recirc_id(0x1),dp_hash(0x9eeb76ae/0xff),in_port(8),packet_type(ns=0,id=0),eth_type(0x8100),vlan(vid=111,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)), packets:20, bytes:2040, used:0.942s, actions:4 ct_state(-new-est-rel-inv-trk),recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03/01:00:00:00:00:00,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:25, bytes:2354, used:0.942s, flags:S, actions:ct_clear,ct(zone=5,nat),recirc(0xb1) ct_state(+new-est-rel-inv+trk),recirc_id(0xb2),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85),eth_type(0x0800),ipv4(src=10.0.0.2/255.0.0.0,dst=216.58.215.110/128.0.0.0,ttl=63,frag=no), packets:20, bytes:1960, used:0.942s, actions:set(eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94)),set(ipv4(src=10.0.0.0/255.0.0.0,dst=128.0.0.0/128.0.0.0,ttl=62)),ct(commit,zone=3,nat(src=10.250.111.40)),recirc(0xb3) ct_state(+new-est-rel-inv+trk),recirc_id(0xb1),in_port(8),packet_type(ns=0,id=0),eth(src=0a:00:00:00:00:03,dst=00:00:00:6b:83:b1),eth_type(0x0800),ipv4(src=10.0.0.2/255.255.254.0,dst=216.58.215.110/224.0.0.0,ttl=64,frag=no), packets:20, bytes:1960, used:0.942s, actions:ct_clear,ct_clear,set(eth(src=00:00:00:73:a8:30,dst=00:00:00:da:6b:85)),set(ipv4(src=10.0.0.0/255.255.254.0,dst=192.0.0.0/224.0.0.0,ttl=63)),ct(zone=2,nat),recirc(0xb2) ct_state(-new+est-rel-inv+trk),recirc_id(0xb3),in_port(8),packet_type(ns=0,id=0),eth(src=00:00:00:61:f0:c0,dst=00:25:90:e7:23:94),eth_type(0x0800),ipv4(frag=no), packets:19, bytes:1862, used:0.942s, actions:ct_clear,push_vlan(vid=111,pcp=0),hash(l4(0)),recirc(0x1) == # ovs-appctl dpctl/dump-conntrack icmp,orig=(src=10.0.0.2,dst=216.58.215.110,id=246,type=8,code=0),reply=(src=216.58.215.110,dst=10.250.111.40,id=246,type=0,code=0),zone=3 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] HA: SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
> How about dumping flows and conntrack entries and checking stats at various > points ? > ovs-ofctl dump-flows > ovs-appctl dpif/dump-flows > ovs-appctl dpctl/dump-conntrack Please find flow dumps at the following link: https://pastebin.com/raw/epKAhTKm > How are you sending said UDP/TCP packets ? Curl and telnet requests from the container. -- Best regards, Rostyslav Fridman -Исходное сообщение- От: Darrell Ball [mailto:db...@vmware.com] Отправлено: 8 февраля 2019 г. 20:59 Кому: Ben Pfaff ; Rostyslav Fridman Копия: ovs-dev@openvswitch.org; Vasyl Samoilov Тема: Re: [ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP We have advanced system tests for userspace datapath to test OVN, including tcp packets. system-ovn 124: ovn -- 2 LRs connected via LS, gateway router, SNAT and DNAT ok 125: ovn -- 2 LRs connected via LS, gateway router, easy SNAT ok 126: ovn -- multiple gateway routers, SNAT and DNAT ok 127: ovn -- load-balancing ok 128: ovn -- load-balancing - same subnet.ok 129: ovn -- load balancing in gateway router ok 130: ovn -- multiple gateway routers, load-balancing ok 131: ovn -- load balancing in router with gateway router port ok 132: ovn -- DNAT and SNAT on distributed router - N/S ok 133: ovn -- DNAT and SNAT on distributed router - E/W ok Let us define the problem first since the context is mostly undefined How about dumping flows and conntrack entries and checking stats at various points ? ovs-ofctl dump-flows ovs-appctl dpif/dump-flows ovs-appctl dpctl/dump-conntrack How are you sending said UDP/TCP packets ? On 2/8/19, 10:15 AM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" wrote: Darrell, is this something you can help with? On Fri, Feb 08, 2019 at 02:18:53PM +, Rostyslav Fridman via dev wrote: > I've encountered the issue that SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP. I am seeing this behavior on version 2.10.1 as well as on top of the git tree. > > I try to access internet (216.58.215.110) from container (10.0.0.2). On the external-router I have SNAT configured. On the external server I see that container address is translated for ICMP request, but not for TCP. > container:/# ping 216.58.215.110 > PING 216.58.215.110 (216.58.215.110) 56(84) bytes of data. > 64 bytes from 216.58.215.110: icmp_seq=1 ttl=53 time=140 ms > ^C > --- 216.58.215.110 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 140.663/140.663/140.663/0.000 ms > container:/# curl 216.58.215.110 > ^C > --- > external-server:~# tcpdump -i vlan111 host 216.58.215.110 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vlan111, link-type EN10MB (Ethernet), capture size 262144 bytes > 07:53:22.393289 IP 10.250.111.40 > waw02s17-in-f14.1e100.net: ICMP echo request, id 218, seq 1, length 64 > 07:53:22.533574 IP waw02s17-in-f14.1e100.net > 10.250.111.40: ICMP echo reply, id 218, seq 1, length 64 > 07:53:24.830595 IP 10.0.0.2.58050 > waw02s17-in-f14.1e100.net.http: Flags [S], seq 219699121, win 29200, options [mss 1460,sackOK,TS val 2742820693 ecr 0,nop,wscale 7], length 0 > > In the bridge flows I see that NAT should be performed since flow packet count is increasing. > ovs-appctl bridge/dump-flows br-int > ... > table_id=41, duration=5135s, n_packets=28, n_bytes=2408, priority=9,ip,metadata=0x1,nw_src=10.0.0.0/8,actions=ct(commit,table=42,zone=NXM_NX_REG12[0..15],nat(src=10.250.111.40)) > > ovn-trace also confirms that it should be working. > > I have the following scheme: > OVS: trunked bonded port --- netdev bridge (br-ext) --- patch --- netdev bridge (br-int) > OVN: container --- logical_switch (internal-switch) --- logical_router (internal-router) --- logical_switch (interconnect) --- logical_router (external-router) --- logical_switch (external-switch with localnet port to br-ext) > > OVN configuration: > switch d0f22f65-214f-422e-a5ba-68b7ef66581b (interconnect) > port interconnect_to_internal-router > type: router > addresses: ["00:00:00:73:a8:30 100.64.1.2/24"] > router-port: internal-router_to_interconnect > port interconnect_to_external-router > type: router > addresses: ["00:00:00:da:6b:85 100.64.1.1/24"] > router-port: external-router_to_interconnect > switch bcdc365a-7c2c-4c32-9a51-8107864e879a (internal-switch) > port internal-switch_to_internal-router > type: router > addresses: ["00:00:00:6b:83:b1 10.0.3.253/22"] > router-port: internal-router_to_internal-switch > port default_aaa_eth0 > addresses: ["0a:00:00:00:00:03 10.0.0.2"] > switch
