I understand. I'll take it up in a network forum. Thanks!
On Sun, Aug 25, 2013 at 8:40 AM, Kir Kolyshkin <[email protected]> wrote: > On 08/24/2013 11:50 AM, Rene C. wrote: >> >> I know I'm probably being a PITA, but I'm still stuck with this. >> >> The problem is very simple at this time - I'm following the guide >> that's referred, but at the second step I get an error, and I have no >> idea how to proceed from here. >> >> # 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 > > > This could be because xxx.13.31.129 is unreachable, so you > have to add a route to it first, as I suggested before: > > ip route add xxx.13.31.128/27 dev eth0 scope link > > Generally, the problem is not OpenVZ specific in any way, so > you might have better luck asking on some linux networking > forums or lists. > >> >> Help. Please. >> >> >> On Wed, Aug 21, 2013 at 12:39 AM, Rene C. <[email protected]> wrote: >>> >>> 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 > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
