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

I decided to use "logical_ip"/"external_ip". logical_ip feels like a good
term as I can easily associate it with logical_port.


>
> Mickey
>
> -----Guru Shetty <g...@ovn.org> wrote: -----
> To: Mickey Spiegel/San Jose/IBM@IBMUS
> From: Guru Shetty <g...@ovn.org>
> Date: 06/07/2016 08:14AM
> Cc: ovs dev <dev@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
>
>
>
>
>
> _______________________________________________
> 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