Difference between revisions of "VPS Migration with OSPF"
(VPS -> VE, some formatting, quagga install for Gentoo/Fedora added) |
|||
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 VE 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 | ||
− | <pre> | + | Under Gentoo: |
− | + | emerge quagga</pre> | |
− | + | ||
+ | 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 VE. |
<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 VE between different subnet of the network and the IP of the VE 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 VE must be taken outside of any other subnet configured on your network. If the IP address of the VE 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. |
Revision as of 20:00, 22 January 2007
This article presents how to be able to migrate a VE 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
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
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 VE.
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
Once your OpenVZ server takes part in the OSPF network, you can easily use the ‘vzmigrate’ command to migrate a VE between different subnet of the network and the IP of the VE will be redistributed in the whole network as a /32 (host route).
Bugs
To avoid problems with this setup the IP addresses of your VE must be taken outside of any other subnet configured on your network. If the IP address of the VE 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.