Difference between revisions of "Using private IPs for Hardware Nodes"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
m (/etc/vz/vznet.conf doesn't hasve to be executable)
(formatting fixes: removed u and br tags, pre's for onelines; avoid using < >; other fixes)
Line 1: Line 1:
 
This article describes how to assign public IPs to VEs running on OVZ Hardware Nodes in case you have a following network topology:
 
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]]
 
[[Image:PrivateIPs_fig1.gif|An initial network topology]]
  
 
== Prerequisites ==
 
== Prerequisites ==
This configuration was tested on a RHEL5 OVZ Hardware Node and a VE based on a Fedora Core 5 template.
+
This configuration was tested on a RHEL5 OpenVZ Hardware Node and a VE based on a Fedora Core 5 template.
Other host OSes and templates might require some configuration changes, please, add corresponding OS specific changes if you've faced any.<br>
+
Other host OSs and templates might require some configuration changes, please, add corresponding OS specific changes if you've faced any.
 +
 
 
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 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.
 
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.}}
 
{{Note|don't assign an IP after VE creation.}}
<br>
 
  
== (1) An OVZ Hardware Node has the only one ethernet interface ==
+
== An OVZ Hardware Node has the only one Ethernet interface ==
 
(assume eth0)
 
(assume eth0)
  
=== <u>Hardware Node configuration</u> ===
+
=== Hardware Node configuration ===
  
 
==== Create a bridge device ====
 
==== Create a bridge device ====
<pre>[HN]# brctl addbr br0</pre>
+
[HN]# brctl addbr br0
  
 
==== Remove an IP from eth0 interface ====
 
==== Remove an IP from eth0 interface ====
<pre>[HN]# ifconfig eth0 0</pre>
+
[HN]# ifconfig eth0 0
  
 
==== Add eth0 interface into the bridge ====
 
==== Add eth0 interface into the bridge ====
<pre>[HN]# brctl addif br0 eth0</pre>
+
[HN]# brctl addif br0 eth0
 
   
 
   
 
==== Assign the IP to the bridge ====
 
==== Assign the IP to the bridge ====
 
(the same that was assigned on eth0 earlier)
 
(the same that was assigned on eth0 earlier)
<pre>[HN]# ifconfig br0 10.0.0.2/24</pre>
+
[HN]# ifconfig br0 10.0.0.2/24
  
 
==== Resurrect the default routing ====
 
==== Resurrect the default routing ====
<pre>[HN]# ip route add default via 10.0.0.1 dev br0</pre>
+
[HN]# ip route add default via 10.0.0.1 dev br0
 
   
 
   
{{Note|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.}}
+
{{Warning|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 ====
 
==== A script example ====
Line 46: Line 47:
 
</pre>
 
</pre>
  
<pre>[HN]# /tmp/br_add >/dev/null 2>&1 &</pre>
+
[HN]# /tmp/br_add >/dev/null 2>&1 &
<br>
+
 
=== <u>VE configuration</u> ===
+
=== VE configuration ===
  
 
==== Start a VE ====
 
==== Start a VE ====
<pre>[HN]# vzctl start 101</pre>
+
[HN]# vzctl start 101
  
 
==== Add a [[Virtual_Ethernet_device|veth interface]] to the VE ====
 
==== Add a [[Virtual_Ethernet_device|veth interface]] to the VE ====
<pre>[HN]# vzctl set 101 --netif_add eth0 --save</pre>
+
[HN]# vzctl set 101 --netif_add eth0 --save
  
 
==== Set up an IP to the newly created VE's veth interface ====
 
==== Set up an IP to the newly created VE's veth interface ====
<pre>[HN]# vzctl exec 101 ifconfig eth0 85.86.87.195/26</pre>
+
[HN]# vzctl exec 101 ifconfig eth0 85.86.87.195/26
 
   
 
   
 
==== Add the VE's veth interface to the bridge ====
 
==== Add the VE's veth interface to the bridge ====
<pre>[HN]# brctl addif br0 veth101.0</pre>
+
[HN]# brctl addif br0 veth101.0
 +
 
 
{{Note|veth interface will work as expected only after it is turned by the bridge into the forwarding state after some delay.
 
{{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 by default.
+
In 2.6.18 kernel it is 15 seconds by default.
 
<!-- /sys/class/net/$BR_NAME/bridge/forward_delay in SEC*USER_HZ -->}}
 
<!-- /sys/class/net/$BR_NAME/bridge/forward_delay in SEC*USER_HZ -->}}
  
 
==== Set up the default route for the VE ====
 
==== Set up the default route for the VE ====
<pre>[HN]# vzctl exec 101 ip route add default via 85.86.87.193 dev eth0</pre>
+
[HN]# vzctl exec 101 ip route add default via 85.86.87.193 dev eth0
 
   
 
   
==== (Optional) Add routes VE <-> HN ====
+
==== (Optional) Add VE↔HN routes ====
 
The configuration above provides following connections available:
 
The configuration above provides following connections available:
<pre>
+
* VE X VE Y (where VE X and VE Y can locate on any OVZ HN)
VE X <-> VE Y (where VE X and VE Y can locate on any OVZ HN)
+
* VE  Internet
VE  <-> Internet
+
 
</pre>
+
Note that
 
* A VE accessibility from the HN depends on if the local gateway provides NAT or not (probably - yes).
 
* 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).
 
* 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 following route rules:
+
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]# ip route add 85.86.87.195 dev br0
[HN]# vzctl exec 101 ip route add 10.0.0.2 dev eth0
+
[HN]# vzctl exec 101 ip route add 10.0.0.2 dev eth0
</pre>
 
  
=== <u>The resulted OVZ Node configuration</u> ===
+
=== Resulting OpenVZ Node configuration ===
[[Image:PrivateIPs_fig2.gif|The resulted OVZ Node configuration]]
+
[[Image:PrivateIPs_fig2.gif|Resulting OpenVZ Node configuration]]
  
=== <u>Making the configuration persistent</u> ===
+
=== Making the configuration persistent ===
  
 
==== Set up a bridge on a HN ====
 
==== Set up a bridge on a HN ====
Line 99: Line 100:
 
GATEWAY=10.0.0.1
 
GATEWAY=10.0.0.1
 
</pre>
 
</pre>
<br>
+
 
 
To make bridge <code>br0</code> automatically created you can create <code>ifcfg-br0</code>:
 
To make bridge <code>br0</code> automatically created you can create <code>ifcfg-br0</code>:
 
<pre>
 
<pre>
Line 119: Line 120:
 
==== Edit the VE's configuration ====
 
==== 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 some parameters to the <code>/etc/vz/conf/$VEID.conf</code> which will be used during the network configuration:
* Add/change CONFIG_CUSTOMIZED="yes" (indicates that a custom script should be run on a VE start)
+
* Add/change <code>CONFIG_CUSTOMIZED="yes"</code> (indicates that a custom script should be run on a VE start)
* Add VETH_IP_ADDRESS="<VE IP>/<MASK>" (a VE can have multiple IPs separated by spaces)
+
* Add <code>VETH_IP_ADDRESS="VE IP/MASK"</code> (a VE can have multiple IPs separated by spaces)
* Add VE_DEFAULT_GATEWAY="<VE DEFAULT GATEWAY>"
+
* Add <code>VE_DEFAULT_GATEWAY="VE DEFAULT GATEWAY"</code>
* Add BRIDGEDEV="<BRIDGE NAME>" (a bridge name to which the VE veth interface should be added)
+
* Add <code>BRIDGEDEV="BRIDGE NAME"</code> (a bridge name to which the VE veth interface should be added)
  
 
An example:
 
An example:
Line 218: Line 219:
  
 
==== Make the script to be run on a VE start ====
 
==== 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> file:
+
In order to run above script on a VE start create <code>/etc/vz/vznet.conf</code> file with the following contents:
<pre>
+
 
EXTERNAL_SCRIPT="/usr/sbin/vznetcfg.custom"
+
EXTERNAL_SCRIPT="/usr/sbin/vznetcfg.custom"
</pre>
+
 
{{Note|<code>/usr/sbin/vznetcfg.custom</code> should be executable.}}
+
{{Note|<code>/usr/sbin/vznetcfg.custom</code> file should be executable.}}
  
==== Setting the route VE -> HN ====
+
==== 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:
 
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>$VEID.conf</code>
 
# Add an entry VE0_IP="VE0 IP" to the <code>/etc/vz/vz.conf</code> (the global configuration config file)
 
# 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
 
# 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).
 
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 Hardware Node has two ethernet interfaces ==
+
== An OpenVZ Hardware Node has two 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.
 
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.
 
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:
 
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#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]]
+
* 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 nesessary to set an IP (local) to the 'br0'.
+
For the VE HN connections availability it is nesessary to set an IP (local) to the 'br0'.
  
== (3) Putting VEs to different subnetworks ==
+
== Putting VEs to different subnetworks ==
 
It's enough to set up the correct $VETH_IP_ADDRESS and $VE_DEFAULT_GATEWAY values in the  
 
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]].
 
