Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Although the SNAT DVR has some trade off, I still think it is necessary. Here is pros and cons for consideration: pros: save W-E bandwidth high availability (distributed, no single point failure) cons: waste public ips (one ip per compute node vs one ip per l3-agent, if double-SNAT implemented) different tenants may share SNAT source ips compute node requires public interface Under certain deployment, the cons may not cause problems, can we provide SNAT DVR as a alternative option, which can be fully controlled by could admin ? The admin chooses whether use it or not. To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24 then, SNAT from 169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent Functionally it could works, but break the existing normal OAM pattern, which expecting VMs from one tenant share a public IP, but share no IP with other tenant. As I know, at least some customer don't accept this way, they think VMs in different hosts appear as different public IP is very strange. In fact I severely doubt the value of N-S distributing in a real commercialized production environment, including FIP. There are many things that traditional N-S central nodes need to control: security, auditing, logging, and so on, it is not the simple forwarding. We need a tradeoff between performance and policy control model: 1. N-S traffic is usually much less than W-E traffic, do we really need distribute N-S traffic besides W-E traffic? 2. With NFV progress like intel DPDK, we can build very cost-effective service application on commodity x86 server (simple SNAT with 10Gbps/s per core at average Internet packet length) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
I would just add that if I'm not mistaken the DVR work would also include the features currently offered by nova network's 'multi-host' capability. While DVR clearly does a lot more than multi host, keeping SNAT centralized only might not fully satisfy this requirement. Indeed nova-network offers SNAT at the compute node thus achieving distribution of N-S traffic. I agree with Zang's point regarding wasting public IPs. On the other hand one IP per agent with double SNAT might be a reasonable compromise. And in that case I'm not sure whether sharing SNAT source IPs among tenants would have any security implications, so somebody else might comment there. Summarizing, I think that distributing N-S traffic is important, but I don't think that to achieve this we'd necessarily need to implement SNAT at the compute nodes. I have reviewed the l3 agent part of the DVR work, it seems that there will be floating IP distribution at the agent level - but I could not understand whether there will be also SNAT distribution. Salvatore On 3 July 2014 10:45, Zang MingJie zealot0...@gmail.com wrote: Although the SNAT DVR has some trade off, I still think it is necessary. Here is pros and cons for consideration: pros: save W-E bandwidth high availability (distributed, no single point failure) cons: waste public ips (one ip per compute node vs one ip per l3-agent, if double-SNAT implemented) different tenants may share SNAT source ips compute node requires public interface Under certain deployment, the cons may not cause problems, can we provide SNAT DVR as a alternative option, which can be fully controlled by could admin ? The admin chooses whether use it or not. To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24 then, SNAT from 169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent Functionally it could works, but break the existing normal OAM pattern, which expecting VMs from one tenant share a public IP, but share no IP with other tenant. As I know, at least some customer don't accept this way, they think VMs in different hosts appear as different public IP is very strange. In fact I severely doubt the value of N-S distributing in a real commercialized production environment, including FIP. There are many things that traditional N-S central nodes need to control: security, auditing, logging, and so on, it is not the simple forwarding. We need a tradeoff between performance and policy control model: 1. N-S traffic is usually much less than W-E traffic, do we really need distribute N-S traffic besides W-E traffic? 2. With NFV progress like intel DPDK, we can build very cost-effective service application on commodity x86 server (simple SNAT with 10Gbps/s per core at average Internet packet length) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Salvatore, There is FIP distribution at the agent level, in the sense the N/S of FIP for a VM will be hosted on the same compute node. We centralized SNAT from feedback by others. The current design and code only supports centralized SNAT for DVR routers. The design could be modified to allow for distributed SNAT as an option but would be a tough task to get in for the first release of DVR support. We wanted to come in with the basic support first. Yours, Michael Smith Hewlett-Packard Company HP Networking RD 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747 PC Phone: 916 540-1884 Ph: 916 785-0918 Fax: 916 785-1199 From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Thursday, July 03, 2014 3:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut I would just add that if I'm not mistaken the DVR work would also include the features currently offered by nova network's 'multi-host' capability. While DVR clearly does a lot more than multi host, keeping SNAT centralized only might not fully satisfy this requirement. Indeed nova-network offers SNAT at the compute node thus achieving distribution of N-S traffic. I agree with Zang's point regarding wasting public IPs. On the other hand one IP per agent with double SNAT might be a reasonable compromise. And in that case I'm not sure whether sharing SNAT source IPs among tenants would have any security implications, so somebody else might comment there. Summarizing, I think that distributing N-S traffic is important, but I don't think that to achieve this we'd necessarily need to implement SNAT at the compute nodes. I have reviewed the l3 agent part of the DVR work, it seems that there will be floating IP distribution at the agent level - but I could not understand whether there will be also SNAT distribution. Salvatore On 3 July 2014 10:45, Zang MingJie zealot0...@gmail.commailto:zealot0...@gmail.com wrote: Although the SNAT DVR has some trade off, I still think it is necessary. Here is pros and cons for consideration: pros: save W-E bandwidth high availability (distributed, no single point failure) cons: waste public ips (one ip per compute node vs one ip per l3-agent, if double-SNAT implemented) different tenants may share SNAT source ips compute node requires public interface Under certain deployment, the cons may not cause problems, can we provide SNAT DVR as a alternative option, which can be fully controlled by could admin ? The admin chooses whether use it or not. To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24http://169.254.255.0/24 then, SNAT from 169.254.255.0/24http://169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent Functionally it could works, but break the existing normal OAM pattern, which expecting VMs from one tenant share a public IP, but share no IP with other tenant. As I know, at least some customer don't accept this way, they think VMs in different hosts appear as different public IP is very strange. In fact I severely doubt the value of N-S distributing in a real commercialized production environment, including FIP. There are many things that traditional N-S central nodes need to control: security, auditing, logging, and so on, it is not the simple forwarding. We need a tradeoff between performance and policy control model: 1. N-S traffic is usually much less than W-E traffic, do we really need distribute N-S traffic besides W-E traffic? 2. With NFV progress like intel DPDK, we can build very cost-effective service application on commodity x86 server (simple SNAT with 10Gbps/s per core at average Internet packet length) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Paul, Is there a blueprint filed on the subject of logging? This really doesn't have anything to do with DVR. The current solution has no logging either. Carl On Thu, Jun 26, 2014 at 5:41 AM, CARVER, PAUL pc2...@att.com wrote: Original message From: Yi Sun beyo...@gmail.com Date: To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut Yi wrote: +1, I had another email to discuss about FW (FWaaS) and DVR integration. Traditionally, we run firewall with router so that firewall can use route and NAT info from router. since DVR is asymmetric when handling traffic, it is hard to run stateful firewall on top of DVR just like a traditional firewall does . When the NAT is in the picture, the situation can be even worse. Yi Don't forget logging either. In any security concious environment , particularly any place with legal/regulatory/contractual audit requirements a firewall that doesn't keep full logs of all dropped and passed sessions is worthless. Stateless packet dropping doesn't help at all when conducting forensics on an attack that is already known to have occured. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack jack.mcc...@hp.com wrote: If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? It is technically possible to implement default SNAT at the compute node. One approach would be to use a single IP address per compute node as a default SNAT address shared by all VMs on that compute node. While this optimizes for number of external IPs consumed per compute node, the downside is having VMs from different tenants sharing the same default SNAT IP address and conntrack table. That downside may be acceptable for some deployments, but it is not acceptable in others. To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24 then, SNAT from 169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent Another approach would be to use a single IP address per router per compute node. This avoids the multi-tenant issue mentioned above, at the cost of consuming more IP addresses, potentially one default SNAT IP address for each VM on the compute server (which is the case when every VM on the compute node is from a different tenant and/or using a different router). At that point you might as well give each VM a floating IP. Hence the approach taken with the initial DVR implementation is to keep default SNAT as a centralized service. - Jack -Original Message- From: Zang MingJie [mailto:zealot0...@gmail.com] Sent: Wednesday, June 25, 2014 6:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com wrote: Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. SNAT can save more ips than wasted on floating ips 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too Floating ip also need a public NIC on br-ex. Also we can use a separate vlan to handle the network, so this is not a problem So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. BTW, does HA implementation still active ? I haven't seen it has been touched for a while yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Original message From: Yi Sun beyo...@gmail.com Date: To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut Yi wrote: +1, I had another email to discuss about FW (FWaaS) and DVR integration. Traditionally, we run firewall with router so that firewall can use route and NAT info from router. since DVR is asymmetric when handling traffic, it is hard to run stateful firewall on top of DVR just like a traditional firewall does . When the NAT is in the picture, the situation can be even worse. Yi Don't forget logging either. In any security concious environment , particularly any place with legal/regulatory/contractual audit requirements a firewall that doesn't keep full logs of all dropped and passed sessions is worthless. Stateless packet dropping doesn't help at all when conducting forensics on an attack that is already known to have occured. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
From: Zang MingJie [zealot0...@gmail.com] Sent: Thursday, June 26, 2014 6:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack jack.mcc...@hp.com wrote: If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? It is technically possible to implement default SNAT at the compute node. One approach would be to use a single IP address per compute node as a default SNAT address shared by all VMs on that compute node. While this optimizes for number of external IPs consumed per compute node, the downside is having VMs from different tenants sharing the same default SNAT IP address and conntrack table. That downside may be acceptable for some deployments, but it is not acceptable in others. To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24 then, SNAT from 169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent Functionally it could works, but break the existing normal OAM pattern, which expecting VMs from one tenant share a public IP, but share no IP with other tenant. As I know, at least some customer don't accept this way, they think VMs in different hosts appear as different public IP is very strange. In fact I severely doubt the value of N-S distributing in a real commercialized production environment, including FIP. There are many things that traditional N-S central nodes need to control: security, auditing, logging, and so on, it is not the simple forwarding. We need a tradeoff between performance and policy control model: 1. N-S traffic is usually much less than W-E traffic, do we really need distribute N-S traffic besides W-E traffic? 2. With NFV progress like intel DPDK, we can build very cost-effective service application on commodity x86 server (simple SNAT with 10Gbps/s per core at average Internet packet length) Another approach would be to use a single IP address per router per compute node. This avoids the multi-tenant issue mentioned above, at the cost of consuming more IP addresses, potentially one default SNAT IP address for each VM on the compute server (which is the case when every VM on the compute node is from a different tenant and/or using a different router). At that point you might as well give each VM a floating IP. Hence the approach taken with the initial DVR implementation is to keep default SNAT as a centralized service. - Jack -Original Message- From: Zang MingJie [mailto:zealot0...@gmail.com] Sent: Wednesday, June 25, 2014 6:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com wrote: Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. SNAT can save more ips than wasted on floating ips 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too Floating ip also need a public NIC on br-ex. Also we can use a separate vlan to handle the network, so this is not a problem So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. BTW, does HA implementation still active ? I haven't seen it has been touched for a while yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev
[openstack-dev] [Neutron] DVR SNAT shortcut
Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com wrote: Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. SNAT can save more ips than wasted on floating ips 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too Floating ip also need a public NIC on br-ex. Also we can use a separate vlan to handle the network, so this is not a problem So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. BTW, does HA implementation still active ? I haven't seen it has been touched for a while yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? It is technically possible to implement default SNAT at the compute node. One approach would be to use a single IP address per compute node as a default SNAT address shared by all VMs on that compute node. While this optimizes for number of external IPs consumed per compute node, the downside is having VMs from different tenants sharing the same default SNAT IP address and conntrack table. That downside may be acceptable for some deployments, but it is not acceptable in others. Another approach would be to use a single IP address per router per compute node. This avoids the multi-tenant issue mentioned above, at the cost of consuming more IP addresses, potentially one default SNAT IP address for each VM on the compute server (which is the case when every VM on the compute node is from a different tenant and/or using a different router). At that point you might as well give each VM a floating IP. Hence the approach taken with the initial DVR implementation is to keep default SNAT as a centralized service. - Jack -Original Message- From: Zang MingJie [mailto:zealot0...@gmail.com] Sent: Wednesday, June 25, 2014 6:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com wrote: Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. SNAT can save more ips than wasted on floating ips 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too Floating ip also need a public NIC on br-ex. Also we can use a separate vlan to handle the network, so this is not a problem So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. BTW, does HA implementation still active ? I haven't seen it has been touched for a while yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack jack.mcc...@hp.com wrote: If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? It is technically possible to implement default SNAT at the compute node. One approach would be to use a single IP address per compute node as a default SNAT address shared by all VMs on that compute node. While this optimizes for number of external IPs consumed per compute node, the downside is having VMs from different tenants sharing the same default SNAT IP address and conntrack table. That downside may be acceptable for some deployments, but it is not acceptable in others. In fact, it is only acceptable in some very special cases. Another approach would be to use a single IP address per router per compute node. This avoids the multi-tenant issue mentioned above, at the cost of consuming more IP addresses, potentially one default SNAT IP address for each VM on the compute server (which is the case when every VM on the compute node is from a different tenant and/or using a different router). At that point you might as well give each VM a floating IP. Hence the approach taken with the initial DVR implementation is to keep default SNAT as a centralized service. In contrast to moving service to distributed CN, we should take care of keeping them as centralized, especially FIP and FW. I know a lot of customer prefer using some dedicated servers to act as network nodes, which have more NICs(as external connection) than compute nodes, in these cases FIP must be centralized instead of being distributed. As for FW, if we want stateful ACL then DVR can do nothing, except that we think security group is already some kind of FW. - Jack -Original Message- From: Zang MingJie [mailto:zealot0...@gmail.com] Sent: Wednesday, June 25, 2014 6:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong gong...@unitedstack.com wrote: Hi, for each compute node to have SNAT to Internet, I think we have the drawbacks: 1. SNAT is done in router, so each router will have to consume one public IP on each compute node, which is money. SNAT can save more ips than wasted on floating ips 2. for each compute node to go out to Internet, the compute node will have one more NIC, which connect to physical switch, which is money too Floating ip also need a public NIC on br-ex. Also we can use a separate vlan to handle the network, so this is not a problem So personally, I like the design: floating IPs and 1:N SNAT still use current network nodes, which will have HA solution enabled and we can have many l3 agents to host routers. but normal east/west traffic across compute nodes can use DVR. BTW, does HA implementation still active ? I haven't seen it has been touched for a while yong sheng gong On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote: Hi: In current DVR design, SNAT is north/south direction, but packets have to go west/east through the network node. If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? SNAT versus floating ips, can save tons of public ips, in trade of introducing a single failure point, and limiting the bandwidth of the network node. If the SNAT performance problem can be solved, I'll encourage people to use SNAT over floating ips. unless the VM is serving a public service -- Zang MingJie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Another approach would be to use a single IP address per router per compute node. This avoids the multi-tenant issue mentioned above, at the cost of consuming more IP addresses, potentially one default SNAT IP address for each VM on the compute server (which is the case when every VM on the compute node is from a different tenant and/or using a different router). At that point you might as well give each VM a floating IP. Hence the approach taken with the initial DVR implementation is to keep default SNAT as a centralized service. In contrast to moving service to distributed CN, we should take care of keeping them as centralized, especially FIP and FW. I know a lot of customer prefer using some dedicated servers to act as network nodes, which have more NICs(as external connection) than compute nodes, in these cases FIP must be centralized instead of being distributed. As for FW, if we want stateful ACL then DVR can do nothing, except that we think security group is already some kind of FW. +1, I had another email to discuss about FW (FWaaS) and DVR integration. Traditionally, we run firewall with router so that firewall can use route and NAT info from router. since DVR is asymmetric when handling traffic, it is hard to run stateful firewall on top of DVR just like a traditional firewall does . When the NAT is in the picture, the situation can be even worse. Yi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
