diff mbox series

[ovs-dev,ovn,v2] ovn-openstack.rst: Correct IP for Adding a Gateway

Message ID 20200721103812.4081424-1-yili@winhong.com
State Accepted
Headers show
Series [ovs-dev,ovn,v2] ovn-openstack.rst: Correct IP for Adding a Gateway | expand

Commit Message

Yi Li July 21, 2020, 10:38 a.m. UTC
Correct the VM 'd' private IP address
on the Adding a Gateway Section.

Signed-off-by: Yi Li <yili@winhong.com>
---
 Documentation/tutorials/ovn-openstack.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Dumitru Ceara Aug. 7, 2020, 8:12 a.m. UTC | #1
On 7/21/20 12:38 PM, Yi Li wrote:
> Correct the VM 'd' private IP address
> on the Adding a Gateway Section.
> 
> Signed-off-by: Yi Li <yili@winhong.com>

Looks good to me, thanks!

Acked-by: Dumitru Ceara <dceara@redhat.com>
Numan Siddique Aug. 7, 2020, 10:29 a.m. UTC | #2
On Fri, Aug 7, 2020 at 1:42 PM Dumitru Ceara <dceara@redhat.com> wrote:
>
> On 7/21/20 12:38 PM, Yi Li wrote:
> > Correct the VM 'd' private IP address
> > on the Adding a Gateway Section.
> >
> > Signed-off-by: Yi Li <yili@winhong.com>
>
> Looks good to me, thanks!
>
> Acked-by: Dumitru Ceara <dceara@redhat.com>

Thanks. I applied this patch to master.

Numan

>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
diff mbox series

Patch

diff --git a/Documentation/tutorials/ovn-openstack.rst b/Documentation/tutorials/ovn-openstack.rst
index 2e4f6340..4eae486e 100644
--- a/Documentation/tutorials/ovn-openstack.rst
+++ b/Documentation/tutorials/ovn-openstack.rst
@@ -1410,7 +1410,7 @@  and the router between them::
 What we see is:
 
 * VM ``d`` is on the "private" switch under its private IP address
-  10.0.0.8.  The "private" switch is connected to "router1" via two
+  10.0.0.6.  The "private" switch is connected to "router1" via two
   router ports (one for IPv4, one for IPv6).
 
 * The "public" switch is connected to "router1" and to the physical
@@ -1420,14 +1420,14 @@  What we see is:
   addition to the router ports that connect to these switches, it has
   "nat" entries that direct network address translation.  The
   translation between floating IP address 172.24.4.8 and private
-  address 10.0.0.8 makes perfect sense.
+  address 10.0.0.6 makes perfect sense.
 
 When the NB DB gets translated into logical flows at the southbound
 layer, the "nat" entries get translated into IP matches that then
 invoke "ct_snat" and "ct_dnat" actions.  The details are intricate,
 but you can get some of the idea by just looking for relevant flows::
 
-  $ ovn-sbctl lflow-list router1 | abbrev | grep nat | grep -E '172.24.4.8|10.0.0.8'
+  $ ovn-sbctl lflow-list router1 | abbrev | grep nat | grep -E '172.24.4.8'
     table=3 (lr_in_unsnat       ), priority=100  , match=(ip && ip4.dst == 172.24.4.8 && inport == "lrp-ae9b52" && is_chassis_resident("cr-lrp-ae9b52")), action=(ct_snat;)
     table=3 (lr_in_unsnat       ), priority=50   , match=(ip && ip4.dst == 172.24.4.8), action=(reg9[0] = 1; next;)
     table=4 (lr_in_dnat         ), priority=100  , match=(ip && ip4.dst == 172.24.4.8 && inport == "lrp-ae9b52" && is_chassis_resident("cr-lrp-ae9b52")), action=(ct_dnat(10.0.0.6);)
@@ -1459,7 +1459,7 @@  The first two stanzas just show the packet traveling through the
 In "router1", first the ``ct_snat`` action without an argument
 attempts to "un-SNAT" the packet.  ovn-trace treats this as a no-op,
 because it doesn't have any state for tracking connections.  As an
-alternative, it invokes ``ct_dnat(10.0.0.8)`` to NAT the destination
+alternative, it invokes ``ct_dnat(10.0.0.6)`` to NAT the destination
 IP::
 
   ingress(dp="router1", inport="lrp-ae9b52")