[opensuse-es] OT: Conectar a mysql con una ip específica
Hola a todos, ¿Hay alguna forma de conectar a un servidor MySQL desde un cliente, asignándole a este último una ip específica?? Me explico. Tengo un servidor con MySQL instalado e IP 172.17.3.3 y un cliente con IP 172.21.2.2. En el servidor MySQL tengo una bd a la que solo se puede acceder desde el cliente 172.21.2.2, pero este a su vez dispone de varias IPs en modo alias para la ejecución de servicios. Ahora necesito ejecutar un script que elimina registros superiores a un mes desde ese cliente y preciso hacerlo desde el propio cliente sí o sí. No puedo hacerlo desde el server ya que antes de ejecutar el script de limpieza se deben ejecutar algunas queries, montar unos archivos txt, extraer datos de esos txts y finalmente ejecutar el script de marras. Estoy mirando la documentacion de mysql y no veo la forma de indicarle al cliente mysql que lance el script con la IP indicada, 172.21.2.2. Por ejemplo algo parecido a como se puede hacer con ssh: "ssh -b 172.21.2.2 root@servidor". ¿Existe alguna opción parecida con el cliente mysql?? Gracias. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-04-25 00:50, carlopmart wrote:
¿Existe alguna opción parecida con el cliente mysql??
¿Que cliente usas? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk20v+YACgkQtTMYHG2NR9VRBQCff7wwGG3+8rkdEoNINXSZ1gKy ldsAn0r1dbIUXCZFZ8jp3C3IzzdHe+F7 =v6E2 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 02:27 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-25 00:50, carlopmart wrote:
¿Existe alguna opción parecida con el cliente mysql??
¿Que cliente usas?
- --
El cliente mondo y lirondo de la propia MySQL: mysql, en linea de comandos ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-04-25 10:46, carlopmart wrote:
On 04/25/2011 02:27 AM, Carlos E. R. wrote:
¿Que cliente usas?
El cliente mondo y lirondo de la propia MySQL: mysql, en linea de comandos ...
· --host=host_name, -h host_name Connect to the MySQL server on the given host. Está en el manual. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk21cGkACgkQtTMYHG2NR9UMYwCfYl21F9g4f9q189iQTZwLBUZU GNIAn0h5yFiHDGQunDQsyW9TOnGmWO2g =BTlP -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 03:00 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-25 10:46, carlopmart wrote:
On 04/25/2011 02:27 AM, Carlos E. R. wrote:
¿Que cliente usas?
El cliente mondo y lirondo de la propia MySQL: mysql, en linea de comandos ...
· --host=host_name, -h host_name
Connect to the MySQL server on the given host.
Está en el manual.
- --
Eso es para conectar al host MySQL, no indica con que IP sale el cliente. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-04-25 19:11, carlopmart wrote:
Eso es para conectar al host MySQL, no indica con que IP sale el cliente.
AH! Estás diciendo que la máquina cliente tiene varias IP. Entonces tienes que definirlo en las rutas. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk214iwACgkQtTMYHG2NR9VxCgCfTc8o4spTDv2v1OUQU4t09Fgp mgMAn0n8IvdRJ/2GADorHPEz3YTi4+jH =uZe0 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 11:05 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-25 19:11, carlopmart wrote:
Eso es para conectar al host MySQL, no indica con que IP sale el cliente.
AH! Estás diciendo que la máquina cliente tiene varias IP. Entonces tienes que definirlo en las rutas.
Mande?? Que rutas?? Todas las IPs que tiene asignadas el cliente pertenecen a la misma subred, a excepción de una que le dá acceso a la cabina iSCSI ... De todas formas ya he podido aplicar una solución. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-04-26 01:25, carlopmart wrote:
Mande?? Que rutas?? Todas las IPs que tiene asignadas el cliente pertenecen a la misma subred, a excepción de una que le dá acceso a la cabina iSCSI ...
Hombre, me estas diciendo que quieres que el cliente se conecte a un servidor mediante una IP de salida concreta. Eso se hace ajustando las rutas, encaminas a un rango por una interfaz concreta.
De todas formas ya he podido aplicar una solución.
Ya lo he visto. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk22DkUACgkQtTMYHG2NR9W5RQCfUVeeBZbJC5Hz9rFf9EHgBv3l 96oAn0iprptJbpP+uYQCTO6JgDvvzu/k =uDPv -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/26/2011 02:13 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-26 01:25, carlopmart wrote:
Mande?? Que rutas?? Todas las IPs que tiene asignadas el cliente pertenecen a la misma subred, a excepción de una que le dá acceso a la cabina iSCSI ...
Hombre, me estas diciendo que quieres que el cliente se conecte a un servidor mediante una IP de salida concreta. Eso se hace ajustando las rutas, encaminas a un rango por una interfaz concreta.
No, si se trata de ip aliases asignadas a la interfaz principal que contiene el hostname. Eso es válido para cuando se disponen de múltiples interfaces, que no es el caso, ya que la interfaz iSCSI no entra en la jugada. Si no sería muy fácil :))
De todas formas ya he podido aplicar una solución.
Ya lo he visto.
Sí, pero es una solución parcial, ya que tengo localizado otro escollo que estoy tratando de solventar. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 25 Apr 2011 00:50:57 +0200, carlopmart escribió:
¿Hay alguna forma de conectar a un servidor MySQL desde un cliente, asignándole a este último una ip específica?? Me explico.
(...) Yo lo enfocaría por otro lado. Al usar alias de IP tiene que haber alguna forma de determinar la prioridad (a bajo nivel) entre las distintas interfaces. A ojo de buen cubero y sin tener muy clara las opciones que se pueden definir en los adaptadores de red, "eth0" sería la interfaz que pondría con "172.21.2.2" porque entiendo que debe ser con la que salga el cliente de manera predeterminada. Pero tiene que haber alguna forma más ortodoxa de "dar peso" a las interfaces sin necesidad de andar cambiando la IP :-? (buscando...) Ah, mira... la opción que buscas está disponible en la 5.6.1: *** http://dev.mysql.com/doc/refman/5.6/en/mysql-command-options.html#option_mys... --bind-address=ip_address On a computer having multiple network interfaces, this option can be used to select which interface is employed when connecting to the MySQL server. This option is supported beginning with MySQL 5.6.1. *** Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 12:19 PM, Camaleón wrote:
El Mon, 25 Apr 2011 00:50:57 +0200, carlopmart escribió:
¿Hay alguna forma de conectar a un servidor MySQL desde un cliente, asignándole a este último una ip específica?? Me explico.
(...)
Yo lo enfocaría por otro lado.
Al usar alias de IP tiene que haber alguna forma de determinar la prioridad (a bajo nivel) entre las distintas interfaces.
A ojo de buen cubero y sin tener muy clara las opciones que se pueden definir en los adaptadores de red, "eth0" sería la interfaz que pondría con "172.21.2.2" porque entiendo que debe ser con la que salga el cliente de manera predeterminada.
Si, pero eso no es factible. La IP principal de ese host es otra y no puede ser moficada ...
Pero tiene que haber alguna forma más ortodoxa de "dar peso" a las interfaces sin necesidad de andar cambiando la IP :-?
(buscando...)
Ah, mira... la opción que buscas está disponible en la 5.6.1:
*** http://dev.mysql.com/doc/refman/5.6/en/mysql-command-options.html#option_mys...
--bind-address=ip_address
On a computer having multiple network interfaces, this option can be used to select which interface is employed when connecting to the MySQL server.
This option is supported beginning with MySQL 5.6.1. ***
Puf ... Pues mi cliente es 5.1 ... bueno miraré a ver como puedo hacerlo, si compilar nueva release de cliente (que no me hac maldita la gracia por el tema parches) o bien transferir toda la info al servidor MySQL y que sea él, le que ejecute todo el procedimiento ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 25 Apr 2011 12:57:58 +0200, carlopmart escribió:
On 04/25/2011 12:19 PM, Camaleón wrote:
(...)
A ojo de buen cubero y sin tener muy clara las opciones que se pueden definir en los adaptadores de red, "eth0" sería la interfaz que pondría con "172.21.2.2" porque entiendo que debe ser con la que salga el cliente de manera predeterminada.
Si, pero eso no es factible. La IP principal de ese host es otra y no puede ser moficada ...
Pero tiene que haber alguna forma más ortodoxa de "dar peso" a las interfaces sin necesidad de andar cambiando la IP :-?
Hum... ¿Y definiendo una ruta para interfaz, sería factible? Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1" Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 06:23 PM, Camaleón wrote:
El Mon, 25 Apr 2011 12:57:58 +0200, carlopmart escribió:
On 04/25/2011 12:19 PM, Camaleón wrote:
(...)
A ojo de buen cubero y sin tener muy clara las opciones que se pueden definir en los adaptadores de red, "eth0" sería la interfaz que pondría con "172.21.2.2" porque entiendo que debe ser con la que salga el cliente de manera predeterminada.
Si, pero eso no es factible. La IP principal de ese host es otra y no puede ser moficada ...
Pero tiene que haber alguna forma más ortodoxa de "dar peso" a las interfaces sin necesidad de andar cambiando la IP :-?
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Saludos,
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/25/2011 07:12 PM, carlopmart wrote:
On 04/25/2011 06:23 PM, Camaleón wrote:
El Mon, 25 Apr 2011 12:57:58 +0200, carlopmart escribió:
On 04/25/2011 12:19 PM, Camaleón wrote:
(...)
A ojo de buen cubero y sin tener muy clara las opciones que se pueden definir en los adaptadores de red, "eth0" sería la interfaz que pondría con "172.21.2.2" porque entiendo que debe ser con la que salga el cliente de manera predeterminada.
Si, pero eso no es factible. La IP principal de ese host es otra y no puede ser moficada ...
Pero tiene que haber alguna forma más ortodoxa de "dar peso" a las interfaces sin necesidad de andar cambiando la IP :-?
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Saludos,
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar.
Saludos.
Bueno, pues al final ha sido algo tan "chorras" como poner esta regla única de iptables (no he necesitado iproute2 para nada): iptables -t nat -A POSTROUTING -o eth1 -d 172.17.3.3 -p tcp --dport 3306 -j SNAT --to-source 172.21.2.2 Pues listo. Ahora comprobaré varios servicios y otros scripts para comprobar que no he "roto" nada. Gracias a todos por las respuestas. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 25 Apr 2011 20:37:14 +0200, carlopmart escribió:
On 04/25/2011 07:12 PM, carlopmart wrote:
(...)
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar.
Bueno, pues al final ha sido algo tan "chorras" como poner esta regla única de iptables (no he necesitado iproute2 para nada):
iptables -t nat -A POSTROUTING -o eth1 -d 172.17.3.3 -p tcp --dport 3306 -j SNAT --to-source 172.21.2.2
Pues listo. Ahora comprobaré varios servicios y otros scripts para comprobar que no he "roto" nada.
En realidad me refería a algo más "mundano", manipulando la tabla de rutas. Ya sé que tu caso puede ser más complicado porque entran en juego otros factores pero esto no es tanto una respuesta para ti sino para mí, para comprobar que se puede forzar la salida del tráfico de red hacia un determinado host por la interfaz origen que se quiera, en lugar de la predeterminada. Pongo un ejemplo práctico (nota: esto es en una Debian por lo que los comandos o las salidas pueden diferir de las vuestras): Dadas las interfaces: root@debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.163 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe54:f3a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4434 errors:0 dropped:0 overruns:0 frame:0 TX packets:3884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2575081 (2.4 MiB) TX bytes:508718 (496.7 KiB) eth0:0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.200 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth0:1 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.201 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:868 (868.0 B) TX bytes:868 (868.0 B) Y la tabla de rutas predeterminada: root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Si ejecutamos un simple ping a cualquier equipo de la red, el tráfico sale por eth0 (con el parámetro -B podemos forzar el uso de una interfaz determinada, lo cual me viene muy bien para este ejemplo porque me permite ver cuál es la que está usando en cada momento): root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.354 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.402 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.407 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.354/0.387/0.407/0.032 ms Bien, si por lo que sea queremos que el ping (o cualquier otro comando) salga por una interfaz distinta (eth0:0, eth0:1, ethx, ethx:x...) podemos modificar la tabla de rutas para que cualquier paquete con destino al host especificado (en este caso 172.168.0.150) utilice la interfaz que nosotros queramos: root@debian:~# route add -host 172.16.0.150 dev eth0:0 root@debian:~# ip ro 172.16.0.150 dev eth0 scope link src 172.16.0.200 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Y al ejecutar el ping (y con la ayuda de -B) vemos que se ejecuta por la interfaz seleccionada (eth0:0): root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.200 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.516 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.137 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.415 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.137/0.356/0.516/0.160 ms Mola :-P La ventaja que tiene este sistema es que las rutas son dinámicas y se pueden crear/eliminar al vuelo y a conveniencia para que no altere el funcionamiento habitual de la red por lo que al terminar lo que sea que tengamos que hacer que requiera salir por una interfaz determinada para alcanzar un equipo concreto, sólo tenemos que eliminar la ruta: root@debian:~# route del -host 172.16.0.150 dev eth0:0 Y todo vuelve a la normalidad: root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.061 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.457 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.237 ms --- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.061/0.251/0.457/0.163 ms root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0 Esa era la idea que tenía en mente y por lo que veo parece factible :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/26/2011 10:59 PM, Camaleón wrote:
El Mon, 25 Apr 2011 20:37:14 +0200, carlopmart escribió:
On 04/25/2011 07:12 PM, carlopmart wrote:
(...)
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar.
Bueno, pues al final ha sido algo tan "chorras" como poner esta regla única de iptables (no he necesitado iproute2 para nada):
iptables -t nat -A POSTROUTING -o eth1 -d 172.17.3.3 -p tcp --dport 3306 -j SNAT --to-source 172.21.2.2
Pues listo. Ahora comprobaré varios servicios y otros scripts para comprobar que no he "roto" nada.
En realidad me refería a algo más "mundano", manipulando la tabla de rutas. Ya sé que tu caso puede ser más complicado porque entran en juego otros factores pero esto no es tanto una respuesta para ti sino para mí, para comprobar que se puede forzar la salida del tráfico de red hacia un determinado host por la interfaz origen que se quiera, en lugar de la predeterminada.
Pongo un ejemplo práctico (nota: esto es en una Debian por lo que los comandos o las salidas pueden diferir de las vuestras):
Dadas las interfaces:
root@debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.163 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe54:f3a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4434 errors:0 dropped:0 overruns:0 frame:0 TX packets:3884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2575081 (2.4 MiB) TX bytes:508718 (496.7 KiB)
eth0:0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.200 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.201 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:868 (868.0 B) TX bytes:868 (868.0 B)
Y la tabla de rutas predeterminada:
root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Si ejecutamos un simple ping a cualquier equipo de la red, el tráfico sale por eth0 (con el parámetro -B podemos forzar el uso de una interfaz determinada, lo cual me viene muy bien para este ejemplo porque me permite ver cuál es la que está usando en cada momento):
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.354 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.402 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.407 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.354/0.387/0.407/0.032 ms
Bien, si por lo que sea queremos que el ping (o cualquier otro comando) salga por una interfaz distinta (eth0:0, eth0:1, ethx, ethx:x...) podemos modificar la tabla de rutas para que cualquier paquete con destino al host especificado (en este caso 172.168.0.150) utilice la interfaz que nosotros queramos:
root@debian:~# route add -host 172.16.0.150 dev eth0:0 root@debian:~# ip ro 172.16.0.150 dev eth0 scope link src 172.16.0.200 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Y al ejecutar el ping (y con la ayuda de -B) vemos que se ejecuta por la interfaz seleccionada (eth0:0):
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.200 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.516 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.137 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.415 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.137/0.356/0.516/0.160 ms
Mola :-P
La ventaja que tiene este sistema es que las rutas son dinámicas y se pueden crear/eliminar al vuelo y a conveniencia para que no altere el funcionamiento habitual de la red por lo que al terminar lo que sea que tengamos que hacer que requiera salir por una interfaz determinada para alcanzar un equipo concreto, sólo tenemos que eliminar la ruta:
root@debian:~# route del -host 172.16.0.150 dev eth0:0
Y todo vuelve a la normalidad:
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.061 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.457 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.237 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.061/0.251/0.457/0.163 ms
root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Esa era la idea que tenía en mente y por lo que veo parece factible :-)
Saludos,
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo
antiguo". Si asignas las ip alias con la suite iproute2 (que creo que
debian lo puede hacer), el invento no funciona.
Mira, te pongo de ejemplo otro host que tengo utilizando ip alias con
iproute2:
[root@prodclunode05 ~]# ip addr
1: lo:
On 04/27/2011 12:09 AM, carlopmart wrote:
On 04/26/2011 10:59 PM, Camaleón wrote:
El Mon, 25 Apr 2011 20:37:14 +0200, carlopmart escribió:
On 04/25/2011 07:12 PM, carlopmart wrote:
(...)
Hum... ¿Y definiendo una ruta para interfaz, sería factible?
Algo del tipo "el tráfico que vaya hacia 172.17.3.3 que salga por eth0:1"
Lo que comentas es utilizar iproute2 + iptables. Sí, eso es factible, pero corro el riesgo de complicar y mucho la estructura de ese servidor, y puede que no me valga la pena ... pero lo puedo mirar.
Bueno, pues al final ha sido algo tan "chorras" como poner esta regla única de iptables (no he necesitado iproute2 para nada):
iptables -t nat -A POSTROUTING -o eth1 -d 172.17.3.3 -p tcp --dport 3306 -j SNAT --to-source 172.21.2.2
Pues listo. Ahora comprobaré varios servicios y otros scripts para comprobar que no he "roto" nada.
En realidad me refería a algo más "mundano", manipulando la tabla de rutas. Ya sé que tu caso puede ser más complicado porque entran en juego otros factores pero esto no es tanto una respuesta para ti sino para mí, para comprobar que se puede forzar la salida del tráfico de red hacia un determinado host por la interfaz origen que se quiera, en lugar de la predeterminada.
Pongo un ejemplo práctico (nota: esto es en una Debian por lo que los comandos o las salidas pueden diferir de las vuestras):
Dadas las interfaces:
root@debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.163 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe54:f3a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4434 errors:0 dropped:0 overruns:0 frame:0 TX packets:3884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2575081 (2.4 MiB) TX bytes:508718 (496.7 KiB)
eth0:0 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.200 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 08:00:27:54:f3:a2 inet addr:172.16.0.201 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:868 (868.0 B) TX bytes:868 (868.0 B)
Y la tabla de rutas predeterminada:
root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Si ejecutamos un simple ping a cualquier equipo de la red, el tráfico sale por eth0 (con el parámetro -B podemos forzar el uso de una interfaz determinada, lo cual me viene muy bien para este ejemplo porque me permite ver cuál es la que está usando en cada momento):
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.354 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.402 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.407 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.354/0.387/0.407/0.032 ms
Bien, si por lo que sea queremos que el ping (o cualquier otro comando) salga por una interfaz distinta (eth0:0, eth0:1, ethx, ethx:x...) podemos modificar la tabla de rutas para que cualquier paquete con destino al host especificado (en este caso 172.168.0.150) utilice la interfaz que nosotros queramos:
root@debian:~# route add -host 172.16.0.150 dev eth0:0 root@debian:~# ip ro 172.16.0.150 dev eth0 scope link src 172.16.0.200 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Y al ejecutar el ping (y con la ayuda de -B) vemos que se ejecuta por la interfaz seleccionada (eth0:0):
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.200 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.516 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.137 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.415 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.137/0.356/0.516/0.160 ms
Mola :-P
La ventaja que tiene este sistema es que las rutas son dinámicas y se pueden crear/eliminar al vuelo y a conveniencia para que no altere el funcionamiento habitual de la red por lo que al terminar lo que sea que tengamos que hacer que requiera salir por una interfaz determinada para alcanzar un equipo concreto, sólo tenemos que eliminar la ruta:
root@debian:~# route del -host 172.16.0.150 dev eth0:0
Y todo vuelve a la normalidad:
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.163 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.061 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.457 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.237 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.061/0.251/0.457/0.163 ms
root@debian:~# ip ro 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.163 169.254.0.0/16 dev eth0 scope link metric 1000 default via 172.16.0.1 dev eth0
Esa era la idea que tenía en mente y por lo que veo parece factible :-)
Saludos,
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo antiguo". Si asignas las ip alias con la suite iproute2 (que creo que debian lo puede hacer), el invento no funciona.
Mira, te pongo de ejemplo otro host que tengo utilizando ip alias con iproute2:
[root@prodclunode05 ~]# ip addr 1: lo:
mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:0c:86:0a brd ff:ff:ff:ff:ff:ff inet 172.25.100.4/28 scope global eth0 inet6 fe80::250:56ff:fe0c:860a/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:28:c8:dc brd ff:ff:ff:ff:ff:ff inet 172.25.50.15/27 brd 172.25.50.31 scope global eth1 inet 172.25.50.22/27 scope global secondary eth1 inet 172.25.50.24/27 scope global secondary eth1 inet 172.25.50.16/27 scope global secondary eth1 inet6 fe80::250:56ff:fe28:c8dc/64 scope link valid_lft forever preferred_lft forever ... y la salida del comando ifconfig:
[root@prodclunode05 ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:0C:86:0A inet addr:172.25.100.4 Bcast:0.0.0.0 Mask:255.255.255.240 inet6 addr: fe80::250:56ff:fe0c:860a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27956 errors:0 dropped:0 overruns:0 frame:0 TX packets:18278 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:71128036 (67.8 MiB) TX bytes:6875844 (6.5 MiB)
eth1 Link encap:Ethernet HWaddr 00:50:56:28:C8:DC inet addr:172.25.50.15 Bcast:172.25.50.31 Mask:255.255.255.224 inet6 addr: fe80::250:56ff:fe28:c8dc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:863 errors:0 dropped:0 overruns:0 frame:0 TX packets:1028 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:88650 (86.5 KiB) TX bytes:174562 (170.4 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4060 errors:0 dropped:0 overruns:0 frame:0 TX packets:4060 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:546184 (533.3 KiB) TX bytes:546184 (533.3 KiB)
Las ip alias, en el caso de usar el comando ifconfig, ni aparecen, y no, no es un error ... (Las ips de eth0 no entran en juego, porque acceden a una cabina iSCSI).
Como verás lo que has probado, no funcionará porque cualquier ruta que insertes apuntará al default gateway de eth0 con salida de tráfico la propia eth0, no existen ni eth0:1 ni eth0:2, etc. He ahí el problema.
¿Y porque es así en mi caso? Porque tanto en el host que indico en el email como el que os pongo de ejemplo, es un cluster de 4 nodos cada uno. Para prestar el servicio, se utilizan las "ip flotantes" y estas se asignan via iproute2, no se generan interfaces eth0:X ya que no se utiliza el comando ifconfig. Si pruebas, verás que con iproute2 no podrás generar esas interfaces.
De todas formas, la solución que he indicado no me ha servido de gran cosa, porque hoy mismo he tenido que añadir otro servicio al cluster basado en mysql y como podrás ver todo se me va al traste.
¿Solución? He modificado las ACLs del host mysql e insertado las ip primarias de todos y cada uno de los nodos del cluster como ips de acceso (en el ejemplo esa ip primaria es la 172.25.50.15). Aparte he añadido dicha regla iptables a todos los nodos para forzar siempre la misma ip de salida cuando se ejecuta el comando mysql.
El "invento" sirve para cualquier comando/servicio, etc que no sea capaz de bindar a una ip específica.
Saludos.
Perdón, substituye todo lo que digo de eth0 por eth1, par ajustarme al ejemplo. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 27 Apr 2011 00:09:42 +0200, carlopmart escribió: (recorta sin miedo)
On 04/26/2011 10:59 PM, Camaleón wrote:
(...)
En realidad me refería a algo más "mundano", manipulando la tabla de rutas. Ya sé que tu caso puede ser más complicado porque entran en juego otros factores pero esto no es tanto una respuesta para ti sino para mí, para comprobar que se puede forzar la salida del tráfico de red hacia un determinado host por la interfaz origen que se quiera, en lugar de la predeterminada.
(...)
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo antiguo". Si asignas las ip alias con la suite iproute2 (que creo que debian lo puede hacer), el invento no funciona.
(...) No sé cómo utilizar explícitamente iproute2 en Debian. Las interfaces virtuales se asignan manualmente desde el archivo de configuración "/etc/ network/interfaces" usando la nomenclatura antigua (eth0:0, eth0:1...) y no sé si ese archivo acepta ya la nueva :-? Ahora bien... ¿cómo se identifica unívocamente una interfaz de tipo "alias" con iproute2? Tiene que haber alguna forma. Por la webe me ha parecido leer que se le pueden añadir "etiquetas" para nombrarlas y para poder configurar las rutas. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 27 Apr 2011 11:39:37 +0000, Camaleón escribió:
El Wed, 27 Apr 2011 00:09:42 +0200, carlopmart escribió:
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo antiguo". Si asignas las ip alias con la suite iproute2 (que creo que debian lo puede hacer), el invento no funciona.
(...)
No sé cómo utilizar explícitamente iproute2 en Debian. Las interfaces virtuales se asignan manualmente desde el archivo de configuración "/etc/ network/interfaces" usando la nomenclatura antigua (eth0:0, eth0:1...) y no sé si ese archivo acepta ya la nueva :-?
Ahora bien... ¿cómo se identifica unívocamente una interfaz de tipo "alias" con iproute2? Tiene que haber alguna forma. Por la webe me ha parecido leer que se le pueden añadir "etiquetas" para nombrarlas y para poder configurar las rutas.
<modo matrix on>
"Tanque, carga el programa de iproute2"
(5 minutos después)
"Ya sé cómo funciona iproute2"
Con iproute2 parece que funciona de igual forma.
Añadimos el alias con la etiqueta:
root@debian:~# ip addr add 172.16.0.200/24 brd 172.16.0.255 dev eth0 label eth0:0
^^^^^^^^^^^^
root@debian:~# ip addr show
1: lo:
On 04/27/2011 05:50 PM, Camaleón wrote:
El Wed, 27 Apr 2011 11:39:37 +0000, Camaleón escribió:
El Wed, 27 Apr 2011 00:09:42 +0200, carlopmart escribió:
Todo ok, pero hay una pega. Estás asginando ip aliases "al modo antiguo". Si asignas las ip alias con la suite iproute2 (que creo que debian lo puede hacer), el invento no funciona.
(...)
No sé cómo utilizar explícitamente iproute2 en Debian. Las interfaces virtuales se asignan manualmente desde el archivo de configuración "/etc/ network/interfaces" usando la nomenclatura antigua (eth0:0, eth0:1...) y no sé si ese archivo acepta ya la nueva :-?
Ahora bien... ¿cómo se identifica unívocamente una interfaz de tipo "alias" con iproute2? Tiene que haber alguna forma. Por la webe me ha parecido leer que se le pueden añadir "etiquetas" para nombrarlas y para poder configurar las rutas.
<modo matrix on> "Tanque, carga el programa de iproute2" (5 minutos después) "Ya sé cómo funciona iproute2"
Con iproute2 parece que funciona de igual forma.
Añadimos el alias con la etiqueta:
root@debian:~# ip addr add 172.16.0.200/24 brd 172.16.0.255 dev eth0 label eth0:0 ^^^^^^^^^^^^
root@debian:~# ip addr show 1: lo:
mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:54:f3:a2 brd ff:ff:ff:ff:ff:ff inet 172.16.0.163/24 brd 172.16.0.255 scope global eth0 inet 172.16.0.200/24 brd 172.16.0.255 scope global secondary eth0:0 inet6 fe80::a00:27ff:fe54:f3a2/64 scope link valid_lft forever preferred_lft forever Y creamos la ruta:
root@debian:~# route add -host 172.16.0.150 dev eth0:0
Ejecutamos el ping:
root@debian:~# ping -c 3 -B 172.16.0.150 PING 172.16.0.150 (172.16.0.150) from 172.16.0.200 : 56(84) bytes of data. 64 bytes from 172.16.0.150: icmp_req=1 ttl=128 time=0.543 ms 64 bytes from 172.16.0.150: icmp_req=2 ttl=128 time=0.358 ms 64 bytes from 172.16.0.150: icmp_req=3 ttl=128 time=0.431 ms
--- 172.16.0.150 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.358/0.444/0.543/0.076 ms
Y vemos cómo se fuerza la salida por el alias :-)
Saludos,
Yep, eso no lo habia visto ... ¿que versión de iproute2 tienes?? Aunque de todas formas, en mi caso, tampoco me sirve de gran cosa ya que es un servicio el que asigna las ip aliases y no asignará labels ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 27 Apr 2011 19:40:12 +0200, carlopmart escribió:
On 04/27/2011 05:50 PM, Camaleón wrote:
(...)
Ahora bien... ¿cómo se identifica unívocamente una interfaz de tipo "alias" con iproute2? Tiene que haber alguna forma. Por la webe me ha parecido leer que se le pueden añadir "etiquetas" para nombrarlas y para poder configurar las rutas.
<modo matrix on> "Tanque, carga el programa de iproute2" (5 minutos después) "Ya sé cómo funciona iproute2"
Con iproute2 parece que funciona de igual forma.
Añadimos el alias con la etiqueta:
root@debian:~# ip addr add 172.16.0.200/24 brd 172.16.0.255 dev eth0 label eth0:0
^^^^^^^^^^^^
(...)
Y vemos cómo se fuerza la salida por el alias :-)
Yep, eso no lo habia visto ... ¿que versión de iproute2 tienes??
"ip -V" devuelve "ip utility, iproute2-ss110317" (wheezy/testing). En lenny "ip utility, iproute2-ss080725".
Aunque de todas formas, en mi caso, tampoco me sirve de gran cosa ya que es un servicio el que asigna las ip aliases y no asignará labels ...
Pues según lo que he ido leyendo por ahí sobre iproute2, mal hecho, más que nada porque si usas aliases y quieres mantener la compatibilidad con ifconfig necesitas las etiquetas para no volver a este último "loco" (también lo indican en el manual). *** label NAME Each address may be tagged with a label string. In order to preserve compatibility with Linux-2.0 net aliases, this string must coincide with the name of the device or must be prefixed with the device name followed by colon. *** Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/27/2011 08:01 PM, Camaleón wrote:
El Wed, 27 Apr 2011 19:40:12 +0200, carlopmart escribió:
On 04/27/2011 05:50 PM, Camaleón wrote:
(...)
Ahora bien... ¿cómo se identifica unívocamente una interfaz de tipo "alias" con iproute2? Tiene que haber alguna forma. Por la webe me ha parecido leer que se le pueden añadir "etiquetas" para nombrarlas y para poder configurar las rutas.
<modo matrix on> "Tanque, carga el programa de iproute2" (5 minutos después) "Ya sé cómo funciona iproute2"
Con iproute2 parece que funciona de igual forma.
Añadimos el alias con la etiqueta:
root@debian:~# ip addr add 172.16.0.200/24 brd 172.16.0.255 dev eth0 label eth0:0
^^^^^^^^^^^^
(...)
Y vemos cómo se fuerza la salida por el alias :-)
Yep, eso no lo habia visto ... ¿que versión de iproute2 tienes??
"ip -V" devuelve "ip utility, iproute2-ss110317" (wheezy/testing). En lenny "ip utility, iproute2-ss080725".
Aunque de todas formas, en mi caso, tampoco me sirve de gran cosa ya que es un servicio el que asigna las ip aliases y no asignará labels ...
Pues según lo que he ido leyendo por ahí sobre iproute2, mal hecho, más que nada porque si usas aliases y quieres mantener la compatibilidad con ifconfig necesitas las etiquetas para no volver a este último "loco" (también lo indican en el manual).
*** label NAME Each address may be tagged with a label string. In order to preserve compatibility with Linux-2.0 net aliases, this string must coincide with the name of the device or must be prefixed with the device name followed by colon. ***
Saludos,
Si, lo he visto ... pero es que la suite de cluster, pero principalmente los hosts, no necesitan esa compatibilidad para operar correctamente, así como ningún proceso o soft que tengo cargado en ellos .. Yo por ejemplo, hace "siglos" que no uso ifconfig en linux para nada, ayer fue la primera vez en mucho tiempo. Pero de todas formas, es bueno saber que existe esa compatibilidad ... No la conocía .. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 27 Apr 2011 20:11:36 +0200, carlopmart escribió:
On 04/27/2011 08:01 PM, Camaleón wrote:
(...)
Pues según lo que he ido leyendo por ahí sobre iproute2, mal hecho, más que nada porque si usas aliases y quieres mantener la compatibilidad con ifconfig necesitas las etiquetas para no volver a este último "loco" (también lo indican en el manual).
(...)
Si, lo he visto ... pero es que la suite de cluster, pero principalmente los hosts, no necesitan esa compatibilidad para operar correctamente, así como ningún proceso o soft que tengo cargado en ellos ..
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Yo por ejemplo, hace "siglos" que no uso ifconfig en linux para nada, ayer fue la primera vez en mucho tiempo.
Bueno, yo intento acostumbrarme a utilizar las nuevas herramientas "iproute2" en lugar de route/ifconfig desde que Cristian R. (que por cierto, hace mucho que no se le ve por aquí :-?) nos dijo que iba a ser el sustituto de... creo que en aquél momento hablábamos del comando "route". Pero de esto hace "años" y sigo sin acostumbrarme :-P
Pero de todas formas, es bueno saber que existe esa compatibilidad ... No la conocía ..
No, yo tampoco. Si no hubiera salido el tema no me habría enterado de esto que comentabas. Tenía mis dudas hasta de que fuera posible forzar la salida por una interfaz determinada por medio de la modificación de la tabla de rutas. Está bien saber estas cosas, nunca sabes cuándo te pueden hacer falta. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/28/2011 01:11 PM, Camaleón wrote:
El Wed, 27 Apr 2011 20:11:36 +0200, carlopmart escribió:
On 04/27/2011 08:01 PM, Camaleón wrote:
(...)
Pues según lo que he ido leyendo por ahí sobre iproute2, mal hecho, más que nada porque si usas aliases y quieres mantener la compatibilidad con ifconfig necesitas las etiquetas para no volver a este último "loco" (también lo indican en el manual).
(...)
Si, lo he visto ... pero es que la suite de cluster, pero principalmente los hosts, no necesitan esa compatibilidad para operar correctamente, así como ningún proceso o soft que tengo cargado en ellos ..
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Cierto, pero de entrada solo es útil en un caso como el mio (no me viene a la cabeza ninguno más). Por ejemplo en otros sistemas Unix, tipo BSD, este "invento" no nos funcionaria ya que tratan las ip aliases como lo hace iproute2. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 28 Apr 2011 13:16:15 +0200, carlopmart escribió:
On 04/28/2011 01:11 PM, Camaleón wrote:
Si, lo he visto ... pero es que la suite de cluster, pero principalmente los hosts, no necesitan esa compatibilidad para operar correctamente, así como ningún proceso o soft que tengo cargado en ellos ..
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Cierto, pero de entrada solo es útil en un caso como el mio (no me viene a la cabeza ninguno más).
Para cualquiera que trabaje con aliases e iproute2. Sin etiquetas ¿cómo hacer referencia a esos alias cuando quieres crear una ruta? Salvo que haya alguna otra forma, necesitas marcar las interfaces para poder identificarlas.
Por ejemplo en otros sistemas Unix, tipo BSD, este "invento" no nos funcionaria ya que tratan las ip aliases como lo hace iproute2.
¿A qué te refieres cuando dices "este invento" y "como lo hace iproute2"? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/28/2011 01:31 PM, Camaleón wrote:
El Thu, 28 Apr 2011 13:16:15 +0200, carlopmart escribió:
On 04/28/2011 01:11 PM, Camaleón wrote:
Si, lo he visto ... pero es que la suite de cluster, pero principalmente los hosts, no necesitan esa compatibilidad para operar correctamente, así como ningún proceso o soft que tengo cargado en ellos ..
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Cierto, pero de entrada solo es útil en un caso como el mio (no me viene a la cabeza ninguno más).
Para cualquiera que trabaje con aliases e iproute2. Sin etiquetas ¿cómo hacer referencia a esos alias cuando quieres crear una ruta? Salvo que haya alguna otra forma, necesitas marcar las interfaces para poder identificarlas.
Las rutas las puedes marcar de distintas maneras sin necesidad de disponer interfaces tipo ethX:X. Por ejemplo mediante la opción neighbour, nexthop, marcado de paquetes, etc. De hecho, la mayoría de las veces el tráfico lo puedes hacer salir por las IPs que desees a menos que el proceso, programa, script, componente, etc (llamémoslo como quieras) no tenga soporte para eso, como me ha pasado a mí con el comando mysql. Eso sí, si hay dos interfaces físicas involucradas, el problema desaparece casi al 100%: entre iproute2 e iptables podrás manipular los paquetes a tu antojo y necesidad. Mírate el manual de iproute2: http://lartc.org/howto/.
Por ejemplo en otros sistemas Unix, tipo BSD, este "invento" no nos funcionaria ya que tratan las ip aliases como lo hace iproute2.
¿A qué te refieres cuando dices "este invento" y "como lo hace iproute2"?
Lo de invento lo pongo entrecomillado para conextualizarlo, no por nada
más ... Y lo de "como lo hace iproute2", me refiero a que si no le
indicas forzosamente la opción "label" no te va a generar la opción de
interfaz virtual tipo ethX:X, vamos que la cosa queda tal cual la puse
en otro correo, así:
3: eth1:
El Thu, 28 Apr 2011 14:03:31 +0200, carlopmart escribió:
On 04/28/2011 01:31 PM, Camaleón wrote:
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Cierto, pero de entrada solo es útil en un caso como el mio (no me viene a la cabeza ninguno más).
Para cualquiera que trabaje con aliases e iproute2. Sin etiquetas ¿cómo hacer referencia a esos alias cuando quieres crear una ruta? Salvo que haya alguna otra forma, necesitas marcar las interfaces para poder identificarlas.
Las rutas las puedes marcar de distintas maneras sin necesidad de disponer interfaces tipo ethX:X. Por ejemplo mediante la opción neighbour, nexthop, marcado de paquetes, etc.
(...) Entonces ¿qué problemas tenías exactamente con tus alias y con la tabla de rutas? Es decir, ¿por qué no hacerlo de esa forma? Cambiar la tabla de rutas se me antoja menos agresivo que modificar iptables :-?
Por ejemplo en otros sistemas Unix, tipo BSD, este "invento" no nos funcionaria ya que tratan las ip aliases como lo hace iproute2.
¿A qué te refieres cuando dices "este invento" y "como lo hace iproute2"?
Lo de invento lo pongo entrecomillado para conextualizarlo, no por nada más ... Y lo de "como lo hace iproute2", me refiero a que si no le indicas forzosamente la opción "label" no te va a generar la opción de interfaz virtual tipo ethX:X, vamos que la cosa queda tal cual la puse en otro correo, así:
3: eth1:
mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:28:c8:dc brd ff:ff:ff:ff:ff:ff inet 172.25.50.15/27 brd 172.25.50.31 scope global eth1 inet 172.25.50.20/27 scope global secondary eth1 inet 172.25.50.22/27 scope global secondary eth1 inet 172.25.50.24/27 scope global secondary eth1 inet6 fe80::250:56ff:fe28:c8dc/64 scope link valid_lft forever preferred_lft forever
Vale, pero ¿por qué dices que no funcionaría en otros sistemas *Unix? Sin el label tampoco funciona en linux, no pillo esa distinción que haces entre linux "y el resto". Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 04/28/2011 03:38 PM, Camaleón wrote:
El Thu, 28 Apr 2011 14:03:31 +0200, carlopmart escribió:
On 04/28/2011 01:31 PM, Camaleón wrote:
Además de la compatibilidad tiene ventaja de poder trabajar con los alias a nivel de enrutado ¿no? :-?
Cierto, pero de entrada solo es útil en un caso como el mio (no me viene a la cabeza ninguno más).
Para cualquiera que trabaje con aliases e iproute2. Sin etiquetas ¿cómo hacer referencia a esos alias cuando quieres crear una ruta? Salvo que haya alguna otra forma, necesitas marcar las interfaces para poder identificarlas.
Las rutas las puedes marcar de distintas maneras sin necesidad de disponer interfaces tipo ethX:X. Por ejemplo mediante la opción neighbour, nexthop, marcado de paquetes, etc.
(...)
Entonces ¿qué problemas tenías exactamente con tus alias y con la tabla de rutas? Es decir, ¿por qué no hacerlo de esa forma? Cambiar la tabla de rutas se me antoja menos agresivo que modificar iptables :-?
Mi problema era que el comando mysql no permite (en la versión que yo tengo instalada, claro) bindar con una ip de salida como lo hace ssh o el propio ping. Es por ello que el servidor mysql denegaba la conexión. El segundo problema que surgió es que tuve que instalar un segundo servicio que también tenia que conectar contra el mismo servidor mysql, pero claro, ambos servicios salían con la ip principal del host y no con las ip de alias. Eso lo pude "forzar" parcialmente con una regla de iptables. Pero ¿que ocurrió? ... que todas las peticiones mysql salían con una única ip. Eso era otro problema. ¿La solución? Conservar la regla iptables, pero en este caso forzando una única IP de conexión al servidor mysql, y no "n" IPs, que era las que necesitaba. Lo que realmente hubiese necesitado, era "algo" que discriminase el tráfico. Esto es: BBDD_1 ----> IP1 BBDD_2 ----> IP2 Cuando ese "algo" detectase una conexión mysql hacia la BBDD_1 debía forzar la IP x.x.x.x, por ejemplo. Cuando detectase una concexión mysql hacia la BBDD_2, forzase la IP y.y.y.y.
Por ejemplo en otros sistemas Unix, tipo BSD, este "invento" no nos funcionaria ya que tratan las ip aliases como lo hace iproute2.
¿A qué te refieres cuando dices "este invento" y "como lo hace iproute2"?
Lo de invento lo pongo entrecomillado para conextualizarlo, no por nada más ... Y lo de "como lo hace iproute2", me refiero a que si no le indicas forzosamente la opción "label" no te va a generar la opción de interfaz virtual tipo ethX:X, vamos que la cosa queda tal cual la puse en otro correo, así:
3: eth1:
mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:28:c8:dc brd ff:ff:ff:ff:ff:ff inet 172.25.50.15/27 brd 172.25.50.31 scope global eth1 inet 172.25.50.20/27 scope global secondary eth1 inet 172.25.50.22/27 scope global secondary eth1 inet 172.25.50.24/27 scope global secondary eth1 inet6 fe80::250:56ff:fe28:c8dc/64 scope link valid_lft forever preferred_lft forever Vale, pero ¿por qué dices que no funcionaría en otros sistemas *Unix? Sin el label tampoco funciona en linux, no pillo esa distinción que haces entre linux "y el resto".
Porque un sistema BSD, FreeBSD u OpenBSD, no hacen interfaces virtuales del tipo ethX:X. Te asignan las ip alias tal como ves en la configuración de ese host linux. Mira: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu... http://www.cyberciti.biz/tips/freebsd-how-to-setup-2-ip-address-on-one-nic.h... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 28 Apr 2011 16:26:00 +0200, carlopmart escribió:
On 04/28/2011 03:38 PM, Camaleón wrote:
Las rutas las puedes marcar de distintas maneras sin necesidad de disponer interfaces tipo ethX:X. Por ejemplo mediante la opción neighbour, nexthop, marcado de paquetes, etc.
(...)
Entonces ¿qué problemas tenías exactamente con tus alias y con la tabla de rutas? Es decir, ¿por qué no hacerlo de esa forma? Cambiar la tabla de rutas se me antoja menos agresivo que modificar iptables :-?
Mi problema era que el comando mysql no permite (en la versión que yo tengo instalada, claro) bindar con una ip de salida como lo hace ssh o el propio ping. Es por ello que el servidor mysql denegaba la conexión.
Ya, no me refiero a eso.
El segundo problema que surgió es que tuve que instalar un segundo servicio que también tenia que conectar contra el mismo servidor mysql, pero claro, ambos servicios salían con la ip principal del host y no con las ip de alias. Eso lo pude "forzar" parcialmente con una regla de iptables. Pero ¿que ocurrió? ... que todas las peticiones mysql salían con una única ip. Eso era otro problema.
(...) Me refiero a por qué no modificar la tabla de rutas en lugar de hacer todo eso. Dijiste que no podías por el tema de los alias y del iproute2 pero ya hemos visto que sí es posible hacerlo.
Vale, pero ¿por qué dices que no funcionaría en otros sistemas *Unix? Sin el label tampoco funciona en linux, no pillo esa distinción que haces entre linux "y el resto".
Porque un sistema BSD, FreeBSD u OpenBSD, no hacen interfaces virtuales del tipo ethX:X. Te asignan las ip alias tal como ves en la configuración de ese host linux. Mira:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu... http://www.cyberciti.biz/tips/freebsd-how-to-setup-2-ip-address-on-one-nic.h...
¿Y cuál es el problema? :-? Supongo que podrás usar el nombre "alias0" para identificar esa interfaz. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2011/4/28 Camaleón
El Thu, 28 Apr 2011 16:26:00 +0200, carlopmart escribió:
El segundo problema que surgió es que tuve que instalar un segundo servicio que también tenia que conectar contra el mismo servidor mysql, pero claro, ambos servicios salían con la ip principal del host y no con las ip de alias. Eso lo pude "forzar" parcialmente con una regla de iptables. Pero ¿que ocurrió? ... que todas las peticiones mysql salían con una única ip. Eso era otro problema.
(...)
Me refiero a por qué no modificar la tabla de rutas en lugar de hacer todo eso. Dijiste que no podías por el tema de los alias y del iproute2 pero ya hemos visto que sí es posible hacerlo.
No, te dije que hay un proceso que controla los servicios del cluster y es el encargado de insertar las ip alias de forma automática y nunca lo hará utilizando las labels, sino tal como has visto en los emails que he enviado.
Vale, pero ¿por qué dices que no funcionaría en otros sistemas *Unix? Sin el label tampoco funciona en linux, no pillo esa distinción que haces entre linux "y el resto".
Porque un sistema BSD, FreeBSD u OpenBSD, no hacen interfaces virtuales del tipo ethX:X. Te asignan las ip alias tal como ves en la configuración de ese host linux. Mira:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu... http://www.cyberciti.biz/tips/freebsd-how-to-setup-2-ip-address-on-one-nic.h...
¿Y cuál es el problema? :-?
Supongo que podrás usar el nombre "alias0" para identificar esa interfaz.
Pues no, hasta donde sé yo. Ahí está el tema ... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 28 Apr 2011 18:38:14 +0200, C. L. Martinez escribió:
2011/4/28 Camaleón:
Me refiero a por qué no modificar la tabla de rutas en lugar de hacer todo eso. Dijiste que no podías por el tema de los alias y del iproute2 pero ya hemos visto que sí es posible hacerlo.
No, te dije que hay un proceso que controla los servicios del cluster y es el encargado de insertar las ip alias de forma automática y nunca lo hará utilizando las labels, sino tal como has visto en los emails que he enviado.
Pues por eso te decía que mal hecho, pero no sólo por mantener la compatibilidad con el sistema antiguo (que no aparezca el "eth1:0" al ejecutar ifconfig no es más que un problema de estética porque el alias está igualmente operativo) sino porque no te permite usar las interfaces "aliaseadas" con las rutas.
Porque un sistema BSD, FreeBSD u OpenBSD, no hacen interfaces virtuales del tipo ethX:X. Te asignan las ip alias tal como ves en la configuración de ese host linux. Mira:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu... http://www.cyberciti.biz/tips/freebsd-how-to-setup-2-ip-address-on-one-nic.h...
¿Y cuál es el problema? :-?
Supongo que podrás usar el nombre "alias0" para identificar esa interfaz.
Pues no, hasta donde sé yo. Ahí está el tema ...
No fastidies... qué limitado ¿no? >:-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2011/4/28 Camaleón
El Thu, 28 Apr 2011 18:38:14 +0200, C. L. Martinez escribió:
2011/4/28 Camaleón:
Me refiero a por qué no modificar la tabla de rutas en lugar de hacer todo eso. Dijiste que no podías por el tema de los alias y del iproute2 pero ya hemos visto que sí es posible hacerlo.
No, te dije que hay un proceso que controla los servicios del cluster y es el encargado de insertar las ip alias de forma automática y nunca lo hará utilizando las labels, sino tal como has visto en los emails que he enviado.
Pues por eso te decía que mal hecho pero no sólo por mantener la compatibilidad con el sistema antiguo (que no aparezca el "eth1:0" al ejecutar ifconfig no es más que un problema de estética porque el alias está igualmente operativo) sino porque no te permite usar las interfaces "aliaseadas" con las rutas.
Mal hecho ... pues no lo sé. Pero vamos las suite de cluster actuales que yo conozco, todas trabajan así en linux sin generar las interfaces ethX:X.
Porque un sistema BSD, FreeBSD u OpenBSD, no hacen interfaces virtuales del tipo ethX:X. Te asignan las ip alias tal como ves en la configuración de ese host linux. Mira:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu... http://www.cyberciti.biz/tips/freebsd-how-to-setup-2-ip-address-on-one-nic.h...
¿Y cuál es el problema? :-?
Supongo que podrás usar el nombre "alias0" para identificar esa interfaz.
Pues no, hasta donde sé yo. Ahí está el tema ...
No fastidies... qué limitado ¿no? >:-?
Saludos,
Hombre yo no lo veo limitado ... De hecho los BSD le dan mil vueltas en esto a linux, como enrutadores, fw, gateways, etc ... al menos IMHO. También es algo muy específico lo que quiero/quería hacer ... Saludos. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 28 Apr 2011 19:31:50 +0200, C. L. Martinez escribió:
2011/4/28 Camaleón:
Pues por eso te decía que mal hecho pero no sólo por mantener la compatibilidad con el sistema antiguo (que no aparezca el "eth1:0" al ejecutar ifconfig no es más que un problema de estética porque el alias está igualmente operativo) sino porque no te permite usar las interfaces "aliaseadas" con las rutas.
Mal hecho ... pues no lo sé. Pero vamos las suite de cluster actuales que yo conozco, todas trabajan así en linux sin generar las interfaces ethX:X.
Supongo que la etiqueta (label) servirá para algo más que para mantener la compatibilidad con ifconfig, por ejemplo, para facilitar la identificación de las interfaces (sean alias o no).
¿Y cuál es el problema? :-?
Supongo que podrás usar el nombre "alias0" para identificar esa interfaz.
Pues no, hasta donde sé yo. Ahí está el tema ...
No fastidies... qué limitado ¿no? >:-?
Hombre yo no lo veo limitado ... De hecho los BSD le dan mil vueltas en esto a linux, como enrutadores, fw, gateways, etc ... al menos IMHO.
También es algo muy específico lo que quiero/quería hacer ...
Eso pensaba yo también por eso me extraña que no exista en BSD un sustituto del para el argumento "dev" del comando ip de linux. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
C. L. Martinez
-
Camaleón
-
carlopmart
-
Carlos E. R.