Open Stack

Thiago,

You mention static IPv6 addresses for VMs.
How do tenants get their static IPv6 address / how does OpenStack know
which IPv6 address a tenant has?

My local cloud is using "nova-network with multi-host FlatDHCP networking"
and trying to provide IPv4/IPv6 dual-stack.
The VM's IPv4 addresses are managed via dsnmasq DHCPv4 as per usual.

Because the upstream Cisco router sends IPv6 Router Advertisements, VMs
create an IPv6 address using SLAAC (great), but some VMs don't have IPv6
temporary/privacy addressing disabled and so create and use extra IPv6
addresses that OpenStack doesn't know about (bad).
[ We don't control all the VM images that our tenants may wish to run. ]

With Icehouse, Horizon can now set IPv6 security policy, but we are
wondering how to configure it to block IPv6 address spoofing,
... which would also block IPv6 temporary/privacy addresses ... and the VM
would think it can use IPv6, but it wouldn't work.

Is using DHCPv6 a viable option for configuring the IPv6 addresses on VMs?
[ Disable SLAAC by the router setting the M (managed) flag on the Router
Advertisement, and clearing the A (autonomous) flag on the Prefix
Information. ]

Thanks,
    John

On 14 October 2014 09:36, Martinx - ジェームズ <thiagocmartinsc at 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 <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
>>>
>>>
>
> _______________________________________________
> 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/20141021/83b4bbea/attachment.html>