Hi, I think you have just to set route as kir mentioned and also set net.ipv4.conf.eth0.proxy_arp to 1 or net.ipv4.conf.default.proxy_arp to 1
similar case described in wiki though I don't know do you have follow this article step by step: http://wiki.openvz.org/Using_veth_and_brctl_for_protecting_HN_and_saving_IP_addresses this also can be helpfull: https://access.redhat.com/site/solutions/53031 On Tue, Aug 20, 2013 at 7:13 PM, Rene C. <[email protected]> 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. > > // 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? > >>>>>>>> > >>>>>>>> - Rene > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> A bientôt > >>>>> =========================================================== > >>>>> Jean-Marc Pigeon E-Mail: [email protected] > >>>>> SAFE Inc. Phone: (514) 493-4280 > >>>>> Clement, 'a kiss solution' to get rid of SPAM (at last) > >>>>> Clement' Home base <"http://www.clement.safe.ca";> > >>>>> =========================================================== > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> [email protected] > >>>>> https://lists.openvz.org/mailman/listinfo/users > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> [email protected] > >>>> https://lists.openvz.org/mailman/listinfo/users > >>> > >>> > >>> -- > >>> A bientôt > >>> =========================================================== > >>> Jean-Marc Pigeon E-Mail: [email protected] > >>> SAFE Inc. Phone: (514) 493-4280 > >>> Clement, 'a kiss solution' to get rid of SPAM (at last) > >>> Clement' Home base <"http://www.clement.safe.ca";> > >>> =========================================================== > >>> > >>> _______________________________________________ > >>> 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
