Hi Kir, Thanks for taking the time to reply!! I understand this is probably tedious routine, but it's a blocking issue for me. Yes the provider should probably have taken care of it, but I have the privilege of bringing Internet to a third world country and we sometimes have to live with what we get.
I can ping the gateway fine from the hardware node: [root@server17 ~]# ping xxx.13.31.129 PING xxx.13.31.129 (xxx.13.31.129) 56(84) bytes of data. 64 bytes from xxx.13.31.129: icmp_seq=1 ttl=255 time=0.337 ms 64 bytes from xxx.13.31.129: icmp_seq=2 ttl=255 time=3.46 ms 64 bytes from xxx.13.31.129: icmp_seq=3 ttl=255 time=2.68 ms ... So if I understand you correct, the only thing to do next is to set up source routing. I tried that before and already explained that it stops with an error: # 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 I've got my container and one of the allocated IP's bound to it, but I can't ping either in or out from the container. // Rene On Tue, Aug 20, 2013 at 11:48 PM, Kir Kolyshkin <[email protected]> wrote: > 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. <[email protected]> wrote: >>> >>> ... continued >>> >>> >>> So going the simple/obvious way of bridging the CT0 interface I try >>> the longer route: >>> >>> [root@server17 ~]# ifconfig veth1706.0 0 >>> [root@server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/veth1706.0/forwarding >>> [root@server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/veth1706.0/proxy_arp >>> [root@server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding >>> [root@server17 ~]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp >>> [root@server17 ~]# vzctl enter 1706 >>> entered into CT 1706 >>> [root@vps1706 /]# ifconfig eth0 0 >>> [root@vps1706 /]# ip addr add xxx.13.31.131 dev eth0 >>> [root@vps1706 /]# route add default dev eth0 >>> [root@vps1706 /]# logout >>> exited from CT 1706 >>> [root@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. <[email protected]> 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 <[email protected]> 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." <[email protected]>: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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." <[email protected]>: >>>>>>> >>>>>>>> Kirill, do you know of a page where this procedure is documented? >>>>>>>> Thanks! >>>>>>>> >>>>>>>> On Sat, Aug 17, 2013 at 4:54 PM, Kirill Korotaev <[email protected]> >>>>>>>> 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." <[email protected]> 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? >>>>>>>>>> > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
