[Users] How to configure a server to use multiple subnets/gateways

Tue Aug 20 12:48:32 EDT 2013

On 08/20/2013 09:13 AM, Rene C. wrote:
> No takers!?  Is it more complicated than I imagine?  I have tried to
> explain it as well as I can. Please let me know if there is anything
> unclear and I'll try to clarify.

As I explained earlier, you don't have to use bridging in this scenario.

All you need to do is to add the proper static route to your system so
that other network is reachable from your host, that is it.

First, make sure that the gateway they specified is reachable from your 
host:
ping xxx.13.31.129

I am assuming it is not, and you only have one network card (eth0). So, 
you need
to tell your host that this network is actually there:

ip route add xxx.13.31.128/27 dev eth0 scope link

After that, the above ping should work.

Next, you should probably set up source routing for these IPs, so that
containers in this range will use the gateway provided. Check
http://openvz.org/Source_based_routing for details.

Finally, you can set an IP for your container in a usual manner, using 
venet:

vzctl set NNN --ipadd xxx.13.31.130/27 --save

and then check that everything works (ping from inside container etc.).

Kir.

PS frankly speaking, this is what your hoster should've explained to 
you. If they do
such extravagant setups, they should be able to help their customers 
setting those up.

>
> // Rene
>
> On Sun, Aug 18, 2013 at 1:22 PM, Rene C. <openvz at dokbua.com> wrote:
>> ... continued
>>
>>
>> So going the simple/obvious way of bridging the CT0 interface I try
>> the longer route:
>>
>> [root at server17 ~]# ifconfig veth1706.0 0
>> [root at server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/veth1706.0/forwarding
>> [root at server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/veth1706.0/proxy_arp
>> [root at server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
>> [root at server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
>> [root at server17 ~]# vzctl enter 1706
>> entered into CT 1706
>> [root at vps1706 /]# ifconfig eth0 0
>> [root at vps1706 /]# ip addr add xxx.13.31.131 dev eth0
>> [root at vps1706 /]# route add default dev eth0
>> [root at vps1706 /]# logout
>> exited from CT 1706
>> [root at server17 ~]# ip route add xxx dev veth1706.0
>> RTNETLINK answers: File exists
>>
>>
>> To recap the problem:
>>
>> I have this hardware node with IP xxx.22.181.158
>>
>> Node runs Centos 6, so does all containers.
>>
>> I already have 4 containers with IP addresses on the same subnet
>> (xxx.22.181.*) running fine.
>>
>> Problem is, now my data center gave me 3 IP addresses in a new subnet
>> with a separate gateway:
>>
>> IP add  : xxx.13.31.130  -  132
>> subnet : 255.255.255.224
>> gateway : xxx.13.31.129
>>
>> How can I make this work. Please be specific. I don't mind reading and
>> learning, but the learning curve at this stage is too high, I'm not
>> getting anywhere. Thanks.
>>
>>
>>
>>
>> On Sun, Aug 18, 2013 at 12:28 PM, Rene C. <openvz at dokbua.com> wrote:
>>> I'm sorry but networking is obviously not one of my strong areas and
>>> for all the good intentions, all the buzzwords confuse me more than
>>> they help me.
>>>
>>> I had a look at http://openvz.org/Virtual_Ethernet_device, and it
>>> gives detailed information about a number of scenarios, for example
>>> "Simple configuration with virtual Ethernet devices" and then proceeds
>>> with 50 steps to set it up. (Ok I exaggerate but you get my drift).  I
>>> think my requirement is very very simple, like I explained before, my
>>> DC gave me a bunch of IP addresses on a new subnet requiring a
>>> different gateway for it to work.
>>>
>>> I tried.
>>>
>>> Ok so I start at the "imple configuration with virtual Ethernet
>>> device", with the vzctl start and set commands listed. Then it says
>>> "The following steps are needed when the CT is not bridged to a CT0
>>> network interface.". Ok, I guess I should make the "CT bridged to a
>>> CT0 network inteface" then... but how?   There's a section
>>> "Independent Virtual Ethernet communication through the bridge". It
>>> starts with "create bridge device", starting with "brctl addbr vzbr0".
>>> Ok, I try that...
>>>
>>> # brctl addbr vzbr0
>>> -bash: brctl: command not found
>>>
>>> Now what?
>>>
>>> I just need to set this up. Not how to enable a VPN tunnel or multiple
>>> 192.168 networks.  I'm sure someone in the know could tell me this is
>>> a matter of two lines instead of this information overload.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Sun, Aug 18, 2013 at 3:36 AM, Jean-Marc Pigeon <jmp at safe.ca> wrote:
>>>> Bonjour Rene C.
>>>>
>>>> My understanding you want to route VPS IP not related to host IP.
>>>> Just to tell you we have such config.
>>>> Using veth  within the VPS and the host with Bridge interface.
>>>> Our config is working IP double stack (IPV4 + IPV6).
>>>>
>>>> The VPS eth0 interface is a very straightforward one.
>>>> VPS ifcfg-eth0
>>>> DEVICE=eth0
>>>> BOOTPROTO=static
>>>> ONBOOT=yes
>>>> IPADDR=X.Y.Z.T
>>>> NETMASK=255.255.255.255
>>>> IPV6INIT=yes
>>>> IPV6ADDR=XX:YY.......ZZ:TT
>>>>
>>>> Keyword are veth, IPV4 Routing, Bridge.
>>>> http://openvz.org/Virtual_Ethernet_device
>>>> seems to me a good starting point.
>>>>
>>>>
>>>> Quoting "Rene C." <openvz at dokbua.com>:
>>>>
>>>>> Thanks Jean-Marc, I don't think this is what I need though - I don't
>>>>> have any bridge interfaces anywhere, and frankly don't quite see how
>>>>> it fits into the server. There's only a ifcfg-eth0 file.
>>>>>
>>>>> I had a look at this page -
>>>>> http://wiki.openvz.org/Source_based_routing - am I on the right track?
>>>>>
>>>>> I tried some of the commands but it threw an error early on so I have
>>>>> a feeling I'm not.
>>>>>
>>>>> # ip rule add from xxx.13.31.0/24 table 6
>>>>> # ip route add default dev eth0 via xxx.13.31.129 table 6
>>>>> RTNETLINK answers: No such process
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 17, 2013 at 10:28 PM, Jean-Marc Pigeon <jmp at safe.ca> wrote:
>>>>>> Bonjour Rene C,
>>>>>>
>>>>>> My config:
>>>>>>
>>>>>> ifcfg-br0
>>>>>> #definition Bridge interface
>>>>>> DEVICE=br0
>>>>>> ONBOOT=yes
>>>>>> TYPE=Bridge
>>>>>> BOOTPROTO=static
>>>>>> IPADDR=HOST IP number
>>>>>> NETMASK=255.255.255.224  #(My HOST SUBNET MASK)
>>>>>> IPV6INIT=yes
>>>>>> IPV6ADDR=PP:XX:.....YY:ZZ
>>>>>>
>>>>>> ifcfg-br0:brgd
>>>>>> DEVICE=br0:brgd
>>>>>> ONBOOT=yes
>>>>>> TYPE=Bridge
>>>>>> BOOTPROTO=static
>>>>>> IPADDR=192.0.2.1
>>>>>> NETMASK=255.255.255.255
>>>>>> #to avoid checking for already set IP
>>>>>> ARPCHECK=no
>>>>>>
>>>>>> I am using Quagga(RIP) to transparently route (and displace) VPS IP among
>>>>>> HOST
>>>>>> such the VPS can be "somewhere" within Hardware cloud. (then VPS
>>>>>> can be set with an IP unrelated to HOST).
>>>>>>
>>>>>> Hoping that help.
>>>>>> Contact me privately if I can help.
>>>>>>
>>>>>> Quoting "Rene C." <openvz at dokbua.com>:
>>>>>>
>>>>>>> Kirill, do you know of a page where this procedure is documented?
>>>>>>> Thanks!
>>>>>>>
>>>>>>> On Sat, Aug 17, 2013 at 4:54 PM, Kirill Korotaev <dev at parallels.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Rene, if I got your problem correct you need just create a routing rule
>>>>>>>> in the host, so that it knew where to route your IPs.
>>>>>>>>
>>>>>>>> Or use bridged networking with veth interface instead.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 17.08.2013, at 13:33, "Rene C." <openvz at dokbua.com> wrote:
>>>>>>>>
>>>>>>>>> I have this hardware node with IP xxx.22.181.158
>>>>>>>>>
>>>>>>>>> Node runs Centos 6, so does all containers.
>>>>>>>>>
>>>>>>>>> I already have 4 containers with IP addreses on the same submit
>>>>>>>>> (xxx.22.181.*) running fine.
>>>>>>>>>
>>>>>>>>> Problem is, now my data center gave me 3 IP addresses in a new subnet
>>>>>>>>> with a separate gateway:
>>>>>>>>>
>>>>>>>>> IP add  : xxx.13.31.130  -  132
>>>>>>>>> subnet : 255.255.255.224
>>>>>>>>> gateway : xxx.13.31.129
>>>>>>>>>
>>>>>>>>> The only way I can make this work is by taking one of these IP
>>>>>>>>> addresses and bind to the hardware node, then I can use the remaining
>>>>>>>>> IP addresses with containers - but this way I lose an IP address - the
>>>>>>>>> one bound to the hardware node, which seems no longer usable for
>>>>>>>>> containers.
>>>>>>>>>
>>>>>>>>> This is a problem both because there's a limit to how many IP's the DC
>>>>>>>>> will allocate to a server, and because the IP addresses are quite
>>>>>>>>> costly.
>>>>>>>>>
>>>>>>>>> Did I misunderstand something?
>>>>>>>>>