>
>
>> 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?
>

As an addendum, the current schema does dnat:30.0.0.3=192.168.1.2. I would
like to enhance it to also be able to provide ports. Something like
dnat:30.0.0.3:4443=192.168.1.2:80

So we will need to include the above with the new table that you are
thinking too.

>
>
>
>>
>> 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

Reply via email to