OpenVZ Forum


Home » General » Support » *SOLVED* VEs with different subnets
Re: VEs with different subnets [message #14578 is a reply to message #14577] Mon, 02 July 2007 17:17 Go to previous messageGo to previous message
ugo123 is currently offline  ugo123
Messages: 22
Registered: June 2007
Junior Member
finist wrote on Mon, 02 July 2007 12:08

Thank you for the logs.
yes, my suggestion implied that 10.1.1.1 will route the packets from VEs also as it does for Hardware Nodes.

Well, if you want to set up another gateway for VEs then just try source base routing as dev already suggested.

# /sbin/ip rule add from 87.98.196.135 table 10
# /sbin/ip route add default dev eth0 via 87.98.196.129 table 10

This should do the trick i suppose. (you won't be forced to do this manually each time, when you get the commands consequence required to get it work, you can create a script with these commands).

If it won't work again, please, let me know, we'll think about the reasons. Or just provide an access to the node, it will take much less time to undestand and eliminate the problem. Smile


ugo123 wrote on Mon, 02 July 2007 16:19

titan:~# vzctl exec 101 ip r l
192.0.2.0/24 dev venet0 scope host
169.254.0.0/16 dev venet0 scope link
default via 192.0.2.1 dev venet0
titan:~#

(I really don't get the 192.0.2.0/24 that I've just seen from the route....)


This IP 192.0.2.1 is fake one, it's not used, venet is just a point-to-point conenction, so all the packets got to the venet0 inside a VE appeared on the venet0 interface on a Hardware Node and are routed further according to the rules on Hardware Node.


Ok, thank you both again for you support Smile (at least with Xen I sure had the network, but not the support and the people behind Very Happy) hahaha

Yes I don't want to use 10.1.1.1 as the gateway for the VE....
Because it would be a Single Point Of Failure for the whole network.... whereas the gateway of my ISP is an huge backbone and is fully redondant in many ways...
But it's perfectly acceptable for providing Internet access to the HN (just for the upgrades)

I'm 99% sure that I've tried what you're suggesting, and that it blocked the network of the HN where I've tried that. (as I told dev, I've already read and tried the Source Based Routing)

But I will try again and tell you if it works or not with your EXACT same lines.... but I actually can't test it right now because I've locked the network of one of the HN by wrongfully trying to add the veth device and the eth device to a same bridge (it locked the network too).

So now I need to go to the datacenter in order to reboot all of my hard failures Smile
I will tell you ASAP (in about 2h) if it works or not with the Source Based Routing.

Thanks again.

Ugo

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: *RESOLVED* Solaris 10 Template
Next Topic: *BUG REPORTED* Migration problem with 2.6.18-028stab035
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Oct 14 08:55:28 GMT 2024

Total time taken to generate the page: 0.05729 seconds
Powered by FUDforum Powered by Virtuozzo Containers