Open Stack

You don't need "per project vlans" for inbound and outbound access. Public
Ips only need a single VLAN between the logical routers
(net-hosts/l3-agent hosts) and their next hop... It's the internal
networks which require multiple VLANs if you wish to do such a thing, and
those VLANs are only necessary on your internal switches. Alternatively
you can use GRE or STT or some other segregation method and avoid the VLAN
cap altogether (on internal networks).

Basically, the flow looks like so:

Internet -> Floating IP (hosted on your logical router host... All a
single "public VLAN") -> NAT translation to internal tenant subnet (and
tagged with the "internal OVS VLAN" -> VLAN translation flow (if it needs
to go to the wire) tags the packet with the VLAN assigned to the tenant's
subnet (or goes over the requisite GRE tunnel) -> ...

It's kind of complicated, I know, but hopefully that helps some? Or
perhaps I just misunderstood your scenario/question, which is also
entirely possible :-D


On 7/15/15, 9:24 AM, "Adam Huffman" <adam.huffman at gmail.com> wrote:

>Hello
>
>We're at the stage of working out how to integrate our Icehouse system
>with the external network, using Neutron.
>
>We have a limited set of public IPs available for inbound access, and
>we'd also like to make outbound access optional, in case some projects
>want to be completely isolated.
>
>One suggestion is as follows:
>
>- each project is allocated a single /24 VLAN
>
>- within this VLAN, there are 2 subnets
>
>- the first subnet (/25) would be for outbound access, using floating IPs
>
>- the second (/25) subnet would be for inbound access, drawing from
>the limited public pool, also with floating IPs
>
>Does that sound sensible/feasible? The Cisco hardware that's providing
>the route to the external network has constraints in the numbers of
>VLANs it will support, so we prefer this approach to having separate
>per-project VLANs for outbound and inbound access.
>
>If there's a different way of achieving this, I'd be interested to
>hear that too.
>
>
>Cheers,
>Adam
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators