Works for me.
Mickey
-----Guru Shetty <g...@ovn.org> wrote: -----
To: Mickey Spiegel/San Jose/IBM@IBMUS
From: Guru Shetty <g...@ovn.org>
Date: 06/09/2016 10:20AM
Cc: ovs dev <dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
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
