Open Stack

Sure Brandon,

My files ml2_conf.init looks like this:

---
[ml2]
type_drivers = vlan
tenant_network_types = vlan
mechanism_drivers = openvswitch

[ml2_type_flat]

[ml2_type_vlan]
network_vlan_ranges = physnet1:2090:4094

[ml2_type_gre]

[ml2_type_vxlan]

[securitygroup]
enable_security_group = True
firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs]
enable_tunneling = False
tenant_network_type = vlan
integration_bridge = br-int
network_vlan_ranges = physnet1:2090:4094
bridge_mappings = physnet1:br-eth1
---

My Compute Nodes have two ethernets, eth0 in for "Node Internet Access at
vlan200" / "Node Management at vlan210" and eth1 is where the "VLAN
Provider Network" traffic flows on top of "br-eth1"...

Then I created each "net" as follows (1 for each tenant):

---
neutron net-create --tenant-id $TENANT1_ID
--provider:physical_network=physnet1 --provider:network_type=vlan
--provider:segmentation_id=2090 physnet1-vlan2090
neutron net-create --tenant-id $TENANT2_ID
--provider:physical_network=physnet1 --provider:network_type=vlan
--provider:segmentation_id=2091 physnet1-vlan2091
---

And after this, I connected via Horizon, to create the "subnets" (both
IPv4-dhcp and IPv6-static).

Hope it helps!   :-)

Cheers!
Thiago


On 13 October 2014 19:17, Brandon Sawyers <brandor5 at gmail.com> wrote:

