| Message ID | 1445531331-27231-1-git-send-email-blp@nicira.com |
|---|---|
| State | Rejected |
| Headers | show |
On 10/22/2015 12:28 PM, Ben Pfaff wrote: > Signed-off-by: Ben Pfaff <blp@nicira.com> > --- > ovn/ovn-architecture.7.xml | 83 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 83 insertions(+) > > diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml > index 318555b..8ae148e 100644 > --- a/ovn/ovn-architecture.7.xml > +++ b/ovn/ovn-architecture.7.xml > @@ -309,6 +309,89 @@ > </li> > </ul> > > + <h2>Connecting Logical Networks to Physical Networks</h2> > + > + <p> > + Logical networks can be useful by themselves for use within a cloud, but > + ordinarily at least some part of a cloud deployment will need to connect to > + external physical networks. OVN supports multiple ways to connect to > + physical networks. These methods can be classified along two axes. > + </p> > + > + <p> > + The first axis is the <dfn>connection point</dfn>. Physical networks can > + be <em>connected at hypervisors</em>. To access a physical network in this > + fashion, a VM must run on a hypervisor that is directly connected to that > + network, that is, its hypervisor must be on the physical network's subnet. > + Alternatively, physical networks can be <em>centrally connected</em>, with > + packets passing through a tunnel to a central point. This model does not > + require hypervisors to have a direct connection to the physical network, > + but it does require setting up and maintaining a central gateway. > + </p> > + > + <p> > + The second axis is the <dfn>degree of NAT</dfn> (network address > + translation). The lowest level of NAT is <em>no NAT</em>, in which VMs are > + directly assigned physical network IP addresses. The next level is <em>IP > + address translation</em>, which translates IP addresses. This allows > + physical and logical IP addresses to be separately allocated. Finally, > + <em>(full) NAT</em> translates IP addresses and transport port numbers. > + Only full NAT allows multiple VMs to share a public IP address. > + </p> > + > + <p> > + These axes are independent. Each pairing yields a different design: > + </p> > + > + <dl> > + <dt>No NAT, connected at hypervisors</dt> > + <dd> > + <p> > + This design extends external IP addresses directly into VMs. A CMS can > + implement this design with OVN using <code>localnet</code> ports. VLAN > + tagging is optional. > + </p> > + > + <p> > + OVN doesn't add any value to this kind of physical network > + connectivity, because plugging the VM's interface directly into a > + physical network bridge works just as well. OVN provides this option > + for use by CMSes (e.g. OpenStack Neutron) that require all of the > + network connectivity on a hypervisor to go through a single networking > + provider (i.e. OVN). OVN provides some functional value beyond just centralized management in this case. Basic port security and ACLs are useful here, at least. > + </p> > + </dd> > + > + <dt>IP address translation, connected at hypervisors</dt> > + <dd> > + <p> > + This design uses separate ranges of external and internal IP addresses > + and translates addresses in IP and ARP packets that cross in either > + direction. > + </p> > + > + <p> > + OVN will implement direct support for this case. For now, one can When you say "for now", do you mean OVN will do this, or that it will work if some external entity does this? We can't really do this from Neutron since we don't have an agent running on each hypervisor. ovn-controller would have to do it. > + implement it with an <code>localnet</code> port that patches to an > + isolated bridge. Configure the desired public IP address on the > + bridge, plus the private IP address's gateway IP. Then use > + <code>iptables</code> rules to translate addresses. For example, with > + private IP <code>$PRV</code> and public IP <code>$PUB</code> that is > + routed to physical network device <code>$ETH</code>: > + </p> > + > + <pre> > +iptables -t nat -A POSTROUTING -s $PRV -o $ETH -j SNAT --to-source $PUB > +iptables -t nat -A PREROUTING -d $PUB -i $ETH -j DNAT --to-destination $PRV > + </pre> > + </dd> > + > + <dt>Other pairings</dt> > + <dd> > + OVN will implement support for other pairings as well. Details TBD. > + </dd> > + </dl> > + > <h2>Life Cycle of a VIF</h2> > > <p> >
> On Oct 22, 2015, at 9:28 AM, Ben Pfaff <blp@nicira.com> wrote: > > + The first axis is the <dfn>connection point</dfn>. Physical networks can > + be <em>connected at hypervisors</em>. To access a physical network in this > + fashion, a VM must run on a hypervisor that is directly connected to that > + network, that is, its hypervisor must be on the physical network's subnet. > + Alternatively, physical networks can be <em>centrally connected</em>, with > + packets passing through a tunnel to a central point. This model does not > + require hypervisors to have a direct connection to the physical network, > + but it does require setting up and maintaining a central gateway. I worry a bit that our use of "physical networks" is a bit muddy. In particular, the physical networks described here versus a VTEP bridging physical workloads. > + The second axis is the <dfn>degree of NAT</dfn> (network address > + translation). The lowest level of NAT is <em>no NAT</em>, in which VMs are > + directly assigned physical network IP addresses. The next level is <em>IP > + address translation</em>, which translates IP addresses. This allows This is probably a losing terminology battle, but I think this is really called NAT... > + physical and logical IP addresses to be separately allocated. Finally, > + <em>(full) NAT</em> translates IP addresses and transport port numbers. > + Only full NAT allows multiple VMs to share a public IP address. ...and this is called PAT. I think it may be useful to use both sets of terms. Or not. Maybe I'm just old. > + OVN doesn't add any value to this kind of physical network > + connectivity, because plugging the VM's interface directly into a > + physical network bridge works just as well. OVN provides this option > + for use by CMSes (e.g. OpenStack Neutron) that require all of the > + network connectivity on a hypervisor to go through a single networking > + provider (i.e. OVN). As Russel mentioned, this seems a little overly negative. > + OVN will implement direct support for this case. For now, one can > + implement it with an <code>localnet</code> port that patches to an s/an/a/ --Justin
On Thu, Oct 22, 2015 at 09:28:51AM -0700, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff <blp@nicira.com>
I'm abandoning this patch.
Hi Ben, Could you share the reason of abandoning? Looking forward to a new patch regarding this topic. Han On Tue, Nov 3, 2015 at 1:42 PM, Ben Pfaff <blp@nicira.com> wrote: > On Thu, Oct 22, 2015 at 09:28:51AM -0700, Ben Pfaff wrote: > > Signed-off-by: Ben Pfaff <blp@nicira.com> > > I'm abandoning this patch. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev >
More accurately, I'm abandoning the iptables method. There are better ways that avoid using it. I'll be back in a while with better ways to connect to physical networks. On Tue, Nov 03, 2015 at 02:48:15PM -0800, Han Zhou wrote: > Hi Ben, > > Could you share the reason of abandoning? Looking forward to a new patch > regarding this topic. > > Han > > On Tue, Nov 3, 2015 at 1:42 PM, Ben Pfaff <blp@nicira.com> wrote: > > > On Thu, Oct 22, 2015 at 09:28:51AM -0700, Ben Pfaff wrote: > > > Signed-off-by: Ben Pfaff <blp@nicira.com> > > > > I'm abandoning this patch. > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > >
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index 318555b..8ae148e 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -309,6 +309,89 @@ </li> </ul> + <h2>Connecting Logical Networks to Physical Networks</h2> + + <p> + Logical networks can be useful by themselves for use within a cloud, but + ordinarily at least some part of a cloud deployment will need to connect to + external physical networks. OVN supports multiple ways to connect to + physical networks. These methods can be classified along two axes. + </p> + + <p> + The first axis is the <dfn>connection point</dfn>. Physical networks can + be <em>connected at hypervisors</em>. To access a physical network in this + fashion, a VM must run on a hypervisor that is directly connected to that + network, that is, its hypervisor must be on the physical network's subnet. + Alternatively, physical networks can be <em>centrally connected</em>, with + packets passing through a tunnel to a central point. This model does not + require hypervisors to have a direct connection to the physical network, + but it does require setting up and maintaining a central gateway. + </p> + + <p> + The second axis is the <dfn>degree of NAT</dfn> (network address + translation). The lowest level of NAT is <em>no NAT</em>, in which VMs are + directly assigned physical network IP addresses. The next level is <em>IP + address translation</em>, which translates IP addresses. This allows + physical and logical IP addresses to be separately allocated. Finally, + <em>(full) NAT</em> translates IP addresses and transport port numbers. + Only full NAT allows multiple VMs to share a public IP address. + </p> + + <p> + These axes are independent. Each pairing yields a different design: + </p> + + <dl> + <dt>No NAT, connected at hypervisors</dt> + <dd> + <p> + This design extends external IP addresses directly into VMs. A CMS can + implement this design with OVN using <code>localnet</code> ports. VLAN + tagging is optional. + </p> + + <p> + OVN doesn't add any value to this kind of physical network + connectivity, because plugging the VM's interface directly into a + physical network bridge works just as well. OVN provides this option + for use by CMSes (e.g. OpenStack Neutron) that require all of the + network connectivity on a hypervisor to go through a single networking + provider (i.e. OVN). + </p> + </dd> + + <dt>IP address translation, connected at hypervisors</dt> + <dd> + <p> + This design uses separate ranges of external and internal IP addresses + and translates addresses in IP and ARP packets that cross in either + direction. + </p> + + <p> + OVN will implement direct support for this case. For now, one can + implement it with an <code>localnet</code> port that patches to an + isolated bridge. Configure the desired public IP address on the + bridge, plus the private IP address's gateway IP. Then use + <code>iptables</code> rules to translate addresses. For example, with + private IP <code>$PRV</code> and public IP <code>$PUB</code> that is + routed to physical network device <code>$ETH</code>: + </p> + + <pre> +iptables -t nat -A POSTROUTING -s $PRV -o $ETH -j SNAT --to-source $PUB +iptables -t nat -A PREROUTING -d $PUB -i $ETH -j DNAT --to-destination $PRV + </pre> + </dd> + + <dt>Other pairings</dt> + <dd> + OVN will implement support for other pairings as well. Details TBD. + </dd> + </dl> + <h2>Life Cycle of a VIF</h2> <p>
Signed-off-by: Ben Pfaff <blp@nicira.com> --- ovn/ovn-architecture.7.xml | 83 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+)