diff options
| author | Cor Cornelisse <cor@hyves.nl> | 2012-04-06 15:54:16 +0200 |
|---|---|---|
| committer | Cor Cornelisse <cor@hyves.nl> | 2012-04-08 17:21:29 +0200 |
| commit | bc9f8d4fff225da6130691de2f2eea22215a4f17 (patch) | |
| tree | 3764976309f82172b37ec66b5cbdc7b706691e76 /bin/stack | |
| parent | 5f5295b884f456033d742d08388862615ff3b82b (diff) | |
| download | nova-bc9f8d4fff225da6130691de2f2eea22215a4f17.tar.gz nova-bc9f8d4fff225da6130691de2f2eea22215a4f17.tar.xz nova-bc9f8d4fff225da6130691de2f2eea22215a4f17.zip | |
Cloudpipe tap vpn not always working
Fixes bug 975043
Since Essex, all instances will have an eth0 MAC address in the range
of FA:16:3E, which is near the end of the MAC address space.
When openvpn is started, a TAP interface is created with a random
generated MAC address. Chances are high the generated MAC address is
lower in value than the eth0 MAC address. Once the tap interface is
added to the bridge interface, the bridge interface will no longer have
the eth0 MAC address, but take over the TAP MAC address. This is a
feature of the linux kernel, whereby a bridge interface will take the
MAC address with the lowest value amongst its interfaces. After the ARP
entries expire, this will result in the cloudpipe instance being no
longer reachable.
This fix, randomly generates a MAC address starting with FA:17:3E, which
is greater than FA, and will thus ensure the brige will keep the eth0 MAC
address.
Change-Id: I0bd994b6dc7a92738ed23cd62ee42a021fd394e2
Diffstat (limited to 'bin/stack')
0 files changed, 0 insertions, 0 deletions