Thank you, sir. I'll let you know how it goes. Brandon On Oct 13, 2014 6:37 PM, "Martinx - ジェームズ" <thiagocmarti...@gmail.com> wrote:
> 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 <brand...@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 - ジェームズ" <thiagocmarti...@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 - ジェームズ <thiagocmarti...@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+os...@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 < >>>>> rvatspac...@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:mn1...@att.com <mn1...@att.com>] >>>>>> >>>>>> *Sent:* 29 September 2014 19:26 >>>>>> *To:* denni...@conversis.de >>>>>> *Cc:* openstack@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@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@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@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@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@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack