[NETVIRT-1174] IPv6 GUA L2 connectivity (SLAAC) is broken (network wasn't associated with any router, hence VPN) Created: 23/Mar/18  Updated: 26/Mar/18  Resolved: 26/Mar/18

Status: Resolved
Project: netvirt
Component/s: None
Affects Version/s: None
Fix Version/s: Fluorine

Type: Bug Priority: High
Reporter: Valentina Krasnobaeva Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

IPv6 L2 connectivity (SLAAC) is broken

1. neutron net-create N

2. openstack subnet create --network N --subnet-range 2001:db3:0:2::/64 SUB6_3 --ip-version=6 --ipv6-address-mode=slaac --ipv6-ra-mode=slaac --allocation-pool start=2001:db3:0:2::2,end =2001:db3:0:2:ffff:ffff:ffff:fffe

3. neutron security-group-create SG

openstack security group rule create SG --egress --ethertype IPv6 --dst-port 1:65535 --protocol udp
openstack security group rule create SG --inress --ethertype IPv6 --dst-port 1:65535 --protocol udp
openstack security group rule create SG --egress --ethertype IPv6 --dst-port 1:65535 --protocol tcp
openstack security group rule create SG --inress --ethertype IPv6 --dst-port 1:65535 --protocol tcp
openstack security group rule create SG --egress --ethertype IPv6 --protocol icmp
openstack security group rule create SG --inress --ethertype IPv6 --protocol icmp

openstack security group rule create SG --egress --ethertype IPv4 --dst-port 1:65535 --protocol udp
openstack security group rule create SG --inress --ethertype IPv4 --dst-port 1:65535 --protocol udp
openstack security group rule create SG --egress --ethertype IPv4 --dst-port 1:65535 --protocol tcp
openstack security group rule create SG --inress --ethertype IPv4 --dst-port 1:65535 --protocol tcp
openstack security group rule create SG --egress --ethertype IPv4 --protocol icmp
openstack security group rule create SG --inress --ethertype IPv4 --protocol icmp

4. openstack port create --network N PORT1 --security-group SG  --allowed-address ip-address=3001:db8:cafe:d::/64 --allowed-address ip-address=3001:db8:abcd:d::/64

openstack port create --network N PORT2 --security-group SG  --allowed-address ip-address=3001:db8:cafe:d::/64 --allowed-address ip-address=3001:db8:abcd:d::/64

5. openstack server create --image cirros-0.3.4-x86_64-uec --flavor m1.tiny --nic port-id=0c8595f2-8960-44a8-ab14-e50c132e3d83 --security-group SG VM

openstack server create --image cirros-0.3.4-x86_64-uec --flavor m1.tiny --nic port-id=e25ac678-79fb-47ea-8894-1dd88ad0ce12 --security-group SG VM1

Nova shows VMs IPv6 addresses:

root@controller-deray:~# nova list
-------------------------------------------------------------------------------------------------------+

ID Name Status Task State Power State Networks

-------------------------------------------------------------------------------------------------------+

28931f75-4493-4151-ace8-c27411c9c7ff VM ACTIVE
Running N=2001:db9:0:2:f816:3eff:fe9a:5f0d
e188185c-74f4-4b36-ac24-a97d8295b69e VM1 ACTIVE
Running N=2001:db9:0:2:f816:3eff:fe52:3053

but actually VMs do not receive its IPv6 addresses and if we will ping them from N-network qdhcp-namespace, we see, that L2 IPv6 connectivity is broken:

~# ip netns exec qdhcp-deaa20fb-b9c4-470a-b7bf-09dc3b739730 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
34: tapf738b58d-f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1408 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:0b:e7:d4 brd ff:ff:ff:ff:ff:ff
inet 169.254.169.254/16 brd 169.254.255.255 scope global tapf738b58d-f2
valid_lft forever preferred_lft forever
inet6 2001:db9:0:2:f816:3eff:fe0b:e7d4/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe0b:e7d4/64 scope link
valid_lft forever preferred_lft forever

  1. ip netns exec qdhcp-deaa20fb-b9c4-470a-b7bf-09dc3b739730 ping6 2001:db9:0:2:f816:3eff:fe9a:5f0d
    PING 2001:db9:0:2:f816:3eff:fe9a:5f0d(2001:db9:0:2:f816:3eff:fe9a:5f0d) 56 data bytes
    ^C
      • 2001:db9:0:2:f816:3eff:fe9a:5f0d ping statistics —
        3 packets transmitted, 0 received, 100% packet loss, time 2016ms
  2. ip netns exec qdhcp-deaa20fb-b9c4-470a-b7bf-09dc3b739730 ping6 2001:db9:0:2:f816:3eff:fe52:3053
    PING 2001:db9:0:2:f816:3eff:fe52:3053(2001:db9:0:2:f816:3eff:fe52:3053) 56 data bytes
    From 2001:db9:0:2:f816:3eff:fe0b:e7d4 icmp_seq=1 Destination unreachable: Address unreachable
    From 2001:db9:0:2:f816:3eff:fe0b:e7d4 icmp_seq=2 Destination unreachable: Address unreachable
    From 2001:db9:0:2:f816:3eff:fe0b:e7d4 icmp_seq=3 Destination unreachable: Address unreachable
    ^C
      • 2001:db9:0:2:f816:3eff:fe52:3053 ping statistics —
        4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3015ms

If we reproduce the same steps with IPv4-only, network L2 connectivity works well.

Just to recheck, security-group-rule-list:

~# neutron security-group-rule-list | grep SG
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.

2a3f5e03-f510-4d73-aa0c-c2f3a2f9a70d 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv4 1-65535/tcp 0.0.0.0/0 (CIDR)
35f3b844-bb84-4208-8af8-52afd27d558c 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv6 any any
4143dbb4-609d-48ef-a56d-d3c9df9ad718 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv4 1-65535/udp 0.0.0.0/0 (CIDR)
55aafddd-0265-4323-b400-2dd1b0825c67 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv6 1-65535/tcp any
64b564ae-de8e-445c-924e-86917dbddc8d 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv4 icmp 0.0.0.0/0 (CIDR)
83f0dc7d-9c08-4291-9f90-a71e978fef42 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv6 icmp any
8dce78a6-e80b-45bb-9559-32f017af0583 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv4 1-65535/tcp 0.0.0.0/0 (CIDR)
90067085-010c-42da-8255-f7f553eab255 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv6 1-65535/udp any
96eff42d-57d5-4300-b520-6a4e60a12f8f 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv4 any any
9891f923-af6c-4eed-b695-e36134978b95 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv4 icmp 0.0.0.0/0 (CIDR)
9a3e6607-f137-42c0-af04-d1c1fce85451 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv6 1-65535/tcp any
a1bfc1b9-6858-40ce-a9a9-b7b0bdd552c9 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv6 1-65535/udp any
aa59c493-a520-4de9-a9d9-8b141fde974a 11d9ec262ca542e29d9b4dd94940fc24 SG egress IPv6 icmp any
d0c2b652-c648-4927-8192-d0b4341efc61 11d9ec262ca542e29d9b4dd94940fc24 SG ingress IPv4 1-65535/udp 0.0.0.0/0 (CIDR)


 Comments   
Comment by Valentina Krasnobaeva [ 26/Mar/18 ]

not a bug

Generated at Wed Feb 07 20:23:25 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.