>
>
>
> Looking at the code, it looks like any IP packet matches the priority-50
> flow. Something like:
> For all IP packets, a priority-50 flow with an action
> <code>ct_dnat;</code>.
>
Agreed. Will fix this as part of the next version.
>
>
> >index 7852d83..3ce88a7 100644
> >--- a/ovn/northd/ovn-northd.c
> >+++ b/ovn/northd/ovn-northd.c
> >@@ -105,12 +105,15 @@ enum ovn_stage {
> > /* Logical router ingress stages. */ \
> > PIPELINE_STAGE(ROUTER, IN, ADMISSION, 0, "lr_in_admission") \
> > PIPELINE_STAGE(ROUTER, IN, IP_INPUT, 1, "lr_in_ip_input") \
> >- PIPELINE_STAGE(ROUTER, IN, IP_ROUTING, 2, "lr_in_ip_routing") \
> >- PIPELINE_STAGE(ROUTER, IN, ARP_RESOLVE, 3, "lr_in_arp_resolve") \
> >- PIPELINE_STAGE(ROUTER, IN, ARP_REQUEST, 4, "lr_in_arp_request") \
> >+ PIPELINE_STAGE(ROUTER, IN, SNAT, 2, "lr_in_snat") \
>
> I find calling this table SNAT misleading, since it is actually reverting
> the destination address.
> How about UNDO_SNAT or UNSNAT?
>
I am okay with UNSNAT. What about DNAT as it is currently doing both unDNAT
and DNAT? Leave it at DNAT?
> You are allowing the key to be a prefix, with mask other than OVS_BE32_MAX.
> This implies that a user can specify multiple overlapping prefixes.
> Conflicts should be resolved by going with the longest matching prefix.
>
> We actually need this behavior for OpenStack. If the source IP address is a
> fixed IP that has a corresponding floating IP, then the source IP address
> should be mapped to the floating IP address rather than the router gateway
> address. We need longest match to win to get this behavior.
>
> So, the priority should be (mask+1).
>
Right. I will get this right in the next version.
>
> >--- a/ovn/ovn-nb.ovsschema
> >+++ b/ovn/ovn-nb.ovsschema
> >@@ -1,7 +1,7 @@
> > {
> > "name": "OVN_Northbound",
> >- "version": "2.1.2",
> >- "cksum": "429668869 5325",
> >+ "version": "2.1.3",
> >+ "cksum": "400575131 5731",
> > "tables": {
> > "Logical_Switch": {
> > "columns": {
> >@@ -78,6 +78,14 @@
> > "max": "unlimited"}},
> > "default_gw": {"type": {"key": "string",
> "min": 0, "max": 1}},
> > "enabled": {"type": {"key": "boolean",
> "min": 0, "max": 1}},
> >+ "dnat" : {
> >+ "type": {"key": {"type":
> "string"},
> >+ "value": {"type"
> : "string"},
> >+ "min": 0,
> "max": "unlimited"}},
> >+ "snat" : {
> >+ "type": {"key": {"type":
> "string"},
> >+ "value":
> {"type" : "string"},
> >+ "min": 0, "max":
> "unlimited"}},
>
> As mentioned above, in OpenStack, if the source IP address is a fixed IP
> that has a corresponding floating IP, then the source IP address should be
> mapped to the floating IP address rather than the router gateway address.
>
> Separate dnat and snat lists as defined here can be made to work to support
> the OpenStack behavior using this patch, by copying floating IPs into both
> the dnat and snat lists. However this is a little unwieldy.
>
I see your point. But the behavior you mention is a very OpenStack thing.
OVN config being independent of OpenStack specific behavior looks better to
me, Unless we can think up with a general purpose schema.
>
> If we ever move to distributed handling of floating IPs, which I am still
> working on, then the duplication will be difficult to handle for east/west
> flows. It would be easier if one definition could apply to both dnat and
> snat.
> An additional value could indicate if the rule applies to only dnat or
> both.
> Or, perhaps there could just be a single list of nat rules with an
> additional
> value indicating if the rule applies to snat or dnat or both.
>
This needs some thought. Do you strongly feel that this needs to be handled
now, or would you mind sending a patch that proposes your schema after this
schema goes in?
>
> Note also that for distributed handling of floating IPs, we will need MAC
> addresses to go along with the floating IPs. This makes me think it might
> be worth having an indirection to a separate nat table.
>
> Mickey
>
>
> > "options": {
> > "type": {"key": "string",
> > "value":
> "string",
> >diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> >index d239499..508a865 100644
> >--- a/ovn/ovn-nb.xml
> >+++ b/ovn/ovn-nb.xml
> >@@ -631,18 +631,41 @@
> > router has all ingress and egress traffic dropped.
> > </column>
> >
> >+ <column name="dnat">
> >+ A map of externally visible IP address to their corresponding IP
> >+ addresses in the logical space. The externally visible IP address
> >+ is DNATed to the IP address in the logical space. DNAT only works
> >+ on routers that are non-distributed.
> >+ </column>
> >+
> >+ <column name="snat">
> >+ A map of IP network (e.g 192.168.1.0/24) or an IP address to
> another
> >+ IP address. All IP packets with their source IP address that
> either
> >+ matches the key or is in the provided network is SNATed
> >+ into the IP address in the value. SNAT only works on routers that
> are
> >+ non-distributed.
> >+ </column>
> >+
> > <group title="Options">
> > <p>
> > Additional options for the logical router.
> > </p>
> >
> > <column name="options" key="chassis">
> >- If set, indicates that the logical router in question is
> >- non-distributed and resides in the set chassis. The same
> >- value is also used by <code>ovn-controller</code> to
> >- uniquely identify the chassis in the OVN deployment and
> >- comes from <code>external_ids:system-id</code> in the
> >- <code>Open_vSwitch</code> table of Open_vSwitch database.
> >+ <p>
> >+ If set, indicates that the logical router in question is
> >+ non-distributed and resides in the set chassis. The same
> >+ value is also used by <code>ovn-controller</code> to
> >+ uniquely identify the chassis in the OVN deployment and
> >+ comes from <code>external_ids:system-id</code> in the
> >+ <code>Open_vSwitch</code> table of Open_vSwitch database.
> >+ </p>
> >+
> >+ <p>
> >+ The non-distributed router (also known as Gateway router)
> >+ can only be connected to a distributed router via a switch
> >+ if SNAT and DNAT is to be configured in the Gateway router.
> >+ </p>
> > </column>
> > </group>
> >
> >diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
> >index 741228c..3a0268f 100644
> >--- a/ovn/ovn-sb.xml
> >+++ b/ovn/ovn-sb.xml
> >@@ -951,6 +951,44 @@
> > </p>
> > </dd>
> >
> >+ <dt><code>ct_dnat;</code></dt>
> >+ <dt><code>ct_dnat(<var>IP</var>);</code></dt>
> >+ <dd>
> >+ <p>
> >+ <code>ct_dnat</code> sends the packet through the DNAT zone
> to
> >+ unDNAT any packet that was DNATed in a different direction.
> >+ </p>
> >+ <p>
> >+ <code>ct_dnat(<var>IP</var>)</code> sends the packet through
> the
> >+ DNAT zone to change the destination IP address of the packet
> to
> >+ the one provided inside the parenthesis and commits the
> connection.
> >+ </p>
> >+ <p>
> >+ Both <code>ct_dnat</code> and
> <code>ct_dnat(<var>IP</var>)</code>
> >+ recirculate the packet in the datapath.
> >+ </p>
> >+ </dd>
> >+
> >+ <dt><code>ct_snat;</code></dt>
> >+ <dt><code>ct_snat(<var>IP</var>);</code></dt>
> >+ <dd>
> >+ <p>
> >+ <code>ct_snat</code> sends the packet through the SNAT zone
> to
> >+ unSNAT any packet that was SNATed in a different direction.
> >+ </p>
> >+ <p>
> >+ <code>ct_snat(<var>IP</var>)</code> sends the packet through
> the
> >+ SNAT zone to change the source IP address of the packet to
> >+ the one provided inside the parenthesis and commits the
> connection.
> >+ </p>
> >+ <p>
> >+ <code>ct_snat</code> does not recirculate the packet in the
> >+ datapath and hence should be followed by a <code>next;</code>
> >+ action. <code>ct_snat(<var>IP</var>)</code> does
> >+ recirculate the packet in the datapath.
> >+ </p>
> >+ </dd>
> >+
> > <dt><code>arp { <var>action</var>; </code>...<code>
> };</code></dt>
> > <dd>
> > <p>
> >--
> >1.9.1
> >
> >_______________________________________________
> >dev mailing list
> >dev@openvswitch.org
> >http://openvswitch.org/mailman/listinfo/dev
> >
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
