| 2017-04-17 07:31:58 |
Kevin Benton |
description |
The way the Linux Bridge multinode job works right now, the VXLAN tenant networks are not using l2_population and subsequently rely on the multicast 'group' feature of kernel bridges for carrying broadcast traffic.
This would not normally be a problem, however, the local interface they are using to send this multicast traffic is the one attached directly to the provider cloud's network. So we are ultimately at the mercy of the provider's networks to carry multicast traffic between the multi-node instances, which is just asking for failures.
We need to adjust the job to setup a tunnel between the multinode instances to safely carry traffic between them like we do for DVR [1].
1. http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/multinode_setup_info.txt
This is likely leading to the instability of the LB multi-node job when the job is on certain cloud providers that might not have good multicast routing. |
The way the Linux Bridge multinode job works right now, the VXLAN tenant networks are not using l2_population and subsequently rely on the multicast 'group' feature of kernel bridges for carrying broadcast traffic.
This would not normally be a problem, however, the local interface they are using to send this multicast traffic is the one attached directly to the provider cloud's network. So we are ultimately at the mercy of the provider's networks to carry multicast traffic between the multi-node instances, which is just asking for failures.
We need to adjust the job to setup a tunnel between the multinode instances to safely carry traffic between them like we do for DVR [1].
1. https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate.sh#n149
This is likely leading to the instability of the LB multi-node job when the job is on certain cloud providers that might not have good multicast routing. |
|
