Open Stack

Vivek,
CN to NN Vxlan tunnel is something user/customer configured ?
Or DVR is mandating this VxLan tunnel to reach from NN from CN ? 
Means the packets are encapsulated over network even they are not mandated to do so ? 

Then there should be standard if something is getting done like this.


Thanks & regards,
Keshava.A

-----Original Message-----
From: Narasimhan, Vivekanandan 
Sent: Friday, May 23, 2014 2:49 AM
To: A, Keshava; OpenStack Development Mailing List (not for usage questions); Carl Baldwin
Cc: Grover, Rajeev
Subject: RE: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Keshava,

Tunneled over to network node means:

OVS VXLAN Tunnel will be established between compute node and network node and packets will flow through that OVS VXLAN Tunnel.

NAT'ing and tunneling are not related here.  NAT'ing happens in network node.  Packets that need to reach the external network will be tunneled to NN where SNAT'ing puts them onto external network.

--
Thanks,

Vivek

-----Original Message-----
From: A, Keshava
Sent: Friday, May 23, 2014 1:11 PM
To: OpenStack Development Mailing List (not for usage questions); Carl Baldwin
Cc: Narasimhan, Vivekanandan; Grover, Rajeev; A, Keshava
Subject: RE: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi,
I have one basic question, what is this tunneled over to network node means ? (" At this point, the packet will go back out to br-int and but tunneled over to the network node just like any other intra-network traffic.") What kind of tunnel between Compute to Network Node during SNAT ? 
Why tunneling  will happen during NAT ?

Thanks & regards,
Keshava.A

-----Original Message-----
From: Carl Baldwin [mailto:carl at ecbaldwin.net]
Sent: Thursday, May 22, 2014 3:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi,

I found this message in my backlog from when I was at the summit.
Sorry for the delay in responding.

The "default SNAT" or "dynamic SNAT" use case is one of the last details being worked in the DVR subteam.  That may be why you do not see any code around this in the patches that have been submitted.
Outbound traffic that will use this SNAT address will first enter the IR on the compute host.  In the IR, it will not match against any of the static SNAT addresses for floating IPs.  At that point the packet will be redirected to another port belonging to the central component of the DVR.  This port has an IP address  different from the default gateway address (e.g. 192.168.1.2 instead of 192.168.1.1).  At this point, the packet will go back out to br-int and but tunneled over to the network node just like any other intra-network traffic.

Once the packet hits the central component of the DVR on the network node it will be processed very much like default SNAT traffic is processed in the current Neutron implementation.  Another "interconnect subnet" should not be needed here and would be overkill.

I hope this helps.  Let me know if you have any questions.

Carl

On Fri, May 16, 2014 at 1:57 AM, Wuhongning <wuhongning at huawei.com> wrote:
> Hi DVRers,
>
> I didn't see any detail documents or source code on how to deal with 
> routing packet from DVR node to SNAT gw node. If the routing table see 
> a outside ip, it should be matched with a default route, so for the 
> next hop, which interface will it select?
>
> Maybe another standalone "interconnect subnet" per DVR is needed, 
> which connect each DVR node and optionally, the SNAT gw node. For 
> packets from dvr
> node->snat node, the interconnect subnet act as the "default route" 
> node->for this
> host, and the next hop will be the snat node.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev