Re: [ovs-discuss] Flow not registered in OVSDB flow table
Hi Adrian, thank you for your reply. Your suggestion is the same as Ilya's. I used the following command to monitor the OpenFlow commands modifying the flow table: sudo ovs-ofctl monitor switch1 65534 watch: --protocols=OpenFlow13 But the client doesn't receive any packets even I add and delete some entries in the flow table and the changes can be verified with dump-flows command. Only packets like the following are received: OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload Extensions of the protocols with al the versions other than OpenFlow13 doesn't help either. Can you see if the usage of the client with the command above is correct. Regards, Zekeriya >-Ursprüngliche Nachricht- >Von: Adrian Moreno >Gesendet: Freitag, 19. Januar 2024 13:16 >An: Mansuroglu, Zekeriya ; ovs- >disc...@openvswitch.org >Betreff: Re: [ovs-discuss] Flow not registered in OVSDB flow table > > > >On 1/18/24 11:00, Mansuroglu, Zekeriya via discuss wrote: >> Hi all, >> >> I’m using ovs through mininet with OpendayLight. The ovs version is 2.13.8 >> and >> the mininet version is 2.3.0.dev6. I create a network with a single switch >> and >> two hosts. After that I create a flow through the nortboubd interface of >> opendaylight that works fine. I can also verify with ovs-ofctl that the flow >> is >> accepted by the switch. I expected that the flow is also registered in a >> table >> in ovsdb, but when I dump the database the flow doesn’t appear anywhere in >the >> datastore. >> >> Shouldn’t the flow be registered in one of the table Flow_Table, sFlow or >NetFlow? >> > >OpenFlow flows are not stored in the OVSDB. Only configuration is stored there. > >> I aimed to use the ovsdb-client to monitor for changes of the flow table >> configurations. As I understood ovsdb-client’s monitor command this should >be >> doable when changes of the flow configurations lead to changes in ovsdb. Is >this >> approach realistic? >> > >If you want to monitor the changes in the OpenFlow tables you can use "ovs- >ofctl >monitor". > >> Thanks, >> >> Zekeriya >> >> >> ___ >> discuss mailing list >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > >-- >Adrián Moreno ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow not registered in OVSDB flow table
Additional details: The call to sudo ovs-ofctl monitor switch1 65534 watch: --protocols=OpenFlow13 produces as first output the following everytime: OFPT_ERROR (xid=0x9): OFPBRC_BAD_VERSION NXST_FLOW_MONITOR request (xid=0x9): id=0 flags=initial,add,delete,modify,actions,own Until now I could observe only packets from types like the following OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload NXT_PACKET_IN2 (OF1.3) (xid=0x0): cookie=0xa total_len=70 in_port="s1-eth1" (via no_match) data_len=70 (unbuffered) icmp6,vlan_tci=0x,dl_src=f6:2d:5c:f7:bd:5e,dl_dst=33:33:00:00:00:02,ipv6_src=fe80::f42d:5cff:fef7:bd5e,ipv6_dst=ff02::2,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=133,icmp_code=0 icmp6_csum:5e26 OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload NXT_PACKET_IN2 (OF1.3) (xid=0x0): cookie=0xa total_len=70 in_port="s1-eth2" (via no_match) data_len=70 (unbuffered) icmp6,vlan_tci=0x,dl_src=16:a8:ee:4f:df:42,dl_dst=33:33:00:00:00:02,ipv6_src=fe80::14a8:eeff:fe4f:df42,ipv6_dst=ff02::2,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=133,icmp_code=0 icmp6_csum:b6b8 OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload >-Ursprüngliche Nachricht- >Von: discuss Im Auftrag von >Mansuroglu, Zekeriya via discuss >Gesendet: Mittwoch, 24. Januar 2024 14:24 >An: Adrian Moreno ; ovs-discuss@openvswitch.org >Cc: Ilya Maximets >Betreff: Re: [ovs-discuss] Flow not registered in OVSDB flow table > >Hi Adrian, >thank you for your reply. Your suggestion is the same as Ilya's. > >I used the following command to monitor the OpenFlow commands modifying >the flow table: > >sudo ovs-ofctl monitor switch1 65534 watch: --protocols=OpenFlow13 > >But the client doesn't receive any packets even I add and delete some entries >in >the flow table and the changes can be verified with dump-flows command. Only >packets like the following are received: > >OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload > >Extensions of the protocols with al the versions other than OpenFlow13 doesn't >help either. > >Can you see if the usage of the client with the command above is correct. > >Regards, >Zekeriya > >>-Ursprüngliche Nachricht- >>Von: Adrian Moreno >>Gesendet: Freitag, 19. Januar 2024 13:16 >>An: Mansuroglu, Zekeriya ; ovs- >>disc...@openvswitch.org >>Betreff: Re: [ovs-discuss] Flow not registered in OVSDB flow table >> >> >> >>On 1/18/24 11:00, Mansuroglu, Zekeriya via discuss wrote: >>> Hi all, >>> >>> I’m using ovs through mininet with OpendayLight. The ovs version is 2.13.8 >and >>> the mininet version is 2.3.0.dev6. I create a network with a single switch >>> and >>> two hosts. After that I create a flow through the nortboubd interface of >>> opendaylight that works fine. I can also verify with ovs-ofctl that the >>> flow is >>> accepted by the switch. I expected that the flow is also registered in a >>> table >>> in ovsdb, but when I dump the database the flow doesn’t appear anywhere in >>the >>> datastore. >>> >>> Shouldn’t the flow be registered in one of the table Flow_Table, sFlow or >>NetFlow? >>> >> >>OpenFlow flows are not stored in the OVSDB. Only configuration is stored >there. >> >>> I aimed to use the ovsdb-client to monitor for changes of the flow table >>> configurations. As I understood ovsdb-client’s monitor command this should >>be >>> doable when changes of the flow configurations lead to changes in ovsdb. Is >>this >>> approach realistic? >>> >> >>If you want to monitor the changes in the OpenFlow tables you can use "ovs- >>ofctl >>monitor". >> >>> Thanks, >>> >>> Zekeriya >>> >>> >>> ___ >>> discuss mailing list >>> disc...@openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >>-- >>Adrián Moreno > >___ >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
[ovs-discuss] OVN: Fixing direct access to SNATed network
Hi everyone,
We are encountering an issue with our (Openstack) topology where we
need to directly access hosts in SNATed network from external network.
While the traffic like ICMP works fine, TCP traffic gets SNATed on the
way back **after** the initial handshake. Our setup looks something
like this:
OVN from git (0ce21f2)
OVS from git (4102674)
3x Nova Compute hypervisor, each with GW Chassis
External network: 10.5.0./16
Host on ext. net (S1): 10.5.0.16
Logical Router (r1) ext. IP:10.5.150.143
Internal network (a_net) with SNAT: 192.168.10.0/24
Guest VM (A1) on the int. network: 192.168.10.83
(Host S1 has static routes for the internal network via r1's external
IP)
I think the problem is best demonstrated on the tcpdump captured on the
S1 trying to communicate with A1 [0] (I'm going to use pastebin to keep
this mail shorter, I hope that it's OK). As you can see, after the
initial handshake, S1 pushes data, but ACK comes back from SNATed
router's IP.
I also took OVN traces:
* S1 -> A1 (New direction)[1]
* A1 -> S1 (Reply direction)[2]
The traces themselves look good as they don't show any SNAT in the
reply direction but I'm not sure that this is what's actually happening
when the packet goes through the router. I see that the SNAT rules
should not match for packets in "reply" direction [3] but I don't see
(in the trace) that the router would apply connection tracking on the
packets with "ct_next". If I understand this correctly, if the router
does not commit flow into the connection tracking, it is not able to
match on ct_state.
I tried to apply following changes that initiate CT and commit packets
to the conntrack and it seems to fix the issue without breaking
anything. The gist of the change is that the router initiates CT in the
ingress and commits the packet into CT before moving it to the egress
pipeline. That way, when the packets in the reply direction show up,
router can determine that they are replies and does not perform the
SNAT.
I very much just eyeballed where to put the "ct_next" and "ct_commit"
so I'm sure that this is not the final solution, but I'd just like to
know if I'm going in the right direction.
diff --git a/northd/northd.c b/northd/northd.c
index 952f8200d..4eea38cbd 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11792,7 +11792,7 @@ add_route(struct hmap *lflows, struct
ovn_datapath *od,
"eth.src = %s; "
"outport = %s; "
"flags.loopback = 1; "
- "next;",
+ "ct_next;",
is_ipv4 ? REG_SRC_IPV4 : REG_SRC_IPV6,
lrp_addr_s,
op->lrp_networks.ea_s,
@@ -14331,7 +14331,7 @@ build_arp_request_flows_for_lrouter(
"};",
copp_meter_get(COPP_ND_NS_RESOLVE, od->nbr-
>copp,
meter_groups));
-ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_REQUEST, 0, "1",
"output;");
+ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_REQUEST, 0, "1",
"ct_commit { }; output;");
}
/* Logical router egress table DELIVERY: Delivery (priority 100-110).
@@ -15692,7 +15692,7 @@ build_lrouter_nat_defrag_and_lb(struct
ovn_datapath *od, struct hmap *lflows,
ovn_lflow_add(lflows, od, S_ROUTER_IN_DEFRAG, 0, "1", "next;");
ovn_lflow_add(lflows, od, S_ROUTER_IN_UNSNAT, 0, "1", "next;");
ovn_lflow_add(lflows, od, S_ROUTER_OUT_CHECK_DNAT_LOCAL, 0, "1",
- REGBIT_DST_NAT_IP_LOCAL" = 0; next;");
+ REGBIT_DST_NAT_IP_LOCAL" = 0; ct_next;");
ovn_lflow_add(lflows, od, S_ROUTER_OUT_SNAT, 0, "1", "next;");
ovn_lflow_add(lflows, od, S_ROUTER_IN_DNAT, 0, "1", "next;");
ovn_lflow_add(lflows, od, S_ROUTER_OUT_UNDNAT, 0, "1", "next;");
Thank you for any suggestions,
Martin.
-
[0] https://pastebin.com/gmbNP1Bg
[1] https://pastebin.com/155aVzYj
[2] https://pastebin.com/pcAuCFhT
[3]
https://github.com/ovn-org/ovn/blob/0ce21f2adda1edeeafe10a1d62cd976039a42492/northd/northd.c#L15418
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] ovs-vswitchd.log WARN "(Invalid argument) on packet"
Hi Folks,
I'm trying to understand what this error message means:
2024-01-24T02:32:01.412Z|00117|dpif(handler2)|WARN|system@ovs-system:
execute
ct(commit,zone=1,nat(src)),set(tunnel(tun_id=0x7,dst=253.255.2.65,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x10002}),flags(df|csum|key))),set(eth(src=00:13:97:fa:a8:ad,dst=00:13:97:ae:83:43)),set(ipv4(ttl=61)),4
failed (Invalid argument) on packet
tcp,vlan_tci=0x,dl_src=00:13:97:16:dc:2a,dl_dst=00:13:97:45:c2:ab,nw_src=169.254.169.254,nw_dst=10.196.81.2,nw_tos=0,nw_ecn=0,nw_ttl=62,tp_src=80,tp_dst=51892,tcp_flags=ack
tcp_csum:6cfb
Is it that we are trying to conntrak mark a packet, but there is
something wrong with the packet. But is wrong?
Is it that the packet is an ack and not a syn?
Also would something like this cause ovs-vswitchd to SEGV? I would think
not, I would think this should be a transient issue?
Thanks
Brendan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN: Fixing direct access to SNATed network
On Wed, Jan 24, 2024 at 6:05 PM Martin Kalcok via discuss
wrote:
>
> Hi everyone,
> We are encountering an issue with our (Openstack) topology where we
> need to directly access hosts in SNATed network from external network.
> While the traffic like ICMP works fine, TCP traffic gets SNATed on the
> way back **after** the initial handshake. Our setup looks something
> like this:
>
> OVN from git (0ce21f2)
> OVS from git (4102674)
>
> 3x Nova Compute hypervisor, each with GW Chassis
>
> External network: 10.5.0./16
> Host on ext. net (S1): 10.5.0.16
> Logical Router (r1) ext. IP:10.5.150.143
> Internal network (a_net) with SNAT: 192.168.10.0/24
> Guest VM (A1) on the int. network: 192.168.10.83
>
> (Host S1 has static routes for the internal network via r1's external
> IP)
>
> I think the problem is best demonstrated on the tcpdump captured on the
> S1 trying to communicate with A1 [0] (I'm going to use pastebin to keep
> this mail shorter, I hope that it's OK). As you can see, after the
> initial handshake, S1 pushes data, but ACK comes back from SNATed
> router's IP.
>
> I also took OVN traces:
>
> * S1 -> A1 (New direction)[1]
> * A1 -> S1 (Reply direction)[2]
>
> The traces themselves look good as they don't show any SNAT in the
> reply direction but I'm not sure that this is what's actually happening
> when the packet goes through the router. I see that the SNAT rules
> should not match for packets in "reply" direction [3] but I don't see
> (in the trace) that the router would apply connection tracking on the
> packets with "ct_next". If I understand this correctly, if the router
> does not commit flow into the connection tracking, it is not able to
> match on ct_state.
>
> I tried to apply following changes that initiate CT and commit packets
> to the conntrack and it seems to fix the issue without breaking
> anything. The gist of the change is that the router initiates CT in the
> ingress and commits the packet into CT before moving it to the egress
> pipeline. That way, when the packets in the reply direction show up,
> router can determine that they are replies and does not perform the
> SNAT.
>
> I very much just eyeballed where to put the "ct_next" and "ct_commit"
> so I'm sure that this is not the final solution, but I'd just like to
> know if I'm going in the right direction.
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 952f8200d..4eea38cbd 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -11792,7 +11792,7 @@ add_route(struct hmap *lflows, struct
> ovn_datapath *od,
>"eth.src = %s; "
>"outport = %s; "
>"flags.loopback = 1; "
> - "next;",
> + "ct_next;",
>is_ipv4 ? REG_SRC_IPV4 : REG_SRC_IPV6,
>lrp_addr_s,
>op->lrp_networks.ea_s,
> @@ -14331,7 +14331,7 @@ build_arp_request_flows_for_lrouter(
>"};",
>copp_meter_get(COPP_ND_NS_RESOLVE, od->nbr-
> >copp,
> meter_groups));
> -ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_REQUEST, 0, "1",
> "output;");
> +ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_REQUEST, 0, "1",
> "ct_commit { }; output;");
> }
>
> /* Logical router egress table DELIVERY: Delivery (priority 100-110).
> @@ -15692,7 +15692,7 @@ build_lrouter_nat_defrag_and_lb(struct
> ovn_datapath *od, struct hmap *lflows,
> ovn_lflow_add(lflows, od, S_ROUTER_IN_DEFRAG, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_ROUTER_IN_UNSNAT, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_ROUTER_OUT_CHECK_DNAT_LOCAL, 0, "1",
> - REGBIT_DST_NAT_IP_LOCAL" = 0; next;");
> + REGBIT_DST_NAT_IP_LOCAL" = 0; ct_next;");
> ovn_lflow_add(lflows, od, S_ROUTER_OUT_SNAT, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_ROUTER_IN_DNAT, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_ROUTER_OUT_UNDNAT, 0, "1", "next;");
>
>
> Thank you for any suggestions,
> Martin.
>
> -
> [0] https://pastebin.com/gmbNP1Bg
> [1] https://pastebin.com/155aVzYj
> [2] https://pastebin.com/pcAuCFhT
> [3]
> https://github.com/ovn-org/ovn/blob/0ce21f2adda1edeeafe10a1d62cd976039a42492/northd/northd.c#L15418
Thanks alot for starting this discussion, Martin!
I just wanted to chime in with the desire to see this use case working
and I know we have examples of end users coming from ML2/OVS with this
expectation. There are also other facets of this problem complex with
issues such as internal IP access to a DNAT'ed address backed by an IP
on the same network etc. but I'm sure we will get onto those as part
of the discussion.
FWIW; there are some descriptions of the handling of this use case in
OpenStack documentation and specs, so I thought it would be useful to
reference that here [4] to support the discussion.
4:
https://github.com/openstack/
