servidor con dos interfaces de red
![Antonio Arriaga [DTI2]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW6BLa0MkYwXPwDeB2ee_whUXHMvUjJUOwhErWpGyZXB9yR=s40-c)
Antonio Arriaga [DTI2]
Antes de exponer el problema digo que ya he buscado bastante en internet y
en la lista y no he visto nada...
Tengo un servidor asterisk con dos interfaces de red (con redes distintas).
Desde el interfaz eth0 todo va perfectamente. El problema es que en el
interfaz eth1 los usuarios no registran.
He comprobado que el invite sí que llega al servidor (uso tcpdump), pero
parece que el servidor no responde (por ninguno de los dos interfaces).
¿alguien tiene alguna idea de qué puede ser?
Gracias y un saludo
==============================================================
Antonio Arriaga
Elio Rojano
Eso más que un problema con Asterisk parece un problema de red.
Tan solo chequea que en el sip.conf tienes el parámetro bindaddr=0.0.0.0
Si no, debe ser algo de red.
--
http://www.sinologic.net/
Iñaki Baz Castillo
> Buenas Antonio,
>
> Eso más que un problema con Asterisk parece un problema de red.
>
> Tan solo chequea que en el sip.conf tienes el parámetro bindaddr=0.0.0.0
>
> Si no, debe ser algo de red.
¿No quedamos en que Asterisk no soporta ni de lejos multihoming? Si tiene
puesto "bindaddress=0.0.0.0" pero recibe por dos interfaces me temo que sólo
uno va a funcionar, ¿cuál? lotería.
--
Iñaki Baz Castillo
<ib...@xtratelecom.es>
ramon martinez
hola, tambien puede ser un problema del domain de asterisk.
prueba a añadir
domain=1.1.1.1
domain=2.2.2.2
con las dos ip en el fichero sip.conf
Iñaki Baz Castillo escribió:
Elio Rojano
primera red: 192.168.1.0
segunda red: 192.168.2.0
defines los localnet correspondientes
y con un route -n te aseguras que las rutas son correctas para cada interfaz y debe funcionar sin problemas.
Y cierto, los domains también tienen que estar configurados para cada red.
http://www.sinologic.net/
Jon Bonilla
Iñaki Baz Castillo <ib...@xtratelecom.es> escribió:
>
> ¿No quedamos en que Asterisk no soporta ni de lejos multihoming? Si tiene
> puesto "bindaddress=0.0.0.0" pero recibe por dos interfaces me temo que sólo
> uno va a funcionar, ¿cuál? lotería.
>
>
>
Funciona sin problemas con ambas interfaces si tienes el bindaddress a 0.0.0.0
--
First they ignore you.
Then they laugh at you.
Then they fight you.
**Then you win.**
DaHjaj jaj QaQ Daghajjaj :)
Jon Bonilla
Elio Rojano <hel...@gmail.com> escribió:
>
> Y cierto, los domains también tienen que estar configurados para cada red.
>
Creo que ni eso.
Con bindaddress y un realm=asterisk (por defecto) ya te escucha en
todas las interfaces de red
¿Guarrete? Sí.
Iñaki Baz Castillo
> El Fri, 30 Jan 2009 13:12:51 +0100
>
> Iñaki Baz Castillo <ib...@xtratelecom.es> escribió:
> > ¿No quedamos en que Asterisk no soporta ni de lejos multihoming? Si tiene
> > puesto "bindaddress=0.0.0.0" pero recibe por dos interfaces me temo que
> > sólo uno va a funcionar, ¿cuál? lotería.
>
> Funciona sin problemas con ambas interfaces si tienes el bindaddress a
> 0.0.0.0
¿Entonces sólo falla cuando hay definidos IP's virtuales?
¿Raúl?
Iñaki Baz Castillo
> El Fri, 30 Jan 2009 13:23:26 +0100
>
> Elio Rojano <hel...@gmail.com> escribió:
> > Y cierto, los domains también tienen que estar configurados para cada
> > red.
>
> Creo que ni eso.
>
> Con bindaddress y un realm=asterisk (por defecto) ya te escucha en
> todas las interfaces de red
>
> ¿Guarrete? Sí.
¿Qué más da el "realm"?
Antonio Arriaga [DTI2]
----- Original Message -----
From: "Jon Bonilla (Manwe)" <ma...@aholab.ehu.es>
To: <aster...@googlegroups.com>
Sent: Friday, January 30, 2009 1:28 PM
Subject: [Asterisk-ES] Re: servidor con dos interfaces de red
El Fri, 30 Jan 2009 13:12:51 +0100
Iñaki Baz Castillo <ib...@xtratelecom.es> escribió:
>
> ¿No quedamos en que Asterisk no soporta ni de lejos multihoming? Si tiene
> puesto "bindaddress=0.0.0.0" pero recibe por dos interfaces me temo que
> sólo
> uno va a funcionar, ¿cuál? lotería.
>
>
>
Funciona sin problemas con ambas interfaces si tienes el bindaddress a
0.0.0.0
Muchas gracias a todos.
==============================================================
Antonio Arriaga
Jon Bonilla
Iñaki Baz Castillo <ib...@xtratelecom.es> escribió:
>
> El Friday 30 January 2009 13:30:50 Jon Bonilla escribió:
> > El Fri, 30 Jan 2009 13:23:26 +0100
> >
> > Elio Rojano <hel...@gmail.com> escribió:
> > > Y cierto, los domains también tienen que estar configurados para cada
> > > red.
> >
> > Creo que ni eso.
> >
> > Con bindaddress y un realm=asterisk (por defecto) ya te escucha en
> > todas las interfaces de red
> >
> > ¿Guarrete? Sí.
>
> ¿Qué más da el "realm"?
>
Lo siento shifu :(
Esta tarde me doy diez latigazos y me leo el RFC 2617 enterito.
He tenido unos problemas con realm y unos terminales cerdos y he mezclados
churras con merinas.
Iñaki Baz Castillo
> Esta tarde me doy diez latigazos y me leo el RFC 2617 enterito.
>
> He tenido unos problemas con realm y unos terminales cerdos y he mezclados
> churras con merinas.
El "realm" no es más que una cadena de texto que el servidor indica al cliente
con la cuál, y con otras como en "nonce", debe generar el "response".
Normalmente no es necesario fijar el realm en los tfnos, de hecho si lo fijas
y es distinto al parámetro que pones en "realm" en sip.conf entonces el tfno
ignorará el "realm" que le indica Asterisk, generará el "response" con su
propio "realm" y la autenticación fallará.
Raúl Alexis Betancor Santana
Creo que ya lo expliqué en su momento ... falla cuando hay más de una ip en la
misma tarjeta de red.
Veamos un par de ejemplos que aclaran las cosas ...
Escenario 1
eth0 192.168.0.1
eth0:1 192.168.1.2
FALLAAAAAAAAA, todo lo mandará con la ip .1
Escenario 2:
eth0 192.168.0.1
eth0.1 192.168.1.2 (ojo que es tagged VLAN, no alias)
Furuncula
Escenario 3:
eth0 192.168.0.1
eth0.1 192.168.0.2
FALLAAAAAAAAA, lo manda todo por la tarjeta eth0, incluso lo que le llegue por
la eth0.1
Escenario 4:
eth0 192.168.0.1
eth1 192.168.0.3
Este no recuerdo ... pero así a bote pronto digo que tampoco rula.
Resumen:
- Asterisk no soporta multihoming, teniendo varias IP como alias de una misma
interfaz física.
- Asterisk no soporta multihoming, teniendo varias IP's de una misma red en
VLAN's diferentes asociadas a misma interfaz física
Habían varios casos más en los que no funciona, son como 9, pero paso de
rebuscarlos, en realidad no funciona porque el código de creación de los
sockets y toda la pesca de Asterisk es un puto truño irreparable (sin echarle
20 horas de trabajo)
Saludos
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Paco Gil
--
http://ualtech.wordpress.com
Germán Aracil Boned
Tengo varias máquinas con varios interfaces e incluso más de una ip en
alguno de ellos, funcionando COMPLETAMENTE BIEN
En el caso de dos ips en un mismo interface (caso real):
eth0 Link encap:Ethernet HWaddr 00:0a:e4:84:76:c5
inet addr:x.x.x.81 Bcast:x.x.x.255 Mask:x.x.x.x
inet6 addr: fe80::20a:e4ff:fe84:76c5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:277603158 errors:0 dropped:0 overruns:0 frame:0
TX packets:277130509 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2887879597 (2.6 GiB) TX bytes:3985553127 (3.7 GiB)
Interrupt:16
eth0:2 Link encap:Ethernet HWaddr 00:0a:e4:84:76:c5
inet addr:x.x.x.80 Bcast:x.x.x.255 Mask:x.x.x.x
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:16
Ésta máquina que esta desde hace más de una año en producción, recibe
consultas desde varias interfaces. Incluida una eth1 que no muestro
aquí, con una ip de rango privado.
El bind, está configurado para todas 0.0.0.0 y lo que es realmente muy
muy importante, es decirle al sistema en el caso de eth0:2 una ruta
estática, por la que debe salir. Si no lo hacemos, no nos funcionará jamás.
La tabla de rutas de ésta máquina es:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0
...
Podéis apreciar como parece tener dos entradas para un mismo interface
(eth0) Pero no es así. Son distintas. Pero netstat no lo muestra
correctamente.
Al asignarle una segunda ip, tenemos que crear una ruta estática para
ese interface de la siguiente forma:
route add default gw x.x.x.254 dev eth0:2
Así pues la forma correcta de la tabla de rutas anterior es realmente:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0:2
...
Si ahora, lanzamos llamadas por la ip del interface eth0:2 hacia
asterisk, si nos funcionara. Es más, por la interface eth1 que tiene
ésta máquina, recibe y envia llamadas que ha recibido por cualquiera de
los interface públicos.
Sl2
Raúl Alexis Betancor Santana escribió:
--
-
-------------------------------------
Germán Aracil Boned
Director de Sistemas
Zoon Suite S.L.
www.zoonsuite.com
963146030 - General
963146031 - Asistencia de incidencias
963146032 - FAX
-------------------------------------
-
Germán Aracil Boned
El servidor del que hablo y como digo funciona a pleno rendimiento,
TIENE 21 INTERFACES de red funcionando con ASTERISK. Claro, hay de todo
tipo, desde físicos, ips añadidas a algun interface físico como vlans.
Germán Aracil Boned escribió:
Raúl Alexis Betancor Santana
> Quiero exponer un caso real.
> Tengo varias máquinas con varios interfaces e incluso más de una ip en
> alguno de ellos, funcionando COMPLETAMENTE BIEN
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> ...
> 0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0
> 0.0.0.0 x.x.x.254 0.0.0.0 UG 0 0 0 eth0
> ...
>
> Podéis apreciar como parece tener dos entradas para un mismo interface
> (eth0) Pero no es así. Son distintas. Pero netstat no lo muestra
> correctamente.
¿te importaría pegar la salida de un "ip ro"? ... es una curiosidad malsana
que tengo por esto.
Germán Aracil Boned
x.x.x.0/24 dev eth0 proto kernel scope link src x.x.x.81
default via x.x.x.254 dev eth0 src x.x.x.80
default via x.x.x.254 dev eth0
...
además de éstas publicas salen un porrón privadas.
La razón de ser de todas ellas, es establecer y recibir llamadas.
Raúl Alexis Betancor Santana escribió:
--
Raúl Alexis Betancor Santana
> ...
> x.x.x.0/24 dev eth0 proto kernel scope link src x.x.x.81
> default via x.x.x.254 dev eth0 src x.x.x.80
> default via x.x.x.254 dev eth0
> ...
>
> además de éstas publicas salen un porrón privadas.
> La razón de ser de todas ellas, es establecer y recibir llamadas.
No hay diferencia en la rutas del kernel, solo hay dos default, uno con src
forzado y el otro sin.
¿Te importa una salida del "ip ru" ?
Aunque el problema real no es de configuración ni de Asterisk, ni de las rutas
del kernel, el problema es el código del chan_sip, concretamente el problema
es que cuando Asterisk recibe el INVITE y crea todas las estructuras
asociadas del chan_sip, crea el socket para el RTP SIN TENER en cuenta que
dirección IP es la más adecuada para el destino al que tiene él que enviar su
RTP, sino utilizando la IP primaria del interfaz por el que le llegó el
request.
Si puedes, haz un par de trazas con el ngrep y tshark y verás este
comportamiento.
UAC Ast:IP2
INV ----------->
<---------- 180/183 w SDP AST:IP1
Esa IP1 en la respuesta al INV del UAC, es siempre la misma, la IP primaria
del interfaz por el que le llegó el INV a Asterisk y se pone SIN consultar al
kernel cual es la IP más adecuada a usar para llegar a la IP del UAC (que no
tiene porqué ser ni la IP1 y la IP2 del Ast, por eso digo que Asterisk no
sirve para multihoming.
En tu caso funciona porque ambas IP's públicas que están como alias de la
misma interfaz pertenecerán al mismo rango y estarán dentro de la misma ruta
agregada, intenta lo mismo con IP's de rangos diferentes como alias de la
misma interfaz y me cuentas el resultado ;-)
Para ser más claros, supongamos que jugamos con el LARTC y hacemos lo que
estimamos más oportuno en cada momento a la hora de enviar el tráfico (no voy
a entrar en detalles, que la cosa se puede poner excesivamente técnica),
Asterisk, que no trabaja en entornos multihoming (y recordemos que la
definición correcta de multihoming es la que implica varios caminos de
entrada/salida hacia un mismo destino, no que una tarjeta tenga varias IP's
de un mismo rango), fallará estrepitosamente, utilizando SIEMPRE la IP
primaria del interfaz por el que le llegó el request para indicarla en las
respuestas SDP.
Que dé la casualidad de que en determinados entronos eso es válido, OK, pero
el hecho cierto, es que asterisk lo hace mal y no utliza el algoritmo
correcto para seleccionar la IP.
El problema se ve muy, muy claramente, cuando un asterisk "multihomeado" se
intenta poner en contacto con otro dispositivo SIP que le indica en su
call-flow SIP, que tráfico SIP va a una IP, pero el RTP a otro distinta.
Saludos
Germán Aracil Boned
Si me das un número de teléfono te llamo desde la ip secundaria sin que
ningún paquete salga por la primaria :)
Amigo, me funciona desde hace mucho tiempo. El caso es que lo uso como
failover. Solo tengo que mover (y he movido ya) la ip de una máquina a
otra para que funcione.
De todas formas, igual luego si tengo tiempo, te muestro más cosas.
Raúl Alexis Betancor Santana escribió:
--
Germán Aracil Boned
SME sabía mal irme sin contestarte con un par de ejemplos:
Termino de realiza una llamada desde x.x.x.249 a la ip x.x.x.80
Y esto es lo que pasa:
|Time | x.x.x.249 | x.x.x.80 |
|16,796 | INVITE SDP ( H264) |SIP From:
sip:9xx5...@x.x.x.249 To:sip:9631...@x.x.x.80
| |(5060) ------------------> (5060) |
|16,799 | 100 Trying| |SIP Status
| |(5060) <------------------ (5060) |
|16,810 | 200 OK SDP ( H264) |SIP Status
| |(5060) <------------------ (5060) |
|16,814 | ACK | |SIP Request
| |(5060) ------------------> (5060) |
|16,822 | RTP (g729) |RTP Num packets:178
Duration:3.557s SSRC:0x1C9B69E1
| |(12724) <------------------ (10394) |
|16,867 | RTP (g729) |RTP Num packets:177
Duration:3.519s SSRC:0x899A144
| |(12724) ------------------> (10394) |
Como ves, los paquetes (además te lo puedo asegurar viendolos) van y
bienen a la x.x.x.80 como toca. Decirte que la x.x.x.80 es la eth0:2
añadida. Por supuesto, la llamada tiene sonido en ambas direcciones. El
origen ha sido un asterisk, y el receptor otro asterisk.
En caso de mandar la llamada a la ip principal del mismo interface (eth0):
|Time | x.x.x.249 | x.x.x.81 |
|5,877 | INVITE SDP ( H264) |
|SIP From: sip:9xx5...@x.x.x.249 To:sip:9631...@x.x.x.81
| |(5060) ------------------> (5060) | |
|5,879 | 100 Trying| |
|SIP Status
| |(5060) <-------------------------------------- (5060) |
|5,892 | 200 OK SDP ( H264) |
|SIP Status
| |(5060) <-------------------------------------- (5060) |
|5,895 | ACK | |
|SIP Request
| |(5060) --------------------------------------> (5060) |
|5,903 | RTP (g729) |
|RTP Num packets:191 Duration:3.818s SSRC:0x7EAE0B7
| |(22744) <-------------------------------------- (22028) |
|5,948 | RTP (g729) |
|RTP Num packets:189 Duration:3.759s SSRC:0x317E52BF
| |(22744) --------------------------------------> (22028) |
|9,728 | BYE | |
|SIP Request
| |(5060) --------------------------------------> (5060) |
|9,728 | 200 OK | |
|SIP Status
| |(5060) <-------------------------------------- (5060) |
Como ves ( y yo viendo los paquetes directamente te puedo garantizar)
los paquetes ésta vez salen y entran en la x.x.x.81
Por supuesto la llamada no ha sido sorda y se ha producido correctamente
en ambos sentidos.
A no ser que wireshark me esté mintiendo claro ;)
Te recomiendo hacer la prueba, teniendo muy presente antes de nada, que
tienes las rutas pertinentes. Sino, no te irá. Debe irte en serio.
un saludo !!
Raúl Alexis Betancor Santana escribió:
--
Iñaki Baz Castillo
> te acuerdas qué pasa con las inteface virtuales (ip virtual) para su uso
> con hearbeat???
¿Qué ocurre?
Paco Gil
> El Saturday 31 January 2009 09:30:26 Paco Gil escribió:
>> te acuerdas qué pasa con las inteface virtuales (ip virtual) para su uso
>> con hearbeat???
>
> ¿Qué ocurre?
--
http://ualtech.wordpress.com
Iñaki Baz Castillo
> 2009/2/2 Iñaki Baz Castillo <ib...@xtratelecom.es>:
> > El Saturday 31 January 2009 09:30:26 Paco Gil escribió:
> >> te acuerdas qué pasa con las inteface virtuales (ip virtual) para su uso
> >> con hearbeat???
> >
> > ¿Qué ocurre?
>
> que si te hace algo raro???
Ah, lo preguntabas...
Pues mira, el truco para salir airoso, y confirma lo expuesto por Raúl, es
usar en bindaddress la IP virtual. Es decir:
Asterisk-1:
- eth0 10.10.10.101
- eth0:1 10.10.10.200
Asterisk-2:
- eth0 10.10.10.102
Heartbeat sólo levanta la eth0:1 en uno de los dos Asterisk. Y configuramos,
en cada Asterisk:
bindadress = 10.10.10.200
Los tfnos deben usar la IP de servicio 10.10.10.200
Es la única forma de que funcione (bueno miento, como bien ha explicado Raúl,
en caso de que estemos dentro de una LANy no intervenga NAT en la VoIP,
entonces *de pura chiripa* "funcionaría" aunque pongamos un "bindaddress"
diferente).
Germán Aracil Boned
Yo creo que en asterisk debes poner 0.0.0.0
Las pruebas que expuse, por cierto son desde diferentes lans.
Iñaki Baz Castillo escribió:
--
Raúl Alexis Betancor Santana
> Pero eso que comentais es referente a asterisk ?
> Yo creo que en asterisk debes poner 0.0.0.0
> Las pruebas que expuse, por cierto son desde diferentes lans.
No he contestado aún a tus trazas del otro día, esta tarde le echaré un par de
horas y vuelvo a montar el escenario de pruebas, os mandaré escenarios,
configuraciones, trazas, capturas y conclusiones, a ver si entre todos
llegamos a la misma conclusión.
Ya digo, que por las pruebas que hicimos en su momento el multihoming en
asterisk no funciona, además hay un par de bugs tamaño burro en el trac de
Digium sobre el tema, reconocidas las limitaciones por la gente de Digium,
osea que no es un tema que nos estemos inventando o andemos locos ... es una
realidad palpable.
Es probable, Germán, que simplemente estemos hablando de situaciones
diferentes ó que en tu escenario se de la solución "chiripa", por eso voy
luego ha enviar toda la información, que es mas fácil que veamos así el
problema.
Germán Aracil Boned
Pero en las pruebas recuerda meter las rutas estáticas pertinentes para
los alias de interface como eth0:1 .. etc.
route add default gw ipdelgateway dev eth0:1
sino, no funciona ni de coña.
Raúl Alexis Betancor Santana escribió:
--
Iñaki Baz Castillo
> El Lunes, 2 de Febrero de 2009 09:41, Germán Aracil Boned escribió:
> > Pero eso que comentais es referente a asterisk ?
> > Yo creo que en asterisk debes poner 0.0.0.0
> > Las pruebas que expuse, por cierto son desde diferentes lans.
>
> No he contestado aún a tus trazas del otro día, esta tarde le echaré un par
> de horas y vuelvo a montar el escenario de pruebas, os mandaré escenarios,
> configuraciones, trazas, capturas y conclusiones, a ver si entre todos
> llegamos a la misma conclusión.
Por mis pruebas recientes:
- Asterisk con IP's públicas:
- eth0 99.99.99.10
- eth0:1 99.99.99.11
- Los tfnos tras NAT configurados contra la Ip de servicio 99.99.99.11.
Si ponemos "bindaddress = 0.0.0.0" entonces la liamos parda ya que Asterisk
recibirá un request a la IP 99.99.99.11 pero contestará por la IP
99.99.99.10. Esta respuesta no pasará el NAT abierto.
La única solución usando una IP virtual es hacer que los tfnos usen *sólo*
dicha IP virtual para contactar al Asterisk, y hacer que el Asterisk sólo use
dicha Ip virtual (bindaddress = 99.99.99.11).
¿Estamos de acuerdo? (bueno, ya digo que esto lo confirmo y lo
re-que-te-confirmo).
Saludos.
Germán Aracil Boned
has creado para ese segundo interface un gateway por defecto ?
Has puesto esto ?
route add default gw ipgateway dev eth0:1 (o el que sea)
dime ..
Iñaki Baz Castillo escribió:
--
Germán Aracil Boned
Te puedo pasar en privado un login y acceso para que pruebes
(registrandote incluso con un telefono) como actualmente, hay unas
cuantas personas usandolo como dices que no funciona.
Iñaki Baz Castillo escribió:
--
Ramses II
Al hilo, una duda:
Si no ponemos "bindaddr" ni "bindport", ¿sabemos qué hace por defecto
Asterisk?
Saludos,
Ramses
>-----Mensaje original-----
>De: aster...@googlegroups.com
>[mailto:aster...@googlegroups.com] En nombre de Germán Aracil Boned
>Enviado el: lunes, 02 de febrero de 2009 11:11
>Para: aster...@googlegroups.com
>Asunto: [Asterisk-ES] Re: servidor con dos interfaces de red
Iñaki Baz Castillo
> Germán, buenos días,
>
> Al hilo, una duda:
>
> Si no ponemos "bindaddr" ni "bindport", ¿sabemos qué hace por defecto
> Asterisk?
Escoje la IP primaria del interfaz y lo saca todo con esa IP origen,
independientemente de que haya recibido el request a otra IP virtual del
mismo interfaz físico.
> >[mailto:aster...@googlegroups.com] En nombre de Germán Aracil Boned
> >Iñaki .. he releido lo que comentas.
> >
> >Te puedo pasar en privado un login y acceso para que pruebes
> >(registrandote incluso con un telefono) como actualmente, hay unas
> >cuantas personas usandolo como dices que no funciona.
Sí, haciendo una jugarreta a nivel Iptables o IP routing, jugarreta que no
debería ser necesaria si la aplicación implementase correctamente multihoming
y recordase el socket por el que ha sido contactada y lo usase para
responder. Como ya he comentado, con otras aplicaciones SIP más serias el
multihoming funciona perfectamente sin necesidad de "adaptar" Iptables y las
IP rules a las limitaciones de Asterisk.
¿Tanto nos cuesta reconocer que Asterisk lo hace fatal en este punto? :)
Germán Aracil Boned
Ramses II escribió:
Ramses II
sin el "bindaddr" ni el "bindport", los teléfonos atacando al la "ip
virtual" y todo "chuta"...
>[mailto:aster...@googlegroups.com] En nombre de Iñaki Baz Castillo
>Enviado el: lunes, 02 de febrero de 2009 11:45
Iñaki Baz Castillo
> Creo que gana la respuesta de Germán, ya que tengo un "heartbeat" montado
> sin el "bindaddr" ni el "bindport", los teléfonos atacando al la "ip
> virtual" y todo "chuta"...
A ver... que en este tema hay que considerar *muchaos* aspectos como ya ha
planteado, entre otros, Raúl:
- ¿Están los dos Asterisk con IP privada (o en la misma red que los
teléfonos)? Si es así te funciona de casualidad:
tfno (IP_tfno) ------request-----> (IP_1) Asterisk
tfno (IP_tfno) <-----response----- (IP_2) Asterisk
(si hubiese un router NAT en medio eso no funcionaría).
- Caso en el que lo anterior puede funcionar tras NAT (si se da la bendita
coincidencia de que el router tiene NAT tipo "cono" (o como se llame), es
decir, que permite tráfico desde una IP no contactada desde dentro a través
de un NAT mapping que abrió un equipo interno a *otra* Ip externa. Muy raro
ver esto.
¿Has hecho un "tcpdump" para ver por qué IP te está contestando Asterisk y
comprobar si es la misma por la que recibe el request? El hecho de que
funcione en un determinado escenario no significa que Asterisk lo haga bien
(que ya se ha demostrado que no lo hace, creo yo).
¡Raúl ayuda!
Germán Aracil Boned
A ver si pones un alias al interface eth0 del tipo eth0:1 con otra ip de
otra lan, y pones la ruta estática como he comentado ya varias veces..
tachan.... tambien funcionara todo. Esto no lo he probado, pero me temo
que así sea.
En cambio si lo haces sin ponerle una puerta de enlace específica para
ese interface, ni va a ir apache ni nada de nada.
Conclusión, es mejor indicar una puerta de enlace para cada alias
añadido a una interface de red.
Iñaki Baz Castillo escribió:
--
Ramses II
gusta que las cosas funcionen por casualidad... ;-)
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
nombre de Iñaki Baz Castillo
Iñaki Baz Castillo
> No lo había hecho, pero lo haré mañana, ya me pica la curiosidad, no me
> gusta que las cosas funcionen por casualidad... ;-)
Ok, pero sólo una cosa para ir adelantando: ¿tienes los Asterisk en la misma
red que los teléfonos o hay NAT por medio?
Germán Aracil Boned
en la otra punta del mundo. que conste !
Iñaki Baz Castillo escribió:
> El Monday 02 February 2009 14:40:59 Ramses II escribió:
>> No lo había hecho, pero lo haré mañana, ya me pica la curiosidad, no me
>> gusta que las cosas funcionen por casualidad... ;-)
>
> Ok, pero sólo una cosa para ir adelantando: ¿tienes los Asterisk en la misma
> red que los teléfonos o hay NAT por medio?
>
--
Ramses II
Red IP, tanto los interfaces físicos como los lógicos.
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
nombre de Iñaki Baz Castillo
Iñaki Baz Castillo
> Ambas centrales que pertenecen al mismo cluster heartbeat están en la misma
> Red IP, tanto los interfaces físicos como los lógicos.
Pero ¿los tfnos IP también? ¿a acceden a los Asterisk atravesando un NAT?
Ramses II
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
nombre de Iñaki Baz Castillo
Iñaki Baz Castillo
> "Toito tó" en la misma Red IP.
Pues ahí está el milagro. Te funciona porque todo está en la misma IP. Los
teléfonos conectan al Asterisk a la IP1 y Asterisk les responde por la IP2, y
no pasa nada porque la respuesta llega y el teléfono se la come (ahora, no te
extrañes si algún modelo de tfno no te funciona en ese escenario).
Pero ahora pon Asterisk con Ip's públicas y los tfnos tras NAT, ya verás qué
batacazo se pega la respuesta de Asterisk cuando intenta atravesar el NAT ;)
Ramses II
Ya cuento los resultados...
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
nombre de Iñaki Baz Castillo
Germán Aracil Boned
Tengo ese planteamiento con NAT y teléfonos registrandose en ips
totalmente distintas. FUNCIONA !
Iñaki Baz Castillo escribió:
--
Germán Aracil Boned
route add default gw gateway dev device (eth0:1, o el que sea)
luego haz las pruebas.
Ramses II escribió:
--
sol...@gmail.com
Es que me he decidido a probar la V2 y ya tengo los nodos a punto, con
drbd funcionando, a falta de meter el xml con la configuración de la
V2... Pero de momento estoy leyendo tutoriales, que la V2 no tiene
nada que ver con la V1. Parece mucho más potente, aunque también más
oscurantista.
Ramses II
Lo tengo con la V2.
El XML lo generé con la utilidad que trae para crear el XML a partir del
fichero de V1.
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
Enviado el: lunes, 02 de febrero de 2009 20:24
Para: asterisk-es
Elio Rojano
Tengo un Asterisk con dos tarjetas, una de ellas con ip externa con varios puertos en remoto y otra interna conectada al switch con varias extensiones, y lleva funcionando desde hace años...
http://www.sinologic.net/
Raúl Alexis Betancor Santana
> Buenas,
>
> Tengo un Asterisk con dos tarjetas, una de ellas con ip externa con varios
> puertos en remoto y otra interna conectada al switch con varias extensiones,
> y lleva funcionando desde hace años...
Eso no es multihoming. Eso es un escenario normal, donde la maquina con Asterisk
puede (o no), actuar como gateway entre ambas redes.
Vamos que es la tipica configuracion donde la maquina asterisk se usa de
router/firewall de la red, por ejemplo.
Vuelvo y repito (conste que hoy he estado superliado y no he tenido tiempo de
montar el escenario de pruebas, pero en cuanto tenga un par de horas libres
espero poder aclaraos todo el cacao-mental que se ha montado con este asunto.
Multihoming: VARIAS RUTAS HACIA UN MISMO DESTINO
La clave esta en lo de "mismo destino" y "varias rutas".
Un alias en una tarjeta, con dos gateways (el mismo gateway dos veces en
realidad), no es multihoming, puesto que NO HAY VARIAS RUTAS HACIA UN MISMO
DESTINO, solo hay una ruta, el gateway definido, aunque hayan 2 IP en el
Asterisk.
Saludos
--
Raul Alexis Betancor Santana
Dimension Virtual S.L.
Germán Aracil Boned
funcionar con una interface de red con más de una ip. I eso no es verdura.
Raúl Alexis Betancor Santana escribió:
Iñaki Baz Castillo
> Buenas,
>
> Tengo un Asterisk con dos tarjetas, una de ellas con ip externa con varios
> puertos en remoto y otra interna conectada al switch con varias
> extensiones, y lleva funcionando desde hace años...
Vale, Asterisk es perfecto XD
Jolín, ¿qué pasa? ¿tanto cuesta aceptar que Asterisk tiene *fallos*? Después
de un hilo en el que se han dado detalladas explicaciones sobre los casos en
los que funciona, los que no, y los que funcionan "de casualidad" bajo
determinadas conjunciones astrales... y todavía salís con el argumento pobre
de "a mí me funciona", sin hacer las comprobaciones con TcpDump, sin tener
claro si es un escenario de multihoming o no, sin nada.
Venga Elio, que tú lo puedes (debes) hacer mejor ;)
Raúl Alexis Betancor Santana
> Bueno yo me he lanzado, porque aquí se decía que asterisk no podía
> funcionar con una interface de red con más de una ip. I eso no es verdura.
Perdona German, pero NO FUNCINA, hay que andar con "trucos" para que funcione.
La prueba es muy simple:
- Coge un equipo con 2 ip en la misma intefaz.
- Instala Asterisk, Apache, Mysql y PostgreSQL
- Configura todos ellos para bindearse a 0.0.0.0 (por lo menos en postgresql de
serie de Debian, tendás que cambiar el listen, porque viene a "localhost" de
serie)
- Ahora y SIN añadir un "ip ro add default gw ..." duplicado para la segunda
IP (cosa que no es necesaria, a nivel TCP/IP no tiene sentido), conectate a
todos y cada uno de los servicios instalados y úsalos.
¿Cuales funcionan y cuales nó?
Respuesta: Funcionan todos MENOS Asterisk
¿Porqué?
Porque Asterisk hace "lo que cree correcto" a la hora de trabajar con los
sockets, que de correcto tiene lo que yo de Hawaiano
Saludos
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Germán Aracil Boned
funciona
Raúl Alexis Betancor Santana escribió:
--
Iñaki Baz Castillo
> El Tuesday 03 February 2009 00:06:45 Germán Aracil Boned escribió:
> > Bueno yo me he lanzado, porque aquí se decía que asterisk no podía
> > funcionar con una interface de red con más de una ip. I eso no es
> > verdura.
Germán, es Asterisk el que se debe adaptar a TCP/IP y no al revés.
Elio Rojano
Julian J. M.
eth0? Es decir, en una petición a la IP principal (no el alias),
asterisk respondería siempre desde la IP del alias, no a la que llegó
inicialmente el paquete.
Julian J. M.
2009/2/3 Germán Aracil Boned <ger...@tecnoxarxa.com>:
http://www.julianmenendez.es
Raúl Alexis Betancor Santana
> Pues nada, a rellenar un bug a ver si progresa... :D
Hay varios bugs sobre multihoming en el trac de digium, y varios parches,
algunos han progreseado más que otros, pero todos acaban dandose contra la
misma piedra, para Digium el tema no es prioritario y no dedica recursos a
resolverlo.
El problema REAL de base, es que se deberían de separar las capas de
señalización de la de transporte y de la de red, pero sin embargo estan
entremezcladas.
Ejemplo:
Asterisk lanza un INVITE, y como es lógico ha de poner una IP en el request
inicial.
Pues lo que hace asterisk es pedir un socket bindeado a 0.0.0.0 (a execpción
de que se haya definido bindaddr), indiciando el destino para la señalización y
para el RTP también.
Cuando llega la respuesta al INVITE, Asterisk no comprueba que para alcanzar
la IP de RTP le sea válido o nó el socket que ya pidió ... y lo manda por ahí.
De aquí surge el problema REAL de que no funcione en entornos multihoming.
"La suposición es la madre de los metepatas" ... y desde luego es la abuela de
Digium ... porque ale que no hay código ni nada en Asterisk que "supone" que
las cosas funcionan "ala Asterisk"
Alé ... "porque ellos lo valen ..."
Germán Aracil Boned
añadida
Julian J. M. escribió:
Julian J. M.
(192.168.0.0/24, por ejejmplo), cómo se selecciones la IP correcta?
Asterisk, como ha explicado Raúl, obtiene la dirección IP de origen
del kernel (crea un socket para conectar con una IP, y usa el campo
src que le da el sistema de enrutamiento del kernel).
Si ambas IP's están en la misma subred, y asterisk no selecciona
activamente la IP con la que quiere salir, qué IP es la que se usa
como src en los paquetes?
Si haces un ping a una IP de esa subred, desde qué IP llegan esos paquetes?
Julián J. M.
http://www.julianmenendez.es
Germán Aracil Boned
hace.
Ahora si no queremos verlo .. es otra cosa. ..
Julian J. M. escribió:
Raúl Alexis Betancor Santana
> Ya, pero si tanto la IP real como el alias están en la misma red
> (192.168.0.0/24, por ejejmplo), cómo se selecciones la IP correcta?
> Asterisk, como ha explicado Raúl, obtiene la dirección IP de origen
> del kernel (crea un socket para conectar con una IP, y usa el campo
> src que le da el sistema de enrutamiento del kernel).
>
> Si ambas IP's están en la misma subred, y asterisk no selecciona
> activamente la IP con la que quiere salir, qué IP es la que se usa
> como src en los paquetes?
La IP primaria del interfaz por el que "deba" de salir la respuesta. ¡Ojito!,
que nisiquiera tiene porqué volver por donde entró, que de hecho es lo que
ocurre en los escenarios de multihoming reales, creando un cacao de cuidado.
A ver .. aclaremos también que nos referimos a escenarios de multihoming SIN
BGP.
Hay un parche el track de Digium, que "debería" de hacer que al setear cierto
parámetro en sip.conf (a nivel general, no de peer), Asterisk se comporte de
forma que SIEMPRE envíe el tráfico RTP por la misma IP que usó para
enviar/recibir la señalización.
Este parche es muy útil para escenarios de clientes en los que se tienen
varios enlaces de salida a internet sin BGP (ADSL's por ejemplo), pero está
incompleto, al autor se le vino el mundo encima cuando al arreglar el
comportamiento en un módulo, le saltaban 50 fallos en otro ... cosas de
la "megaintegración" de Asterisk.
> Si haces un ping a una IP de esa subred, desde qué IP llegan esos paquetes?
Dependerá de los routes y los rules que estén cargados.
Julian J. M.
>> Si ambas IP's están en la misma subred, y asterisk no selecciona
>> activamente la IP con la que quiere salir, qué IP es la que se usa
>> como src en los paquetes?
>
> La IP primaria del interfaz por el que "deba" de salir la respuesta. ¡Ojito!,
> que nisiquiera tiene porqué volver por donde entró, que de hecho es lo que
> ocurre en los escenarios de multihoming reales, creando un cacao de cuidado.
>> Si haces un ping a una IP de esa subred, desde qué IP llegan esos paquetes?
>
> Dependerá de los routes y los rules que estén cargados.
>
Claro, pero es a lo que iba con mi comentario, que si asterisk (o
cualquier otra aplicación) no especifica la IP de origen del paquete,
es el kernel quien decide, en función de las reglas de enrutamiento
que tengas puestas, por defecto la IP principal del interfaz.
Julian J. M.
Raúl Alexis Betancor Santana
Asterisk solo especifica la IP de origen en caso (quien tenga ganas/tiempo que
lea el código de rtp.c y chan_sip.c), de qye se haya especificado un
bindaddr en sip.conf en cualquier otro caso, siempre pide un socket poniendo
como src_addr 0.0.0.0, lo que deja en manos del kernel la decisión de que IP
usar.
Y el kernel no lo hace mal, el que lo hace mal es Asterisk, que debería de
especificar la IP origen en más de un caso y no lo hace.
Germán Aracil Boned
Julian J. M. escribió:
--
sol...@gmail.com
casualidad como decía Iñaki.
Tampoco es tan difícil meter la ruta a mano... pero no es lo deseable.
Callweaver también hace guarradas de esas, o han optimizado el codigo
algo más?
Y el chan_sip es tan malo como el de asterisk?
On 3 feb, 13:22, Germán Aracil Boned <ger...@tecnoxarxa.com> wrote:
> Aleluya !!
>
> Julian J. M. escribió:
>
>
>
Iñaki Baz Castillo
> O sea que el multihoming en asterisk funciona guarramente, pero no por
> casualidad como decía Iñaki.
Funciona de casualidad cuando tienes los Asterisk en la misma red que los
teléfonos. Entonces, aunque el tfno contacte al Asterisk por la IP_asterisk_1
y Asterisk responda (incorrectamente) desde la IP_asterisk_2, aún así, la
respuesta llega al teléfono.
Pero si metes un NAT en medio ya no funciona.
Por eso digo que "funciona de casualidad" (sólo bajo la premisa de estar en la
misma red).
> Tampoco es tan difícil meter la ruta a mano... pero no es lo deseable.
Pues no.
> Callweaver también hace guarradas de esas, o han optimizado el codigo
> algo más?
> Y el chan_sip es tan malo como el de asterisk?
CallWeave usa el mismo chan_sip que Asterisk, incluos es posible que esté
mucho más desactualizado. Se decía que iban a incorporan otro SIP stack pero
nada de nada.
Julian J. M.
También es cierto que depende de qué nats haya por medio.
1) Asterisk y teléfonos en la red local.
Salga de la IP que salga, salvo que los teléfonos filtren de alguna
manera y solo acepten los paquetes que vienen del proxy, no hay
problema
2) Asterisk detrás de un NAT y cliente en IP pública
La petición llega de la IP pública del cliente hacia la IP del router.
Aquí se hace un DNAT a la IP del asterisk. Asterisk responde con la IP
que sea (que puede no ser la misma). El paquete llega al router y éste
hace un SNAT, ajustando la IP de origen. Este paquete llega sin
problemas al cliente con IP pública. En principio funcionaría, aunque
habría que ver el /proc/net/ip_conntrack para ver si algún flujo se
puede morir por timeout (al no estar respondida la conexión, desde el
punto de vista del conntrack).
3) Asterisk detrás de un NAT y cliente detŕas de NAT.
Parecido al caso anterior. Como el router que da servicio a asterisk
está tratando independientemente el flujo de entrada y el de salida,
no está garantizado que la salida use el mismo puerto de origen. Suele
ser así en el caso de linux/netfilter, que intenta modificar lo menos
posible el paquete, pero no está garantizado.
Al salir el paquete hacia el router NAT del cliente, aunque la IP de
origen coincida con la que usó el cliente, el puerto de origen
(normalmente 5060) puede que haya cambiado. Si se da el caso, y
también dependiendo del tipo de NAT que use el router del cliente, el
paquete puede llegar al cliente o no. Seguramente funcione, pero yo no
me la jugaría ;)
4) Asterisk en IP pública (con dos IP's, claro, una en cada proveedor)
(por completar la lista, aunque este punto puede tener un hilo aparte
perfectamente ;))
Aquí lo jodido es que se responda al cliente por el mismo proveedor...
Por lo que he leido, se suelen usar marcas (nfmark) para etiquetar la
conexión (conntrack), crear dos tablas de enrutamiento (ip route) y
definir las reglas de salida (ip rule) para, en función de la marca,
devolver los paquetes por un interfaz o por otro.
El principal problema es determinar qué paquetes forman parte de una
conexión... Al llegar a una IP, pero responder por otra (asterisk no
tiene por qué usar la misma), el flujo de entrada y de salida serían
independientes y no parte de la misma conexión, con lo que la marca
que le hacemos a la entrada inicial, no aparece cuando vamos a enviar
el paquete, y no sabremos por qué interfaz enrutarlo.
En fin, alguien está de acuerdo con esto, o no? ;)
http://www.julianmenendez.es
Iñaki Baz Castillo
> Después de pensar un poco más a fondo este tema:
>
> También es cierto que depende de qué nats haya por medio.
>
> 1) Asterisk y teléfonos en la red local.
> Salga de la IP que salga, salvo que los teléfonos filtren de alguna
> manera y solo acepten los paquetes que vienen del proxy, no hay
> problema
Si un tfno no acepta la respuesta de Asterisk por venir de una IP diferente a
la que envió el request, a mí no me parecería nada raro, ni mucho menos un
fallo del teléfono.
Sí :)
¿Podemos entonces consensuar todos que Asterisk no soporta multihoming ni
gestiona bien interfaces con varias IP's y que funciona en algunos escenarios
(descritos ahora por Julián) "de pura casualidad"?
Saludos.
sol...@gmail.com
difícil cambiar el código en asterisk para que responda a las
peticiones por la misma ip por las que le vienen. Esto es por culpa
del temido chan_sip o está escondido en el profundo código de
asterisk? Con IAX pasa lo mismo?
Germán Aracil Boned
nat. No entiendo porque decís que no funciona tan tajantemente, cuando
existe una forma de hacerlo funcionar y no por casualidad. Ya son 2 años
usando el método y nunca me ha dado problemas.
Iñaki Baz Castillo escribió:
--
Germán Aracil Boned
route add default gw ipgategay dev interface añadida (eth0:1)
FUNCIONA EN TODOS LOS CASOS
COMPROBADO !
Julian J. M. escribió:
Iñaki Baz Castillo
> Yo creo para los desarrolladores de asterisk no debería ser tan
> difícil cambiar el código en asterisk para que responda a las
> peticiones por la misma ip por las que le vienen. Esto es por culpa
> del temido chan_sip o está escondido en el profundo código de
> asterisk?
Hasta donde sé, es cosa del chan_sip (a ver quién le mete mano).
> Con IAX pasa lo mismo?
A mí no me apetece probarlo, pero es tan sencillo como:
- Configurar una IP alias eth0:1.
- Asterisk tiene 2 IP's (IP_A e IP_B).
- Poner "bindaddress=0.0.0.0" en iax.conf.
- Conectar un tfno IAX a la IP_A y comprobar con TcpDump o con Ngrep si
Asterisk responde desde la misma IP_A.
- Idem conectando el tfno a la IP_B.
Apuesto a que en ambos casos responde por la misma IP por lo que el fallo
también existiría.
sol...@gmail.com
On 3 feb, 15:58, Iñaki Baz Castillo <i...@xtratelecom.es> wrote:
sol...@gmail.com
bindaddress=la.ip.vir.tual en el sip.conf y en el iax.conf. La cuenta
sip del zoiper se registra sin problemas, pero la iax2 no se
registra!!
Iñaki Baz Castillo
> Con IAX no se registra!!
Más info please.
¿Has comprobado con tcpdump o ngrep si Asterisk responde por una IP distinta a
la que le llega el request IAX?
Si es así, es muy posible que el tfno rechace la respuesta por venir de una IP
distinta a la que envió el request. Me parece bastante lógico.
Pero por favor, que nos corroe la curiosidad: comprueba si Asterisk responde
por una IP diferente a la contactada :)
sol...@gmail.com
On 3 feb, 18:21, Iñaki Baz Castillo <i...@xtratelecom.es> wrote:
>
> > Con IAX no se registra!!
>
> Más info please.
> ¿Has comprobado con tcpdump o ngrep si Asterisk responde por una IP distinta a
> la que le llega el request IAX?
>
> Si es así, es muy posible que el tfno rechace la respuesta por venir de una IP
> distinta a la que envió el request. Me parece bastante lógico.
>
> Pero por favor, que nos corroe la curiosidad: comprueba si Asterisk responde
> por una IP diferente a la contactada :)
>
> --
> Iñaki Baz Castillo
sol...@gmail.com
Responde por la interfaz real, la 192.168.1.220
[root@elastix ~]# ngrep |grep 4569
U 192.168.1.50:4569 -> 192.168.1.55:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.50:4569 -> 192.168.1.55:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.50:4569 -> 192.168.1.55:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 212.121.230.22:4569
U 212.121.230.22:4569 -> 192.168.1.220:4569
U 192.168.1.220:4569 -> 212.121.230.22:4569
U 212.121.230.22:4569 -> 192.168.1.220:4569
U 192.168.1.220:4569 -> 212.121.230.22:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
U 192.168.1.220:4569 -> 192.168.1.50:4569
Ramses II
Saludos,
Ramses
-----Mensaje original-----
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En
nombre de sol...@gmail.com
Enviado el: martes, 03 de febrero de 2009 18:36
Para: asterisk-es
Asunto: [Asterisk-ES] Re: servidor con dos interfaces de red
Iñaki Baz Castillo
> Si, se me ha ido la olla.
> Responde por la interfaz real, la 192.168.1.220
Y el tfno pasa de la respuesta. Es perfectamente normal (los tfnos SIP parecen
tragarse dicha respuesta aunque vengan de otra IP, pero los IAX parece que
no). En cualquier caso seguro que hay tfnos SIP que no permiten esas
respuestas.
Pues eso, que Asterisk no permite "multihoming" ni varias IP's en un mismo
interfaz.
Saludos.
sol...@gmail.com
no.
A lo mejor haciendo alguna guarrada funciona?¿ Ahi queda eso..
On 3 feb, 18:42, Iñaki Baz Castillo <i...@xtratelecom.es> wrote:
>
> > Si, se me ha ido la olla.
> > Responde por la interfaz real, la 192.168.1.220
>
> Y el tfno pasa de la respuesta. Es perfectamente normal (los tfnos SIP parecen
> tragarse dicha respuesta aunque vengan de otra IP, pero los IAX parece que
> no). En cualquier caso seguro que hay tfnos SIP que no permiten esas
> respuestas.
>
> Pues eso, que Asterisk no permite "multihoming" ni varias IP's en un mismo
> interfaz.
>
> Saludos.
>
> --
> Iñaki Baz Castillo
Iñaki Baz Castillo
> Ramses, ya habia hecho el reload. Y parece que para IAX no funciona,
> no.
Lee mis correos recientes, no es que "para SIP funcione y para IAX no", es el
*mismo* comportamiento (en Asterisk).
Otra cosa es que los tfnos SIP "traguen" y los IAX no.
En cualquier caso si hay NAT por medio (tfnos tras NAT y Asterisk con IP's
públicas) no funcionará nada. Es Asterisk el que lo hace mal.
> A lo mejor haciendo alguna guarrada funciona?¿ Ahi queda eso..
Sí, la solución de Germán, a base de tablas de rutado, marcado de paquetes y
adición de gateways duplicados... vamos, una "delicia" (pero esto no
significa que "Asterisk lo permita", sino que el sufrido usuario monta un
cristo tremendo en la capa TCP/IP para "paliar" las carencias de Asterisk).
Como se ha dicho hasta la saciedad, cualquier otro servicio (Apache, MySQL,
OpenSer...) permiten multihoming "out of the box", así como varias IP's en un
mismo interfaz. Asterisk no.
Saludos.
--
Iñaki Baz Castillo
<ib...@xtratelecom.es>
sol...@gmail.com
los teléfonos.
Porque para ambas pruebas he usado la ultima versión de Zoiper...
On 3 feb, 18:50, Iñaki Baz Castillo <i...@xtratelecom.es> wrote:
Germán Aracil Boned
interface te funciona el iax ?
sol...@gmail.com escribió:
sol...@gmail.com
Parece que con IAX no traga igual que con SIP.
On 3 feb, 19:18, Germán Aracil Boned <ger...@tecnoxarxa.com> wrote:
> Yo a mi tema.. Y si le pones las entradas estáticas al alias del
> interface te funciona el iax ?
>
sol...@gmail.com
default gateway para eth0.
route add default gw 192.168.1.200 dev eth0:1
Pues así no registra la iax.
Germán Aracil Boned
sol...@gmail.com escribió:
> Asi seria correcto? El router tiene la ip 192.168.1.200, que es la
> default gateway para eth0.
>
> route add default gw 192.168.1.200 dev eth0:1
>
> Pues así no registra la iax.
>
Sí. Pero bueno .. iax no suele funcionar (carcajada) así que no sorprende ;)
Raúl Alexis Betancor Santana
> Yo no lo estoy.
>
> route add default gw ipgategay dev interface añadida (eth0:1)
>
> FUNCIONA EN TODOS LOS CASOS
>
> COMPROBADO !
Funciona bajo las siguientes premisas:
- NO ES MULTIHOMING, no hay varios posibles "path" hasta el UAC
- Las IP's "aliaseadas" pertenecen a la misma ruta agregada y tienen el mismo
GW
No es por nada German, pero llevo muuuuuuchoooooooos años trabajando con
equipos Linux con LARTC y tener dos veces la misma entrada de GW no es lo que
está "resolviendo" tu problema, en todo caso lo enmascara.
Además .. probemos que sale cuando se intenta lo que comentas:
- Situación de partida:
salma:~# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
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: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:e4:49:23:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.130/24 brd 192.168.2.255 scope global eth1
inet6 fe80::20a:e4ff:fe49:230e/64 scope link
valid_lft forever preferred_lft forever
salma:~# ip ro
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.130
169.254.0.0/16 dev eth1 scope link metric 1000
default via 192.168.2.1 dev eth1
salma:~# ip ru
0: from all lookup 255
32766: from all lookup main
32767: from all lookup default
salma:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
salma:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
salma:~# iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Vamos .. un equipo "pelao"
------------- Añadimos la segunda IP al eth1:1
salma:~# ip addr add 192.168.2.140/24 broadcast 192.168.2.255 scope global
label eth1:1 dev eth1
salma:~# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
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: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:e4:49:23:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.130/24 brd 192.168.2.255 scope global eth1
inet 192.168.2.140/24 brd 192.168.2.255 scope global secondary eth1:1
inet6 fe80::20a:e4ff:fe49:230e/64 scope link
valid_lft forever preferred_lft forever
Ahora la ruta que German recomienda ...
salma:~# ip ro add default via 192.168.2.1 dev eth1:1
RTNETLINK answers: File exists
Upps!! .. ¿que ha pasado? ... ahhhhh! ... es que ya HAY UNA RUTA POR DEFECTO,
bueno .. no importa corrijamos "el despiste"
salma:~# ip ro add default via 192.168.2.1 src 192.168.2.140 dev eth1:1
RTNETLINK answers: File exists
Upps!! ... ¿que ocurre aquí? ... ¿porqué no me deja? .. umm ... ah!, es que
iproute que es muy listo, sabe que eso causará conflictos y no permite dos
rutas default en la tabla main de routing, ¿entonces? ... ¿como lo
hacemos? ... pues con el anticuado y deprecated comando "route" de toda la
live ...
salma:~# route add default gw 192.168.2.1 dev eth1:1
Se lo traga ...!! ¿que habrá hecho? ..
salma:~# ip ro
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.130
default via 192.168.2.1 dev eth1 src 192.168.2.140
default via 192.168.2.1 dev eth1
¡Cojones! ¿no habíamos dicho que no se pueden tener dos default route en la
tabla main? ... y no se puede, puesto que causa conflictos (lo veremos en
breve), lo que ha sucedido es que el comando "route", que es de cuando Franco
era corneta, no tiene ni puta idea de que exista otra tabla que no sea la
main y el código del kernel traga. ¡Dios santo, hemos encontrado un bug en el
kernel de linux! ¡semos más listos que los más de 10.000 ojos que han
revisado el código del kernel a muerte! ... pues no, es un comportamiento
documentado de la pila de iproute y nfnetlink, solo hay que darse una
vueltecita por la documentación de LARTC.
Pero al tajo carajo ... ¿que pasa con los paquetes que entran y salen de esta
máquina ahora? ... comprobemoslo:
salma:~# ping 80.59.XX.YYY
PING 80.59.XX.YYY (80.59.XX.YYY) 56(84) bytes of data.
64 bytes from 80.59.XX.YYY: icmp_seq=1 ttl=56 time=114 ms
64 bytes from 80.59.XX.YYY: icmp_seq=2 ttl=56 time=114 ms
64 bytes from 80.59.XX.YYY: icmp_seq=3 ttl=56 time=120 ms
64 bytes from 80.59.XX.YYY: icmp_seq=4 ttl=56 time=110 ms
64 bytes from 80.59.XX.YYY: icmp_seq=5 ttl=56 time=114 ms
¿Que IP estará usando? ... veamos ...
salma:~# tshark -i eth1 -n | grep ICMP
Capturing on eth1
4.813557 192.168.2.140 -> 80.59.XX.YYY ICMP Echo (ping) request
4.936901 80.59.XX.YYY -> 192.168.2.140 ICMP Echo (ping) reply
5.819587 192.168.2.140 -> 80.59.XX.YYY ICMP Echo (ping) request
5.946237 80.59.XX.YYY -> 192.168.2.140 ICMP Echo (ping) reply
6.823572 192.168.2.140 -> 80.59.XX.YYY ICMP Echo (ping) request
6.937672 80.59.XX.YYY -> 192.168.2.140 ICMP Echo (ping) reply
7.827591 192.168.2.140 -> 80.59.XX.YYY ICMP Echo (ping) request
7.940173 80.59.XX.YYY -> 192.168.2.140 ICMP Echo (ping) reply
¡Jarl, por TuX!, usa la secundaria ... ¿que demonios pasa aquí? ... bueno es
largo de explicar pero tiene que ver con la precedencia de las reglas de
routing y la tabla main, pero el que quiera profundizar que se lea la docu de
LARTC.
¿Significa esto que la máquina no responde a la 192.168.2.130 que tiene como
primaria?, comprobemoslo ...
root@lathome01:~# ping 192.168.2.130
PING 192.168.2.130 (192.168.2.130): 56 data bytes
64 bytes from 192.168.2.130: seq=0 ttl=64 time=1.000 ms
64 bytes from 192.168.2.130: seq=1 ttl=64 time=0.911 ms
64 bytes from 192.168.2.130: seq=2 ttl=64 time=0.915 ms
root@lathome01:~# ping 192.168.2.140
PING 192.168.2.140 (192.168.2.140): 56 data bytes
64 bytes from 192.168.2.140: seq=0 ttl=64 time=1.115 ms
64 bytes from 192.168.2.140: seq=1 ttl=64 time=0.919 ms
64 bytes from 192.168.2.140: seq=2 ttl=64 time=0.923 ms
64 bytes from 192.168.2.140: seq=3 ttl=64 time=0.919 ms
24.736613 192.168.2.1 -> 192.168.2.130 ICMP Echo (ping) request
24.736696 192.168.2.130 -> 192.168.2.1 ICMP Echo (ping) reply
25.735087 192.168.2.1 -> 192.168.2.130 ICMP Echo (ping) request
25.735165 192.168.2.130 -> 192.168.2.1 ICMP Echo (ping) reply
26.735072 192.168.2.1 -> 192.168.2.130 ICMP Echo (ping) request
26.735150 192.168.2.130 -> 192.168.2.1 ICMP Echo (ping) reply
56.483627 192.168.2.1 -> 192.168.2.140 ICMP Echo (ping) request
56.483711 192.168.2.140 -> 192.168.2.1 ICMP Echo (ping) reply
57.474672 192.168.2.1 -> 192.168.2.140 ICMP Echo (ping) request
57.474747 192.168.2.140 -> 192.168.2.1 ICMP Echo (ping) reply
58.474665 192.168.2.1 -> 192.168.2.140 ICMP Echo (ping) request
58.474741 192.168.2.140 -> 192.168.2.1 ICMP Echo (ping) reply
59.474651 192.168.2.1 -> 192.168.2.140 ICMP Echo (ping) request
59.474726 192.168.2.140 -> 192.168.2.1 ICMP Echo (ping) reply
¿Un poltergeist? ... No, hemos hecho consultas desde el mismo segmento de LAN
y por lo tanto funciona sin problemas porque no se sale del scope de local
¿Que pasaría si las IP's 192.168.2.130 y .140 fueran públicas en vez de
privadas? ... que funcionaría porque mientras el gateway de salida de la red
de las IP's públicas sea el mismo y no haga NAT, no se crean "race
conditions" en las tablas de routing del kernel.
¿Entonces, en que quedamos, funciona o no el multihoming con Asterisk?, la
respuesta es ROTUNDA, NO FUNCIONA. Porque en todos las pruebas que aquí se
han detallado, NO HA EXISTIDO NI UN SOLO ESCENARIO de multihoming, porque
SIEMPRE se ha usado el mismo gateway para salir de la red, no había
diferentes rutas para llegar a un mismo destino.
En un escenario de multihoming REAL tenemos cosas como estas:
root@fw01XXXX:~ # ip addr
[...]
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:87:59:95 brd ff:ff:ff:ff:ff:ff
inet 80.35.XXX.YYY/24 brd 80.35.XXX.255 scope global eth1
inet 83.61.ZZ.KK/26 brd 83.61.ZZ.63 scope global eth1
inet 79.148.AAA.BBB/26 brd 79.148.AAA.255 scope global eth1
root@fw01XXXX:~ # ip ro
79.148.AAA.192/26 dev eth1 proto kernel scope link src 79.148.AAA.BBB
83.61.ZZ.0/26 dev eth1 proto kernel scope link src 83.61.ZZ.KK
80.35.XXX.0/24 dev eth1 proto kernel scope link src 80.35.XXX.YYY
¡ No hay default ! ... tranki ...
root@fw01XXXX:~ # ip ru
0: from all lookup local
50: from all lookup main
201: from all fwmark 0xfc/0xff lookup uplink-main
201: from 80.35.XXX.YYY/24 lookup adsl1
202: from 79.148.AAA.BBB/26 lookup adsl2
205: from 79.148.ZZ.KK/26 lookup adsl3
221: from all lookup multiroute
32766: from all lookup main
32767: from all lookup default
Y por supuesto, las tablas adsl1, adsl2, adsl3, uplink-main y multiroute
tienen sus correspondientes reglas de routing.
En este escenario de MULTIHOMING REAL, o metes marcas en el fw para forzar que
todo el tráfico generado por el asterisk salga por una ADSL concreta, o la
has liado parda, porque el hijo de puta de Asterisk, hace lo que le sale de
los cojones, claro que contesta a SIP por cualquiera de las IP, pero el RTP
te lo manda por donde cristo le da a entender, en función de lo que el kernel
devuelva para la apertura de socket con origen 0.0.0.0 y destino la IP que le
llegase en el INVITE para el RTP, y eso es la parte "bonita", porque si es
Asterisk quien genera el INVITE, pondrá como IP para RTP la que obtenga del
kernel a solicitar un socket con bind 0.0.0.0, supongamos que es la IP1,
porque el kernel la tiene en la tabla de cache de rutas hacia la IP destino
del UAC1, pero supongamos ahora (típico en los proveedores IP), que la IP que
me llega en el SDP del 183 del UAC1 para RTP no es la misma que la IP de
señalización del UAC1, Asterisk "obra" su "magia" y ya la hemos liado, porque
el UAC1 espera que el RTP le llegue de la IP1 (tal como asterisk le anunció
en su INVITE), pero resulta que el tráfico RTP en realidad sale de la IP2,
con lo que el UAC1 no acepta ese media, porque no lo está esperando.
Este es el problema de multihoming de asterisk, problema que no se resuelve
añadiendo un segundo default gw, en tú caso, en tú escenario concreto, te
funciona, pero como ya se ha dicho muchas veces en este hilo, DE PUÑETERA
CHIRIPA.
Y yo creo que el tema hemos de dejarlo ya, no es cuestión de convencer a nadie
de nada, si te funciona, perfecto para ti, pero que sepas que en realidad
solo has enmascarado un problema, no lo has solucionado y que hay que admitir
que la implementación de SIP y RTP de asterisk es penosa de cojones y que
hace las cosas a "su modo", lo que no quiere decir que sea lo correcto.
Y de paso deberíamos acostumbrarnos a quejarnos e intentar que las cosas
cumplan con los estandares y no tener que adaptar (limitar en realidad) los
entornos a lo que la herramienta X o Y es capaz de hacer o como lo hace.
Saludos
Germán Aracil Boned
No hay duda, estaba equivocado.
Así si, que queda claro el tema. Y yo he estado engañado.
gracias Raúl !
Raúl Alexis Betancor Santana escribió:
--
Julian J. M.
respuesta le vendrá desde la virtual, y estaremos en las mismas.
Julian J. M.
2009/2/3 Germán Aracil Boned <ger...@tecnoxarxa.com>:
>
> Yo a mi tema.. Y si le pones las entradas estáticas al alias del
> interface te funciona el iax ?
Saúl Ibarra
Una preguntilla (que no soy yo muy juanker del multihoming xD) en un
bug que Olle cerro acerca de este tema (ahora no tengo a mano el ID)
Kevin comentaba que el multihoming con IP alias en la misma LAN no es
multihoming, que multihoming de verdad es solo cuando hay 2 interfaces
de red distintas en la misma LAN, pero que entonces Asterisk funciona
way. Como de cierto es eso?
salu2!
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
Raúl Alexis Betancor Santana
> Essse Raúl!! Buenísimo el mail, gracias por explicarlo así :)
>
> Una preguntilla (que no soy yo muy juanker del multihoming xD) en un
> bug que Olle cerro acerca de este tema (ahora no tengo a mano el ID)
> Kevin comentaba que el multihoming con IP alias en la misma LAN no es
> multihoming, que multihoming de verdad es solo cuando hay 2 interfaces
> de red distintas en la misma LAN, pero que entonces Asterisk funciona
> way. Como de cierto es eso?
Multihoming, estrictamente hablando, es cuando A tienes varios caminos para
llegar a B
Varias IP como alias es una misma tarjeta, no se puede considerar multihoming,
sin embargo, varias tarjetas con IP's de la misma LAN, TAMPOCO, pero es una
cuestión más de "caminos", que de otra cosa, si tienes un server con 2
tarjetas de red, con IP's de la misma LAN, pero conectadas a switches
diferentes ... pues se puede decir que tienes multihoming, habría que ver si
quieres considerar el multihoming a nivel 2 pa'bajo o 2 pa'rriba (nivel OSI
me refiero).
En cuanto al bug que comentas, como ya dije al principio del hilo, si las IP's
está asignadas a VLAN's de una misma tarjeta, funciona, si están asignadas a
tarjetas diferentes, funciona, si son alias de una misma tarjeta y accedemos
al * sin NAT, funciona.
La única premisa para que "siga funcionando", independientemente de las
combinaciones es: QUE NO HAYAN 2 Ó MÁS "CAMINOS" entre A y B
Veamos un ejemplo, que siempre aclara las cosas:
UAC1:IP1 <-GW1/LAN1-> AST1:IP1 | AST1:IP2 <-GW2/LAN2>
Si el UAC1 envía un INVITE al *, y este llega por la IP1, * contestará por esa
IP el tráfico SIP, el RTP dependerá de la IP que el UAC1 indique para RTP y
de la tabla de rutas de Asterisk (aquí es donde * la lía parda)
Si es * quién envía un INVITE a UAC1 y resulta que a la hora de crear el
socket, indica 0.0.0.0 como origen (a priori * no tiene porqué saber como
alcanzar la IP1 de UAC1) y resulta que por casualidades de la vida (tabla de
rutas con multihoming y una tabla multiroute con varios nexthop despachando
tráfico en RRbW) el kernel decide que lo enviará por GW2 y supongamos que GW2
tiene forma de entregar esa petición a UAC1:IP1, el dialogo SIP se
establecerá, ahora el UAC1 envía su 183 con su IP RTP en el SDP por el path
inverso al que le llega el INVITE, es decir por GW2, eso llega a * y el
kernel "decide" (cuando * pide un socket para el RTP en 0.0.0.0, en vez de la
IP2, que es por donde le ha llegado la petición) que ahora el mejor camino es
GW1 ... la hemos liado parda.
Y por raro que parezca ... es lo que ocurre el 99% de las veces en esta
situación.
La solución pasa por que * haga las cosas bien y :
a) Utilice la IP dst del socket por el que le llega una petición para generar
el SDP de la respuesta y abrir los sockets de RTP y RTCP
b) Se flexibilice el comportamiento de la creación del socket RTP y RTCP a la
hora de generar un nuevo request desde *, permitiendo (mediante parámetro
asociado a peer ó mejor aún, mediante variable de canal) que la decisión de
que IP usar para enviar el request la tome el kernel (y que luego * la tenga
en cuenta y la respete) ó la tome el programador, obligando que la IP de RTP
y RTCP sea la misma que se use para la señalización.
c) * no haga cosas "antes de tiempo", si se repasa el código de chan_sip.c ...
veréis la de tiempo que pierde * para inicializar un puto channel por hacer
50.000 cosas que luego no va a usar o peor aún, "adelantandose" a ciertos
acontecimientos de la vida del canal y reservar recursos de forma incorrecta,
que degenerarán en un comportamiento inadecuado del channel, porque cuando
ocurren los "eventos de vida" del channel, no modifique los recursos
adecuadamente, sino que presuponga cosas.
Saúl Ibarra
Elio Rojano
Claro que esto generaría más tráfico, pero en teoría se solucionaría en parte el problema. ¿me equivoco?
--
http://www.sinologic.net/
Iñaki Baz Castillo
> Igual es algo que tiene que ver con los protocolos SIP e IAX y no con
> los teléfonos.
> Porque para ambas pruebas he usado la ultima versión de Zoiper...
solidpc, pero si se ve en las capturas TcpDump que pegaste que Asterisk SI
respondía al teléfono (pero desde la otra IP).
No hay más, el tfno recibe la respuesta y no la procesa por venir de otra IP
distinta a la que envió el request.
Iñaki Baz Castillo
"Pues yo tengo un Asterisk con dos tarjetas de red y me funciona"
XDDDDDDDDDDD
PD: Gracias por tan detallada explicación, ¡a ver quién replica eso!
Germán Aracil Boned
hay duda. Y el error era mio por tomar por válidas pruebas sin
profundicar más en el tema.
Sorry por mi insistencia, pero que conste, que rectifico eh ?!!
Solo necesitaba pruebas ;)
un abrazo peña !
Iñaki Baz Castillo escribió:
--
Elio Rojano
Iñaki Baz Castillo
> > Pues .. yooo .. yooo coñe a mi me va de coña como tu decias iñaki. no
> > hay duda. Y el error era mio por tomar por válidas pruebas sin
> > profundicar más en el tema.
> >
> > Sorry por mi insistencia, pero que conste, que rectifico eh ?!!
> > Solo necesitaba pruebas
No, si la verdad es que tiene mérito hacerlo funcionar a pesar de las
limitaciones y fallos de Asterisk :)
Pero ojito, que como extremadamente bien ha aclarado Raúl, lo que con muchos
trucos puede funcionar en un determinado escenario fallaría en otros.
Avisados estamos todos ;)
Saludos.
Raúl Alexis Betancor Santana
> Como curiosidad, ¿y no podría ser una opción utilizar bonding de red en
> modo de clonación con ips virtuales para las distintas ip?
¿rukutuqueeeeeee? .. ¿me lo explicas mas despacio? .. no entiendo que es lo
comentas.
¿bonding en plan ifenslave y tal? y ¿luego varias IP's en el bond0?... el
problema sería exactamente el mismo.
A no ser que te refieras a otro tipo de bonding.