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 find out where the TCP packets are going. Try making the rules L4 protocol specific (i.e. look for TCP and also do something different for ICMP) Maybe add some other debug rules to trace the TCP packets otherwise On 2/8/19, 1:47 PM, "Rostyslav Fridman" wrote: 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
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
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] Donation
Free Will Donation, Respond to Partake. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
Could you dump the datapath flows and conntrack entries while your test is running (i.e. sending packets) ? == # ovs-appctl dpif/dump-flows br-int == # ovs-appctl dpctl/dump-conntrack Also besides arp, could you limit traffic thru. the SUT to the test traffic, like the curl triggered packets ? On 2/8/19, 12:04 PM, "Rostyslav Fridman" wrote: > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FepKAhTKmdata=02%7C01%7Cdball%40vmware.com%7Cd20b9c1d51e44df4519808d68e00971f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636852530531092223sdata=RAl%2Fe3ktUSwxqCIY5BwGL%2Fdylgp59f%2B3vheX3wRr%2FUM%3Dreserved=0 > 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) ---
[ovs-dev] Cómo implementarlo de manera eficiente
Cursos esenciales - Webinar Interactivo – Miércoles 27 de Febrero Balanced Scorecard El Balanced Scorecard ayuda a lograr un balance integrado del avance, crecimiento, productividad y competitividad de una organización y que proporciona la información necesaria para definir la dirección que deberá seguir la compañía en el futuro. Conoceremos la metodología en la que se fundamenta en Balanced Scorecard y su implementación en una organización. Ojetivos Específicos: • El participante identificará la importancia de integrar el Balanced Scorecard en su organización. • El participante revisará los conceptos clave del Balanced Scorecard que facilitarán su comprensión. • El participante revisará los pasos a seguir en la implementación del Balanced Scorecard. Para mayor información, responder sobre este correo con la palabra Balanced + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: Llamanos al (045) 55 1554 6630 www.Innovalearn.mx ___ 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
Re: [ovs-dev] [PATCH v4 1/1] acinclude: Also use LIBS from dpkg pkg-config
Christian Ehrhardt writes: > DPDK 18.11 builds using the more modern meson build system no more > provide the -ldpdk linker script. Instead it is expected to use > pkgconfig for linker options as well. > > This change will set DPDK_LIB from pkg-config (if pkg-config was > available) and since that already carries the whole-archive flags > around the PMDs skips the further wrapping in more whole-archive > if that is already part of DPDK_LIB. > > To work reliable in all environments this needs pkg-config 0.29.1. > We want to be able to use PKG_CHECK_MODULES_STATIC which > is not yet available in 0.24. Therefore update pkg.m4 > to pkg-config 0.29.1. > > This should be backport-safe as these macro files are all versioned. > autoconf is smart enough to check the version if you have it locally, > and if the system's is higher, it will use that one instead. > > Finally make configure.ac use the locally provided pkg.m4 before > calling the PKG_PROG_PKG_CONFIG macro. > > Signed-off-by: Christian Ehrhardt > --- As before, Acked-by: Aaron Conole ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 3feba85f-4c6f-4550-9435-7f27837c1fd8 (external-switch) > port vlan111-mgmt > addresses: ["a2:dc:3c:76:8f:27"] > port vlan111 > type: localnet > tag: 111 > addresses: ["unknown"] > port external-switch_to_external-router > type: router > addresses: ["00:00:00:61:f0:c0 10.250.111.40/24"] > router-port: external-router_to_external-switch > router f97f9421-c727-488d-8575-bfaf7a7bde6b (vlan111-80973513-f2fe-48cb-904a-b205fb0bcc6f) > port external-router_to_interconnect > mac: "00:00:00:da:6b:85" > networks: ["100.64.1.1/24"] >
Re: [ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
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 3feba85f-4c6f-4550-9435-7f27837c1fd8 (external-switch)
> port vlan111-mgmt
> addresses: ["a2:dc:3c:76:8f:27"]
> port vlan111
> type: localnet
> tag: 111
> addresses: ["unknown"]
> port external-switch_to_external-router
> type: router
> addresses: ["00:00:00:61:f0:c0 10.250.111.40/24"]
> router-port: external-router_to_external-switch
> router f97f9421-c727-488d-8575-bfaf7a7bde6b
> (vlan111-80973513-f2fe-48cb-904a-b205fb0bcc6f)
> port external-router_to_interconnect
> mac: "00:00:00:da:6b:85"
> networks: ["100.64.1.1/24"]
> port external-router_to_external-switch
> mac: "00:00:00:61:f0:c0"
> networks: ["10.250.111.40/24"]
> nat 486f81b0-491f-4c90-9ddd-04ea27e70ac5
> external ip: "10.250.111.40"
> logical ip: "10.0.0.0/8"
> type: "snat"
> router 5ca8fc47-1860-43c9-a0ee-a285fd877db5
> (overlay-vlan111-80973513-f2fe-48cb-904a-b205fb0bcc6f)
> port internal-router_to_interconnect
> mac: "00:00:00:73:a8:30"
> networks: ["100.64.1.2/24"]
> port internal-router_to_internal-switch
> mac: "00:00:00:6b:83:b1"
> networks: ["10.0.3.253/22"]
>
> OVS configuration:
> Bridge br-int
> Port patch-br-int-br-ext
> Interface patch-br-int-br-ext
> type: patch
> options: {peer=patch-br-ext-br-int}
> Port "patch-br-int-to-vlan111 "
> Interface "patch-br-int-to-vlan111 "
> type: patch
> options: {peer="patch-vlan111-to-br-int"}
> Port "vlan111-mgmt"
> Interface "vlan111-mgmt"
> type: internal
> Port br-int
> Interface br-int
> type: internal
> Port "veth51a477d8"
> Interface "veth51a477d8"
> Bridge br-ext
> Port "patch-vlan111-to-br-int"
>
[ovs-dev] [PATCH 7/8] travis: Use parallel jobs for DPDK and sparse builds.
This allows to save a few minutes. Signed-off-by: Ilya Maximets --- .travis/linux-build.sh | 2 +- .travis/linux-prepare.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh index b1b2c831b..0cf5da6af 100755 --- a/.travis/linux-build.sh +++ b/.travis/linux-build.sh @@ -73,7 +73,7 @@ function install_dpdk() export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)/$TARGET/lib fi make config CC=gcc T=$TARGET -make CC=gcc RTE_KERNELDIR=$KERNELSRC +make -j4 CC=gcc RTE_KERNELDIR=$KERNELSRC echo "Installed DPDK source in $(pwd)" cd .. } diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh index 89770c28d..eaff88cd2 100755 --- a/.travis/linux-prepare.sh +++ b/.travis/linux-prepare.sh @@ -8,7 +8,7 @@ set -ev # environments claim to have LLVM (llvm-config exists and works) but # linking against it fails. git clone git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git -cd sparse && make HAVE_LLVM= install && cd .. +cd sparse && make -j4 HAVE_LLVM= install && cd .. pip install --disable-pip-version-check --user six flake8 hacking pip install --user --upgrade docutils -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] travis: Fix building datapath instead of userspace with DPDK_SHARED.
I re-sent this patch as part of the series:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=90839
Best regards, Ilya Maximets.
On 07.02.2019 19:36, Aaron Conole wrote:
> Ilya Maximets writes:
>
>> Current script does not check build of OVS with DPDK.
>> It builds datapath instead:
>> https://travis-ci.org/openvswitch/ovs/jobs/489520695
>>
>> CC: Ian Stokes
>> Fixes: edfe8d263d2e ("travis: Add dpdk shared library build.")
>> Signed-off-by: Ilya Maximets
>> ---
>
> Neat catch!
>
> Acked-by: Aaron Conole
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 8/8] travis: Drop redundant DPDK build check.
This check covered by 'TESTSUITE=1 DPDK=1'. No need to run it separately. Signed-off-by: Ilya Maximets --- .travis.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 8a0707f4f..531a45157 100644 --- a/.travis.yml +++ b/.travis.yml @@ -33,7 +33,6 @@ env: - TESTSUITE=1 KERNEL=3.16.54 - TESTSUITE=1 OPTS="--enable-shared" - BUILD_ENV="-m32" OPTS="--disable-ssl" - - KERNEL=3.16.54 DPDK=1 - KERNEL=3.16.54 DPDK=1 OPTS="--enable-shared" - KERNEL=3.16.54 TESTSUITE=1 DPDK=1 - KERNEL=3.16.54 DPDK_SHARED=1 -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 6/8] travis: Enable printing of executed commands.
This increases the output by a few lines, but gives important information regarding commands and their exact arguments. Very useful for debugging. Signed-off-by: Ilya Maximets --- .travis/linux-build.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh index ef1e5f063..b1b2c831b 100755 --- a/.travis/linux-build.sh +++ b/.travis/linux-build.sh @@ -1,6 +1,7 @@ #!/bin/bash set -o errexit +set -x KERNELSRC="" CFLAGS="-Werror" -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 5/8] travis: Dump config.log on configure failures.
Useful for debugging.
Signed-off-by: Ilya Maximets
---
.travis/linux-build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index e91fa1395..ef1e5f063 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -79,7 +79,7 @@ function install_dpdk()
function configure_ovs()
{
-./boot.sh && ./configure $*
+./boot.sh && ./configure $* || { cat config.log; exit 1; }
}
if [ "$KERNEL" ] || [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 4/8] travis: Run testsuite with desired options.
'make distcheck' executes it's own './configure' without any options provided to the script. This means that in current configuration Travis CI always re-builds and runs testsuite on a defualt binaries. i.e. we're not checking testsuite with DPDK, not checking testsuite with '--enable-shared' and not checking it with '-ljemalloc'. We just 8 times running the testsuite without arguments. Only compiler changes (gcc or clang) because CC is exported by Travis. This patch reorders the commands in the build script and provides 'DISTCHECK_CONFIGURE_FLAGS' to force 'make distcheck' using our desired configuration. Another issue that addressed here is that we will no longe build twice in case of TESTSUITE. For linking inside the distcheck we also need to provide absulute path to DPDK libraries. 'configure' executed before 'distcheck' to have a Makefile target. It's executed without arguments because 'configure' inside the 'distcheck' will fail if we'll use sparse-wrapped CC. Signed-off-by: Ilya Maximets --- .travis/linux-build.sh | 33 - 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh index 8c931ebc5..e91fa1395 100755 --- a/.travis/linux-build.sh +++ b/.travis/linux-build.sh @@ -95,37 +95,44 @@ if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then # Disregard cast alignment errors until DPDK is fixed CFLAGS="$CFLAGS -Wno-cast-align" fi -EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=./dpdk-$DPDK_VER/build" +EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/dpdk-$DPDK_VER/build" elif [ "$CC" != "clang" ]; then # DPDK headers currently trigger sparse errors SPARSE_FLAGS="$SPARSE_FLAGS -Wsparse-error" fi -configure_ovs $EXTRA_OPTS $* - -make selinux-policy - -# Only build datapath if we are testing kernel w/o running testsuite -if [ "$KERNEL" ] && [ ! "$TESTSUITE" ] && \ - [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then -cd datapath -fi +OPTS="$EXTRA_OPTS $*" if [ "$CC" = "clang" ]; then -make -j2 CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument" +export OVS_CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument" elif [[ $BUILD_ENV =~ "-m32" ]]; then # Disable sparse for 32bit builds on 64bit machine -make -j2 CFLAGS="$CFLAGS $BUILD_ENV" +export OVS_CFLAGS="$CFLAGS $BUILD_ENV" else -make -j2 CFLAGS="$CFLAGS $BUILD_ENV $SPARSE_FLAGS" C=1 +OPTS="$OPTS --enable-sparse" +export OVS_CFLAGS="$CFLAGS $BUILD_ENV $SPARSE_FLAGS" fi if [ "$TESTSUITE" ]; then +# 'distcheck' will reconfigure with required options. +# Now we only need to prepare the Makefile wihtout sparse-wrapped CC. +configure_ovs + +export DISTCHECK_CONFIGURE_FLAGS="$OPTS" if ! make distcheck TESTSUITEFLAGS=-j4 RECHECK=yes; then # testsuite.log is necessary for debugging. cat */_build/tests/testsuite.log exit 1 fi +else +configure_ovs $OPTS +make selinux-policy + +# Only build datapath if we are testing kernel w/o running testsuite +if [ "$KERNEL" ] && [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then +cd datapath +fi +make -j4 fi exit 0 -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 3/8] automake: Clean up cxxtest.cc.
'distcheck' complains on some configurations:
ERROR: files left in build directory after distclean:
./include/openvswitch/cxxtest.cc
CC: Ben Pfaff
Fixes: 994bfc298502 ("Automatically verify that OVS header files work OK in C++
also.")
Signed-off-by: Ilya Maximets
---
include/openvswitch/automake.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/openvswitch/automake.mk b/include/openvswitch/automake.mk
index aede51566..73c346175 100644
--- a/include/openvswitch/automake.mk
+++ b/include/openvswitch/automake.mk
@@ -64,6 +64,7 @@ include/openvswitch/cxxtest.cc: \
for header in $(openvswitchinclude_HEADERS); do \
echo $$header; \
done | sed 's,^include/\(.*\)$$,#include <\1>,'; } > $@
+CLEANFILES += include/openvswitch/cxxtest.cc
endif
# OVS does not use C++ itself, but it provides public header files
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/8] datapath: Clean up some gcov, tmp and cache files.
'distcheck' complains about these files while building --with-linux. ERROR: files left in build directory after distclean: ./datapath/linux/.tmp_ip6_gre.gcno ./datapath/linux/.tmp_ip_tunnels_core.gcno ./datapath/linux/.tmp_genetlink-openvswitch.gcno ./datapath/linux/.tmp_stt.gcno <..> ./datapath/linux/.tmp_versions/vport-gre.mod ./datapath/linux/.tmp_versions/vport-geneve.mod ./datapath/linux/.tmp_versions/vport-vxlan.mod ./datapath/linux/.tmp_versions/vport-lisp.mod ./datapath/linux/.tmp_versions/vport-stt.mod <..> ./datapath/linux/.dev-openvswitch.o.d ./datapath/linux/.ip_tunnels_core.o.d ./datapath/linux/.vport.o.d ./datapath/linux/.udp_tunnel.o.d ./datapath/linux/.cache.mk Signed-off-by: Ilya Maximets --- datapath/linux/Makefile.main.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/datapath/linux/Makefile.main.in b/datapath/linux/Makefile.main.in index 328bbfbb6..6db4aa3ab 100644 --- a/datapath/linux/Makefile.main.in +++ b/datapath/linux/Makefile.main.in @@ -29,8 +29,8 @@ check: all installcheck: mostlyclean: clean: - rm -f *.o *.ko *.mod.* Module.symvers .*.cmd kcompat.h.new \ - modules.order .tmp_versions/openvswitch.mod + rm -f *.o *.ko *.mod.* .*.gcno .*.d .*.cmd kcompat.h.new \ + .cache.mk Module.symvers modules.order .tmp_versions/*.mod for d in $(build_links); do if test -h $$d; then rm $$d; fi; done distclean: clean rm -f kcompat.h -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/8] travis: Fix building datapath instead of userspace with DPDK_SHARED.
Current script does not check build of OVS with DPDK.
It builds datapath instead.
CC: Ian Stokes
Fixes: edfe8d263d2e ("travis: Add dpdk shared library build.")
Signed-off-by: Ilya Maximets
Acked-by: Aaron Conole
---
.travis/linux-build.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 9d177aa1b..8c931ebc5 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -43,7 +43,7 @@ function install_kernel()
fi
KERNELSRC=$(pwd)
-if [ ! "$DPDK" ]; then
+if [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then
EXTRA_OPTS="--with-linux=$(pwd)"
fi
echo "Installed kernel source in $(pwd)"
@@ -106,7 +106,8 @@ configure_ovs $EXTRA_OPTS $*
make selinux-policy
# Only build datapath if we are testing kernel w/o running testsuite
-if [ "$KERNEL" ] && [ ! "$TESTSUITE" ] && [ ! "$DPDK" ]; then
+if [ "$KERNEL" ] && [ ! "$TESTSUITE" ] && \
+ [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then
cd datapath
fi
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 0/8] travis: Fix equal distcheck runs.
All the distcheck runs in Travis are equal. Only compiler changes. This patch set targeted to actually run testsuite with desired build options. See patch #4 for details. First few patches are fixes for the issues I found by Travis after enabling the proper builds. Ilya Maximets (8): travis: Fix building datapath instead of userspace with DPDK_SHARED. datapath: Clean up some gcov, tmp and cache files. automake: Clean up cxxtest.cc. travis: Run testsuite with desired options. travis: Dump config.log on configure failures. travis: Enable printing of executed commands. travis: Use parallel jobs for DPDK and sparse builds. travis: Drop redundant DPDK build check. .travis.yml | 1 - .travis/linux-build.sh | 39 - .travis/linux-prepare.sh| 2 +- datapath/linux/Makefile.main.in | 4 ++-- include/openvswitch/automake.mk | 1 + 5 files changed, 28 insertions(+), 19 deletions(-) -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Use NUMA_AWARE_HUGEPAGES too for libnuma check.
On 07.02.2019 19:26, Ilya Maximets wrote:
> On 07.02.2019 19:18, Ian Stokes wrote:
>> On 2/7/2019 1:00 PM, Ilya Maximets wrote:
>>> This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA
>>> disabled. This should not be a usual case. But it's possible to
>>> configure DPDK this way.
>>>
>>
>> Out of interest, with RTE_EAL_NUMA_AWARE_HUGEPAGES defined but not
>> RTE_LIBRTE_VHOST_NUMA, does vhost numa still work as expected?
>
> If RTE_LIBRTE_VHOST_NUMA disabled, all the numa related code from
> librte_vhost will be compiled out. So, rte_vhost_get_numa_node()
> will always return -1. i.e. we will not be able to reallocate
> memory pools according to numa node where VM started.
>
> At the same time eal_memory and eal_memalloc modules will work fine
> allocating hugepages and memory from the requested numa nodes.
>
There are few realistic examples for that case:
1. User builds dpdk without vhost library because there is no plan to
run VMs on target platform. (Some HW switch or edge node).
2. User builds dpdk without vhost library because there is a plan to
use SR-IOV with full HW offloading and port representors. No
vhost ports planned. (Not possible with upstream OVS, but patches
are already on a list).
>>
>> Ian
>>> Fixes: 5e925ccc2a6f ("netdev-dpdk: DPDK v17.11 upgrade")
>>>
>>> Signed-off-by: Ilya Maximets
>>> ---
>>> acinclude.m4 | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/acinclude.m4 b/acinclude.m4
>>> index c51af246a..e2af4ee16 100644
>>> --- a/acinclude.m4
>>> +++ b/acinclude.m4
>>> @@ -254,7 +254,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [
>>> AC_LANG_PROGRAM(
>>> [
>>> #include
>>> -#if RTE_LIBRTE_VHOST_NUMA
>>> +#if defined(RTE_LIBRTE_VHOST_NUMA) || defined(RTE_EAL_NUMA_AWARE_HUGEPAGES)
>>> #error
>>> #endif
>>> ], [])
>>>
>>
>>
>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] SNAT on OVN logical_router in userspace works for ICMP but not TCP or UDP
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 3feba85f-4c6f-4550-9435-7f27837c1fd8 (external-switch)
port vlan111-mgmt
addresses: ["a2:dc:3c:76:8f:27"]
port vlan111
type: localnet
tag: 111
addresses: ["unknown"]
port external-switch_to_external-router
type: router
addresses: ["00:00:00:61:f0:c0 10.250.111.40/24"]
router-port: external-router_to_external-switch
router f97f9421-c727-488d-8575-bfaf7a7bde6b
(vlan111-80973513-f2fe-48cb-904a-b205fb0bcc6f)
port external-router_to_interconnect
mac: "00:00:00:da:6b:85"
networks: ["100.64.1.1/24"]
port external-router_to_external-switch
mac: "00:00:00:61:f0:c0"
networks: ["10.250.111.40/24"]
nat 486f81b0-491f-4c90-9ddd-04ea27e70ac5
external ip: "10.250.111.40"
logical ip: "10.0.0.0/8"
type: "snat"
router 5ca8fc47-1860-43c9-a0ee-a285fd877db5
(overlay-vlan111-80973513-f2fe-48cb-904a-b205fb0bcc6f)
port internal-router_to_interconnect
mac: "00:00:00:73:a8:30"
networks: ["100.64.1.2/24"]
port internal-router_to_internal-switch
mac: "00:00:00:6b:83:b1"
networks: ["10.0.3.253/22"]
OVS configuration:
Bridge br-int
Port patch-br-int-br-ext
Interface patch-br-int-br-ext
type: patch
options: {peer=patch-br-ext-br-int}
Port "patch-br-int-to-vlan111 "
Interface "patch-br-int-to-vlan111 "
type: patch
options: {peer="patch-vlan111-to-br-int"}
Port "vlan111-mgmt"
Interface "vlan111-mgmt"
type: internal
Port br-int
Interface br-int
type: internal
Port "veth51a477d8"
Interface "veth51a477d8"
Bridge br-ext
Port "patch-vlan111-to-br-int"
Interface "patch-vlan111-to-br-int"
type: patch
options: {peer="patch-br-int-to-vlan111 "}
Port "bond0"
trunks: [111]
Interface "enp4s0f0"
type: dpdk
options: {dpdk-devargs=":04:00.0"}
Interface "enp4s0f1"
type:
Re: [ovs-dev] OVN: Setting custom data
Thanks for your reply Ben. Comments in-line below. On 2/7/19 10:06 PM, Ben Pfaff wrote: On Thu, Feb 07, 2019 at 02:24:08PM -0500, Mark Michelson wrote: The general problem I have is that I'm developing a feature for OVN. When a relevant packet arrives, I want to set some data and have that data available the entire time that the packet is being processed. My initial idea was to use one of reg0-reg9 for this. However, those register values get reset to 0 when the packet changes from the ingress to the egress pipeline and when the packet moves from one logical datapath to another. My question is, is it possible (or acceptable) for me to use one of reg0-reg9 as a special purpose register and not to reset its value to 0 automatically? Or is there some other method that would be appropriate? The reason that the registers get reset to 0 on transition between pipelines is that the transition between pipelines is where packets get transmitted across tunnels from one hypervisor to another. The registers don't get transmitted in the tunnels, so they would naturally get reset to 0. We want the logical pipeline to be independent of the physical pipeline, so we reset all the registers even when the packets are not transmitted over a tunnel. This could easily be changed, if we want to assume the use of Geneve, since we can transmit as many registers as we want as Geneve TLVs. But that would rule out the use of STT (and further restrict the use of VXLAN). In the past, there's been little willingness to do that. Yes, this is an excellent point. If we can avoid having to modify encapsulation metadata that'd be swell. Here's a more detailed explanation of the problem. OpenShift is migrating from using their own custom use of OVS to using OVN (via ovn-kubernetes). One feature they currently offer is for any pod in a namespace to be able to send a multicast packet and have it reach all other pods in the same namespace. The actual multicast destination address is not important. This is on purpose so that separate namespaces can use the same multicast destination without the worry of collision. They want to maintain this feature when switching to OVN. You may recall me talking about doing something like this quite some time ago, but the actual method has changed a bit since then. My approach for implementing this is to create a new northbound table for multicast groups. This table contains a list of logical switch ports that represent members of the group. In ovn-northd, we do some magic to ensure that if any of these logical switch ports are on separate logical switches, then appropriate logical flows get installed so that the multicast packet attempts to traverse the logical router(s) that separate the logical switches. When the packet initially arrives on a logical switch, we can use the logical input port, coupled with the multicast destination, to determine the multicast group that this packet should be sent to. However, once the packet reaches a logical router, there's nothing about the packet that we can use to determine which multicast group is the appropriate destination. Same thing occurs when the packet arrives in a logical switch from a logical router. My idea for fixing this is to store the multicast group ID in a general-purpose register. But as stated above, if I set this value in a register, the register's value will get reset to 0 when the packet reaches the logical router pipeline. Hence my questions from the beginning. It seems like this could be done by using allocating multicast IP addresses to the groups, and then mapping from multicast IP addresses to the OVN multicast group. But I'm really naive about IP multicast so maybe this doesn't make sense. You're exactly right. When I first started implementing multicast groups, I did it this way. However, as I mentioned above, I'm trying to keep OpenShift's current usage in mind, and they wish to be able to send to any multicast address and keep the packet in the current namespace. I thought about this some more this morning, and I may be able to do this by fudging with the logical output port. This is already in the encapsulation metadata, so if I could get away with that, I might have what I need. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC v3 1/5] datapath: Add a new action check_pkt_len
> From: Numan Siddique
>
> [Please note, this patch is submitted as RFC in ovs-dev ML to
> get feedback before submitting to netdev ML]
>
> This patch adds a new action which checks the packet length and
> executes a set of actions if the packet length is greater than
> the specified length or executes another set of actions if the
> packet length is lesser or equal to.
>
> This action takes below nlattrs
> * OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for
>
> * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER (optional) - Nested actions
> to apply if the packet length is greater than the specified 'pkt_len'
>
> * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL (optional) - Nested
> actions to apply if the packet length is lesser or equal to the
> specified 'pkt_len'.
>
> The main use case for adding this action is to solve the packet
> drops because of MTU mismatch in OVN virtual networking solution.
> When a VM (which belongs to a logical switch of OVN) sends a packet
> destined to go via the gateway router and if the nic which provides
> external connectivity, has a lesser MTU, OVS drops the packet
> if the packet length is greater than this MTU.
>
> With the help of this action, OVN will check the packet length
> and if it is greater than the MTU size, it will generate an
> ICMP packet (type 3, code 4) and includes the next hop mtu in it
> so that the sender can fragment the packets.
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
> Suggested-by: Ben Pfaff
> Signed-off-by: Numan Siddique
> CC: Ben Pfaff
> CC: Justin Pettit
> CC: Pravin B Shelar
Hi Numan,
just fiew comments inline
Regards,
Lorenzo
> ---
> include/uapi/linux/openvswitch.h | 25 -
> net/openvswitch/actions.c| 55 +-
> net/openvswitch/flow_netlink.c | 175 +++
> 3 files changed, 253 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h
> b/include/uapi/linux/openvswitch.h
> index dbe0cbe4f1b7..c395baffdd42 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -798,6 +798,27 @@ struct ovs_action_push_eth {
> struct ovs_key_ethernet addresses;
> };
>
> +/*
> + * enum ovs_check_pkt_len_attr - Attributes for
> %OVS_ACTION_ATTR_CHECK_PKT_LEN.
> + *
> + * @OVS_CHECK_PKT_LEN_ATTR_PKT_LEN: u16 Packet length to check for.
> + * @OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER: Nested OVS_ACTION_ATTR_*
> + * actions to apply if the packer length is greater than the specified
> + * length in the attr - OVS_CHECK_PKT_LEN_ATTR_PKT_LEN.
> + * @OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL - Nested OVS_ACTION_ATTR_*
> + * actions to apply if the packer length is lesser or equal to the specified
> + * length in the attr - OVS_CHECK_PKT_LEN_ATTR_PKT_LEN.
> + */
> +enum ovs_check_pkt_len_attr {
> + OVS_CHECK_PKT_LEN_ATTR_UNSPEC,
This is not used actually
> + OVS_CHECK_PKT_LEN_ATTR_PKT_LEN,
> + OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER,
> + OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL,
> + __OVS_CHECK_PKT_LEN_ATTR_MAX,
> +};
> +
> +#define OVS_CHECK_PKT_LEN_ATTR_MAX (__OVS_CHECK_PKT_LEN_ATTR_MAX - 1)
> +
> /**
> * enum ovs_action_attr - Action types.
> *
> @@ -842,7 +863,8 @@ struct ovs_action_push_eth {
> * packet, or modify the packet (e.g., change the DSCP field).
> * @OVS_ACTION_ATTR_CLONE: make a copy of the packet and execute a list of
> * actions without affecting the original packet and key.
> - *
> + * @OVS_ACTION_ATTR_CHECK_PKT_LEN: Check the length of the packet and
> + * execute a set of actions as specified in OVS_CHECK_PKT_LEN_ATTR_*.
> * Only a single header can be set with a single %OVS_ACTION_ATTR_SET. Not
> all
> * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
> * type may not be changed.
> @@ -875,6 +897,7 @@ enum ovs_action_attr {
> OVS_ACTION_ATTR_PUSH_NSH, /* Nested OVS_NSH_KEY_ATTR_*. */
> OVS_ACTION_ATTR_POP_NSH, /* No argument. */
> OVS_ACTION_ATTR_METER,/* u32 meter ID. */
> + OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested OVS_CHECK_PKT_LEN_ATTR_*. */
> OVS_ACTION_ATTR_CLONE,/* Nested OVS_CLONE_ATTR_*. */
>
> __OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index e47ebbbe71b8..9551c07eae92 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -169,6 +169,10 @@ static int clone_execute(struct datapath *dp, struct
> sk_buff *skb,
>const struct nlattr *actions, int len,
>bool last, bool clone_flow_key);
>
> +static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> + struct sw_flow_key *key,
> + const struct nlattr *attr, int len);
> +
> static void update_ethertype(struct sk_buff
[ovs-dev] Mutlique support in OVS without DPDK ?
Hello, I am trying to use sch_mqprio qdsic with OVS interface but the problem is that it supports only multi-queue device only. Does OVS supports multiqueue option without DPDK if yes how we can enable it ? Please give your views for the above query ! *Regard* Rakesh Kumar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC 1/3] dpdk: Unify passing of DPDK EAL arguments.
Hi Ilya, Thanks for raising this and explaining in detail so it can be discussed. Comments below, On 02/01/2019 01:11 PM, Ilya Maximets wrote: > This patch deprecates the usage of current configuration knobs for > DPDK EAL arguments: > > - dpdk-alloc-mem > - dpdk-socket-mem > - dpdk-socket-limit > - dpdk-lcore-mask > - dpdk-hugepage-dir > - dpdk-extra > > All above configuration options replaced with single 'dpdk-options' > which has same format as old 'dpdk-extra', i.e. just a string with > all the DPDK EAL arguments. > > All the documentation about old configuration knobs removed. Users > could still use an old interface, but the deprecation warning will be > printed. In case 'dpdk-options' provided, values of old options will > be ignored. New users will start using new 'dpdk-options' as this is > the only documented way providing EAL arguments. > > Rationale: > > From release to release DPDK becomes more complex. New EAL arguments > appears, old arguments becomes deprecated. Some changes their meaning > and behaviour. It's not easy task to manage all this and current > code in OVS that tries to manage DPDK options is not flexible/extendable > enough even to track all the dependencies between options in DPDK 18.11. > For example, '--socket-mem' changed its meaning, '--legacy-mem' and > '--socket-limit' appeared. But '--legacy-mem' and '--socket-limit' > could not be used at the same time and, also, we want to provide > good default value for '--socket-limit' to keep the consistent > behaviour of OVS memory usage. And this will be worse in the future. > I think it is an exception that shows it is quite stable. There's probably been something like 10 DPDK releases (didn't check exactly) since these params were introduced and this seems to be first time that there was an issue with an argument. It was also a very rare change in DPDK where the memory mgmt was re-designed and re-written from the ground up. That meant an extra flag was needed to keep the same behavior. Perhaps if the existing flag was not reused, there wouldn't have been an issue at all (or at least it would have been much clearer). > Another point is that even now we have mutually exclusive database > configs in OVS and we have to handle them. i.e we're providing > 'dpdk-alloc-mem' and 'dpdk-socket-mem' at the same time. Additionally, > user allowed to configure same options in 'dpdk-extra'. So, we have > similar/equal options in a three places in ovsdb and we need to > choose which one to use. It's pretty easy for user to get into > inconsistent database configuration, because users could update > one field without removing others, and OVS has to resolve all the > conflicts somehow constructing the EAL args. But we do not know in > practice, if the resulted arguments are the arguments that user wanted > to see or just forget to remove the higher priority knob. > That's true about dpdk-alloc-mem and dpdk-socket-mem. I'm not sure if the docs give some direction on that. IIRC, it is documented and checked about precedence when using dpdk-extra's. > Next point is that we have 'dpdk-lcore-mask' (-c) which is actually not > so user-friendly as '-l', but we have no option for it. Will we create > additional 'dpdk-lcore-list' ? I guess, no, because it's not really > important thing. But users will stuck with this not so user-friendly > masks. > I'm not sure which is more user-friendly but I agree adding dpdk-lcore-list is not needed, and probably could add confusion (especially as dpdk-lcore-mask doesn't need '0x' prefix). > Another thing is that OVS is not really need to check the consistency > of the EAL arguments because DPDK could check it instead. DPDK will > always check the args and it will do it better. There is no real > need to duplicate this functionality. > > Keeping all the options in a single string 'dpdk-options' allows: > > * To have only one place for all the configs, i.e. it will be harder > for user to forget to remove something from the single string while > updating it. > * Not to check the consistency between different configs, DPDK could > check the cmdline itself. > * Not to document every DPDK EAL argument in OVS. We can just > describe few of them and point to DPDK docs for more information. > * OVS still able to provide some minimal default arguments. > Thanks to DPDK 18.11 we only need to specify an lcore. All other > arguments are not necessary. (We still also providing default > --socket-limit in case --socket-mem passed without it and without > --legacy-mem) > It would seem wrong to tell the OVS user to fill in the DPDK EAL arguments in a type of passthrough string to DPDK but then also insert defaults to that. > Usage example: > > ovs-vsctl set Open_vSwitch . \ > other_config:dpdk-options="-l 1 -n 4 --socket-mem 1024,1024" > It is possible to do that now. > Signed-off-by: Ilya Maximets What I like about the current scheme is
Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
On 2/8/2019 9:59 AM, Simon Horman wrote:
> On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
>> From: Gregory Rose
>> Date: Mon, 4 Feb 2019 11:41:29 -0800
>>
>>> On 2/3/2019 1:12 AM, Eli Britstein wrote:
Declare ovs key structures using macros as a pre-step towards to
enable retrieving fields information, as a work done in proposed
commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
("odp-util: Do not rewrite fields with the same values as matched"),
with no functional change.
Signed-off-by: Eli Britstein
Reviewed-by: Roi Dayan
>>> Obscuring the structures with these macros is awful. I'm opposed but
>>> I see it has already been
>>> accepted upstream so I guess that's that.
>> I am personally in no way obligated to apply this patch to my tree
>> just because "upstream" did, and I absolutely have no plans to do so
>> at this point.
>>
>> This patch is absolutely awful.
> I hate to jump on a bandwagon, but this patch makes the code much
> less readable.
Please review the alternative I have posted:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/356000.html
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] overdue payment
___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
> From: Gregory Rose
> Date: Mon, 4 Feb 2019 11:41:29 -0800
>
> >
> > On 2/3/2019 1:12 AM, Eli Britstein wrote:
> >> Declare ovs key structures using macros as a pre-step towards to
> >> enable retrieving fields information, as a work done in proposed
> >> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
> >> ("odp-util: Do not rewrite fields with the same values as matched"),
> >> with no functional change.
> >>
> >> Signed-off-by: Eli Britstein
> >> Reviewed-by: Roi Dayan
> >
> > Obscuring the structures with these macros is awful. I'm opposed but
> > I see it has already been
> > accepted upstream so I guess that's that.
>
> I am personally in no way obligated to apply this patch to my tree
> just because "upstream" did, and I absolutely have no plans to do so
> at this point.
>
> This patch is absolutely awful.
I hate to jump on a bandwagon, but this patch makes the code much
less readable.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