[[Using_private_IPs_for_Hardware_Nodes#Edit_the_VE.27s_configuration|above configuration]].

Revision as of 22:13, 11 November 2007

This article describes how to assign public IPs to VEs running on OVZ Hardware Nodes in case you have a following network topology:

An initial network topology

Prerequisites

This configuration was tested on a RHEL5 OpenVZ Hardware Node and a VE based on a Fedora Core 5 template. Other host OSs and templates might require some configuration changes, please, add corresponding OS specific changes if you've faced any.

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 installed OpenVZ, prepared the OS template cache(s) and have VE(s) created. If not, follow the links to perform the steps needed.

Yellowpin.svg Note: don't assign an IP after VE creation.

An OVZ Hardware Node has the only one Ethernet interface

(assume eth0)

Hardware Node configuration

Create a bridge device

[HN]# brctl addbr br0

Remove an IP from eth0 interface

[HN]# ifconfig eth0 0

Add eth0 interface into the bridge

[HN]# brctl addif br0 eth0

Assign the IP to the bridge

(the same that was assigned on eth0 earlier)

[HN]# ifconfig br0 10.0.0.2/24

Resurrect the default routing

[HN]# ip route add default via 10.0.0.1 dev br0

Warning.svg Warning: 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

[HN]# cat /tmp/br_add 
#!/bin/bash

brctl addbr br0
ifconfig eth0 0 
brctl addif br0 eth0 
ifconfig br0 10.0.0.2/24 
ip route add default via 10.0.0.1 dev br0
[HN]# /tmp/br_add >/dev/null 2>&1 &

VE configuration

Start a VE

[HN]# vzctl start 101

Add a veth interface to the VE

[HN]# vzctl set 101 --netif_add eth0 --save

Set up an IP to the newly created VE's veth interface

[HN]# vzctl exec 101 ifconfig eth0 85.86.87.195/26

Add the VE's veth interface to the bridge

[HN]# brctl addif br0 veth101.0
Yellowpin.svg 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 seconds by default.

Set up the default route for the VE

[HN]# vzctl exec 101 ip route add default via 85.86.87.193 dev eth0

(Optional) Add VE↔HN routes

The configuration above provides following connections available:

  • VE X ↔ VE Y (where VE X and VE Y can locate on any OVZ HN)
  • VE ↔ Internet

Note that

  • 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:

[HN]# ip route add 85.86.87.195 dev br0
[HN]# vzctl exec 101 ip route add 10.0.0.2 dev eth0

Resulting OpenVZ Node configuration

Resulting OpenVZ Node configuration

Making the configuration persistent

Set up a bridge on a HN

This can be done by configuring ifcfg-* files located in /etc/sysconfig/network-scripts/.

Assuming you had a configuration file (e.g. ifcfg-eth0) like:

DEVICE=eth0
ONBOOT=yes
IPADDR=10.0.0.2
NETMASK=255.255.255.0
GATEWAY=10.0.0.1

To make bridge br0 automatically created you can create ifcfg-br0:

DEVICE=br0
TYPE=Bridge
ONBOOT=yes
IPADDR=10.0.0.2
NETMASK=255.255.255.0
GATEWAY=10.0.0.1

and edit ifcfg-eth0 file to add eth0 interface into the bridge br0:

DEVICE=eth0
ONBOOT=yes
BRIDGE=br0

Edit the VE's configuration

Add some parameters to the /etc/vz/conf/$VEID.conf which will be used during the network configuration:

  • Add/change CONFIG_CUSTOMIZED="yes" (indicates that a custom script should be run on a VE start)
  • Add VETH_IP_ADDRESS="VE IP/MASK" (a VE can have multiple IPs separated by spaces)
  • Add VE_DEFAULT_GATEWAY="VE DEFAULT GATEWAY"
  • Add BRIDGEDEV="BRIDGE NAME" (a bridge name to which the VE veth interface should be added)

An example:

# Network customization section
CONFIG_CUSTOMIZED="yes"
VETH_IP_ADDRESS="85.86.87.195/26"
VE_DEFAULT_GATEWAY="85.86.87.193"
BRIDGEDEV="br0"

Create a custom network configuration script

which should be called each time a VE started (e.g. /usr/sbin/vznetcfg.custom):

#!/bin/bash
# /usr/sbin/vznetcfg.custom
# a script to bring up bridged network interfaces (veth's) in a VE

GLOBALCONFIGFILE=/etc/vz/vz.conf
VECONFIGFILE=/etc/vz/conf/$VEID.conf
vzctl=/usr/sbin/vzctl
brctl=/usr/sbin/brctl
ip=/sbin/ip
ifconfig=/sbin/ifconfig
. $GLOBALCONFIGFILE
. $VECONFIGFILE

NETIF_OPTIONS=`echo $NETIF | sed 's/,/\n/g'`
for str in $NETIF_OPTIONS; do \
        # getting 'ifname' parameter value
        if [[ "$str" =~ "^ifname=" ]]; then
                # remove the parameter name from the string (along with '=')
                VEIFNAME=${str#*=};
        fi
        # getting 'host_ifname' parameter value
        if [[ "$str" =~ "^host_ifname=" ]]; then
                # remove the parameter name from the string (along with '=')
                VZHOSTIF=${str#*=};
        fi
done

if [ ! -n "$VETH_IP_ADDRESS" ]; then
   echo "According to $CONFIGFILE VE$VEID has no veth IPs configured."
   exit 1
fi

if [ ! -n "$VZHOSTIF" ]; then
   echo "According to $CONFIGFILE VE$VEID has no veth interface configured."
   exit 1
fi

if [ ! -n "$VEIFNAME" ]; then
   echo "Corrupted $CONFIGFILE: no 'ifname' defined for host_ifname $VZHOSTIF."
   exit 1
fi

echo "Initializing interface $VZHOSTIF for VE$VEID."
$ifconfig $VZHOSTIF 0

VEROUTEDEV=$VZHOSTIF

if [ -n "$BRIDGEDEV" ]; then
   echo "Adding interface $VZHOSTIF to the bridge $BRIDGEDEV."
   VEROUTEDEV=$BRIDGEDEV
   $brctl addif $BRIDGEDEV $VZHOSTIF
fi

# Up the interface $VEIFNAME link in VE$VEID
$vzctl exec $VEID $ip link set $VEIFNAME up

for IP in $VETH_IP_ADDRESS; do
   echo "Adding an IP $IP to the $VEIFNAME for VE$VEID."
   $vzctl exec $VEID $ip address add $IP dev $VEIFNAME

   # removing the netmask
   IP_STRIP=${IP%%/*};

   echo "Adding a route from VE0 to VE$VEID."
   $ip route add $IP_STRIP dev $VEROUTEDEV
done

if [ -n "$VE0_IP" ]; then
   echo "Adding a route from VE$VEID to VE0."
   $vzctl exec $VEID $ip route add $VE0_IP dev $VEIFNAME
fi

if [ -n "$VE_DEFAULT_GATEWAY" ]; then
   echo "Setting $VE_DEFAULT_GATEWAY as a default gateway for VE$VEID."
   $vzctl exec $VEID \
        $ip route add default via $VE_DEFAULT_GATEWAY dev $VEIFNAME
fi

exit 0

Make the script to be run on a VE start

In order to run above script on a VE start create /etc/vz/vznet.conf file with the following contents:

EXTERNAL_SCRIPT="/usr/sbin/vznetcfg.custom"
Yellowpin.svg Note: /usr/sbin/vznetcfg.custom 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:

  1. Add an entry VE0_IP="VE0 IP" to the $VEID.conf
  2. Add an entry VE0_IP="VE0 IP" to the /etc/vz/vz.conf (the global configuration config file)
  3. 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).

An OpenVZ Hardware Node has two 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:

For the VE ↔ HN connections availability it is nesessary to set an IP (local) to the 'br0'.

Putting VEs to different subnetworks

It's enough to set up the correct $VETH_IP_ADDRESS and $VE_DEFAULT_GATEWAY values in the above configuration.

See also