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