6,534
edits
Changes
formatting fixes: removed u and br tags, pre's for onelines; avoid using < >; other fixes
This article describes how to assign public IPs to VEs running on OVZ Hardware Nodes in case you have a following network topology:
[[Image:PrivateIPs_fig1.gif|An initial network topology]]
== Prerequisites ==
This configuration was tested on a RHEL5 OVZ OpenVZ Hardware Node and a VE based on a Fedora Core 5 template.Other host OSes OSs and templates might require some configuration changes, please, add corresponding OS specific changes if you've faced any.<br>
This article assumes the presence of 'brctl', 'ip', 'ifconfig' utils thus might require installation of missed packages like 'bridge-utils'/'iproute'/'net-tools' or others which contain those utilities.
This article assumes you have already [[Quick installation|installed OpenVZ]], prepared the [[OS template cache]](s) and have [[Basic_operations_in_OpenVZ_environment|VE(s) created]]. If not, follow the links to perform the steps needed.
{{Note|don't assign an IP after VE creation.}}
== (1) An OVZ Hardware Node has the only one ethernet Ethernet interface ==
(assume eth0)
=== <u>Hardware Node configuration</u> ===
==== Create a bridge device ====
==== Remove an IP from eth0 interface ====
==== Add eth0 interface into the bridge ====
==== Assign the IP to the bridge ====
(the same that was assigned on eth0 earlier)
==== Resurrect the default routing ====
{{NoteWarning|if you are '''configuring''' the node '''remotely''' you '''must''' prepare a '''script''' with the above commands and run it in background with the redirected output or you'll '''lose the access''' to the Node.}}
==== A script example ====
</pre>
==== Start a VE ====
==== Add a [[Virtual_Ethernet_device|veth interface]] to the VE ====
==== Set up an IP to the newly created VE's veth interface ====
==== Add the VE's veth interface to the bridge ====
{{Note|veth interface will work as expected only after it is turned by the bridge into the forwarding state after some delay.
In 2.6.18 kernel it is 15 sec seconds by default.
<!-- /sys/class/net/$BR_NAME/bridge/forward_delay in SEC*USER_HZ -->}}
==== Set up the default route for the VE ====
==== (Optional) Add VE↔HN routes VE <-> HN ====
The configuration above provides following connections available:
* A VE accessibility from the HN depends on if the local gateway provides NAT or not (probably - yes).
* A HN accessibility from a VE depends on if the ISP gateway is aware about the local network addresses (most probably - no).
So to provide VE <-> ↔ HN accessibility despite the gateways' configuration you can add the following route rules:<pre> [HN]# ip route add 85.86.87.195 dev br0 [HN]# vzctl exec 101 ip route add 10.0.0.2 dev eth0</pre>
=== <u>The resulted OVZ Resulting OpenVZ Node configuration</u> ===[[Image:PrivateIPs_fig2.gif|The resulted OVZ Resulting OpenVZ Node configuration]]
=== <u>Making the configuration persistent</u> ===
==== Set up a bridge on a HN ====
GATEWAY=10.0.0.1
</pre>
To make bridge <code>br0</code> automatically created you can create <code>ifcfg-br0</code>:
<pre>
==== Edit the VE's configuration ====
Add some parameters to the <code>/etc/vz/conf/$VEID.conf</code> which will be used during the network configuration:
* Add/change <code>CONFIG_CUSTOMIZED="yes" </code> (indicates that a custom script should be run on a VE start)* Add <code>VETH_IP_ADDRESS="<VE IP>/MASK"<MASK/code>" (a VE can have multiple IPs separated by spaces)* Add <code>VE_DEFAULT_GATEWAY="<VE DEFAULT GATEWAY"</code>"* Add <code>BRIDGEDEV="<BRIDGE NAME"</code>" (a bridge name to which the VE veth interface should be added)
An example:
==== Make the script to be run on a VE start ====
In order to run above script on a VE start create the following <code>/etc/vz/vznet.conf</code> filewith the following contents:<pre> EXTERNAL_SCRIPT="/usr/sbin/vznetcfg.custom"</pre>{{Note|<code>/usr/sbin/vznetcfg.custom</code> file should be executable.}}
==== Setting the route VE -> → HN ====
To set up a route from VE to HN the custom script has to get a HN IP (the $VE0_IP variable in the script). There can be different approaches to specify it:
# Add an entry VE0_IP="VE0 IP" to the <code>$VEID.conf</code>
# Add an entry VE0_IP="VE0 IP" to the <code>/etc/vz/vz.conf</code> (the global configuration config file)
# Implement some smart algorithm to determine the VE0 IP right in the custom network configuration script
Every variant has its pros and cons, nevertheless for HN static IP configuration variant 2 seems to be acceptable (and the most simple).
== (2) An OVZ OpenVZ Hardware Node has two ethernet Ethernet interfaces ==
Assume you have 2 interfaces eth0 and eth1 and want to separate local traffic (10.0.0.0/24) from the external traffic.
Let's assign eth0 for the external traffic and eth1 for the local one.
If there is no aim to make VE accessible from HN and vice versa, it's enough to replace 'br0' with 'eth1' in the following steps of above configuration:
* Hardware Node configuration -> → [[Using_private_IPs_for_Hardware_Nodes#Assign_the_IP_to_the_bridge|Assign the IP to the bridge]]* Hardware Node configuration -> → [[Using_private_IPs_for_Hardware_Nodes#Resurrect_the_default_routing|Resurrect the default routing]]
For the VE <-> ↔ HN connections availability it's is nesessary to set an IP (local) to the 'br0'.
== (3) Putting VEs to different subnetworks ==
It's enough to set up the correct $VETH_IP_ADDRESS and $VE_DEFAULT_GATEWAY values in the
[[Using_private_IPs_for_Hardware_Nodes#Edit_the_VE.27s_configuration|above configuration]].