> I would love to see your config for vlan provider networks. We're
> interested in using these but are running into trouble getting it set up
> correctly, even using the link you provided.
>
> Thanks,
> Brandon
> On Oct 13, 2014 2:40 PM, "Martinx - ジェームズ" <thiagocmartinsc at gmail.com>
> wrote:
>
>> Hey guys,
>>
>> A few people asked me what kind of problems I reached when using
>> GRE/VXLAN tunnels, well, here we go:
>>
>> ---
>> I faced lots of problems with Neutron L3 Router in the past, now, I'm
>> using in production, the topology called "VLAN Provider Networks" (no GRE /
>> VXLAN tunnels, only plain Flat tagged VLANs).
>>
>> Like this:
>>
>>
>> https://developer.rackspace.com/blog/neutron-networking-vlan-provider-networks/
>>
>> It is by far, much more stable, even when with OpenvSwitch. No more
>> Neutron L3 Router... I'll start testing it again, with Juno (because of its
>> native IPv6 support, seems pretty cool, BTW), looking to put it into prod
>> again with K...
>>
>> This way (Flat / VLAN provider), the Network Node runs only the dhcp and
>> the metadata (iptables redirect to compute) services.
>>
>> Also, there is no GRE / VXLAN tunnels, only plain tagged VLANs.
>>
>> I have a guide to configure Flat Provider Network, which is very similar
>> with VLANs (only that it have only 1 LAN, same topology with upstream
>> router), take a look:
>> https://github.com/tmartinx/openstack-guides/tree/master/IceHouse
>>
>> -
>> Neutron L3 Router problems I faced (already fixed) - (there are more
>> problems, like the one you're facing):
>>
>> Directional network performance issues with Neutron + OpenvSwitch:
>> https://bugs.launchpad.net/neutron/+bug/1252900 - huge problem with a
>> simple fix, by disabling gro with ethtool at your L3 Router
>>
>> Attaching a IPv6 private subnet to a L3 Router, breaks it and its IPv4
>> Floating IPs:
>> https://bugs.launchpad.net/neutron/+bug/1322945
>> -
>>
>> Another problem:
>>
>> Neutron router and nf_conntrack performance problems:
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/043269.html
>> ---
>>
>> Not to mention that, when I first deployed OpenStack with Neutron L3
>> couple years ago, everything appeared to be working, Floating IPs, and ICMP
>> connectivity but, when I tried to run "apt-get update" within a Instance.
>> it did not worked... After digging a lot on the Interwebs, I figured out
>> that I was seeing the infamous "MTU problem"... Lowering it to 1450 was the
>> first workaround I touched with Neutron L3...
>>
>> Also, during the life cycle of random instances, it sees too many network
>> outages. Forcing me (the architect / operator) to shutdown the instances
>> lots of times, run `neutron-ovs-cleanup` at the network and compute nodes,
>> compute nodes reboots and then, "out-of-nothing", instance got connectivity
>> again...
>>
>> None of this problems exists on a plain VLAN topology.
>>
>> And BTW, from my point of view, it seems very weird to deploy IPv6
>> connectivity to the instances, on top of IPv4 tunnels! That GRE / VXLAN...
>> While I like the idea of "per-tenant routers with private networks", I also
>> like the idea of stability and of the performance of plain (V)LANs. Q-in-Q
>> seems a nice approach either.
>>
>> -
>>  Thiago
>>
>> On 9 October 2014 23:17, Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>> wrote:
>>
>>> Just for the record, I gave up on Neutron L3 Router, powered by
>>> GRE/VXLAN tunnels. There are too many problems on this architecture.
>>> I'm using Flat/VLAN Provider Networks right now (still with OpenvSwitch
>>> but, no problems), I'm looking for a new solution (with IPv6), I'll take a
>>> look at OpenContrail!
>>>
>>> Thanks!
>>>
>>> On 9 October 2014 20:35, Rudrajit Tapadar <
>>> rudrajit.tapadar+osgen at gmail.com> wrote:
>>>
>>>> At Symantec's Cloud Platform Engineering, we have deployed
>>>> OpenStack+OpenContrail at a fairly large scale. I can't give you exact
>>>> numbers, but you can get some data points from our SDN evaluation
>>>> presentation in the Atlanta summit:
>>>> https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/software-defined-networking-performance-and-architecture-evaluation
>>>>
>>>>
>>>> On Mon, Sep 29, 2014 at 4:14 PM, Raghu Vadapalli <rvatspacket at gmail.com
>>>> > wrote:
>>>>
>>>>>
>>>>> On 09/29/2014 01:52 PM, Tim Bell wrote:
>>>>>
>>>>>
>>>>>
>>>>> Are there any references for people running OpenContrail at scale ?
>>>>>
>>>>>
>>>>>
>>>>> Though reference are good to have, in general, L3 networks are known
>>>>> to scale better than L2 networks.
>>>>> Having said that, the complexity of two large frameworks  OpenStack +
>>>>> OpenContrail working together nicely in
>>>>> deployment is not known to me. Any ideas ?
>>>>>
>>>>>    *From:* NAPIERALA, MARIA H [mailto:mn1921 at att.com <mn1921 at att.com>]
>>>>>
>>>>> *Sent:* 29 September 2014 19:26
>>>>> *To:* dennisml at conversis.de
>>>>> *Cc:* openstack at lists.openstack.org
>>>>> *Subject:* Re: [Openstack] Rackspace abandons Open vSwitch ?
>>>>>
>>>>>
>>>>>
>>>>> ……
>>>>>
>>>>>   > What are the alternatives though? As far as I know the regular
>>>>> linux
>>>>>
>>>>> > bridge lacks most of the features of OVS and these are the only to
>>>>>
>>>>> > options I've played with so far. Is the a third alternative out there
>>>>>
>>>>> > that they've switched to?
>>>>>
>>>>>
>>>>>
>>>>> One alternative is OpenContrail vRouter as ML3 plugin. It meets the
>>>>> scale and feature requirements.
>>>>>
>>>>>
>>>>>
>>>>> Maria
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>> Post to     : openstack at lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list:
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>> Post to     : openstack at lists.openstack.org
>>>>> Unsubscribe :
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe :
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141013/88aad857/attachment.html>