<p dir="ltr">Does the decision about the floating IP have to be based on the use of the private IP in the original destination, or could you get by with rules on the L3 agent to avoid NAT just based on the destination being in a configured set of CIDRs? </p>
<p dir="ltr">If you could get by with the latter it would be a much simpler problem to solve. However, I suspect you will want the former to be able to connect to floating IPs internally as well. </p>
<div class="gmail_quote">On Mar 28, 2015 12:24 PM, "Steve Wormley" <<a href="mailto:openstack@wormley.com">openstack@wormley.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Sat, Mar 28, 2015 at 1:57 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You want floating IPs at each compute node, and DVR with VLAN support got you close. Are the floating IPs okay being on a different network/VLAN? </div></blockquote><div> </div><div>I should clarify, the floating IPs are publicly routable addresses, as opposed to instances on RFC1918 space. This is the 'standard' neutron and nova-network floating IP model. Nothing really special there.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Which address do you expect the source to be when an instance communicates outside of its network (no existing connection state)? You mentioned having the L3 agent ARP for a different gateway, do you still want the floating IP translation to happen before that? Is there any case where it should ever be via the private address?</div></div></blockquote><div> </div><div>Instances with assigned floating IP addresses initiating connections are NATted and go out the floating IP. In reality, we special case all RFC 1918 space to not trigger the floating IP. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The header mangling is to make up for the fact that traffic coming to the floating IP gets translated by the L3 agent before it makes it to the instance so there is no way to distinguish whether the floating IP or private IP was targeted. Is that correct?<br></div></div></blockquote><div><br>Basically. Traffic coming in on a tenant vlan to the instance is mangled by the first OVS rule it hits to indicate it came in via a private interface/subnet/VLAN. It then hits iptables on the instance Linux bridge with turns the header bits onto a conntrack mark. The outbound packets from the instance for connection gets the conntrack mark changed back to a header bit. If this packet then hits iptables in the qrouter namespace where it's turned into a normal fwmark/nfmark. That mark is used to disable NAT for the packet and flags the ip route rules to not send the packet to the FIP namespace but to instead let it flow normally.<br><br></div><div>Of course, all this horribleness is because the veth drivers in Linux wipe the SKB Mark(fwmark/nfmark) so I have no way to persistently track a packet across the OVS-veth-Linux Bridge boundaries.</div><div><br></div><div>-Steve Wormley<br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>