Difference between revisions of "VPS Migration with OSPF"
(→Quagga installation) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:HOWTO]] | [[Category:HOWTO]] | ||
| + | [[Category:Networking]] | ||
| − | This article presents how to be able to migrate | + | This article presents how to be able to migrate a container between different subnets in the network by using a dynamic routing protocol such as OSPF. An already working OSPF setup is mandatory, this article only shows the OpenVZ specifics. |
== Quagga installation == | == Quagga installation == | ||
| − | Install the Quagga routing suite available on [http://www.quagga.net the official website]. | + | Install the Quagga routing suite available on [http://www.quagga.net/ the official website]. For many distributions, a prebuilt package is available: |
| − | Under Debian | + | Under Debian: |
| + | apt-get install quagga | ||
| − | + | Under Gentoo: | |
| − | + | emerge quagga | |
| − | + | ||
| + | Under Fedora: | ||
| + | yum install quagga | ||
== Quagga configuration == | == Quagga configuration == | ||
| Line 21: | Line 25: | ||
</pre> | </pre> | ||
| − | In /etc/quagga/ospfd.conf configure the OSPF network and area in which is OpenVZ server will be and configure the redistribution of routes generated by the | + | In /etc/quagga/ospfd.conf configure the OSPF network and area in which is OpenVZ server will be and configure the redistribution of routes generated by the container. |
<pre> | <pre> | ||
| Line 27: | Line 31: | ||
! | ! | ||
router ospf | router ospf | ||
| − | redistribute kernel route-map only- | + | redistribute kernel route-map only-ve |
network YOUR_NETWORK/XX area 0.0.0.0 | network YOUR_NETWORK/XX area 0.0.0.0 | ||
! | ! | ||
| − | route-map only- | + | route-map only-ve permit 10 |
match interface venet0 | match interface venet0 | ||
! | ! | ||
| Line 38: | Line 42: | ||
== Usage == | == Usage == | ||
| − | Once your OpenVZ server takes part in the OSPF network, you can easily use the ‘vzmigrate’ command to migrate a | + | Once your OpenVZ server takes part in the OSPF network, you can easily use the ‘vzmigrate’ command to migrate a container between different subnet of the network and the IP of the container will be redistributed in the whole network as a /32 (host route). |
== Bugs == | == Bugs == | ||
| − | To avoid problems with this setup the IP addresses of your | + | To avoid problems with this setup the IP addresses of your container must be taken outside of any other subnet configured on your network. If the IP address of the container is taken from an actual subnet, the other hosts of the subnet won't be able to communicate with it, except if you use proxy arp on the router. |
Latest revision as of 12:07, 29 November 2010
This article presents how to be able to migrate a container between different subnets in the network by using a dynamic routing protocol such as OSPF. An already working OSPF setup is mandatory, this article only shows the OpenVZ specifics.
Quagga installation[edit]
Install the Quagga routing suite available on the official website. For many distributions, a prebuilt package is available:
Under Debian:
apt-get install quagga
Under Gentoo:
emerge quagga
Under Fedora:
yum install quagga
Quagga configuration[edit]
In /etc/quagga/zebra.conf just put a password to be able to access the telnet interface.
password zebra
In /etc/quagga/ospfd.conf configure the OSPF network and area in which is OpenVZ server will be and configure the redistribution of routes generated by the container.
password zebra ! router ospf redistribute kernel route-map only-ve network YOUR_NETWORK/XX area 0.0.0.0 ! route-map only-ve permit 10 match interface venet0 ! line vty
Usage[edit]
Once your OpenVZ server takes part in the OSPF network, you can easily use the ‘vzmigrate’ command to migrate a container between different subnet of the network and the IP of the container will be redistributed in the whole network as a /32 (host route).
Bugs[edit]
To avoid problems with this setup the IP addresses of your container must be taken outside of any other subnet configured on your network. If the IP address of the container is taken from an actual subnet, the other hosts of the subnet won't be able to communicate with it, except if you use proxy arp on the router.
