Open Stack

I really appreciate your help Jorge and David!

After far to many hours of troubleshooting the root cause ended up being
caused by the IPv6 Privacy Extensions (RFC 4941) that is on with Windows by
default... Had I mentioned these issues were happening on a Windows
instance, you guys would have undoubtedly zeroed in on this root cause too.
With Privacy Extensions, Windows 10 was contriving a random arrangement for
the host bits of the IPv6 address, instead of using the EUI-64 construct
that Openstack was expecting for the Link Local address. Some folks on the
Neutron IRC channel really helped out with pointing us in the correct
direction. Looking closer at the iptables ruleset associated with the
respective VM, we noticed the Chain that verified the source Link Local
IPv6 address was the EUI-64 format showed a different Link Local address
then what Windows had assigned to it's NIC. Once we turned off Privacy
Extensions in Windows 10, DHCPv6 worked like a charm!

Thanks again for your help!!

Steve

On Wed, Sep 27, 2017 at 6:13 PM, Jorge Luiz Correa <correajl at gmail.com>
wrote:

> Hum, nice inspection.
>
> Try to create rules that pass the IPv6 Multicast addresses and ICMPv6
> protocol. These are the addresses used by IPv6.
>
> FF02:0:0:0:0:0:1:2 All-dhcp-agents
> FF05:0:0:0:0:0:1:3 All-dhcp-servers
>
> I think all-dhcp-agents is sufficient.
>
> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-
> addresses.xhtml
>
> Regards
>
>
> On 27 Sep 2017, at 20:44, Sterdnot Shaken <sterdnotshaken at gmail.com>
> wrote:
>
> So, after more digging, it appears DHCPv6 traffic coming from the test
> VM's is being dropped at the Security Group (Linux Bridge) enforcement
> point ... I can restart a VM's while doing a tcpdump on the respective tap
> interface for that VM and see DHCPv6 request packets being sent out as
> expected, but they never make it through the IPTables rules associated with
> the Linux Bridge that represents the Security Group assigned to the VM.
> Hopefully that makes sense.
>
> The DHCPv6 packets seem to be getting dropped by the last IPTables Drop
> rule:
>
> Chain neutron-openvswi-sd36b2151-0 (1 references)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 RETURN     all      *      *       2604:ba00:ffff:fff2::b
> ::/0                 MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined
> IP/MAC pairs. */
>     0     0 RETURN     all      *      *       fe80::f816:3eff:fe05:c1a3
> ::/0                 MAC FA:16:3E:05:C1:A3 /* Allow traffic from defined
> IP/MAC pairs. */
> * 6475  895K DROP       all      *      *       ::/0
> ::/0                 /* Drop traffic without an IP/MAC allow rule. */*
>
> We've tried creating new Security Groups that explicitly allow ports, but
> still no luck:
>
> Ingress        IPv6     UDP     1 - 65535
> Egress         IPv6     UDP     1 - 65535
>
> Any ideas?
>
> Thanks!
>
> Steve
>
>
>
> On Tue, Sep 26, 2017 at 5:58 PM, Sterdnot Shaken <sterdnotshaken at gmail.com
> > wrote:
>
>> Openstack version: Ocata
>> Mech driver: OVS
>> Security: Linuxbridge
>>
>> Hello!
>>
>> Anyone have any idea why DHCP for IPv4 works fine but DHCP for IPv6
>> doesn't? With Stateless or just SLAAC, the VM's calculate a correct IPv6
>> address from the IPv6 prefix I've assigned, but (for stateless) the
>> instances doesn't get any of the options, like DNS, etc...  Stateful
>> doesn't work at all. I configure a stateful network using a command like
>> this:
>>
>> openstack subnet create --allocation-pool start=2604:ffff:ffff:ffff::2,e
>> nd=2604:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip-version 6
>> --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful
>> --dns-nameserver 2620:0:ccc::2 --network cust01-v6_net0 --subnet-range
>> 2604:ffff:ffff:ffff::/64 cust01-v6_sub0
>>
>> But none of the instances added to that network acquire a v6 address
>> ever. I can statically assign the selected IPv6 address to the respective
>> instance and it can then ping out using v6 just fine. I can also add IPv6
>> DNS addresses to resolv.conf and the instance can correctly resolve as
>> well. This issue happens on both Linux and Windows instances...
>>
>> Any ideas?
>>
>> Thanks in advance!
>>
>> Steve
>>
>
> _______________________________________________
> 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/20170928/ed3a682a/attachment.html>