Re: Consulta Container 2 Nic OpenVz
2010/3/2 debian@mstaaravin.com.ar <debian@mstaaravin.com.ar>
>
> 2010/2/26 Marc Aymerich <glicerinu@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 161e92c31003011948ua3b439fi75c408cca74153fe@mail.gmail.com">http://lists.debian.org/[🔎] 161e92c31003011948ua3b439fi75c408cca74153fe@mail.gmail.com
>
--
Marc
Reply to: