[ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.

Mickey Spiegel emspiege at us.ibm.com
Thu Jun 9 01:34:31 UTC 2016


Guru,

>The  names "inside_ip" and "outside_ip" keeps tripping me up. The  nomenclature feels similar to tunnel outside_ip and tunnel inside_ip.  What do you think about "logical_ip" and "physical_ip" instead?

A quick search revealed that "inside" and "outside" are not always used the way that I thought, so my proposed terminology does not really work.

Thinking about "logical_ip" and "physical_ip", I am concerned that "physical_ip" will confuse people. When I hear "physical_ip", my mind wanders to pieces of hardware, which is not what this is about.

How about "internal_ip"/"external_ip"?

Mickey

-----Guru Shetty <guru at ovn.org> wrote: -----
To: Mickey Spiegel/San Jose/IBM at IBMUS
From: Guru Shetty <guru at ovn.org>
Date: 06/07/2016 08:14AM
Cc: ovs dev <dev at openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.



I am always a little nervous about putting things in schema that I know will change later,
especially when it comes to the structure of the config.

I am thinking of ovn-nb.ovsschema changes along the following lines:

         "Logical_Router": {
             "columns": {
                 "name": {"type": "string"},
                 "ports": {"type": {"key": {"type": "uuid",
                                            "refTable": "Logical_Router_Port",
                                            "refType": "strong"},
                                    "min": 0,
                                    "max": "unlimited"}},
                 "static_routes": {"type": {"key": {"type": "uuid",
                                             "refTable": "Logical_Router_Static_Route",
                                             "refType": "strong"},
                                    "min": 0,
                                    "max": "unlimited"}},
                 "default_gw": {"type": {"key": "string", "min": 0, "max": 1}},
                 "enabled": {"type": {"key": "boolean", "min": 0, "max": 1}},
+                "nat": {"type": {"key": {"type": "uuid",
+                                         "refTable": "NAT”,
+                                         "refType": "strong"},
+                                   "min": 0,
+                                   "max": "unlimited"}},
                 "options": {
                      "type": {"key": "string",
                               "value": "string",
                               "min": 0,
                               "max": "unlimited"}},
                 "external_ids": {
                     "type": {"key": "string", "value": "string",
                              "min": 0, "max": "unlimited"}}},
             "isRoot": true},


+        “NAT”: {
+            "columns": {
+                "outside_ip": {"type": {"key": "string", "min": 0, "max": 1}},
+                "inside_ip": {"type": {"key": "string", "min": 0, "max": 1}},
+                "direction": {"type": {"key": {"type": "string",
+                                       "enum": ["set", ["dnat", “snat", "dnat_and_snat"]]}}},
+            "isRoot": false},

DNAT maps from destination outside_ip to inside_ip.
SNAT maps from source inside_ip to outside_ip.
If direction == dnat or direction == dnat_and_snat, then check for inside_ip mask == 32
If direction == snat or direction == dnat_and_snat, then check for outside_ip == 32

The names "inside_ip" and "outside_ip" keeps tripping me up. The nomenclature feels similar to tunnel outside_ip and tunnel inside_ip. What do you think about "logical_ip" and "physical_ip" instead? 
 

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

You can add outside_protocol, outside_l4_port, inside_protocol, and inside_l4_port.

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

We will add outside_mac in the patch for distributed handling of floating IPs.

Mickey



 




More information about the dev mailing list