Re: Consulta Container 2 Nic OpenVz
Respondo entre lineas 2010/3/2 Marc Aymerich glicer...@gmail.com: Yo núnca he visto una sola IP del bridge interno en ningún log de ningún HN ni Container, y no es que no mire los logs :) Incluso haciendo un tcpdump -i venet0, todas las ip's que veo són las esperadas. Eso si, sín las reglas ip que he mencionado pasaria exactamente lo que tu comentas. En eso te doy la razón, porque tiene un servidor con una sola interface hacia LAN. Mis servers son todos gateways tambien por lo tanto la interface venet0 siempre apunta a la interface LAN (generalmente eth1) y alli sí la red venet tiene su propia IP. Si puedes poner restricciones para los servicios. Yo lo hago a través de tcp_wrappers (/etc/hosts.allow y /etc/hosts.deny), y con iptables también puedes, aunque yo no lo uso. La clave está en el par de reglas ip que uso, sin ellas estoy convencido que seria como tu comentas. uso intensivamente denyhosts, lo conozco muy bien. Si quiere mantener las redes separadas, no hay mas opcion que usar veth. De acuerdo con eso. Y sobre el ping te voy a decir algo al respecto... ICMP lo entre los pocos resultados que te puede dar es la latencia, NO el bandwith que por ahi viene la confusion. No soy experto en el protocolo ICMP pero el número de paquetes ICMP que una red es capaz de asumir me parece un dato bastante razonable para tener una idea de que tecnologia es más eficiente. ping -f hace flood ICMP, así que cuanto más eficiente sea el dispositivo de red, más echo replays podrá recivir. ping -f envía un paquete de 84 bytes por vez, muchas si pero no mayor a eso, cualquier host puede manejar esos paquetes tranquilamente. Te sugiero tengas un iptraf o iftop a mano mientras realizas el ping verás que nunca sobrepasa los 4.80mbs en un LAN, casi el 50% del total disponible en una red de 100 . nodo B 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Tengo algo parecido. saludos, y disculpa mi insisténcia :) No hay problema porque asi es como se aprende, intercambiando datos y experiencias. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31003040132hb166f16w2ac89f6ddb672...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/3/2 deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar 2010/2/26 Marc Aymerich glicer...@gmail.com: Que quieres decir con discriminar trafico? Yo tengo varios containers conectados a multiples redes (NIC por red) y el trafico de la red X sale por la interficie fisica de red X' y el trafico de la red Y sale por la interficie fisica de red Y'. Para asegurarse de que se comporta de esta manera no está de más usar un par de reglas de enrrutado dentro del container. Algo como: ip r add 10.0.0.0/24 dev venet0 src 10.0.0.21 ip r add 77.206.129.0/24 dev venet0 src 77.206.129.81 De esta forma te aseguras que al passar pro el bridge interno se mantienen las ips origen y cuando el HN las encamine lo hará por la interficie asociada a cada red. Encuento al rendimiento, pués no, no lo digo por lo que hay en el wiki de openvz. En su dia realizé varias pruevas de performance ya que mis servidores tienen mucho trafico y el rendimiento era algo a tener en cuenta. Lo que hice fué hacer varios ping -f a través de venet i veth. Al analizar los datos pude concluir que las venet tenian entre un 10-15% más de desempeño, osea que en el mismo tiempo recivia un 10-15% más de paquetes. Te voy a explicar porque con esa solucion te quedas a medias nada mas. 1ro: Solo te sirve para el trafico saliente de la VM, eso a su vez me lleva al segundo punto. 2do: Que al pasar todo el trafico por el bridge interno siempre la IP que tengas en los logs sera la de ese bridge interno. No te sirve para llevar un control correcto de los logs, ni tampoco si quiere especificar reglas de acceso en base a MACs/IPs ya que veras las IPs externas, sino la del bridge interno. Buenas, Dejame insistirte con otro correo más :) Te sorprenderias de lo que pasa al usuar las reglas IP que comenté: ip r add 10.0.0.0/24 dev venet0 src 10.0.0.21 ip r add 77.206.129.0/24 dev venet0 src 77.206.129.81 Yo núnca he visto una sola IP del bridge interno en ningún log de ningún HN ni Container, y no es que no mire los logs :) Incluso haciendo un tcpdump -i venet0, todas las ip's que veo són las esperadas. Eso si, sín las reglas ip que he mencionado pasaria exactamente lo que tu comentas. Si por ejemplo yo quisiera poner un MTA (justo como el que estoy necesitando ahora) no puedo asignar a mi red local el envio sin autentificar (por mas que ninca hago eso) Completamente deacuerdo con eso. y menos que menos poner restricciones de acceso si quiero que se conecte a mi ssh el host micasa.no-ip.org y no mioficina.no-ip.org. Si puedes poner restricciones para los servicios. Yo lo hago a través de tcp_wrappers (/etc/hosts.allow y /etc/hosts.deny), y con iptables también puedes, aunque yo no lo uso. La clave está en el par de reglas ip que uso, sin ellas estoy convencido que seria como tu comentas. Si quiere mantener las redes separadas, no hay mas opcion que usar veth. De acuerdo con eso. Y sobre el ping te voy a decir algo al respecto... ICMP lo entre los pocos resultados que te puede dar es la latencia, NO el bandwith que por ahi viene la confusion. No soy experto en el protocolo ICMP pero el número de paquetes ICMP que una red es capaz de asumir me parece un dato bastante razonable para tener una idea de que tecnologia es más eficiente. ping -f hace flood ICMP, así que cuanto más eficiente sea el dispositivo de red, más echo replays podrá recivir. Ademas no es lo mismo hacer las pruebas en un ambiente pristino y con tarjetas/placas de red confiables (para servidores) que con una Realtek8139/69. nodo A 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0c:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) nodo B 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Saludos saludos, y disculpa mi insisténcia :) -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31003011948ua3b439fi75c408cca7415...@mail.gmail.com -- Marc -- To UNSUBSCRIBE, email to
Re: Consulta Container 2 Nic OpenVz
2010/2/26 Marc Aymerich glicer...@gmail.com: Que quieres decir con discriminar trafico? Yo tengo varios containers conectados a multiples redes (NIC por red) y el trafico de la red X sale por la interficie fisica de red X' y el trafico de la red Y sale por la interficie fisica de red Y'. Para asegurarse de que se comporta de esta manera no está de más usar un par de reglas de enrrutado dentro del container. Algo como: ip r add 10.0.0.0/24 dev venet0 src 10.0.0.21 ip r add 77.206.129.0/24 dev venet0 src 77.206.129.81 De esta forma te aseguras que al passar pro el bridge interno se mantienen las ips origen y cuando el HN las encamine lo hará por la interficie asociada a cada red. Encuento al rendimiento, pués no, no lo digo por lo que hay en el wiki de openvz. En su dia realizé varias pruevas de performance ya que mis servidores tienen mucho trafico y el rendimiento era algo a tener en cuenta. Lo que hice fué hacer varios ping -f a través de venet i veth. Al analizar los datos pude concluir que las venet tenian entre un 10-15% más de desempeño, osea que en el mismo tiempo recivia un 10-15% más de paquetes. Te voy a explicar porque con esa solucion te quedas a medias nada mas. 1ro: Solo te sirve para el trafico saliente de la VM, eso a su vez me lleva al segundo punto. 2do: Que al pasar todo el trafico por el bridge interno siempre la IP que tengas en los logs sera la de ese bridge interno. No te sirve para llevar un control correcto de los logs, ni tampoco si quiere especificar reglas de acceso en base a MACs/IPs ya que veras las IPs externas, sino la del bridge interno. Si por ejemplo yo quisiera poner un MTA (justo como el que estoy necesitando ahora) no puedo asignar a mi red local el envio sin autentificar (por mas que ninca hago eso) y menos que menos poner restricciones de acceso si quiero que se conecte a mi ssh el host micasa.no-ip.org y no mioficina.no-ip.org. Se entiende...? Si quiere mantener las redes separadas, no hay mas opcion que usar veth. Y sobre el ping te voy a decir algo al respecto... ICMP lo entre los pocos resultados que te puede dar es la latencia, NO el bandwith que por ahi viene la confusion. Ademas no es lo mismo hacer las pruebas en un ambiente pristino y con tarjetas/placas de red confiables (para servidores) que con una Realtek8139/69. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31003011948ua3b439fi75c408cca7415...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/26 deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar: 2010/2/26 CHACO diego.cha...@gmail.com: Gracias !! Y por aprender, x que venet no funciona? En que casos se debe usar uno u el otro? No es que venet no funcione, puedes ponerle las IPs 2 ambas interfaces. Pero sucede que el modo venet esta asociado a una interface real en el anfitrion, y si le pones la IP de la otra subred, al estar venet asigando a eth1 (ejemplo) se comporta como un bridge con su propia subred internet, que generalmente es 10.1.1.0/24. De nada te serviria tener una VM que necesite discriminar tráfico en sus 2 interfaces si ambas terminan siendo una sola asignada a la venet del anfitrion. Que quieres decir con discriminar trafico? Yo tengo varios containers conectados a multiples redes (NIC por red) y el trafico de la red X sale por la interficie fisica de red X' y el trafico de la red Y sale por la interficie fisica de red Y'. Para asegurarse de que se comporta de esta manera no está de más usar un par de reglas de enrrutado dentro del container. Algo como: ip r add 10.0.0.0/24 dev venet0 src 10.0.0.21 ip r add 77.206.129.0/24 dev venet0 src 77.206.129.81 De esta forma te aseguras que al passar pro el bridge interno se mantienen las ips origen y cuando el HN las encamine lo hará por la interficie asociada a cada red. Encuento al rendimiento, pués no, no lo digo por lo que hay en el wiki de openvz. En su dia realizé varias pruevas de performance ya que mis servidores tienen mucho trafico y el rendimiento era algo a tener en cuenta. Lo que hice fué hacer varios ping -f a través de venet i veth. Al analizar los datos pude concluir que las venet tenian entre un 10-15% más de desempeño, osea que en el mismo tiempo recivia un 10-15% más de paquetes. Haz las pruebas y lo verás. Por esa razón veth esta hecho para asignar una ethx en la VM a una vethX en el anfitrion y es independiente de la venet, que puede y recomiendo que siga activa aunque no se use. Las veth són por si necesitas una interficie de red lo maximo parecido a una real. Pero para connectar un container a dos redes distintas no hace falta. Repito que yo lo tengo funcionando en varias maquinas. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002252156t25408baehaedeb6494b240...@mail.gmail.com -- Marc -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee5163b51002260409l3538de95oa10bf6c6c1983...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
On Thu, Feb 25, 2010 at 4:11 AM, CHACO diego.cha...@gmail.com wrote: On Wed, Feb 24, 2010 at 8:47 PM, deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar wrote: 2010/2/24 CHACO diego.cha...@gmail.com: Configure devices in CT0 [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp [edit] Configure device in CT [host-node]# vzctl enter 101 [ve-101]# /sbin/ifconfig eth0 0 [ve-101]# /sbin/ip addr add 10.100.0.3 dev eth0 [ve-101]# /sbin/ip route add default dev eth0 Y finalmente ip route add 10.100.03 dev veth101.0 Pregunta, porque no entendí bien... Dijiste que pudiste agregarle una segunda interfaz a la VM.? En este caso eth1..? Qué IP tiene esa interface...? Agregaste una nueva ruta si tiene una IP distinta en el host anfitrion? Tal como esto: ip route add 10.100.03 dev veth101.0 ip route add 192.168.0.1 dev veth101.1 El host anfitrio tiene dos interfaces de red fisicas conectadas a dos redes diferentes. Lo que necesito es que un container se comunique con una red y el otro container con la otra red. tienes 2 containers: container 100 container 101 tienes dos redes 10.0.0.0/24 192.168.1.0/24 solo ponle una ip de la subred que quieras a cada container y openvz hará el resto. # nano /etc/vz/conf/100.conf [...] IP_ADDRESS=10.0.0.10 [...] # nano /etc/vz/conf/101.conf [...] IP_ADDRESS=192.168.1.10 [...] así de simple. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee5163b51002250344n47fa69ddu8add9a9b68ac3...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
On Thu, Feb 25, 2010 at 8:44 AM, Marc Aymerich glicer...@gmail.com wrote: tienes 2 containers: container 100 container 101 tienes dos redes 10.0.0.0/24 192.168.1.0/24 solo ponle una ip de la subred que quieras a cada container y openvz hará el resto. # nano /etc/vz/conf/100.conf [...] IP_ADDRESS=10.0.0.10 [...] # nano /etc/vz/conf/101.conf [...] IP_ADDRESS=192.168.1.10 [...] así de simple. NO, no es asi de simple... evidentemente no sos usuario de openvz. el usuario que preguntó originalmente esta usando openvz en modo veth, por lo tanto necesita separar fisicamente ambas redes, con sus respectivas tablas de ruteo, tu sugerencia asume que esta usando openvz en modo venet lo cual es distinto porque por mas que tenga 2 IPs, internamente sólo tendrá una que es por la que pasan todos los paquetes, que generalmente es 10.1.1.0./24. -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002251345p390173f9hcf19fa0e93a9e...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/25 deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar: On Thu, Feb 25, 2010 at 8:44 AM, Marc Aymerich glicer...@gmail.com wrote: tienes 2 containers: container 100 container 101 tienes dos redes 10.0.0.0/24 192.168.1.0/24 solo ponle una ip de la subred que quieras a cada container y openvz hará el resto. # nano /etc/vz/conf/100.conf [...] IP_ADDRESS=10.0.0.10 [...] # nano /etc/vz/conf/101.conf [...] IP_ADDRESS=192.168.1.10 [...] así de simple. NO, no es asi de simple... evidentemente no sos usuario de openvz. el usuario que preguntó originalmente esta usando openvz en modo veth, por lo tanto necesita separar fisicamente ambas redes, con sus respectivas tablas de ruteo, tu sugerencia asume que esta usando openvz en modo venet lo cual es distinto porque por mas que tenga 2 IPs, internamente sólo tendrá una que es por la que pasan todos los paquetes, que generalmente es 10.1.1.0./24. El usuario que preguntó dijo que no tenia muy clara la diferencia entre el tipo de interficies de red que hay en openvz. En mi primer mensaje le he recomendado que usara las venet, que para lo que quiere ya le sirven, y le he indicado como configurarlas en el segundo mensaje. He asumido que no tenia ninguna preferencia en usar las veth, que són más complicadas y su rendimiento y seguridad son inferiores a las venet. Pensé que habia escojido las veth porque a simple vista parecen más adecuadas para su caso, aunque yo para eso usaria las venet :P Pero bueno, que si hay que usar veth se usan y con tu explicación ya sabrá como hacerlo. Saludos :) -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002251345p390173f9hcf19fa0e93a9e...@mail.gmail.com -- Marc -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee5163b51002251535o23a052b3g4a32db813cb03...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/25 Marc Aymerich glicer...@gmail.com: He asumido que no tenia ninguna preferencia en usar las veth, que són más complicadas y su rendimiento y seguridad son inferiores a las venet. Mas complejas de entender, una vez superado este paso son sumamente simples de implementar. Y el rendimiento es relativo, no porque el wiki de openvz diga eso SIN explicar el porque y máxime que tengo servidores usando venet y veth y no notar ninguna merma en su rendimiento hace que eso sea discutible. Seguridad... el wiki menciona que venet tiene mayor seguridad por el hecho de que venet esta detrás del las reglas iptables del anfitrion, con veth en cambio tienes que escribir tus propias reglas como cualquier servidor con interfaces normales. Asi que eso tambien es discutible Al usuario que hizo la pregunta orginal... Me surgio tambien resolver el mismo problema, tenes 2 veth por cada VM (todas mis VMs las tengo con una) asi que este fin de semana hago las pruebas necesarias y documento todo al respecto. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002251635j2c5ae267x9eeaad13d9fd...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/25 deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar 2010/2/25 Marc Aymerich glicer...@gmail.com: He asumido que no tenia ninguna preferencia en usar las veth, que són más complicadas y su rendimiento y seguridad son inferiores a las venet. Mas complejas de entender, una vez superado este paso son sumamente simples de implementar. Y el rendimiento es relativo, no porque el wiki de openvz diga eso SIN explicar el porque y máxime que tengo servidores usando venet y veth y no notar ninguna merma en su rendimiento hace que eso sea discutible. Seguridad... el wiki menciona que venet tiene mayor seguridad por el hecho de que venet esta detrás del las reglas iptables del anfitrion, con veth en cambio tienes que escribir tus propias reglas como cualquier servidor con interfaces normales. Asi que eso tambien es discutible Al usuario que hizo la pregunta orginal... Me surgio tambien resolver el mismo problema, tenes 2 veth por cada VM (todas mis VMs las tengo con una) asi que este fin de semana hago las pruebas necesarias y documento todo al respecto. Gracias por las respuestas. Yo fui quien pregunto originalmente. Y si no tengo preferencia por ninguno de las dos modalidades, siempre y cuando me funcione. El resumen de mi necesidad es en un host con dos interfaces fisicas, hacer que cada container use cada una de las interfaces para acceder a redes diferentes. Igual probare lo que me han recomendado. Si logras documentar ese caso que necesita seria sumamente valioso. Saludos, -- Diego Chacón Rojas diego.cha...@gmail.com San Jose Costa Rica .-. /v\L I N U X // \\ /( )\ ^^-^^ This is Unix-Land. In quiet nights, you can hear the Windows machines reboot USER350910 MACHINE 244435 No me envie correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html http://www.debian.org/intro/about.es.html
Re: Consulta Container 2 Nic OpenVz
2010/2/26 CHACO diego.cha...@gmail.com: Gracias por las respuestas. Yo fui quien pregunto originalmente. Y si no tengo preferencia por ninguno de las dos modalidades, siempre y cuando me funcione. El resumen de mi necesidad es en un host con dos interfaces fisicas, hacer que cada container use cada una de las interfaces para acceder a redes diferentes. Entonces veth es lo que debes usar venet no te sirve para eso. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002251957p6ec927d6g16b6e11f45271...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/25 deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar 2010/2/26 CHACO diego.cha...@gmail.com: Gracias por las respuestas. Yo fui quien pregunto originalmente. Y si no tengo preferencia por ninguno de las dos modalidades, siempre y cuando me funcione. El resumen de mi necesidad es en un host con dos interfaces fisicas, hacer que cada container use cada una de las interfaces para acceder a redes diferentes. Entonces veth es lo que debes usar venet no te sirve para eso. Gracias !! Y por aprender, x que venet no funciona? En que casos se debe usar uno u el otro? -- Diego Chacón Rojas diego.cha...@gmail.com San Jose Costa Rica .-. /v\L I N U X // \\ /( )\ ^^-^^ This is Unix-Land. In quiet nights, you can hear the Windows machines reboot USER350910 MACHINE 244435 No me envie correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html http://www.debian.org/intro/about.es.html
Re: Consulta Container 2 Nic OpenVz
2010/2/26 CHACO diego.cha...@gmail.com: Gracias !! Y por aprender, x que venet no funciona? En que casos se debe usar uno u el otro? No es que venet no funcione, puedes ponerle las IPs 2 ambas interfaces. Pero sucede que el modo venet esta asociado a una interface real en el anfitrion, y si le pones la IP de la otra subred, al estar venet asigando a eth1 (ejemplo) se comporta como un bridge con su propia subred internet, que generalmente es 10.1.1.0/24. De nada te serviria tener una VM que necesite discriminar tráfico en sus 2 interfaces si ambas terminan siendo una sola asignada a la venet del anfitrion. Haz las pruebas y lo verás. Por esa razón veth esta hecho para asignar una ethx en la VM a una vethX en el anfitrion y es independiente de la venet, que puede y recomiendo que siga activa aunque no se use. Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002252156t25408baehaedeb6494b240...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/24 CHACO diego.cha...@gmail.com: Saludos, Tengo la necesidad de crear un container en openz, el cual debera de tener dos nic. Es un debian estable 64 bits. Con la primera interzar no tengo problema. Se comunica bien con su subred y hacia ella el trafico llega bien. Con la segunda interfaz probe creando una Virtual Ethernet czctl set 101 --netif_add eth0 --save Luego segun esto http://wiki.openvz.org/Veth, hice Configure devices in CT0 [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp [edit] Configure device in CT [host-node]# vzctl enter 101 [ve-101]# /sbin/ifconfig eth0 0 [ve-101]# /sbin/ip addr add 10.100.0.3 dev eth0 [ve-101]# /sbin/ip route add default dev eth0 Y finalmente ip route add 10.100.03 dev veth101.0 Pero no puedo hacerle ping a 10.100.0.3, aunque desde ese container si puedo. Lo que necesito es que ese container tenga comunicacion con las otras maquinas de la otra subred, aunque desde ella si puedo hacer ping, no puedo ni contectarme ssh ni hacerle ping a ella desde otra maquina de la sub red. Estoy en debian estable. Aun estoy confundido entre Virtual Ethernet device, Virtual network device y brigdes. No hace falta que creas una veth (virtual ethernet) para connectarte a más de una red. Lo puedes hacer a través de una venet (virtual network), más eficiente (10%) y más seguro. Ahora mismo no sabria decirte como configurarlo a través del vzctl (tendria que mirar el man), lo que si puedo decirte esque hay otra forma de configurarlo y es editando el fichero de configuración del container (en /etc/vz/conf/vid.conf) y agregar las ip's más o menos así IP_ADDRESS=77.243.129.81 10.0.0.21 77.243.129.84 Cuando el container arranque ya te creará la interficie venet0 venet0:1 y venet0:2 y podras manejar estas ips des del container. Saludos y agradezco los comentarios. -- Diego Chacón Rojas diego.cha...@gmail.com San Jose Costa Rica .-. /v\ L I N U X // \\ /( )\ ^^-^^ This is Unix-Land. In quiet nights, you can hear the Windows machines reboot USER 350910 MACHINE 244435 No me envie correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html http://www.debian.org/intro/about.es.html -- Marc -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee5163b51002241425n6b100c71ya0c6af81738fd...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
2010/2/24 Marc Aymerich glicer...@gmail.com 2010/2/24 CHACO diego.cha...@gmail.com: Saludos, Tengo la necesidad de crear un container en openz, el cual debera de tener dos nic. Es un debian estable 64 bits. Con la primera interzar no tengo problema. Se comunica bien con su subred y hacia ella el trafico llega bien. Con la segunda interfaz probe creando una Virtual Ethernet czctl set 101 --netif_add eth0 --save Luego segun esto http://wiki.openvz.org/Veth, hice Configure devices in CT0 [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp [edit] Configure device in CT [host-node]# vzctl enter 101 [ve-101]# /sbin/ifconfig eth0 0 [ve-101]# /sbin/ip addr add 10.100.0.3 dev eth0 [ve-101]# /sbin/ip route add default dev eth0 Y finalmente ip route add 10.100.03 dev veth101.0 Pero no puedo hacerle ping a 10.100.0.3, aunque desde ese container si puedo. Lo que necesito es que ese container tenga comunicacion con las otras maquinas de la otra subred, aunque desde ella si puedo hacer ping, no puedo ni contectarme ssh ni hacerle ping a ella desde otra maquina de la sub red. Estoy en debian estable. Aun estoy confundido entre Virtual Ethernet device, Virtual network device y brigdes. No hace falta que creas una veth (virtual ethernet) para connectarte a más de una red. Lo puedes hacer a través de una venet (virtual network), más eficiente (10%) y más seguro. Ahora mismo no sabria decirte como configurarlo a través del vzctl (tendria que mirar el man), lo que si puedo decirte esque hay otra forma de configurarlo y es editando el fichero de configuración del container (en /etc/vz/conf/vid.conf) y agregar las ip's más o menos así IP_ADDRESS=77.243.129.81 10.0.0.21 77.243.129.84 Cuando el container arranque ya te creará la interficie venet0 venet0:1 y venet0:2 y podras manejar estas ips des del container. Muchas gracias por la respuesta. Voy a probar Saludos, -- Diego Chacón Rojas diego.cha...@gmail.com San Jose Costa Rica .-. /v\L I N U X // \\ /( )\ ^^-^^ This is Unix-Land. In quiet nights, you can hear the Windows machines reboot USER350910 MACHINE 244435 No me envie correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html http://www.debian.org/intro/about.es.html
Re: Consulta Container 2 Nic OpenVz
2010/2/24 CHACO diego.cha...@gmail.com: Configure devices in CT0 [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp [edit] Configure device in CT [host-node]# vzctl enter 101 [ve-101]# /sbin/ifconfig eth0 0 [ve-101]# /sbin/ip addr add 10.100.0.3 dev eth0 [ve-101]# /sbin/ip route add default dev eth0 Y finalmente ip route add 10.100.03 dev veth101.0 Pregunta, porque no entendí bien... Dijiste que pudiste agregarle una segunda interfaz a la VM.? En este caso eth1..? Qué IP tiene esa interface...? Agregaste una nueva ruta si tiene una IP distinta en el host anfitrion? Tal como esto: ip route add 10.100.03 dev veth101.0 ip route add 192.168.0.1 dev veth101.1 -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002241847o3988966dh3f10aa4199d2b...@mail.gmail.com
Re: Consulta Container 2 Nic OpenVz
On Wed, Feb 24, 2010 at 8:47 PM, deb...@mstaaravin.com.ar deb...@mstaaravin.com.ar wrote: 2010/2/24 CHACO diego.cha...@gmail.com: Configure devices in CT0 [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp [edit] Configure device in CT [host-node]# vzctl enter 101 [ve-101]# /sbin/ifconfig eth0 0 [ve-101]# /sbin/ip addr add 10.100.0.3 dev eth0 [ve-101]# /sbin/ip route add default dev eth0 Y finalmente ip route add 10.100.03 dev veth101.0 Pregunta, porque no entendí bien... Dijiste que pudiste agregarle una segunda interfaz a la VM.? En este caso eth1..? Qué IP tiene esa interface...? Agregaste una nueva ruta si tiene una IP distinta en el host anfitrion? Tal como esto: ip route add 10.100.03 dev veth101.0 ip route add 192.168.0.1 dev veth101.1 El host anfitrio tiene dos interfaces de red fisicas conectadas a dos redes diferentes. Lo que necesito es que un container se comunique con una red y el otro container con la otra red. Saludos, -- Diego Chacón Rojas diego.cha...@gmail.com San Jose Costa Rica .-. /v\L I N U X // \\ /( )\ ^^-^^ This is Unix-Land. In quiet nights, you can hear the Windows machines reboot USER350910 MACHINE 244435 No me envie correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html http://www.debian.org/intro/about.es.html
Re: Consulta Container 2 Nic OpenVz
On Thu, Feb 25, 2010 at 12:11 AM, CHACO diego.cha...@gmail.com wrote: El host anfitrio tiene dos interfaces de red fisicas conectadas a dos redes diferentes. Lo que necesito es que un container se comunique con una red y el otro container con la otra red. Eso se deduce de tu consulta. ahora respondeme mis preguntas. -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://mstaaravin.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161e92c31002242037p2d4b63b3x113388c344e4d...@mail.gmail.com