| 2016-07-10 04:01:17 |
Trent Lloyd |
bug |
|
|
added bug |
| 2016-07-10 04:03:05 |
Trent Lloyd |
bug task added |
|
nova-compute (Juju Charms Collection) |
|
| 2016-07-11 02:18:29 |
Trent Lloyd |
description |
the LXD bridge subnet setup by juju will interfere with openstack instance
traffic
When juju configures lxd, it sets up an IPv4 subnet from 10.0.0.0/8 in
container/lxd/initialisation.go:findNextAvailableIPv4Subnet()
This network configuration (ultimately written into /etc/default/lxd-bridge)
also configures a MASQUERADE rule in POSROUTING:
root@unsecretive-raelynn:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1472 packets, 145K bytes)
pkts bytes target prot opt in out source destination
1476 145K neutron-openvswi-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0
1476 145K neutron-postrouting-bottom all -- * * 0.0.0.0/0 0.0.0.0/0
4 240 MASQUERADE all -- * * 10.0.0.0/24 !10.0.0.0/24
These POSTROUTING rules are applied to instance traffic including tenant GRE
networks. Though the traffic still goes into the GRE tunnel because this rule
is POSTROUTING, the traffic is masqueraded to the compute servers IP and will
never make it back to the instance.
The instance traffic being routed externally will not work, and it also breaks
the metadata service so the instance will not come up correctly and the issue
can be hard to debug.
See also the same issue caused by libvirt-bin's default network in #1387390
Using this method to configure a network will never be safe, for the same
reason lxd recently removed all default network configuration out of the box.
Given the lxd containers are mostly bridged by juju, do we even need to
configure this default subnet? It will work fine without it in bridged mode, as
it does in the default out of the box configuration. I have no idea if juju
can somehow use these non-bridged interfaces, but even if it can I think that
this setup needs to be explicitly configured manually.
How to test:
(1) Setup an openstack installation (tested setup was juju
2.0-beta11-xenial-amd64, xenial-mitaka charms)
(2) Check which subnet the lxd containers are configured for, in my case it was
simply 10.0.0.0/8 but can vary because of the detection code if you are using
10.0.0.0/8 subnets. Setup a GRE tenant network with this subnet.
(3) Setup a router for this tenant network, optionally create and connect an
external network (not strictly necessary but hard to test/debug/observe without)
(4) Boot a new instance, observe the instance cannot contact metadata service.
If you tcpdump the qrouter namespaces qg interface or the compute host, you
will see the traffic is coming from the compute node's IP and not the instance's |
the LXD bridge subnet setup by juju will interfere with openstack instance traffic
When juju configures lxd, it sets up an IPv4 subnet from 10.0.0.0/8 in
container/lxd/initialisation.go:findNextAvailableIPv4Subnet()
This network configuration (ultimately written into /etc/default/lxd-bridge)
also configures a MASQUERADE rule in POSROUTING:
root@unsecretive-raelynn:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1472 packets, 145K bytes)
pkts bytes target prot opt in out source destination
1476 145K neutron-openvswi-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0
1476 145K neutron-postrouting-bottom all -- * * 0.0.0.0/0 0.0.0.0/0
4 240 MASQUERADE all -- * * 10.0.0.0/24 !10.0.0.0/24
These POSTROUTING rules are applied to instance traffic including tenant GRE networks. Though the traffic still goes into the GRE tunnel because this rule is POSTROUTING, the traffic is masqueraded to the compute servers IP and will never make it back to the instance.
The instance traffic being routed externally will not work, and it also breaks
the metadata service so the instance will not come up correctly and the issue
can be hard to debug.
See also the same issue caused by libvirt-bin's default network in #1387390
Using this method to configure a network will never be safe, for the same
reason lxd recently removed all default network configuration out of the box.
Given the lxd containers are mostly bridged by juju, do we even need to
configure this default subnet? It will work fine without it in bridged mode, as
it does in the default out of the box configuration. I have no idea if juju
can somehow use these non-bridged interfaces, but even if it can I think that
this setup needs to be explicitly configured manually.
How to test:
(1) Setup an openstack installation (tested setup was juju
2.0-beta11-xenial-amd64, xenial-mitaka charms)
(2) Check which subnet the lxd containers are configured for, in my case it was
simply 10.0.0.0/8 but can vary because of the detection code if you are using
10.0.0.0/8 subnets. Setup a GRE tenant network with this subnet.
(3) Setup a router for this tenant network, optionally create and connect an
external network (not strictly necessary but hard to test/debug/observe without)
(4) Boot a new instance, observe the instance cannot contact metadata service.
If you tcpdump the qrouter namespaces qg interface or the compute host, you
will see the traffic is coming from the compute node's IP and not the instance's |
|
| 2016-07-11 02:19:24 |
Trent Lloyd |
description |
the LXD bridge subnet setup by juju will interfere with openstack instance traffic
When juju configures lxd, it sets up an IPv4 subnet from 10.0.0.0/8 in
container/lxd/initialisation.go:findNextAvailableIPv4Subnet()
This network configuration (ultimately written into /etc/default/lxd-bridge)
also configures a MASQUERADE rule in POSROUTING:
root@unsecretive-raelynn:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1472 packets, 145K bytes)
pkts bytes target prot opt in out source destination
1476 145K neutron-openvswi-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0
1476 145K neutron-postrouting-bottom all -- * * 0.0.0.0/0 0.0.0.0/0
4 240 MASQUERADE all -- * * 10.0.0.0/24 !10.0.0.0/24
These POSTROUTING rules are applied to instance traffic including tenant GRE networks. Though the traffic still goes into the GRE tunnel because this rule is POSTROUTING, the traffic is masqueraded to the compute servers IP and will never make it back to the instance.
The instance traffic being routed externally will not work, and it also breaks
the metadata service so the instance will not come up correctly and the issue
can be hard to debug.
See also the same issue caused by libvirt-bin's default network in #1387390
Using this method to configure a network will never be safe, for the same
reason lxd recently removed all default network configuration out of the box.
Given the lxd containers are mostly bridged by juju, do we even need to
configure this default subnet? It will work fine without it in bridged mode, as
it does in the default out of the box configuration. I have no idea if juju
can somehow use these non-bridged interfaces, but even if it can I think that
this setup needs to be explicitly configured manually.
How to test:
(1) Setup an openstack installation (tested setup was juju
2.0-beta11-xenial-amd64, xenial-mitaka charms)
(2) Check which subnet the lxd containers are configured for, in my case it was
simply 10.0.0.0/8 but can vary because of the detection code if you are using
10.0.0.0/8 subnets. Setup a GRE tenant network with this subnet.
(3) Setup a router for this tenant network, optionally create and connect an
external network (not strictly necessary but hard to test/debug/observe without)
(4) Boot a new instance, observe the instance cannot contact metadata service.
If you tcpdump the qrouter namespaces qg interface or the compute host, you
will see the traffic is coming from the compute node's IP and not the instance's |
the LXD bridge subnet setup by juju will interfere with openstack instance traffic
When juju configures lxd, it sets up an IPv4 subnet from 10.0.0.0/8 in container/lxd/initialisation.go:findNextAvailableIPv4Subnet()
This network configuration (ultimately written into /etc/default/lxd-bridge) also configures a MASQUERADE rule in POSROUTING
root@unsecretive-raelynn:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1472 packets, 145K bytes)
pkts bytes target prot opt in out source destination
1476 145K neutron-openvswi-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0
1476 145K neutron-postrouting-bottom all -- * * 0.0.0.0/0 0.0.0.0/0
4 240 MASQUERADE all -- * * 10.0.0.0/24 !10.0.0.0/24
These POSTROUTING rules are applied to instance traffic including tenant GRE networks. Though the traffic still goes into the GRE tunnel because this rule is POSTROUTING, the traffic is masqueraded to the compute servers IP and will never make it back to the instance.
The instance traffic being routed externally will not work, and it also breaks the metadata service so the instance will not come up correctly and the issue can be hard to debug.
See also the same issue caused by libvirt-bin's default network in #1387390
Using this method to configure a network will never be safe, for the same reason lxd recently removed all default network configuration out of the box.
Given the lxd containers are mostly bridged by juju, do we even need to configure this default subnet? It will work fine without it in bridged mode, as it does in the default out of the box configuration. I have no idea if juju can somehow use these non-bridged interfaces, but even if it can I think that this setup needs to be explicitly configured manually.
How to test:
(1) Setup an openstack installation (tested setup was juju 2.0-beta11-xenial-amd64, xenial-mitaka charms)
(2) Check which subnet the lxd containers are configured for, in my case it was simply 10.0.0.0/8 but can vary because of the detection code if you are using 10.0.0.0/8 subnets. Setup a GRE tenant network with this subnet.
(3) Setup a router for this tenant network, optionally create and connect an external network (not strictly necessary but hard to test/debug/observe without)
(4) Boot a new instance, observe the instance cannot contact metadata service. If you tcpdump the qrouter namespaces qg interface or the compute host, you will see the traffic is coming from the compute node's IP and not the instance's |
|
| 2016-07-11 02:51:42 |
Yoshi Kadokawa |
bug |
|
|
added subscriber Yoshi Kadokawa |
| 2016-07-11 06:36:58 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2016-07-11 10:09:26 |
Andrew McDermott |
bug |
|
|
added subscriber Andrew McDermott |
| 2016-07-11 10:21:29 |
Andrew McDermott |
tags |
sts |
network sts |
|
| 2016-07-11 14:35:54 |
James Tunnicliffe |
juju-core: status |
New |
Triaged |
|
| 2016-07-11 14:36:00 |
James Tunnicliffe |
juju-core: importance |
Undecided |
High |
|
| 2016-07-14 19:52:53 |
Cheryl Jennings |
tags |
network sts |
2.0 network sts |
|
| 2016-08-03 03:44:52 |
Anastasia |
juju-core: milestone |
|
2.0.0 |
|
| 2016-08-23 00:15:06 |
Canonical Juju QA Bot |
affects |
juju-core |
juju |
|
| 2016-08-23 00:15:06 |
Canonical Juju QA Bot |
juju: milestone |
2.0.0 |
|
|
| 2016-08-23 00:15:09 |
Canonical Juju QA Bot |
juju: milestone |
|
2.0.0 |
|
| 2016-09-27 00:14:22 |
Alexis Bruemmer |
juju: assignee |
|
Richard Harding (rharding) |
|
| 2016-10-05 20:04:09 |
Alexis Bruemmer |
juju: milestone |
2.0.0 |
2.1.0 |
|
| 2016-10-10 06:28:37 |
Mario Splivalo |
bug |
|
|
added subscriber Mario Splivalo |
| 2016-10-10 21:02:55 |
Richard Harding |
juju: milestone |
2.1.0 |
2.0.1 |
|
| 2016-10-21 17:43:44 |
Ryan Beisner |
bug |
|
|
added subscriber Ryan Beisner |
| 2016-10-21 17:44:08 |
Ryan Beisner |
nova-compute (Juju Charms Collection): status |
New |
Invalid |
|
| 2016-10-21 17:44:58 |
Ryan Beisner |
tags |
2.0 network sts |
2.0 network sts uosci |
|
| 2016-10-28 13:27:52 |
Curtis Hovey |
juju: milestone |
2.0.1 |
|
|
| 2017-02-02 11:16:02 |
Anastasia |
juju: assignee |
Richard Harding (rharding) |
|
|
| 2017-02-02 11:16:12 |
Anastasia |
juju: milestone |
|
2.1.0 |
|
| 2017-02-02 11:16:26 |
Anastasia |
nominated for series |
|
juju/2.0 |
|
| 2017-02-02 11:16:26 |
Anastasia |
bug task added |
|
juju/2.0 |
|
| 2017-02-02 11:16:33 |
Anastasia |
juju/2.0: status |
New |
Won't Fix |
|
| 2017-02-15 11:28:13 |
Anastasia |
marked as duplicate |
|
1614364 |
|
