2 isp [ot]

[Francisco Eduardo Ascencio Dominguez]

Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.

eh estado por ahu y me ah surgido una locura. aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red. por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los dos tendria 4 mb peri como lo hago ? es posible esto ? o solo es una idea absurda que se me ah ocurrido ? XD

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BLU405-EAS367828F15...@phx.gbl

[osearg...@gmail.com]

El 06/03/13 01:42, Francisco Eduardo Ascencio Dominguez escribió:

>
> Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.
>
> eh estado por ahu y me ah surgido una locura. aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red. por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los dos tendria 4 mb peri como lo hago ? es posible esto ? o solo es una idea absurda que se me ah ocurrido ? XD
>

hola francisco, si es posible hacerlo, podes hacer balanceo de carga y/o
tolerancia a fallos, una forma es a través de bounding [0] otra es con
iproute2 [1]

saludos

[0]
http://phenobarbital.wordpress.com/2011/06/22/linux-guia-rapida-de-network-bonding-en-debian/
[1]
http://www.k-nabora.com/index.php/blog/Balanceo-de-Carga-con-dos-ADSL-y-Debian-Lenny-.html

--
Javier Obregón (aka 4rkng3l)

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5136D45D...@gmail.com

[Francisco Eduardo Ascencio Dominguez]

bueno esto seria un servidor. no hay una manera. de hacerlo por hardware ?

[Camaleón]

El Tue, 05 Mar 2013 22:42:28 -0600, Francisco Eduardo Ascencio Dominguez
escribió:

> Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.
>
> eh estado por ahu y me ah surgido una locura.

Bueno, a ti y a millones de personas :-)

> aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red.
> por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los dos
> tendria 4 mb peri como lo hago ? es posible esto ? o solo es una idea
> absurda que se me ah ocurrido ? XD

Busca en Google por la palabra en clave "linux isp load balance", está
llenito de tutoriales y guías de configuración para hacer eso que buscas
(combinar el ancho de banda de dos proveedores) y más, desde linux.

Otra opción sería comprar un dispositivo de hardware que integre ya esa
opción (enrutador multi-wan) y que normalmente vienen con alguna versión
compacta de *BSD.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kh7lmh$u5i$8...@ger.gmane.org

[Francisco Eduardo Ascencio Dominguez]

Ok. les comentaba. que como seria por hardware con uno de estos aparatos ? este es o estoy mal ?

http://articulo.mercadolibre.com.mx/MLM-417305675-balanceador-de-carga-tplink-tl-r470t-multi-wan-mmu-_JM#questionText

Y una pregunta que es mejor hacerlo por hardware o por software ( I love debian ! ) ?

Enviado desde mi macbook.

Archive: http://lists.debian.org/BLU0-SMTP179C54733...@phx.gbl

[Camaleón]

El Wed, 06 Mar 2013 12:03:34 -0600, Francisco Eduardo Ascencio Dominguez
escribió:

No hagas top-posting... gracias.

> El 06/03/2013, a las 09:00, Camaleón <noel...@gmail.com> escribió:
>
>> El Tue, 05 Mar 2013 22:42:28 -0600, Francisco Eduardo Ascencio
>> Dominguez escribió:

(...)

>>> aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red.
>>> por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los
>>> dos tendria 4 mb peri como lo hago ? es posible esto ? o solo es una
>>> idea absurda que se me ah ocurrido ? XD
>>
>> Busca en Google por la palabra en clave "linux isp load balance", está
>> llenito de tutoriales y guías de configuración para hacer eso que
>> buscas (combinar el ancho de banda de dos proveedores) y más, desde
>> linux.
>>
>> Otra opción sería comprar un dispositivo de hardware que integre ya esa
>> opción (enrutador multi-wan) y que normalmente vienen con alguna
>> versión compacta de *BSD.

> Ok. les comentaba. que como seria por hardware con uno de estos aparatos
> ? este es o estoy mal ?
>
> http://articulo.mercadolibre.com.mx/MLM-417305675-balanceador-de-carga-tplink-tl-r470t-multi-wan-mmu-_JM#questionText

Según la hoja de producto¹ yo diría que permite balanceo de carga pero no
agregación de canales, es decir, entiendo que si tienes 2 proveedores
distintos podrías conectar ambos y el aparatejo este determinaría la salida
según el ancho de banda que tenga cada canal y lo saturado que esté.

Lo que no me queda claro es si permite configurarlo en modo "failover" (si
un enlace cae que se use el segundo) o para unir el ancho de banda de los
dos canales (si tienes dos adsl de 6 Mbps obtener un ancho de banda efectivo
de 12 Mbps).

Tendrás que leer el manual completo >:-)

> Y una pregunta que es mejor hacerlo por hardware o por software ( I love
> debian ! ) ?

Supongo que te refieres a si es mejor usar un /appliance/ dedicado o no. Hombre,
pues depende. ¿Ventajas de usar un dispositivo dedicado? Facilidad de uso,
configuración y mantenimiento ¿Desventajas? Limitaciones de uso, actualizaciones
complicadas (en cuanto a añadir funcionalidades)... en definitiva, menor control.

> Enviado desde mi macbook.

Ya decía yo...

¹http://www.tp-link.es/Resources/software/TL-R470T_v2.0_Datasheet.zip

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kh81ae$u5i$1...@ger.gmane.org

[Marc Olivé]

A Dimecres, 6 de març de 2013 19:03:34, Francisco Eduardo Ascencio Dominguez va escriure:

> Ok. les comentaba. que como seria por hardware con uno de estos aparatos ?

> este es o estoy mal ?

>

> http://articulo.mercadolibre.com.mx/MLM-417305675-balanceador-de-carga-tpli

> nk-tl-r470t-multi-wan-mmu-_JM#questionText

>

> Y una pregunta que es mejor hacerlo por hardware o por software ( I love

> debian ! ) ?

 

Yo, personalmente y en general (lo que significa que en ocasiones va a ser _equivocado_), no creo en las soluciones llamadas "por hardware". Por que toda solución "por hardware" necesita del software, y toda solución "por software" necesita del hardware. ¿Es que no corre ningún software en las soluciones hardware? ¿O es que tu software no corre sobre ningún hardware?

Y concretamente hablando de enrutadores, el software Linux es excelente en este campo[0], tanto que la mayoria de soluciones hardware corren Linux para realizar dichas funciones.

 

Por menos de la mitad de los 715€ que cuesta el hardware que propones, puedes comprate un HP MicroServer[1] (o similar) y añadirle una (o mas) targeta de red, instalarle GNU/Linux Debian y usarlo como gateway para todas las conexiones[2] que tengas contratadas.

Te va a costar mas de trabajo y menos dinero. Pero sobretodo, vas a disfrutarlo mucho mas y vas a aprender, y podras añadirle otros usos al gateway (firewall, dhcp, dns, vpn, etc...).

Y si algun dia el se queda corto, puedes cambiar el hardware conservando la instalacion de GNU/Linux y las configuraciones que hayas hecho, y así poder adaptarlo a las crecientes necesidades de tu red.

 

Respondiendo a tu pregunta: no creo en soluciones hardware, el cerebro es el software.

 

> Enviado desde mi macbook.

>

> El 06/03/2013, a las 09:00, Camaleón <noel...@gmail.com> escribió:

> > El Tue, 05 Mar 2013 22:42:28 -0600, Francisco Eduardo Ascencio Dominguez

> >

> > escribió:

> >> Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.

> >>

> >> eh estado por ahu y me ah surgido una locura.

> >

> >> aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red.

> >> por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los dos

> >> tendria 4 mb peri como lo hago ? es posible esto ? o solo es una idea

> >> absurda que se me ah ocurrido ? XD

 

> >

> > Saludos,

 

[0]http://www.lartc.org/

[1]http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-4237916-4237918-4237917-4248009.html?dnr=1

[2]http://bourneagainshell.blogspot.com.es/2008/05/de-como-conectar-13-adsls-en-balanceo.html

 

--

 

Marc Olivé

http://www.blauadvisors.com

[Felix Perez]

El día 6 de marzo de 2013 11:31, Francisco Eduardo Ascencio Dominguez
<ly...@live.com> escribió:

> bueno esto seria un servidor. no hay una manera. de hacerlo por hardware ?
>

NO hagas top posting por favor.

Existen equipos como el linksys RV082 (habrá otros más modernos) que
permite conectar dos enlaces adsl y trabajar con ambos, no se si sumar
el ancho de banda me imagino que no, pero si el balanceo de carga.

Suerte.

--
usuario linux #274354
normas de la lista: http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAAiZAx49VsY3X0uVYPcLxgqR...@mail.gmail.com

[Roberto Quiñones]

El ancho de banda no se puede sumar al de otro proveedor, tampoco si
fuese el mismo proveedor pero con distintos enlaces (fibras), pero si es
fiable lo que comentas de trabajar en un mismo dispositivo con los 2
enlace para una alta disponibilidad de enlaces en caso de caida de una,
se sigue usando la otra y si se configura correctamente, el corte no se
sentiria en lo absoluto a nivel de usuarios al navegar.

Saludos

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/513CA4E7...@acshell.net

[Camaleón]

El Sun, 10 Mar 2013 12:21:11 -0300, Roberto Quiñones escribió:

> El ancho de banda no se puede sumar al de otro proveedor, tampoco si
> fuese el mismo proveedor pero con distintos enlaces (fibras),

(...)

Se llama "link aggregation" (o "broadband bonding") y sí es posible. No
todos los dispositivos lo admiten pero existen soluciones profesionales
en el mercado que ya lo implementan.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khi9tt$fam$6...@ger.gmane.org

[Roberto Quiñones]

El 10/03/2013 12:47, Camaleón escribió:
> El Sun, 10 Mar 2013 12:21:11 -0300, Roberto Quiñones escribió:
>
>> El ancho de banda no se puede sumar al de otro proveedor, tampoco si
>> fuese el mismo proveedor pero con distintos enlaces (fibras),
>
> (...)
>
> Se llama "link aggregation" (o "broadband bonding") y sí es posible. No
> todos los dispositivos lo admiten pero existen soluciones profesionales
> en el mercado que ya lo implementan.
>
> Saludos,
>

cuando hablo de sumar me reifiero a que no es posible tener un enlace de
100 mb de proveedor A y un segundo enlace de 100 mb de proveedor B y
hacer un unico enlace por el que sale la red hacia internet, dejando un
enlace de 200 mbps, pero si es posible hacer una alta disponibilidad con
los dispositivos que hay en el mercado y que te permite tener 2 enlaces
de un mismo proveedor o de otro, en un mismo dispositivo y que
practicamente como tu dices que es, configurar por un unico canal sale,
sale todo por ahi, pero es simplemente una alta disponibilidad, el
dispositivo sabe por donde enviar mejor el paquete de una comunicacion
entre maquinas entre los enlaces que tienes unidos.

Saludos

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/513CF7D9...@acshell.net

[Ricardo]

El 10/03/2013 18:15, Roberto Quiñones escribió:
> El 10/03/2013 12:47, Camaleón escribió:
>> El Sun, 10 Mar 2013 12:21:11 -0300, Roberto Quiñones escribió:
>>
>>> El ancho de banda no se puede sumar al de otro proveedor, tampoco si
>>> fuese el mismo proveedor pero con distintos enlaces (fibras),
>>
>> (...)
>>
>> Se llama "link aggregation" (o "broadband bonding") y sí es posible. No
>> todos los dispositivos lo admiten pero existen soluciones profesionales
>> en el mercado que ya lo implementan.
>>
>> Saludos,
>>
>
> cuando hablo de sumar me reifiero a que no es posible tener un enlace
> de 100 mb de proveedor A y un segundo enlace de 100 mb de proveedor B
> y hacer un unico enlace por el que sale la red hacia internet, dejando
> un enlace de 200 mbps, pero si es posible hacer una alta
> disponibilidad con los dispositivos que hay en el mercado y que te
> permite tener 2 enlaces de un mismo proveedor o de otro, en un mismo
> dispositivo y que practicamente como tu dices que es, configurar por
> un unico canal sale, sale todo por ahi, pero es simplemente una alta
> disponibilidad, el dispositivo sabe por donde enviar mejor el paquete
> de una comunicacion entre maquinas entre los enlaces que tienes unidos.
>

Tal como ya te respondieron no puedes "sumar" ancho de banda, pero creo
que este articulo, explica perfectamente lo que deseas hacer:
http://phenobarbital.wordpress.com/2011/06/22/linux-guia-rapida-de-network-bonding-en-debian/
--
Ricardo

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/513CFAA3...@gmail.com

[Camaleón]

El Sun, 10 Mar 2013 18:15:05 -0300, Roberto Quiñones escribió:

> El 10/03/2013 12:47, Camaleón escribió:
>> El Sun, 10 Mar 2013 12:21:11 -0300, Roberto Quiñones escribió:
>>
>>> El ancho de banda no se puede sumar al de otro proveedor, tampoco si
>>> fuese el mismo proveedor pero con distintos enlaces (fibras),
>>
>> (...)
>>
>> Se llama "link aggregation" (o "broadband bonding") y sí es posible. No
>> todos los dispositivos lo admiten pero existen soluciones profesionales
>> en el mercado que ya lo implementan.
>>

> cuando hablo de sumar me reifiero a que no es posible tener un enlace de
> 100 mb de proveedor A y un segundo enlace de 100 mb de proveedor B y
> hacer un unico enlace por el que sale la red hacia internet, dejando un
> enlace de 200 mbps,

(...)

Que sí es posible ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khkqro$48c$2...@ger.gmane.org

[Carlos Miranda Molina (Mstaaravin)]

2013/3/11 Camaleón <noel...@gmail.com>

> cuando hablo de sumar me reifiero a que no es posible tener un enlace de
> 100 mb de proveedor A y un segundo enlace de 100 mb de proveedor B y
> hacer un unico enlace por el que sale la red hacia internet, dejando un
> enlace de 200 mbps,

(...)

Que sí es posible ;-)

NO es posible con el tipo de conexiones hogareñas del tipo que se está hablando en este lista, es una confusión muy común

Puedes tener disponibles 200mb en total para utilizar pero cada conexión cliente de la red cuando salga a internet saldrá por uno de los enlaces con su límite de velocidad.

Es posible sólo cuando los enlaces trabajan con protocolos de enrutamiento (BGP, OSPF, Ripv2, etc) algo que no es el caso aqui.

Saludos

--

"La Voluntad es el único motor de nuestros logros"
http://blog.ngen.com.ar/

[Ricardo]

El día 11 de marzo de 2013 12:31, Carlos Miranda Molina (Mstaaravin)
<mstaa...@gmail.com> escribió:

Hola, yo en persona uso Mikrotik RB750, para sumar ancho de banda es
execelente este apratito. tambien es Linux. SO que lleva. tenes
Firewall, todo tipo de VPN. en muy cencillo de configurar.. mas uso
para que no navegen los usuarios por puerto 80 filtro por Mac. de la
Pc de usuario. si filtro por ip no tiene sentido. el resto de los
puertos todo habilitado. reciben correos etc.

Por el ootro lado hay para PC se baja desde la pagina oficial.. es una
ISo se instala en cualquier pc yo tengo uno con Pentium III con 32Mb
de ram, sim problemas, y ademas le sumo una placa WIFI. tengo cubierto
hasta con los vecinos. el WIFI es 5 veces mas potente que los
aparatitos (Routers comunes). si alguien me dice como configurar les
hecho una mano no tengo problema solo ustedes los dicen nomas....
ayude a muchos como en otras listas.. .

Saludos cordiales

Ricardo

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAH45FxdhsoaGHA7ejoOGX2bZ...@mail.gmail.com

[Camaleón]

El Mon, 11 Mar 2013 15:04:48 -0300, Ricardo escribió:

> Hola, yo en persona uso Mikrotik RB750, para sumar ancho de banda es
> execelente este apratito. tambien es Linux. SO que lleva. tenes
> Firewall, todo tipo de VPN. en muy cencillo de configurar.. mas uso
> para que no navegen los usuarios por puerto 80 filtro por Mac. de la Pc
> de usuario. si filtro por ip no tiene sentido. el resto de los puertos
> todo habilitado. reciben correos etc.

(...)

No sé qué decirte. Por 40$ no creo que dé mucho de sí aunque no dudo que
tenga otras características interesantes pero no la que busca el OP ;-)

La mayoría de los dispositivos que permiten "unir" el ancho de banda de
enlaces convencionales ADSL (que sí, que ya existen, que sí, para líneas
ADSL convencionales... ains) suelen ser mucho más caros.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khl7e5$48c$7...@ger.gmane.org

[Hector Garcia]

El día 11 de marzo de 2013 12:23, Camaleón <noel...@gmail.com> escribió:
> El Mon, 11 Mar 2013 15:04:48 -0300, Ricardo escribió:
>
>> Hola, yo en persona uso Mikrotik RB750, para sumar ancho de banda es
>> execelente este apratito. tambien es Linux. SO que lleva. tenes
>> Firewall, todo tipo de VPN. en muy cencillo de configurar.. mas uso
>> para que no navegen los usuarios por puerto 80 filtro por Mac. de la Pc
>> de usuario. si filtro por ip no tiene sentido. el resto de los puertos
>> todo habilitado. reciben correos etc.
>
> (...)
>
> No sé qué decirte. Por 40$ no creo que dé mucho de sí aunque no dudo que
> tenga otras características interesantes pero no la que busca el OP ;-)
>
> La mayoría de los dispositivos que permiten "unir" el ancho de banda de
> enlaces convencionales ADSL (que sí, que ya existen, que sí, para líneas
> ADSL convencionales... ains) suelen ser mucho más caros.
>
> Saludos,
>
> --
> Camaleón
>
>

> --offline

> To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/khl7e5$48c$7...@ger.gmane.org
>

Hola Ricardo. ¿Es link agregattion real? ¿ O es alguno de los
diferentes balanceos de carga que soporta el Routerboard?
Hasta ahora, lo más cercano que he visto es con una implementación
rara de tuneles EOIP, pero no es efectiva en el 100 % de los casos.

¿Podrías compartir tu solución? Si gustas, fuera de la lista, para no
generar ruido.

Elsa, si bien es posible que no sea la respuesta al OP, te
sorprenderías de lo que puede hacer ese aparatito de ~ USD 40, en las
manos correctas.

Salud!
--
Hector
--
El Pic no pudo Iniciar correctamente.
Inserte el disco de arranque y presione cualquier pin para continuar...

Linux Registered User #467500
https://linuxcounter.net/user/467500.html

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CACzWLTLkOTXXdgu0nbVtkw+L...@mail.gmail.com

[Roberto Quiñones]

El 12/03/2013 16:25, Hector Garcia escribi�:
> El d�a 11 de marzo de 2013 12:23, Camale�n <noel...@gmail.com> escribi�:
>> El Mon, 11 Mar 2013 15:04:48 -0300, Ricardo escribi�:

>>
>>> Hola, yo en persona uso Mikrotik RB750, para sumar ancho de banda es
>>> execelente este apratito. tambien es Linux. SO que lleva. tenes
>>> Firewall, todo tipo de VPN. en muy cencillo de configurar.. mas uso
>>> para que no navegen los usuarios por puerto 80 filtro por Mac. de la Pc
>>> de usuario. si filtro por ip no tiene sentido. el resto de los puertos
>>> todo habilitado. reciben correos etc.
>>
>> (...)
>>

>> No s� qu� decirte. Por 40$ no creo que d� mucho de s� aunque no dudo que
>> tenga otras caracter�sticas interesantes pero no la que busca el OP ;-)
>>
>> La mayor�a de los dispositivos que permiten "unir" el ancho de banda de
>> enlaces convencionales ADSL (que s�, que ya existen, que s�, para l�neas
>> ADSL convencionales... ains) suelen ser mucho m�s caros.
>>
>> Saludos,
>>
>> --
>> Camale�n

>>
>>
>> --offline
>> To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>> Archive: http://lists.debian.org/khl7e5$48c$7...@ger.gmane.org
>>
>
> Hola Ricardo. �Es link agregattion real? � O es alguno de los
> diferentes balanceos de carga que soporta el Routerboard?

> Hasta ahora, lo m�s cercano que he visto es con una implementaci�n

> rara de tuneles EOIP, pero no es efectiva en el 100 % de los casos.
>

> �Podr�as compartir tu soluci�n? Si gustas, fuera de la lista, para no

> generar ruido.
>
> Elsa, si bien es posible que no sea la respuesta al OP, te

> sorprender�as de lo que puede hacer ese aparatito de ~ USD 40, en las

> manos correctas.
>
> Salud!
> --
> Hector
> --
> El Pic no pudo Iniciar correctamente.
> Inserte el disco de arranque y presione cualquier pin para continuar...
>
> Linux Registered User #467500
> https://linuxcounter.net/user/467500.html
>
>

Vuelvo a decir que no se puede "SUMAR" un enlace a otro y dejar uno solo
como enlace por el que va toda la conexion, por que internamente estos
enlaces pasan por un canal (chanel) a nivel de la capa osi y que puede
ser manejado por hardware o por software, pero que igual siguen siendo 2
enlaces de 100 mbps o de 1 gbps de distintos proveedores pero que estan
configurado por un canal unico pero es una alta disponibilidad.
simplemente eso.

Saludos

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/513FE342...@acshell.net

[Camaleón]

El Tue, 12 Mar 2013 23:24:02 -0300, Roberto Quiñones escribió:

> El 12/03/2013 16:25, Hector Garcia escribió:
>> El día 11 de marzo de 2013 12:23, Camaleón <noel...@gmail.com>
>> escribió:

>>> El Mon, 11 Mar 2013 15:04:48 -0300, Ricardo escribió:
>>>
>>>> Hola, yo en persona uso Mikrotik RB750, para sumar ancho de banda es
>>>> execelente este apratito. tambien es Linux. SO que lleva. tenes
>>>> Firewall, todo tipo de VPN. en muy cencillo de configurar.. mas uso
>>>> para que no navegen los usuarios por puerto 80 filtro por Mac. de la
>>>> Pc de usuario. si filtro por ip no tiene sentido. el resto de los
>>>> puertos todo habilitado. reciben correos etc.
>>>
>>> (...)
>>>

>>> No sé qué decirte. Por 40$ no creo que dé mucho de sí aunque no dudo
>>> que tenga otras características interesantes pero no la que busca el
>>> OP ;-)
>>>

>>> La mayoría de los dispositivos que permiten "unir" el ancho de banda
>>> de enlaces convencionales ADSL (que sí, que ya existen, que sí, para

>>> líneas ADSL convencionales... ains) suelen ser mucho más caros.

>> Hola Ricardo. ¿Es link agregattion real? ¿ O es alguno de los
>> diferentes balanceos de carga que soporta el Routerboard? Hasta ahora,

>> lo más cercano que he visto es con una implementación rara de tuneles

>> EOIP, pero no es efectiva en el 100 % de los casos.

Tras haber leído por encima las características del dispositivo y haber
visto su precio, dudo mucho que lo permita ;-)

>> ¿Podrías compartir tu solución? Si gustas, fuera de la lista, para no
>> generar ruido.

No veo por qué no comentarlo en la lista, el hilo está marcado como OT y
seguramente al OP le pueda interesar.

>> Elsa, si bien es posible que no sea la respuesta al OP, te

>> sorprenderías de lo que puede hacer ese aparatito de ~ USD 40, en las
>> manos correctas.

Como ya he dicho antes, no dudo de que permita cosas majas, pero entre
ellas no figura gestionar el ancho de banda de las conexiones que
proporcionan los ISP.

> Vuelvo a decir que no se puede "SUMAR" un enlace a otro y dejar uno solo
> como enlace por el que va toda la conexion, por que internamente estos
> enlaces pasan por un canal (chanel) a nivel de la capa osi y que puede
> ser manejado por hardware o por software, pero que igual siguen siendo 2
> enlaces de 100 mbps o de 1 gbps de distintos proveedores pero que estan
> configurado por un canal unico pero es una alta disponibilidad.
> simplemente eso.

Que sí se puede. Infórmate bien ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khq3nv$7u8$3...@ger.gmane.org

[Ramses]

Camaleón, buenas tardes,

Quieres decir que: Sí tenemos 2 ADSL's caseras de 2 ISP's distintos,, sin contratar nada especifico con los ISP's, de 20Mbps de descarga cada una, ¿podemos poner 1 PC a descargarse un fichero de 100Mb a 40Mbps?

¿Cómo?


Saludos,

Ramses

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/D7C1BE64-51E2-4358...@gmail.com

[Camaleón]

El Wed, 13 Mar 2013 16:54:19 +0100, Ramses escribió:

> Camaleón, buenas tardes,
>
> El 13/03/2013, a las 15:50, Camaleón <noel...@gmail.com> escribió:
>
>> El Tue, 12 Mar 2013 23:24:02 -0300, Roberto Quiñones escribió:

(...)

>>> Vuelvo a decir que no se puede "SUMAR" un enlace a otro y dejar uno
>>> solo como enlace por el que va toda la conexion, por que internamente
>>> estos enlaces pasan por un canal (chanel) a nivel de la capa osi y que
>>> puede ser manejado por hardware o por software, pero que igual siguen
>>> siendo 2 enlaces de 100 mbps o de 1 gbps de distintos proveedores pero
>>> que estan configurado por un canal unico pero es una alta
>>> disponibilidad. simplemente eso.
>>
>> Que sí se puede. Infórmate bien ;-)
>
> Quieres decir que: Sí tenemos 2 ADSL's caseras de 2 ISP's distintos,,
> sin contratar nada especifico con los ISP's, de 20Mbps de descarga cada
> una, ¿podemos poner 1 PC a descargarse un fichero de 100Mb a 40Mbps?

Sí, esa es la idea del "link aggregation, aunque las cifras variarán,
obviamente.

> ¿Cómo?

Comprando hardware/software que implemente esta funcionalidad :-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khq93a$7u8$1...@ger.gmane.org

[Ramses]

Buenas tardes,

El 13/03/2013, a las 17:22, Camaleón <noel...@gmail.com> escribió:

> El Wed, 13 Mar 2013 16:54:19 +0100, Ramses escribió:
>
>> Camaleón, buenas tardes,
>>
>> El 13/03/2013, a las 15:50, Camaleón <noel...@gmail.com> escribió:
>>
>>> El Tue, 12 Mar 2013 23:24:02 -0300, Roberto Quiñones escribió:
>
> (...)
>
>>>> Vuelvo a decir que no se puede "SUMAR" un enlace a otro y dejar uno
>>>> solo como enlace por el que va toda la conexion, por que internamente
>>>> estos enlaces pasan por un canal (chanel) a nivel de la capa osi y que
>>>> puede ser manejado por hardware o por software, pero que igual siguen
>>>> siendo 2 enlaces de 100 mbps o de 1 gbps de distintos proveedores pero
>>>> que estan configurado por un canal unico pero es una alta
>>>> disponibilidad. simplemente eso.
>>>
>>> Que sí se puede. Infórmate bien ;-)
>>
>> Quieres decir que: Sí tenemos 2 ADSL's caseras de 2 ISP's distintos,,
>> sin contratar nada especifico con los ISP's, de 20Mbps de descarga cada
>> una, ¿podemos poner 1 PC a descargarse un fichero de 100Mb a 40Mbps?
>
> Sí, esa es la idea del "link aggregation, aunque las cifras variarán,
> obviamente.
>
>> ¿Cómo?
>
> Comprando hardware/software que implemente esta funcionalidad :-)

Un ejemplo de ese hardware que permite bajarse un único fichero, desde un único PC a través de 2 ADSL's de 2 ISP's distintos, a una velocidad igual a la suma de ambas velocidades de descarga de las 2 ADSL's.


Saludos,

Ramses

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/B339FBE9-588F-4C6D...@gmail.com

[Carlos Miranda Molina (Mstaaravin)]

2013/3/13 Camaleón <noel...@gmail.com>

> Quieres decir que: Sí tenemos 2 ADSL's caseras de 2 ISP's distintos,,
> sin contratar nada especifico con los ISP's, de 20Mbps de descarga cada
> una, ¿podemos poner 1 PC a descargarse un fichero de 100Mb a 40Mbps?

Sí, esa es la idea del "link aggregation, aunque las cifras variarán,
obviamente.

> ¿Cómo?

Comprando hardware/software que implemente esta funcionalidad :-) 

Camaleon por favor, no tienes la mas puta idea de lo que estas diciendo.

NO se puede sin utilizar enlaces con protocolos de enrutamiento tales como BGP, EIGRP, OSPF, etc

Los enlaces hogareños tales como PPPOE, cable, etc NO soportan estos protocolos desde las conexiones de los usuarios.

Links agregation, trunking, bonding, etc no son mas que métodos para sumar el ancho de banda de interfaces físicas, pero si a un bond0 conectas un ADSL eso va a funcionar a la velocidad del proveedor.

Saludos

[Camaleón]

El Wed, 13 Mar 2013 17:39:58 +0100, Ramses escribió:

> Buenas tardes,
>
> El 13/03/2013, a las 17:22, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Quieres decir que: Sí tenemos 2 ADSL's caseras de 2 ISP's distintos,,
>>> sin contratar nada especifico con los ISP's, de 20Mbps de descarga
>>> cada una, ¿podemos poner 1 PC a descargarse un fichero de 100Mb a
>>> 40Mbps?
>>
>> Sí, esa es la idea del "link aggregation, aunque las cifras variarán,
>> obviamente.
>>
>>> ¿Cómo?
>>
>> Comprando hardware/software que implemente esta funcionalidad :-)
>
> Un ejemplo de ese hardware que permite bajarse un único fichero, desde
> un único PC a través de 2 ADSL's de 2 ISP's distintos, a una velocidad
> igual a la suma de ambas velocidades de descarga de las 2 ADSL's.

Pues sí, claro... ¿buscando en Google por ejemplo?

http://bit.ly/Y9Ne1H

Esta empresa parece que tiene algo:

http://www.mushroomnetworks.com/

Dan más detalles en su blog:

ADSL bonding done right – how can DSL aggregation be done without telco
coordination
http://www.mushroomnetworks.com/blog/2012/04/02/adsl-bonding-and-bonded-dsl/

Y esa otra, también:

http://www.teloip.com/link-aggregation-hardware.php#ai-400

O esta:

http://www.edge2wan.com/e2w/components/wanbonding.xrn

Son los primeros enlaces que he visto, supongo que habrá más empresas
con este tipo de soluciones.

Por lo que leo se ve que se basan en esto:

http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching

Recuerdo que en la RDSI se usaba algo similar en cuanto a concepto (se
sumaban los dos canales B de 64 Kbps para obtener "súper-velocidades"
de 128 Kbps). Es normal que estas cosas avancen, habrán desarrollado alguna
diablura para aprovechar los nuevos protocolos >:-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khqchr$7u8$1...@ger.gmane.org

[Carlos Miranda Molina (Mstaaravin)]

2013/3/13 Camaleón <noel...@gmail.com>

Pues sí, claro... ¿buscando en Google por ejemplo?

http://bit.ly/Y9Ne1H

Esta empresa parece que tiene algo:

http://www.mushroomnetworks.com/

Interesante, es la prueba de que estoy un poco desactualizado!

Caramba!

 

 

[Ramses]

Buenas,

Esto era a través del mismo enlace físico...

¿Seguro que un server en Internet va a mandar un cachito del fichero a cada una de las 2 IP Públicas distintas?.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/6EFD359F-18EA-4833...@gmail.com

[Roberto Quiñones]

El 13/03/2013 13:45, Carlos Miranda Molina (Mstaaravin) escribió:
> 2013/3/13 Camaleón <noel...@gmail.com <mailto:noel...@gmail.com>>

Vuelvo a decir que un enlace no se puede "SUMAR" por que de ser así
seria como en su matematica, 1 + 1 = 2 eso quiere decir sumar, no 1 + =1
puesto que si uno 2 enlaces por un mismo canal da igual el protocolo que
utilice de los que fueron definicos para el broadbonding, siempre serán
2 enlaces y no uno solo, es uno solo en forma logica por que se une 2 o
más enlaces para hacer uno solo pero en forma logica, pero la
comunicaxion se distribulle entre todas o entre alguna, depende de como
se defina la red de ese tipo. Ahora estoy es ya más personal, esto lo
digo por que en donde trabajo hemos implementado hace poco 2 enlaces de
1 gbps para tener una alta disponibilidad y justamente lo que se hizo
fue tener 2 enlaces de distintos proveedores y que un dispositivo
inteligente maneje la forma en como se va la comunicación a los destinos
donde debe ir.

Saludos.

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/514132A7...@acshell.net

[Ramses]

Buenos días,

Correcto, tendrás 2 enlaces de 1Gbps cada uno, que la LAN podrá aprovechar y descargarse un Ancho de Banda total de 2 Gbps, pero un PC se podrá descargar 1 fichero con un Ancho de Banda máximo de 1 Gbps.

¿Cómo abriría nuestro PC, o el otro dispositivo, 2 sesiones distintas, ya que van por enlaces distintos, y las mantendría, y el Servidor remoto mandaría un cacho de fichero por cada sesión, y después recomponer el fichero y...?

Creo que esa es la confusión, que se ve, o te lo venden, desde el punto de vista de la LAN y lo confunden con verlo desde el punto de vista del PC.

Dicho de otra forma: Si tenemos un único PC en una LAN que se tiene que descargar un fichero de 100Gb por una ADSL de 1Gbps (Guaaauuuu), si le ponemos dos ADSL's de 1Gbps, el tiempo de descarga será el mismo que con 1 de las ADSL.

O si lo vemos desde el punto de vista público, desde Internet, si tenemos 2 ADSL's de 1Gbps en nuestra red, de distinto proveedor, sin nada especial, e intentamos descargarnos desde un PC en Internet un fichero de 10Gb que está en un servidor en nuestra red, ¿atacamos a una IP Pública desde el PC y el Servidor nos devuelve el fichero por las 2 ADSL's?


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/47A730FA-9612-4211...@gmail.com

[Kmilo Noa]

Hola lista, necesito saber los nombres de los paquetes que debo instalar
para leer y escribir en particiones ntfs

uso Debian Lenny

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/e4730e942eeed242e701...@webmail.fcom.uh.cu

[Manel Bazalo]

El 2013-03-14 14:48, Kmilo Noa escribió:
> Hola lista, necesito saber los nombres de los paquetes que debo
> instalar
> para leer y escribir en particiones ntfs
>
> uso Debian Lenny

Hola,

aptitute show ntfs-3g

Saludos
/M

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/e122ea581798d89c...@tocolors.com

[Roberto Quiñones]

Y por que piensas que un una estructura de la que he mencionado se hace pensado en 1 o 10 computadores que solo se dedican a bajar, acaso tus maquinas en tu red las tienes solo para bajar files de gran tamaño o de menor tamaño ¿?, no tienes corriendo servicios y otras cosas ¿?

> ¿Cómo abriría nuestro PC, o el otro dispositivo, 2 sesiones distintas, ya que van por enlaces distintos, y las mantendría, y el Servidor remoto mandaría un cacho de fichero por cada sesión, y después recomponer el fichero y...?
>

Sigo sin entender tu punto, no se si cuestionado el que no se pueda hacer o no, pero igual que lo anterior,es configurable.

> Creo que esa es la confusión, que se ve, o te lo venden, desde el punto de vista de la LAN y lo confunden con verlo desde el punto de vista del PC.
>

No se que intentas decir,

> Dicho de otra forma: Si tenemos un único PC en una LAN que se tiene que descargar un fichero de 100Gb por una ADSL de 1Gbps (Guaaauuuu), si le ponemos dos ADSL's de 1Gbps, el tiempo de descarga será el mismo que con 1 de las ADSL.
>

y quien ha dicho que el que se agregue un enlace junto a otro sea para tener una mayor rapides de mi red para la descarga, creo que estas algo confundido. ahora aqui nadie habla de conexion ADSL.

> O si lo vemos desde el punto de vista público, desde Internet, si tenemos 2 ADSL's de 1Gbps en nuestra red, de distinto proveedor, sin nada especial, e intentamos descargarnos desde un PC en Internet un fichero de 10Gb que está en un servidor en nuestra red, ¿atacamos a una IP Pública desde el PC y el Servidor nos devuelve el fichero por las 2 ADSL's?
>

puede ser posible y lo es, por algo hemos hablado de que existen dispositivos inteligentes que permiten hacer un broadband bonding manejando a nivel de comunicación y paquete que este no importe por donde valla, siempre tenga claro a donde debe llegar y es gracias a los protocolos que se han diseñado para hacer esto.

>
> Saludos,
>
> Ramsés
>
> --
> To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/47A730FA-9612-4211...@gmail.com
>

Saludos.

[Ramses II]

Roberto, buenos días,

Lo que intento decir es que creo que ese tipo de equipos no suman los Anchos
de Banda de las ADSL's que se pongan en la WAN, que es lo que cree la gente.
Que más bien lo que hacen es balancear el tráfico por todos los enlaces WAN
conectados, pero que un PC solo, en una única tarea, por ejemplo, la
descarga de un fichero desde Internet, no llegará a tener el Ancho de Banda
de la suma de todos los enlaces WAN que tengan conectados esos aparatos...

Evidentemente, para una LAN sí es apreciable, ya que con un único enlace
WAN, en el momento que se satura porque un equipo está descargando un
fichero o usando algún servicio que ocupe todo el Ancho de Banda , es lo que
hay, los demás tendrán que esperar, pero si colocas uno de estos
dispositivos, el resto de las peticiones / tareas irán balanceándose entre
todos los enlaces WAN, pero la tarea de ese PC, que como ejemplo he puesto
una descarga, solo sale por uno de los enlaces WAN, no se reparte entre
todos...

Solo quiero evidenciar eso, que no se suma, que se balancea, pero que cada
sesión sale por un enlace. ¿Es correcto?.

Evidentemente, está claro que no solo se ponen enlaces redundantes para
aumentar el Ancho de Banda entre dos puntos, la Tolerancia a Fallos es la
otra. Pero yo no hablo de esto, estoy hablando de lo que han comentado en el
hilo, que con esos dispositivos se pueden colocar ADSL's normales y
corrientes, de proveedores distintos, y se suma el Ancho de Banda. Y no creo
que sea así, que no se suman, que el tráfico de la LAN lo balanceará /
distribuirá el dispositivo entre todos los enlaces WAN, porque si los
sumara, y es por lo que he puesto el ejemplo, un PC, por ejemplo el de mi
casa, se descargaría un fichero grande a la mitad de tiempo si coloco un
dispositivo de estos y 2 ADSL's.

Saludos,

Ramsés


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/004501ce20ba$dab11f90$90135eb0$@gmail.com

[Camaleón]

El Thu, 14 Mar 2013 00:06:49 +0100, Ramses escribió:

> El 13/03/2013, a las 18:20, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Un ejemplo de ese hardware que permite bajarse un único fichero, desde
>>> un único PC a través de 2 ADSL's de 2 ISP's distintos, a una velocidad
>>> igual a la suma de ambas velocidades de descarga de las 2 ADSL's.
>>
>> Pues sí, claro... ¿buscando en Google por ejemplo?

(...)

>> Son los primeros enlaces que he visto, supongo que habrá más empresas
>> con este tipo de soluciones.
>>
>> Por lo que leo se ve que se basan en esto:
>>
>> http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
>>
>> Recuerdo que en la RDSI se usaba algo similar en cuanto a concepto (se
>> sumaban los dos canales B de 64 Kbps para obtener "súper-velocidades"
>> de 128 Kbps). Es normal que estas cosas avancen, habrán desarrollado
>> alguna diablura para aprovechar los nuevos protocolos >:-)
>
> Esto era a través del mismo enlace físico...

Sí, claro, y del mismo ISP. El concepto es lo que es "parecido", vamos,
que como suele suceder no se han inventado nada sino que han adaptado lo
existente a los nuevos protocolos. Normal.

> ¿Seguro que un server en Internet va a mandar un cachito del fichero a
> cada una de las 2 IP Públicas distintas?.

Si te interesa esa tecnología, pregunta a las empresas que han
desarrollado esos productos a ver qué te dicen ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khso7t$183$2...@ger.gmane.org

[Camaleón]

El Thu, 14 Mar 2013 08:48:18 -0500, Kmilo Noa escribió:

Kmilo, has vuelto a secuestrar un hilo, abro uno nuevo.

> Hola lista, necesito saber los nombres de los paquetes que debo instalar
> para leer y escribir en particiones ntfs
>
> uso Debian Lenny

Para *leer* creo que nada ya que el módulo "ntfs" se instala de manera
predeterminada con el kernel.

Para *escribir* necesitarás la solución de Tuxera, que como te ha
comentado Manel se instala con el paquete "ntfs-3g".

Tienes más información sobre este sistema de archivos en la Wiki de
Debian:

http://wiki.debian.org/NTFS

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/khsoiq$183$3...@ger.gmane.org

[Manel Bazalo]

El 2013-03-14 15:58, Camaleón escribió:
> El Thu, 14 Mar 2013 08:48:18 -0500, Kmilo Noa escribió:
>
> Kmilo, has vuelto a secuestrar un hilo, abro uno nuevo.
>
>> Hola lista, necesito saber los nombres de los paquetes que debo
>> instalar
>> para leer y escribir en particiones ntfs
>>
>> uso Debian Lenny
>
> Para *leer* creo que nada ya que el módulo "ntfs" se instala de
> manera
> predeterminada con el kernel.
>
> Para *escribir* necesitarás la solución de Tuxera, que como te ha
> comentado Manel se instala con el paquete "ntfs-3g".
>
> Tienes más información sobre este sistema de archivos en la Wiki de
> Debian:
>
> http://wiki.debian.org/NTFS
>
> Saludos,
>
> --
> Camaleón

Hola,

Es recomendable este paquete para lectura y escritura, pero como bien
te ha explicado Camaleón, para leer no te haría falta.

Echa un vistazo

http://es.wikipedia.org/wiki/NTFS-3G

Saludos
/M

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/042e730a07410ae9...@tocolors.com

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]
Enviado el: jueves, 14 de marzo de 2013 15:53

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Thu, 14 Mar 2013 00:06:49 +0100, Ramses escribió:

> El 13/03/2013, a las 18:20, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Un ejemplo de ese hardware que permite bajarse un único fichero,
>>> desde un único PC a través de 2 ADSL's de 2 ISP's distintos, a una
>>> velocidad igual a la suma de ambas velocidades de descarga de las 2 ADSL's.
>>
>> Pues sí, claro... ¿buscando en Google por ejemplo?

(...)

>> Son los primeros enlaces que he visto, supongo que habrá más empresas
>> con este tipo de soluciones.
>>
>> Por lo que leo se ve que se basan en esto:
>>
>> http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
>>
>> Recuerdo que en la RDSI se usaba algo similar en cuanto a concepto
>> (se sumaban los dos canales B de 64 Kbps para obtener "súper-velocidades"
>> de 128 Kbps). Es normal que estas cosas avancen, habrán desarrollado
>> alguna diablura para aprovechar los nuevos protocolos >:-)
>
> Esto era a través del mismo enlace físico...

Sí, claro, y del mismo ISP. El concepto es lo que es "parecido", vamos, que como suele suceder no se han inventado nada sino que han adaptado lo existente a los nuevos protocolos. Normal.

* Estábamos hablando de operadores distintos, con ADSL's normales...

> ¿Seguro que un server en Internet va a mandar un cachito del fichero a
> cada una de las 2 IP Públicas distintas?.

Si te interesa esa tecnología, pregunta a las empresas que han desarrollado esos productos a ver qué te dicen ;-)

* Planteada la duda de la suma a los fabricantes. A ver si contestan...


Saludos,

Ramses

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/007601ce20d7$116fcc40$344f64c0$@gmail.com

[Camaleón]

El Thu, 14 Mar 2013 18:12:02 +0100, Ramses II escribió:

>> El 13/03/2013, a las 18:20, Camaleón <noel...@gmail.com> escribió:

(...)

>>>> Recuerdo que en la RDSI se usaba algo similar en cuanto a concepto
>>>> (se sumaban los dos canales B de 64 Kbps para obtener "súper
>>>> -velocidades" de 128 Kbps). Es normal que estas cosas avancen,
>>>> habrán desarrollado alguna diablura para aprovechar los nuevos
>>>> protocolos >:-)
>>
>>> Esto era a través del mismo enlace físico...
>>
>> Sí, claro, y del mismo ISP. El concepto es lo que es "parecido", vamos,
>> que como suele suceder no se han inventado nada sino que han adaptado
>> lo existente a los nuevos protocolos. Normal.
>
> * Estábamos hablando de operadores distintos, con ADSL's normales...

Bueno, ahora mismo no. Hablábamos sobre la opción que permitía la RDSI de
sumar los dos canales B para aumentar el ancho de banda.

>>> ¿Seguro que un server en Internet va a mandar un cachito del fichero a
>>> cada una de las 2 IP Públicas distintas?.
>>
>> Si te interesa esa tecnología, pregunta a las empresas que han
>> desarrollado esos productos a ver qué te dicen ;-)
>
> * Planteada la duda de la suma a los fabricantes. A ver si contestan...

Perfecto. Ya nos dirás con quién has contactado y qué te responden X-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kht22c$q15$1...@ger.gmane.org

[Ramses II]

Buenos días,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: jueves, 14 de marzo de 2013 18:40

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Thu, 14 Mar 2013 18:12:02 +0100, Ramses II escribió:

>> El 13/03/2013, a las 18:20, Camaleón <noel...@gmail.com> escribió:

(...)

>>>> Recuerdo que en la RDSI se usaba algo similar en cuanto a concepto
>>>> (se sumaban los dos canales B de 64 Kbps para obtener "súper
>>>> -velocidades" de 128 Kbps). Es normal que estas cosas avancen,
>>>> habrán desarrollado alguna diablura para aprovechar los nuevos
>>>> protocolos >:-)
>>
>>> Esto era a través del mismo enlace físico...
>>
>> Sí, claro, y del mismo ISP. El concepto es lo que es "parecido",
>> vamos, que como suele suceder no se han inventado nada sino que han
>> adaptado lo existente a los nuevos protocolos. Normal.
>
> * Estábamos hablando de operadores distintos, con ADSL's normales...

Bueno, ahora mismo no. Hablábamos sobre la opción que permitía la RDSI de sumar los dos canales B para aumentar el ancho de banda.

>>> ¿Seguro que un server en Internet va a mandar un cachito del fichero
>>> a cada una de las 2 IP Públicas distintas?.
>>
>> Si te interesa esa tecnología, pregunta a las empresas que han
>> desarrollado esos productos a ver qué te dicen ;-)
>
> * Planteada la duda de la suma a los fabricantes. A ver si contestan...

Perfecto. Ya nos dirás con quién has contactado y qué te responden X-)

-----------------------

Bien, pues respondieron los tres a los que pregunté, que son los enlaces que pusiste.

A los tres les pregunté por la misma situación que plantee aquí, la de si un único fichero se descargaría por los dos enlaces a la vez sumando así el ancho de banda de ambas ADSL's, y respondieron lo siguiente:

- Los de http://www.mushroomnetworks.com/:

---------------------------------------------------------------------------------------------------------------
Cahit Jay Akin <ha...@mushroomnetworks.com>

For those types of traffic to be bonded, you will need a peering node, either at a data center, or as a service from us (Broadband Bonding Service), as it is technically impossible with them for non-http traffic.

Please let me know if you need additional information or if you have any questions.

-jay
---------------------------------------------------------------------------------------------------------------

- Los de http://www.teloip.com/link-aggregation-hardware.php#ai-400:

---------------------------------------------------------------------------------------------------------------
Todd Davis <tda...@teloip.com>

The answer is the file will transfer at 40Mbps, ANA makes all the bandwidth from both links available. The links can be different type and speed, yet ANA can make them all perform as one pipe.

I see you are asking from Spain, and unfortunately we do not have the service available in Spain yet. The Ai400 device is only part of the required architecture. There is also a concentrator that works in the data center or Point of Presence. We will need to find a carrier partner in Spain to bring ANA service to your area.

Regards,

Todd
---------------------------------------------------------------------------------------------------------------

- Los de http://www.edge2wan.com/e2w/components/wanbonding.xrn:

---------------------------------------------------------------------------------------------------------------
French, Daren <dfr...@xroadsnetworks.com>

Any http traffic, the technology decides the best way to perform the download bonding.
---------------------------------------------------------------------------------------------------------------

Es decir, que todos coinciden en que solo bajo algunas condiciones muy particulares con http y que necesitarían "peering", vamos, la misma tecnología en las dos puntas, bien en el operador o en tu otra oficina, que no es pinchar un cacharro de esos y 2 ADSL's de distintos operadores y listos...

Que realmente lo que hacen es repartir el tráfico entre los enlaces WAN que se le conecten al "appliance", dando, desde el punto de vista de la LAN, que suman el Ancho de Banda, y que sí dan una mayor Tolerancia a Fallos.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/000c01ce23d6$8827db50$987791f0$@gmail.com

[Camaleón]

El Mon, 18 Mar 2013 13:45:48 +0100, Ramses II escribió:

(corrijo las citas)

>>>>> ¿Seguro que un server en Internet va a mandar un cachito del fichero
>>>>> a cada una de las 2 IP Públicas distintas?.
>>>>
>>>> Si te interesa esa tecnología, pregunta a las empresas que han
>>>> desarrollado esos productos a ver qué te dicen ;-)
>>>
>>> * Planteada la duda de la suma a los fabricantes. A ver si
>>> contestan...
>
>> Perfecto. Ya nos dirás con quién has contactado y qué te responden X-)
> -----------------------
>
> Bien, pues respondieron los tres a los que pregunté, que son los enlaces
> que pusiste.
>
> A los tres les pregunté por la misma situación que plantee aquí, la de
> si un único fichero se descargaría por los dos enlaces a la vez sumando
> así el ancho de banda de ambas ADSL's, y respondieron lo siguiente:
>
> - Los de http://www.mushroomnetworks.com/:
>

(quito el nombre/correo)

> For those types of traffic to be bonded, you will need a peering node,
> either at a data center, or as a service from us (Broadband Bonding
> Service), as it is technically impossible with them for non-http
> traffic.
>
> Please let me know if you need additional information or if you have any
> questions.
>
> -jay

Sería interesante que también enviaras la pregunta que les hiciste tal
cual, porque leyendo esta respuesta me faltan algunos datos, por ejemplo,
habla de "un tipo de tráfico" que aparentemente "no es http" ¿a qué se
refiere?

> - Los de http://www.teloip.com/link-aggregation-hardware.php#ai-400:
>

(quito el nombre/correo)

> The answer is the file will transfer at 40Mbps, ANA makes all the
> bandwidth from both links available. The links can be different type
> and speed, yet ANA can make them all perform as one pipe.

Ah, eso está muy bien.

> I see you are asking from Spain, and unfortunately we do not have the
> service available in Spain yet. The Ai400 device is only part of the
> required architecture. There is also a concentrator that works in the
> data center or Point of Presence. We will need to find a carrier
> partner in Spain to bring ANA service to your area.
>
> Regards,
>
> Todd

Este fabricante dice que hace falta un concentrador en las instalaciones
del ISP (entiendo) además de necesitar colaboración por su parte y que en
España no tienen ningún acuerdo con socios españoles, por lo que este
dispositivo quedaría descartado (la idea es unir el ancho de banda de dos
conexiones de banda ancha a través de un dispositivo autónomo).

> - Los de http://www.edge2wan.com/e2w/components/wanbonding.xrn:
>

(quito el nombre/correo)

> Any http traffic, the technology decides the best way to perform the
> download bonding.

Aquí también me faltan datos... ¿sólo te ha respondido eso? :-?

> Es decir, que todos coinciden en que solo bajo algunas condiciones muy
> particulares con http y que necesitarían "peering", vamos, la misma
> tecnología en las dos puntas, bien en el operador o en tu otra oficina,
> que no es pinchar un cacharro de esos y 2 ADSL's de distintos operadores
> y listos...

El dispositivo de Teoip sí necesitaría colaboración del carrier (al menos
es lo que se desprende de la respuesta) pero de los otros dos no me queda
claro tras haber leído esas respuestas que has enviado.

> Que realmente lo que hacen es repartir el tráfico entre los enlaces WAN
> que se le conecten al "appliance", dando, desde el punto de vista de la
> LAN, que suman el Ancho de Banda, y que sí dan una mayor Tolerancia a
> Fallos.

Eso te lo has sacado de la manga ya que no lo dicen por ningún lado (ni
si quiera el aparatejo de Teloip) ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ki78cs$noi$3...@ger.gmane.org

[Ramses II]

Buenas tardes,

Perdón por no haber quitado los nombres...

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: lunes, 18 de marzo de 2013 15:30

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Mon, 18 Mar 2013 13:45:48 +0100, Ramses II escribió:

(corrijo las citas)

>>>>> ¿Seguro que un server en Internet va a mandar un cachito del
>>>>> fichero a cada una de las 2 IP Públicas distintas?.
>>>>
>>>> Si te interesa esa tecnología, pregunta a las empresas que han
>>>> desarrollado esos productos a ver qué te dicen ;-)
>>>
>>> * Planteada la duda de la suma a los fabricantes. A ver si
>>> contestan...
>
>> Perfecto. Ya nos dirás con quién has contactado y qué te responden
>> X-)
> -----------------------
>
> Bien, pues respondieron los tres a los que pregunté, que son los
> enlaces que pusiste.
>
> A los tres les pregunté por la misma situación que plantee aquí, la de
> si un único fichero se descargaría por los dos enlaces a la vez
> sumando así el ancho de banda de ambas ADSL's, y respondieron lo siguiente:
>

- ¡Ay, Camaleón!, esta es la pregunta que les planteé a los 3, evidentemente, a cada uno con su producto:

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Dear gentlemen,

I want to raise you a technical doubt that I have with your XXXXXX product. I explain you one situation.

For example, I have:

- Two ADSL links of different ISPs that both are connected to Internet. Those ADSL links have 20Mbps of downloads band width. Both links are connected to a XXXXXX device.

- One PC in the LAN.

- One file with a size of 100Mb allocated in a server in Internet.

The doubt is:

If I download this file from the PC It will be downloaded with a bandwidth of 40Mbps or at a bandwidth of 20Mbps?

In other words, the traffic of the download is directed (balanced) by one of the two links (20Mbps) or it's directed by the two links (20Mbps+20Mbps = 40Mbps).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>
> - Los de http://www.mushroomnetworks.com/:
>

(quito el nombre/correo)

> For those types of traffic to be bonded, you will need a peering node,
> either at a data center, or as a service from us (Broadband Bonding
> Service), as it is technically impossible with them for non-http
> traffic.
>
> Please let me know if you need additional information or if you have
> any questions.
>
> -jay

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

For those types of traffic to be bonded, you will need a peering node, either at a data center, or as a service from us (Broadband Bonding Service), as it is technically impossible with them for non-http traffic.

Please let me know if you need additional information or if you have any questions.

-jay

Cahit, very thanks by your answer.

Let me another question, please: Why only with http downloads and not with ftp or another traffics?


Best regards,

Ramses

De: Cahit
Enviado el: jueves, 14 de marzo de 2013 17:46
Para: Ramses
Asunto: Re: Technical doubt about Truffle device (Broadband Bonding Network Appliance).

Hello Ramses,

Short answer is 40Mbps for http downloads.

Our devices have 2 operational modes.

1) Standalone mode: In this mode, our Truffle appliances will bond all http downlink traffic. As an example if you were to download a file behind the Truffle device which has 4 ADSL lines plugged in with 6Mbps speed each. Your download speed would be around 24Mbps even for that single file download. For all other traffic, our device will implement the "intelligent load-balancing" where the Truffle device will distribute the different Internet sessions, on various WAN links on a session by session basis. Truffle will keep the application semantics in tact, by making sure the sessions from certain applications are kept on the same WAN line, such as banking sites, where a blind load-balancing would break the application.

2) Peered mode: When Truffle is peered with another Truffle device with a VLL server license over the Internet (let's say a branch office and a headquarter office), the two units create a virtual leased line connection between them over the bonded pipe. In this mode downlink and uplink is bonded for all types of Internet traffic.

Peered mode can also be achieved by our monthly subscription service: Broadband Bonding Service (BBS). BBS is optional and let's the customer Truffle device peer with one of our data centers to enable bonding for all protocols. As I mentioned, BBS is an optional add-on service.

I am attaching the brochure for Truffle and Truffle Lite. In case your project involves more than one office, here is a link for a white-paper about our usual ISP and multi-office installations.

We have a remote online demo through a gotomeeting session, where we showcase a real Truffle unit in action and fly through some of the features within 15 minutes. As a next step, would you like to schedule that?

Warmest regards,

-jay
--

On Thu, Mar 14, 2013 at 9:41 AM, Ramses wrote:
Dear gentlemen,

I want to raise you a technical doubt that I have with your Truffle product. I explain you one situation.

For example, I have:

- Two ADSL links of different ISPs that both are connected to Internet. Those ADSL links have 20Mbps of downloads band width. Both links are connected to a Truffle device.

- One PC in the LAN.

- One file with a size of 100Mb allocated in a server in Internet.

The doubt is:

If I download this file from the PC It will be downloaded with a bandwidth of 40Mbps or at a bandwidth of 20Mbps?

In other words, the traffic of the download is directed (balanced) by one of the two links (20Mbps) or it's directed by the two links (20Mbps+20Mbps = 40Mbps).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

> Sería interesante que también enviaras la pregunta que les hiciste tal cual, porque leyendo esta respuesta me faltan algunos datos, por ejemplo, habla de "un tipo de tráfico" que aparentemente "no es http" ¿a qué se refiere?

> - Los de http://www.teloip.com/link-aggregation-hardware.php#ai-400:
>

(quito el nombre/correo)

> The answer is the file will transfer at 40Mbps, ANA makes all the
> bandwidth from both links available. The links can be different type
> and speed, yet ANA can make them all perform as one pipe.

Ah, eso está muy bien.

> I see you are asking from Spain, and unfortunately we do not have the
> service available in Spain yet. The Ai400 device is only part of the
> required architecture. There is also a concentrator that works in the
> data center or Point of Presence. We will need to find a carrier
> partner in Spain to bring ANA service to your area.
>
> Regards,
>
> Todd

Este fabricante dice que hace falta un concentrador en las instalaciones del ISP (entiendo) además de necesitar colaboración por su parte y que en España no tienen ningún acuerdo con socios españoles, por lo que este dispositivo quedaría descartado (la idea es unir el ancho de banda de dos conexiones de banda ancha a través de un dispositivo autónomo).

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Como este te ha quedado claro, no te pongo el correo completo. Si lo quieres, también te lo pongo...
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

> - Los de http://www.edge2wan.com/e2w/components/wanbonding.xrn:
>

(quito el nombre/correo)

> Any http traffic, the technology decides the best way to perform the
> download bonding.

Aquí también me faltan datos... ¿sólo te ha respondido eso? :-?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Any http traffic, the technology decides the best way to perform the download bonding.

From: Ramses
Sent: Thursday, March 14, 2013 1:40 PM
To: Daren
Subject: RE: Technical doubt about Edge2WAN device.

Daren, very thanks by your answer.

You want tell me that if I only put a LINKaXcel appliance and I connect it two ADSL links of 20Mbps, I can to download from Internet, for example, via ftp, a file of 100Mb of size at a bandwidth of 40Mbps (20Mbps+20Mbps)?

Who decide what part of the file need go across a link and what part to the other link?


Best regards,

Ramsés

De: Daren
Enviado el: jueves, 14 de marzo de 2013 18:39
Para: Ramses
Asunto: RE: Technical doubt about Edge2WAN device.

Ramses,

With the proper appliance, yes you can download at 40Mbps based on your question.

Our link bonding, actually bonds the links together for faster download throughput, we have unique technology that does this.

It would require our LINKaXcel appliance to accomplish this task, see the attached.

Daren


From: Ramses
Sent: Thursday, March 14, 2013 10:07 AM
To: Sales
Cc: Support
Subject: Technical doubt about Edge2WAN device.

Dear gentlemen,

I want to raise you a technical doubt that I have with your Edge2WAN product. I explain you one situation.

For example, I have:

- Two ADSL links of different ISPs that both are connected to Internet. Those ADSL links have 20Mbps of downloads band width. Both links are connected to a Edge2WAN device.

- One PC in the LAN.

- One file with a size of 100Mb allocated in a server in Internet.

The doubt is:

If I download this file from the PC It will be downloaded with a bandwidth of 40Mbps or at a bandwidth of 20Mbps?

In other words, the traffic of the download is directed (balanced) by one of the two links (20Mbps) or it's directed by the two links (20Mbps+20Mbps = 40Mbps).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

- Como ves, ellos te dicen al principio que sí, que a 40Mbps, pero si los obligas a ceñirse a la situación planteada, que es si realmente se suman o no, es decir, si desde un único punto (PC) puedes utilizar todo el Ancho de Banda para descargar un único fichero (que sería la situación real de que se suman los Anchos de Banda), ya empiezan a salir "peros" y situaciones concretas en las que únicamente se podría. Y si sigues apretando, pues aparecerá la situación única en que lo pueden conseguir...

- Vamos, este último, hasta dice al principio que su tecnología es la única que lo hace. Después le afinas, y ya es que solo lo hacen con http...

> Es decir, que todos coinciden en que solo bajo algunas condiciones muy
> particulares con http y que necesitarían "peering", vamos, la misma
> tecnología en las dos puntas, bien en el operador o en tu otra
> oficina, que no es pinchar un cacharro de esos y 2 ADSL's de distintos
> operadores y listos...

El dispositivo de Teoip sí necesitaría colaboración del carrier (al menos es lo que se desprende de la respuesta) pero de los otros dos no me queda claro tras haber leído esas respuestas que has enviado.

- Todos necesitarían montar algo en el Carrier, si es para acceso a Internet, o si es Peer to Peer, montarlo en la oficina remota.

> Que realmente lo que hacen es repartir el tráfico entre los enlaces
> WAN que se le conecten al "appliance", dando, desde el punto de vista
> de la LAN, que suman el Ancho de Banda, y que sí dan una mayor
> Tolerancia a Fallos.

Eso te lo has sacado de la manga ya que no lo dicen por ningún lado (ni si quiera el aparatejo de Teloip) ;-)

- Que va, de la manga no, si hasta lo dicen ellos cuando les dices que no se vayan por los "Cerros de Úbeda", que ciñan la respuesta a la pregunta. Y es cuando ellos te dicen:

"For all other traffic, our device will implement the "intelligent load-balancing" where the Truffle device will distribute the different Internet sessions, on various WAN links on a session by session basis."

En definitiva, y que no me lo saco de la manga, que si hacen Load Balancing, si se les cae una de las WAN, siguen mandando el tráfico por el resto de los enlaces WAN que tenga conectado el dispositivo, por lo que aumentan la Tolerancia a Fallos.

¿Sabes por qué podías sumar los canales de una RDSI (64+64 = 128Kbps?. Porque era el mismo enlace físico y lo controlaba el proveedor también en el otro extremo...

Lo que estamos comentando aquí sería como una RDSI de cada Operador, por ejemplo 2 RDSI, y sumar los 4 canales para tener 256Kbps. ¿Piensas que se podría...?

Esta es una solución fantástica para "sumar" el Ancho de Banda de varias ADSL's / Enlaces WAN.

http://bourneagainshell.blogspot.com.es/2008/05/de-como-conectar-13-adsls-en-balanceo.html

OJO, no la he probado, pero hay gente que dice que va bien...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/!&!AAAAAAAAAAAYAAAAAAAAAENFkb7HiHhNgxBWRjH4G...@gmail.com

[Camaleón]

El Mon, 18 Mar 2013 17:36:50 +0100, Ramses II escribió:

> Buenas tardes,
>
> Perdón por no haber quitado los nombres...

Personalmente no me gusta mandar a una lista pública contenido que parte
de una conversación que se supone es privada, salvo en honrosas
excepciones. Nunca se sabe O:-)

(...)

> - ¡Ay, Camaleón!, esta es la pregunta que les planteé a los 3,
> evidentemente, a cada uno con su producto:

(...)

Leídos.

Gracias por enviarlo, ya me parecía a mí que faltaban datos, pillín >:-)

Y no me había fijado que al menos en el primero de los casos (el de la
empresa Mushroom Networks) tienen una FAQ muy completa. Por ejemplo, en
el caso del dispositivo de gama baja (Truffle Lite):

***
https://www.mushroomnetworks.com/product/products.aspx?product_id=1002&tab=faqs

Let's say I have 4 DSL lines with 6Mbps downlink speed each, after I
install Internet load balancer, Truffle Lite, how fast will I be able to
download files?

Truffle Lite will aggregate all the 4 DSL lines that are connected to the
WAN ports and file downloads will be around 4 x 6 = 24 Mbps. Truffle Lite
can provide aggregate throughputs of up to 95Mbps.
***

Responden a tu pregunta ;-)

Pero qué quieres te diga, lo aclaran perfectamente en el correo que te
mandan: muy completo y de agradecer por su parte, denota profesionalidad.

> - Como ves, ellos te dicen al principio que sí, que a 40Mbps, pero si
> los obligas a ceñirse a la situación planteada, que es si realmente se
> suman o no, es decir, si desde un único punto (PC) puedes utilizar todo
> el Ancho de Banda para descargar un único fichero (que sería la
> situación real de que se suman los Anchos de Banda), ya empiezan a salir
> "peros" y situaciones concretas en las que únicamente se podría. Y si
> sigues apretando, pues aparecerá la situación única en que lo pueden
> conseguir...

(...)

Lo siento, no cuela... te lo dicen muy claramente: que sí lo permiten. Y que
si quieres "afinar" más pues que contrates servicios adicionales, normal.

También de su FAQ:

***
Do I need the "Broadband Bonding Service" subscription with my Truffle Lite
device?

No. All Truffle devices will provide http downlink bonding and intelligent
load-balancing for uplink and non-http traffic without requiring the monthly
Broadband Bonding Service. Broadband Bonding Service will however provide
additional bonding capability enabling bonding for all protocols in uplink
and downlink.
***

> - Todos necesitarían montar algo en el Carrier, si es para acceso a
> Internet, o si es Peer to Peer, montarlo en la oficina remota.

Qué va, y gracias por preguntarles, ahora me queda mucho más claro y me gusta
ver que ya hay varias soluciones en el mercado que lo permiten.

(...)

> En definitiva, y que no me lo saco de la manga, que si hacen Load
> Balancing, si se les cae una de las WAN, siguen mandando el tráfico por
> el resto de los enlaces WAN que tenga conectado el dispositivo, por lo
> que aumentan la Tolerancia a Fallos.

(...)

No hablamos de eso sino de "sumar" anchos de banda para aumentar la velocidad
de las descargas algo que ya es posible ;-)

También hay un artículo (generalista) en Wikipedia:

***
Broadband bonding
http://en.wikipedia.org/wiki/Broadband_bonding

Broadband bonding is a type of channel bonding that refers to aggregation of
multiple channels at OSI layers at level four or above. Channels bonded can be
wired links such as a T-1 or DSL line. Additionally, it is possible to bond
multiple cellular links for an aggregated wireless bonded link.

Previous bonding methodologies resided at lower OSI layers, requiring
coordination with telecommunications companies for implementation. Broadband
bonding, because it is implemented at higher layers, can be done without this
coordination.
***

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ki7hdm$noi$1...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: lunes, 18 de marzo de 2013 18:04

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Mon, 18 Mar 2013 17:36:50 +0100, Ramses II escribió:

> Buenas tardes,
>
> Perdón por no haber quitado los nombres...

Personalmente no me gusta mandar a una lista pública contenido que parte de una conversación que se supone es privada, salvo en honrosas excepciones. Nunca se sabe O:-)

(...)

> - ¡Ay, Camaleón!, esta es la pregunta que les planteé a los 3,
> evidentemente, a cada uno con su producto:

(...)

Leídos.

Gracias por enviarlo, ya me parecía a mí que faltaban datos, pillín >:-)

Camaleón, no he omitido ningún dato en lo referente a mi planteamiento inicial. No es posible sumar el ancho de banda sin controlar ambas puntas, hasta ellos te lo dicen, pero bueno, esto ya es una conversación absurda...

Y no me había fijado que al menos en el primero de los casos (el de la empresa Mushroom Networks) tienen una FAQ muy completa. Por ejemplo, en el caso del dispositivo de gama baja (Truffle Lite):

***
https://www.mushroomnetworks.com/product/products.aspx?product_id=1002&tab=faqs

Let's say I have 4 DSL lines with 6Mbps downlink speed each, after I install Internet load balancer, Truffle Lite, how fast will I be able to download files?

Truffle Lite will aggregate all the 4 DSL lines that are connected to the WAN ports and file downloads will be around 4 x 6 = 24 Mbps. Truffle Lite can provide aggregate throughputs of up to 95Mbps.
***

Responden a tu pregunta ;-)

Ala, Camaleón, cuando te encierras, no hay quien te haga "bajarte del burro".

Pues como veo que te crees todo lo que te cuentan, desde el punto de vista comercial, porque si les planteas una situación clara, comienzan a salir los "peros", píllate uno de esos cacharros, le pinchas 2 enlaces, de operadores distintos, y te conectas a Internet, te pillas un Cliente FTP y te descargas un fichero de 100Mb. Haces una captura de la tasa de transferencia y la guardas. Después haces la misma operación con un solo enlace. A ver cual es la diferencia... Dicen que los dejan en demo...

Sí, sí, las FAQ's lo dicen muy claro, correo y plantéales la situación, como he hecho yo, desde un único punto, tanto origen como destino, un Peer-to-Peer, y que te juren por Petete que suman el Ancho de Banda de todos los enlaces que le pongas al cacharro sin controlar las dos puntas.

Pero qué quieres te diga, lo aclaran perfectamente en el correo que te
mandan: muy completo y de agradecer por su parte, denota profesionalidad.

> - Como ves, ellos te dicen al principio que sí, que a 40Mbps, pero si
> los obligas a ceñirse a la situación planteada, que es si realmente se
> suman o no, es decir, si desde un único punto (PC) puedes utilizar
> todo el Ancho de Banda para descargar un único fichero (que sería la
> situación real de que se suman los Anchos de Banda), ya empiezan a
> salir "peros" y situaciones concretas en las que únicamente se podría.
> Y si sigues apretando, pues aparecerá la situación única en que lo
> pueden conseguir...

(...)

Lo siento, no cuela... te lo dicen muy claramente: que sí lo permiten. Y que si quieres "afinar" más pues que contrates servicios adicionales, normal.

También de su FAQ:

***
Do I need the "Broadband Bonding Service" subscription with my Truffle Lite device?

No. All Truffle devices will provide http downlink bonding and intelligent load-balancing for uplink and non-http traffic without requiring the monthly Broadband Bonding Service. Broadband Bonding Service will however provide additional bonding capability enabling bonding for all protocols in uplink and downlink.
***

Que te están diciendo que solo lo hacen con HTTP, que no es real la suma del Ancho de Banda " provide http downlink bonding and intelligent load-balancing for uplink and non-http traffic", que con el resto hacen load-balancing, que eso no es sumar desde el punto de vista Peer-to-Peer, aunque sí desde el punto de vista de una LAN, que son muchas las conexiones que se realizan...

> - Todos necesitarían montar algo en el Carrier, si es para acceso a
> Internet, o si es Peer to Peer, montarlo en la oficina remota.

Qué va, y gracias por preguntarles, ahora me queda mucho más claro y me gusta ver que ya hay varias soluciones en el mercado que lo permiten.

Ala, pues a hacer las pruebas y después nos cuentas los resultados de las tasas de transferencia con uno y varios enlaces en uno de esos cacharros, en una descarga Peer-to-Peer con un FTP.

(...)

> En definitiva, y que no me lo saco de la manga, que si hacen Load
> Balancing, si se les cae una de las WAN, siguen mandando el tráfico
> por el resto de los enlaces WAN que tenga conectado el dispositivo,
> por lo que aumentan la Tolerancia a Fallos.

(...)

No hablamos de eso sino de "sumar" anchos de banda para aumentar la velocidad de las descargas algo que ya es posible ;-)

También hay un artículo (generalista) en Wikipedia:

***
Broadband bonding
http://en.wikipedia.org/wiki/Broadband_bonding

Broadband bonding is a type of channel bonding that refers to aggregation of multiple channels at OSI layers at level four or above. Channels bonded can be wired links such as a T-1 or DSL line. Additionally, it is possible to bond multiple cellular links for an aggregated wireless bonded link.

Previous bonding methodologies resided at lower OSI layers, requiring coordination with telecommunications companies for implementation. Broadband bonding, because it is implemented at higher layers, can be done without this coordination.
***

Ala, pues a hacer las pruebas sin tener en el otro extremo otro equipo para realizar el "Broadband bounding". Nos cuentas los resultados. Siempre desde el punto de vista planteado, nada desde el punto de vista de una LAN.

Me gustaría que asomaran por aquí algunos de la lista, de los que se dedican a comunicaciones a lo bestia, que me consta que los hay, y apoye la postura de que, sin hacer peering, bien en el operador, bien en el destino remoto, el Ancho de Banda de 2 o más enlaces WAN de Operadores distintos pueden ser sumados desde el punto de vista aquí planteado, una descarga Peer-to-Peer de un fichero en cualquier protocolo posible...


P.D.: Sorry, en el anterior correo se me pasó quitar la confirmación de lectura...

Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/002d01ce2401$5aba0230$102e0690$@gmail.com

[Camaleón]

El Mon, 18 Mar 2013 18:52:25 +0100, Ramses II escribió:

> Buenas tardes,

(no sé qué le pasa a tu cliente de correo pero rompe las citas :-?)

>> Gracias por enviarlo, ya me parecía a mí que faltaban datos, pillín
>> >:-)
>
> Camaleón, no he omitido ningún dato en lo referente a mi planteamiento
> inicial.

Es que la parte de las respuestas que has recibido y que has enviado en
primer lugar quedaban un poco "cojas".

> No es posible sumar el ancho de banda sin controlar ambas puntas, hasta
> ellos te lo dicen, pero bueno, esto ya es una conversación absurda...

Pues chico, te lo están diciendo ellos, si no les quieres creer es cosa
tuya.

> Y no me había fijado que al menos en el primero de los casos (el de la
> empresa Mushroom Networks) tienen una FAQ muy completa. Por ejemplo, en
> el caso del dispositivo de gama baja (Truffle Lite):
>

> https://www.mushroomnetworks.com/product/products.aspx?product_id=1002&tab=faqs

(...)

> Responden a tu pregunta ;-)
>
> Ala, Camaleón, cuando te encierras, no hay quien te haga "bajarte del
> burro".

No tengo ningún interés especial en este asunto, la verdad, pero es lo
que hay. Si aún así sigues pensando que estos productos son meros
"balanceadores de carga" pues nada, tú mismo. Personalmente me ha quedado
claro lo que permiten y para qué sirven.

> Pues como veo que te crees todo lo que te cuentan, desde el punto de
> vista comercial, porque si les planteas una situación clara, comienzan a
> salir los "peros", píllate uno de esos cacharros, le pinchas 2 enlaces,
> de operadores distintos, y te conectas a Internet, te pillas un Cliente
> FTP y te descargas un fichero de 100Mb. Haces una captura de la tasa de
> transferencia y la guardas. Después haces la misma operación con un solo
> enlace. A ver cual es la diferencia... Dicen que los dejan en demo...

(...)

Pues si necesitas esa funcionalidad te suscribes a su servicio de ancho
de banda "total" por una módica cantidad ;-) pero para las descargas
convencionales cumple su función.

Y sinceramente, no se me ocurriría unir dos enlaces de FTTH de 100 Mbps,
no creo que se obtenga mucho beneficio. Este tipo de "agregadores" pueden
mostrar su utilidad cuando se tienen enlaces de baja velocidad, entonces
sí se puede percibir una mejora al descargar archivos o en la navegación
convencional.

Como ves, yo también puedo ponerle "peros" en ciertas condiciones (para
tiquismiquis, yo :-P) pero eso no significa que ese producto haga
exactamente lo que dice que hace: sumar el ancho de banda de dos enlaces
ADSL para aumentar la velocidad.

>> Lo siento, no cuela... te lo dicen muy claramente: que sí lo permiten.
>> Y que si quieres "afinar" más pues que contrates servicios adicionales,
>> normal.
>>
>> También de su FAQ:
>>
>> ***
>> Do I need the "Broadband Bonding Service" subscription with my Truffle
>> Lite device?
>>
>> No. All Truffle devices will provide http downlink bonding and
>> intelligent load-balancing for uplink and non-http traffic without
>> requiring the monthly Broadband Bonding Service. Broadband Bonding
>> Service will however provide additional bonding capability enabling
>> bonding for all protocols in uplink and downlink. ***
>>
>> Que te están diciendo que solo lo hacen con HTTP,

Suficiente. Representa el 95% del tráfico en gran parte de las empresas y
no te digo en un entorno casero. Si quieres más, a pasar por caja :-)

> que no es real la suma del Ancho de Banda " provide http downlink
> bonding and intelligent load-balancing for uplink and non-http
> traffic", que con el resto hacen load-balancing, que eso no es sumar
> desde el punto de vista Peer-to-Peer, aunque sí desde el punto de vista
> de una LAN, que son muchas las conexiones que se realizan...

Real o virtual, ellos sabrán. Si aumenta la velocidad porque hace uso de
la capacidad del ancho de banda de los dos enlaces, perfecto.

>> Qué va, y gracias por preguntarles, ahora me queda mucho más claro y me
>> gusta ver que ya hay varias soluciones en el mercado que lo permiten.
>
> Ala, pues a hacer las pruebas y después nos cuentas los resultados de
> las tasas de transferencia con uno y varios enlaces en uno de esos
> cacharros, en una descarga Peer-to-Peer con un FTP.

Si lo necesito ya lo pagaré ;-)

> También hay un artículo (generalista) en Wikipedia:
>
> ***
> Broadband bonding
> http://en.wikipedia.org/wiki/Broadband_bonding

(...)

> Ala, pues a hacer las pruebas sin tener en el otro extremo otro equipo
> para realizar el "Broadband bounding". Nos cuentas los resultados.
> Siempre desde el punto de vista planteado, nada desde el punto de vista
> de una LAN.

No te preocupes que ya irán sacando más soluciones en el mercado e irán
añadiendo funcionalidades. Cuestión de tiempo, ya verás.

No siempre se puede optar por conexiones de banda ancha de alta velocidad
(fibra, vdsl...) y cuando sólo tienes un ADSL de "hasta" 20 Mpbs este
tipos de cacharros te pueden servir.

> Me gustaría que asomaran por aquí algunos de la lista, de los que se
> dedican a comunicaciones a lo bestia, que me consta que los hay, y apoye
> la postura de que, sin hacer peering, bien en el operador, bien en el
> destino remoto, el Ancho de Banda de 2 o más enlaces WAN de Operadores
> distintos pueden ser sumados desde el punto de vista aquí planteado, una
> descarga Peer-to-Peer de un fichero en cualquier protocolo posible...

Pero si el bonding lo llevan haciendo los ISP internamente desde hace
años... ¿no te parece lo más normal del mundo que ahora esté al alcance
de todos?

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ki7lpo$noi$1...@ger.gmane.org

[Ramses II]

Buenas tardes,

- Yo no he dicho que sean meros balanceadores de carga, de hecho, si en el Operador o en el otro extremo pones otro, pues sumas el Ancho de Banda. Ahí no he discutido yo nada.

- No estamos discutiendo si el 95% del tráfico sea HTTP o no, sino si el concepto "SUMAR" el Ancho de Banda de enlaces de distinto proveedores es real, o está bien usado.

- Tú lo estás viendo desde el punto de vista de la LAN, y yo estoy hablando desde punto de vista de un PC en la LAN y una única tarea, que es como sería realmente que suma los Anchos de Banda.

Si esto solo es un tema de conceptos y de interpretaciones... El Ancho de Banda total del que dispone una LAN para descargas/moverse por Internet, y el Ancho de Banda máximo del que dispone un único PC de esa LAN para descargarse un único fichero desde Internet con cualquier protocolo, no solo HTTP, sino también FTP o cualquier otro...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/003f01ce2408$66b74c30$3425e490$@gmail.com

[Camaleón]

El Mon, 18 Mar 2013 19:42:52 +0100, Ramses II escribió:

> Buenas tardes,

Buenas noches.

> - Yo no he dicho que sean meros balanceadores de carga, de hecho, si en
> el Operador o en el otro extremo pones otro, pues sumas el Ancho de
> Banda. Ahí no he discutido yo nada.
>
> - No estamos discutiendo si el 95% del tráfico sea HTTP o no, sino si el
> concepto "SUMAR" el Ancho de Banda de enlaces de distinto proveedores es
> real, o está bien usado.

Pues eso es precisamente lo que permite ese dispositivo.

Ahora bien, ¿que _a ti_ no te sirve porque en tu caso (personal y
particular) usas exclusivamente conexiones a servidores ftp y no vas a
utilizar la funcionalidad que ofrece el aparato porque no utilizas apenas
tráfico http? Perfecto, no te estoy diciendo que este aparato sea el
"Santo Grial" de las soluciones de "agregración" de ancho de banda y que
sea útil para todos los casos. No, ni mucho menos.

Como te he dicho antes yo no lo compraría para unir el ancho de banda de
dos módems de fibra óptica porque:

a) Sé qué no voy a obtener un canal efectivo (ya sea virtual, real o
imaginario) de 200 Mpbs de descarga y,

b) Aún en el hipotético caso de que lo consiguiera no lo voy a aprovechar
porque ahora mismo tenemos los enlaces de fibra óptica completamente
desaprovechados ya que los servidores (servicios) usuales a los que se
conectan los usuarios en la oficina NO permiten sacar el máximo partido a
la velocidad que ofrece la fibra (sólo he conseguido descargas a 10 MiB/s
"netos" cuando me conecto a los servidores de Oracle para descargar
VirtualBox que tarda -reloj en mano- 8 segundos en bajar los 80 MiB de la
aplicación), así que no voy a ganar nada duplicando el ancho de banda.

¿Cuándo compraría ese cacharro, cuándo lo vería útil? Pues mira, si
tuviera dos líneas ADSL sobre RDSI que sólo permiten conexiones de
3000/300 kbps, y siempre y cuando no tuviera un precio desorbitado. ¿Por
qué? Pues porque añadido al aumento del ancho de banda que se pueda ganar
en las descargas http (las convencionales) que no vendría nada mal en
este caso concreto dado en "escaso caudal" disponible, se le añade la
posibilidad del failover (muy interesante) y el balanceo de carga, es
decir, tendría características de valor añadido que sí podrían justificar
la compra de ese dispositivo.

Es decir, el aparato hace lo que hace y sirve para lo que sirve. Punto.
Cosa distinta es que le sea útil a todo el mundo, en todos los casos y en
todas las circunstancias.

> - Tú lo estás viendo desde el punto de vista de la LAN, y yo estoy
> hablando desde punto de vista de un PC en la LAN y una única tarea, que
> es como sería realmente que suma los Anchos de Banda.

Yo veo sencillamente lo que permite, nada más.

> Si esto solo es un tema de conceptos y de interpretaciones... El Ancho
> de Banda total del que dispone una LAN para descargas/moverse por
> Internet, y el Ancho de Banda máximo del que dispone un único PC de esa
> LAN para descargarse un único fichero desde Internet con cualquier
> protocolo, no solo HTTP, sino también FTP o cualquier otro...

No sé... a mí me parece que tiene un mercado bien definido y que puede
ser de utilidad para algunos usuarios pero obviamente no para todos ni
para todo.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ki7uu7$noi$1...@ger.gmane.org

[Ramses]

Buenas noches,

Pues eso, lo que te comentaba, que a mi no es que me valgan o me dejen de valer, sólo es un tema de conceptos y desde el punto de vista desde el que se interpreten...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CD142A8D-E79C-4956...@gmail.com

[Camaleón]

El Mon, 18 Mar 2013 23:30:36 +0100, Ramses escribió:

> El 18/03/2013, a las 21:54, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Si esto solo es un tema de conceptos y de interpretaciones... El Ancho
>>> de Banda total del que dispone una LAN para descargas/moverse por
>>> Internet, y el Ancho de Banda máximo del que dispone un único PC de
>>> esa LAN para descargarse un único fichero desde Internet con cualquier
>>> protocolo, no solo HTTP, sino también FTP o cualquier otro...
>>
>> No sé... a mí me parece que tiene un mercado bien definido y que puede
>> ser de utilidad para algunos usuarios pero obviamente no para todos ni
>> para todo.
>
> Pues eso, lo que te comentaba, que a mi no es que me valgan o me dejen
> de valer, sólo es un tema de conceptos y desde el punto de vista desde
> el que se interpreten...

No sé cómo lo interpretarás pero a mí me parece que está bastante claro
lo que permite el dispositivo que no es ni más ni menos lo que preguntaba
el OP unos 150 correos más arriba.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ki9td6$m9s$1...@ger.gmane.org

[Ramses]

Buenas tardes,

El 19/03/2013, a las 15:40, Camaleón <noel...@gmail.com> escribió:

> El Mon, 18 Mar 2013 23:30:36 +0100, Ramses escribió:
>
>> El 18/03/2013, a las 21:54, Camaleón <noel...@gmail.com> escribió:
>
> (...)
>
>>>> Si esto solo es un tema de conceptos y de interpretaciones... El Ancho
>>>> de Banda total del que dispone una LAN para descargas/moverse por
>>>> Internet, y el Ancho de Banda máximo del que dispone un único PC de
>>>> esa LAN para descargarse un único fichero desde Internet con cualquier
>>>> protocolo, no solo HTTP, sino también FTP o cualquier otro...
>>>
>>> No sé... a mí me parece que tiene un mercado bien definido y que puede
>>> ser de utilidad para algunos usuarios pero obviamente no para todos ni
>>> para todo.
>>
>> Pues eso, lo que te comentaba, que a mi no es que me valgan o me dejen
>> de valer, sólo es un tema de conceptos y desde el punto de vista desde
>> el que se interpreten...
>
> No sé cómo lo interpretarás pero a mí me parece que está bastante claro
> lo que permite el dispositivo que no es ni más ni menos lo que preguntaba
> el OP unos 150 correos más arriba.

Sí, sí, eso, eso, es tal como tú dices, tal y como lo estás interpretando tú...

Es que como soy nuevo en esto de las comunicaciones, me he liado y se me había ido la olla...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/843D989F-5CD6-4507...@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 16:07:30 +0100, Ramses escribió:

> El 19/03/2013, a las 15:40, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Pues eso, lo que te comentaba, que a mi no es que me valgan o me dejen
>>> de valer, sólo es un tema de conceptos y desde el punto de vista desde
>>> el que se interpreten...
>>
>> No sé cómo lo interpretarás pero a mí me parece que está bastante claro
>> lo que permite el dispositivo que no es ni más ni menos lo que
>> preguntaba el OP unos 150 correos más arriba.
>
> Sí, sí, eso, eso, es tal como tú dices, tal y como lo estás
> interpretando tú...

Yo no, es lo que te ha respondido el fabricante, lo que indica en la hoja
de especificaciones del producto... de hecho es una característica
diferencial del aparato.

> Es que como soy nuevo en esto de las comunicaciones, me he liado y se me
> había ido la olla...

Pues no sé... será que los de Mushroom Networks también son unos recién
iniciados en esto de las redes, no saben lo que dicen, no saben lo que
venden y no saben lo que hacen. Ains...

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kia06h$m9s$4...@ger.gmane.org

[Ramses]

Buenas tardes,

El 19/03/2013, a las 16:28, Camaleón <noel...@gmail.com> escribió:

> El Tue, 19 Mar 2013 16:07:30 +0100, Ramses escribió:
>
>> El 19/03/2013, a las 15:40, Camaleón <noel...@gmail.com> escribió:
>
> (...)
>
>>>> Pues eso, lo que te comentaba, que a mi no es que me valgan o me dejen
>>>> de valer, sólo es un tema de conceptos y desde el punto de vista desde
>>>> el que se interpreten...
>>>
>>> No sé cómo lo interpretarás pero a mí me parece que está bastante claro
>>> lo que permite el dispositivo que no es ni más ni menos lo que
>>> preguntaba el OP unos 150 correos más arriba.
>>
>> Sí, sí, eso, eso, es tal como tú dices, tal y como lo estás
>> interpretando tú...
>
> Yo no, es lo que te ha respondido el fabricante, lo que indica en la hoja
> de especificaciones del producto... de hecho es una característica
> diferencial del aparato.
>
>> Es que como soy nuevo en esto de las comunicaciones, me he liado y se me
>> había ido la olla...
>
> Pues no sé... será que los de Mushroom Networks también son unos recién
> iniciados en esto de las redes, no saben lo que dicen, no saben lo que
> venden y no saben lo que hacen. Ains...

Eso será, Camaleón, que cuando dicen que, sin hacer "peering", suman el Ancho de Banda SOLO para el protocolo HTTP, y que para el resto hacen Balanceo de Carga, pues será lo que tú estás interpretando, que suma el Ancho de Banda de los enlaces WAN de distintos operadores que se le conecten al appliance.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CF690768-3B08-4454...@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 16:48:29 +0100, Ramses escribió:

> Buenas tardes,
>
> El 19/03/2013, a las 16:28, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Sí, sí, eso, eso, es tal como tú dices, tal y como lo estás
>>> interpretando tú...
>>
>> Yo no, es lo que te ha respondido el fabricante, lo que indica en la
>> hoja de especificaciones del producto... de hecho es una característica
>> diferencial del aparato.
>>
>>> Es que como soy nuevo en esto de las comunicaciones, me he liado y se
>>> me había ido la olla...
>>
>> Pues no sé... será que los de Mushroom Networks también son unos recién
>> iniciados en esto de las redes, no saben lo que dicen, no saben lo que
>> venden y no saben lo que hacen. Ains...
>
> Eso será, Camaleón, que cuando dicen que, sin hacer "peering", suman el
> Ancho de Banda SOLO para el protocolo HTTP, y que para el resto hacen
> Balanceo de Carga, pues será lo que tú estás interpretando, que suma el
> Ancho de Banda de los enlaces WAN de distintos operadores que se le
> conecten al appliance.

Y eso es exactamente lo que hace el dispositivo: sumar el ancho de banda
de los dos enlaces que tengas conectados (de distintos ISP o del mismo)
sin necesidad de "colaboración" por parte del carrier para "duplicar" el
ancho de banda (lo de "duplicar" lo dicen ellos no yo) y acelerar las
descargas http... que vuelvo a decir quizá no es lo que tu querías/
imaginabas/pensabas pero sí es lo que preguntaba el OP.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kia3iq$m9s$5...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: martes, 19 de marzo de 2013 17:26

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Tue, 19 Mar 2013 16:48:29 +0100, Ramses escribió:

> Buenas tardes,
>
> El 19/03/2013, a las 16:28, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Sí, sí, eso, eso, es tal como tú dices, tal y como lo estás
>>> interpretando tú...
>>
>> Yo no, es lo que te ha respondido el fabricante, lo que indica en la
>> hoja de especificaciones del producto... de hecho es una
>> característica diferencial del aparato.
>>
>>> Es que como soy nuevo en esto de las comunicaciones, me he liado y
>>> se me había ido la olla...
>>
>> Pues no sé... será que los de Mushroom Networks también son unos
>> recién iniciados en esto de las redes, no saben lo que dicen, no
>> saben lo que venden y no saben lo que hacen. Ains...
>
> Eso será, Camaleón, que cuando dicen que, sin hacer "peering", suman
> el Ancho de Banda SOLO para el protocolo HTTP, y que para el resto
> hacen Balanceo de Carga, pues será lo que tú estás interpretando, que
> suma el Ancho de Banda de los enlaces WAN de distintos operadores que
> se le conecten al appliance.

Y eso es exactamente lo que hace el dispositivo: sumar el ancho de banda de los dos enlaces que tengas conectados (de distintos ISP o del mismo) sin necesidad de "colaboración" por parte del carrier para "duplicar" el ancho de banda (lo de "duplicar" lo dicen ellos no yo) y acelerar las descargas http... que vuelvo a decir quizá no es lo que tu querías/ imaginabas/pensabas pero sí es lo que preguntaba el OP.

No, no, si ya está claro, si aquí lo dice bien claro:

------------------------------------

1) Standalone mode: In this mode, our Truffle appliances will bond all http downlink traffic. As an example if you were to download a file behind the Truffle device which has 4 ADSL lines plugged in with 6Mbps speed each. Your download speed would be around 24Mbps even for that single file download. For all other traffic, our device will implement the "intelligent load-balancing" where the Truffle device will distribute the different Internet sessions, on various WAN links on a session by session basis. Truffle will keep the application semantics in tact, by making sure the sessions from certain applications are kept on the same WAN line, such as banking sites, where a blind load-balancing would break the application.

------------------------------------

Que según tú, ellos dicen ahí esto:

------------------------------------

Y eso es exactamente lo que hace el dispositivo: sumar el ancho de banda de los dos enlaces que tengas conectados (de distintos ISP o del mismo) sin necesidad de "colaboración" por parte del carrier para "duplicar" el ancho de banda (lo de "duplicar" lo dicen ellos no yo) y acelerar las descargas http...

------------------------------------

Si está claro que ahí dice lo que tú has dicho.

Me imagino que también establecerán la sesión por una WAN y le responderán por la otra, porque, por esta regla de tres, también pone ahí eso...

Que ellos no ponen en ningún momento que el UNICO tráfico con el que hacen "bond" es con el HTTP, ni que con el resto hacen Load Balancing, no. Ellos dicen, que SUMAN el Ancho de Banda en cualquier circunstancia y sin contar con el Carrier, ni el operador, ni nadie, que lo suman y punto.

Si está claro, si lo pone en ese párrafo.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/002101ce24c2$12786ae0$376940a0$@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 17:51:49 +0100, Ramses II escribió:

Corrijo las citas... a ver si cambias ese Outlook ;-)

(...)

>>> Eso será, Camaleón, que cuando dicen que, sin hacer "peering", suman
>>> el Ancho de Banda SOLO para el protocolo HTTP, y que para el resto
>>> hacen Balanceo de Carga, pues será lo que tú estás interpretando, que
>>> suma el Ancho de Banda de los enlaces WAN de distintos operadores que
>>> se le conecten al appliance.
>>
>> Y eso es exactamente lo que hace el dispositivo: sumar el ancho de
>> banda de los dos enlaces que tengas conectados (de distintos ISP o del
>> mismo) sin necesidad de "colaboración" por parte del carrier para
>> "duplicar" el ancho de banda (lo de "duplicar" lo dicen ellos no yo) y
>> acelerar las descargas http... que vuelvo a decir quizá no es lo que

>> tu querías/imaginabas/pensabas pero sí es lo que preguntaba el OP.

>
> No, no, si ya está claro, si aquí lo dice bien claro:
>
> ------------------------------------
> 1) Standalone mode: In this mode, our Truffle appliances will bond all
> http downlink traffic. As an example if you were to download a file
> behind the Truffle device which has 4 ADSL lines plugged in with 6Mbps
> speed each. Your download speed would be around 24Mbps even for that
> single file download. For all other traffic, our device will implement
> the "intelligent load-balancing" where the Truffle device will
> distribute the different Internet sessions, on various WAN links on a
> session by session basis. Truffle will keep the application semantics in
> tact, by making sure the sessions from certain applications are kept on
> the same WAN line, such as banking sites, where a blind load-balancing
> would break the application.
> ------------------------------------
>
> Que según tú, ellos dicen ahí esto:
>
> ------------------------------------
> Y eso es exactamente lo que hace el dispositivo: sumar el ancho de banda
> de los dos enlaces que tengas conectados (de distintos ISP o del mismo)
> sin necesidad de "colaboración" por parte del carrier para "duplicar" el
> ancho de banda (lo de "duplicar" lo dicen ellos no yo) y acelerar las
> descargas http...
> ------------------------------------
>
> Si está claro que ahí dice lo que tú has dicho.

Pues sí, hijo, más claro agua.

Traducido: "A modo de ejemplo, si vas a descargar un archivo que está
detrás del dispositivo Truffle que tiene conectadas 4 líneas ADSL de 6
Mbps cada una la velocidad de descarga será de unos 24 Mbps para esa
descarga de un único archivo."

> Me imagino que también establecerán la sesión por una WAN y le
> responderán por la otra, porque, por esta regla de tres, también pone
> ahí eso...

Si tienes más dudas pregúntales de nuevo y ya que estás, si te dicen el
precio de los dispositivos, mejor.

> Que ellos no ponen en ningún momento que el UNICO tráfico con el que
> hacen "bond" es con el HTTP, ni que con el resto hacen Load Balancing,
> no. Ellos dicen, que SUMAN el Ancho de Banda en cualquier circunstancia
> y sin contar con el Carrier, ni el operador, ni nadie, que lo suman y
> punto.
>
> Si está claro, si lo pone en ese párrafo.

Y luego dicen que yo soy cabezota... caray.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kia6i8$m9s$6...@ger.gmane.org

[Ramses II]

Buenas tardes,

Qué más quisiera yo, cambiar el Outlook, bueno, no, mejor, me gustaría que lo hiciera bien, mejor que cambiar. Ya cambiaría después de que lo hiciera bien si veo otro que me simpatice más...

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: martes, 19 de marzo de 2013 18:17

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

------------------------

Cierto, Camaleón, delante de la frase que tú has traducido, no pone nada de que SOLO se está refiriendo al tráfico HTTP.

Ni detrás de la frase que tú has traducido, tampoco pone que con el resto del tráfico, el que no es HTTP, hace Load-Balancing.

Tienes razón, si te la estoy dando, que lo que tú dices que pone es que se suma el Ancho de Banda y punto...

Si no puede estar más claro, si lo dicen ellos en ese párrafo. No hay más que interpretarlo completo...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/003301ce24c7$d34d1860$79e74920$@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 18:33:07 +0100, Ramses II escribió:

> Buenas tardes,
>
> Qué más quisiera yo, cambiar el Outlook, bueno, no, mejor, me gustaría
> que lo hiciera bien, mejor que cambiar. Ya cambiaría después de que lo
> hiciera bien si veo otro que me simpatice más...

Es que ese cliente no maneja bien el texto citado, parece que sólo
trabaja con dos niveles y en las listas de correos canta mucho :-/

> Cierto, Camaleón, delante de la frase que tú has traducido, no pone nada
> de que SOLO se está refiriendo al tráfico HTTP.

Que sí, ¡pero si eso ya lo sabemos!

http://lists.debian.org/debian-user-spanish/2013/03/msg00504.html

Que resumía en los siguientes párrafos:

"(...) Es decir, el aparato hace lo que hace y sirve para lo que sirve.

Punto. Cosa distinta es que le sea útil a todo el mundo, en todos los

casos y en todas las circunstancias. (...) No sé... a mí me parece que

tiene un mercado bien definido y que puede ser de utilidad para algunos
usuarios pero obviamente no para todos ni para todo."

Me pregunto si _lees_ los correos que mando _antes_ de responderlos o
simplemente "disparas" antes de "apuntar" ;-)

> Ni detrás de la frase que tú has traducido, tampoco pone que con el
> resto del tráfico, el que no es HTTP, hace Load-Balancing.

(...)

Que sí, pero no voy a repetir lo que ya está escrito.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kia8tt$m9s$7...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: martes, 19 de marzo de 2013 18:57

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Tue, 19 Mar 2013 18:33:07 +0100, Ramses II escribió:

> Buenas tardes,
>
> Qué más quisiera yo, cambiar el Outlook, bueno, no, mejor, me gustaría
> que lo hiciera bien, mejor que cambiar. Ya cambiaría después de que lo
> hiciera bien si veo otro que me simpatice más...

Es que ese cliente no maneja bien el texto citado, parece que sólo trabaja con dos niveles y en las listas de correos canta mucho :-/

> Cierto, Camaleón, delante de la frase que tú has traducido, no pone
> nada de que SOLO se está refiriendo al tráfico HTTP.

Que sí, ¡pero si eso ya lo sabemos!

http://lists.debian.org/debian-user-spanish/2013/03/msg00504.html

Que resumía en los siguientes párrafos:

"(...) Es decir, el aparato hace lo que hace y sirve para lo que sirve.
Punto. Cosa distinta es que le sea útil a todo el mundo, en todos los casos y en todas las circunstancias. (...) No sé... a mí me parece que tiene un mercado bien definido y que puede ser de utilidad para algunos usuarios pero obviamente no para todos ni para todo."

Me pregunto si _lees_ los correos que mando _antes_ de responderlos o simplemente "disparas" antes de "apuntar" ;-)

> Ni detrás de la frase que tú has traducido, tampoco pone que con el
> resto del tráfico, el que no es HTTP, hace Load-Balancing.

(...)

Que sí, pero no voy a repetir lo que ya está escrito.

-------------------------------------------

Je, je, no vas a repetir lo que está escrito, pero sí traduces una frase en la que solo se dice que suma el Ancho de Banda, cuando en la frase anterior ponía que SOLO vale para HTTP y la siguiente tampoco la traduces porque pone que con el resto del tráfico hace Load-Balancing.

No, si está clarísimo...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/003a01ce24cd$b639cce0$22ad66a0$@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 19:15:16 +0100, Ramses II escribió:

(...)

>>> Ni detrás de la frase que tú has traducido, tampoco pone que con el
>>> resto del tráfico, el que no es HTTP, hace Load-Balancing.
>>
>> (...)
>>
>> Que sí, pero no voy a repetir lo que ya está escrito.
>>
>

> Je, je, no vas a repetir lo que está escrito, pero sí traduces una frase
> en la que solo se dice que suma el Ancho de Banda, cuando en la frase
> anterior ponía que SOLO vale para HTTP y la siguiente tampoco la
> traduces porque pone que con el resto del tráfico hace Load-Balancing.
>
> No, si está clarísimo...

Lo único que me queda claro, además de que ese chisme permite añadir dos
conexiones ADSL para aumentar el ancho de banda en las descargas web (por
ejemplo, para bajarse una imagen ISO sumando el ancho de banda de las dos
líneas) es que por algún motivo extraño no quieres (o no te interesa)
leer los correos que mando y entre eso y tu Outlook destroza-citas, hace
muy difícil la comunicación escrita :-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kiab6k$m9s$8...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: martes, 19 de marzo de 2013 19:36

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Tue, 19 Mar 2013 19:15:16 +0100, Ramses II escribió:

(...)

>>> Ni detrás de la frase que tú has traducido, tampoco pone que con el
>>> resto del tráfico, el que no es HTTP, hace Load-Balancing.
>>
>> (...)
>>
>> Que sí, pero no voy a repetir lo que ya está escrito.
>>
>
> Je, je, no vas a repetir lo que está escrito, pero sí traduces una
> frase en la que solo se dice que suma el Ancho de Banda, cuando en la
> frase anterior ponía que SOLO vale para HTTP y la siguiente tampoco la
> traduces porque pone que con el resto del tráfico hace Load-Balancing.
>
> No, si está clarísimo...

Lo único que me queda claro, además de que ese chisme permite añadir dos conexiones ADSL para aumentar el ancho de banda en las descargas web (por ejemplo, para bajarse una imagen ISO sumando el ancho de banda de las dos
líneas) es que por algún motivo extraño no quieres (o no te interesa) leer los correos que mando y entre eso y tu Outlook destroza-citas, hace muy difícil la comunicación escrita :-)

---------------------------------

Sí, sí, si mientras que la descarga sea por HTTP, sí, pero que no vale para otros protocolos, como, por ejemplo, FTP. Lo dice bien claro el fabricante...

Si a mi me parece también fantástico el appliance, si yo lo que estoy defendiendo es que no se suman los Anchos de Banda en su amplio sentido, sino que se tiene que dar la situación concreta de que el tráfico debe ser sólo, única y exclusivamente, HTTP, y que el resto es balanceado...

Lo de mi cliente de correo, creo que no tiene solución, y de lo mío, que te voy a contar...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/003c01ce24d5$f802a540$e807efc0$@gmail.com

[Camaleón]

El Tue, 19 Mar 2013 20:14:22 +0100, Ramses II escribió:

Corrijo las citas...

(...)

>>> No, si está clarísimo...
>>
>> Lo único que me queda claro, además de que ese chisme permite añadir
>> dos conexiones ADSL para aumentar el ancho de banda en las descargas
>> web (por ejemplo, para bajarse una imagen ISO sumando el ancho de
>> banda de las dos líneas) es que por algún motivo extraño no quieres (o
>> no te interesa) leer los correos que mando y entre eso y tu Outlook
>> destroza-citas, hace muy difícil la comunicación escrita :-)
>

> Sí, sí, si mientras que la descarga sea por HTTP, sí, pero que no vale
> para otros protocolos, como, por ejemplo, FTP. Lo dice bien claro el
> fabricante...

¡Pues eso es lo que estoy diciendo hace eones!

Y lo vuelvo a repetir: el dispositivo permite hacer lo que preguntaba el
OP (unir el ancho de banda de varias líneas ADSL para acelerar las
descargas). No especificaba ninguna necesidad adicional, y las descargas
de los archivos y la navegación convencional suele realizarse a través de
http.

> Si a mi me parece también fantástico el appliance, si yo lo que estoy
> defendiendo es que no se suman los Anchos de Banda en su amplio sentido,
> sino que se tiene que dar la situación concreta de que el tráfico debe
> ser sólo, única y exclusivamente, HTTP, y que el resto es balanceado...

Se suman en UNA situación determinada: tráfico http de bajada. Punto.
Para el resto de casos NO (sólo realiza balanceo de carga y el resto de
funcionalidades estándar en este tipo de aparatos), salvo que te
suscribas a su servicio.

> Lo de mi cliente de correo, creo que no tiene solución, y de lo mío, que
> te voy a contar...

Personalmente me gusta el Outlook (como aplicación PIM, digo) pero no
para usarlo en las listas. Además, tiene un error muy gordo de diseño,
desde mi punto de vista, y es que almacena todos los datos en un único
archivo .PST (salvo que te preocupes de configurarlo para que use varios
que no suele ser lo habitual) por lo que en caso de que se corrompa te
las ves y te las deseas para poder repararlo o tener una copia de
seguridad reciente a mano.

Kmail es el gestor de correos con el que más a gusto me he sentido, pero
ahora que estoy con GNOME (y en breve con XFCE) uso Thunderbird.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kich1l$cpo$1...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: miércoles, 20 de marzo de 2013 15:28

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

--------------------------------

Todo empieza así:

" Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.

eh estado por ahu y me ah surgido una locura. aver. supongamos que tengo 2 isp y laa quiero conectar a la misma red. por ejemplo los isp cada una tiene 2 mb de descarga y al juntar los dos tendria 4 mb peri como lo hago ? es posible esto ? o solo es una idea absurda que se me ah ocurrido ? XD"

Y yo lo único que he hecho es matizar que ese cacharro SOLO SUMA el BW de los enlaces WAN que se le conectan en caso de ser tráfico HTTP, porque la pregunta puede resultar muy ambigua.

En la pregunta no comenta si es HTTP o FTP o si tiene un Servidor Windows 2008 alojado en algún sitio en Internet, por eso lo de matizar que solo lo hace en caso de tráfico HTTP, y que el resto lo balancea...

Además, si pone uno de esos cacharros, tiene que ser muy consciente de qué tráfico tiene en su red y si en el cacharro tiene opción de discriminar que algún tipo de tráfico debe salir por un enlace en concreto y no balancearse entre todos, porque podría montársele una fiesta simpática. Imagina que tiene tráfico SIP y RTP contra Internet y el cacharro se lo empieza a balancear por todos los enlaces...

El tema del Outlook, pues eso, que estoy de acuerdo contigo, que es un "coñazo" cuando le das al Responder y no te hace las citas, ni te hace la sangría con el mensaje anterior, ni... Pero entre eso y tener un cliente para las listas y otro para el resto, pues...

Yo he probado, usado, y me gusta bastante Thunderbird, y de hecho, lo tengo instalado, pero arrastro muchos .pst antiguos y no he dado nunca el salto...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/004f01ce258b$66c17780$34446680$@gmail.com

[Martin Mantaras]

Hola, si la idea es utilizar dos ISP en la misma red te recomiento
utilizar un Microtik [1].
Con esta maravilla podrás hacer lo que necesitas y muchisimo mas.


[1] http://www.mikrotik.com/index.html

Atte.


Martin

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5149EAF8...@gmail.com

[Camaleón]

El Wed, 20 Mar 2013 17:53:07 +0100, Ramses II escribió:

> Todo empieza así:
>
> " Hola lista. bueno solo es una duda por si algun dia necesito hacerlo.
>
> eh estado por ahu y me ah surgido una locura. aver. supongamos que tengo
> 2 isp y laa quiero conectar a la misma red. por ejemplo los isp cada una
> tiene 2 mb de descarga y al juntar los dos tendria 4 mb peri como lo
> hago ? es posible esto ? o solo es una idea absurda que se me ah
> ocurrido ? XD"
>
> Y yo lo único que he hecho es matizar que ese cacharro SOLO SUMA el BW
> de los enlaces WAN que se le conectan en caso de ser tráfico HTTP,
> porque la pregunta puede resultar muy ambigua.

No, perdona, vamos a hablar con propiedad. Tu primera intervención en
este hilo fue esta:

http://lists.debian.org/debian-user-spanish/2013/03/msg00312.html

De tu pregunta deduje que tú (al igual que la mayoría de la gente que ha
respondido en este hilo) desconocías este tipo de tecnología así como que
ya había en el mercado un dispositivo capaz de hacer lo que preguntaba el
OP: unir varias conexiones ADSL para aprovechar -sumar- el ancho de banda
que ambos, sin más detalles, especificaciones ni gaitas.

> En la pregunta no comenta si es HTTP o FTP o si tiene un Servidor
> Windows 2008 alojado en algún sitio en Internet, por eso lo de matizar
> que solo lo hace en caso de tráfico HTTP, y que el resto lo balancea...

Lo de "matizar" ya vino después cuando puse los enlaces a los primeros
chismes que busqué en Google (he de reconocer que tampoco entré en cada
una de las hojas de datos de productos para ver qué permitían y que no
pero no era la primera vez que leía sobre esto así que no me extrañó en
absoluto que hubiera más dispositivos de este tipo en el mercado).

> Además, si pone uno de esos cacharros, tiene que ser muy consciente de
> qué tráfico tiene en su red y si en el cacharro tiene opción de
> discriminar que algún tipo de tráfico debe salir por un enlace en
> concreto y no balancearse entre todos, porque podría montársele una
> fiesta simpática. Imagina que tiene tráfico SIP y RTP contra Internet y
> el cacharro se lo empieza a balancear por todos los enlaces...

Pero Ramses, si me parece perfecto todo eso que dices. Ya te he dicho
antes (y varias veces, además) que yo NO lo compraría salvo en el caso
concreto que mencioné o una situación similar porque teniendo enlaces de
ancho de banda de FTTH ese aparato no me haría ninguna función real, más
allá de aprovechar el balanceo de carga y el failover, pero eso lo podría
hacer con otro "appliance" o con un ordenador dedicado.

Vuelvo a repetir: sirve para lo que sirve y hace lo que hace, a quien le
venga útil, perfecto y a quien no, pues también. Pero no puedes negar una
funcionalidad que permite el dispositivo simplemente porque tú no le veas
uso; eso es tergiversar la realidad un poco demasiado.

> El tema del Outlook, pues eso, que estoy de acuerdo contigo, que es un
> "coñazo" cuando le das al Responder y no te hace las citas, ni te hace
> la sangría con el mensaje anterior, ni... Pero entre eso y tener un
> cliente para las listas y otro para el resto, pues...
>
> Yo he probado, usado, y me gusta bastante Thunderbird, y de hecho, lo
> tengo instalado, pero arrastro muchos .pst antiguos y no he dado nunca
> el salto...

Yo migré mi Outlook (era un PST de unos ~3,5 GiB) a Kmail usando un
servidor IMAP local y fue muy sencillo. Lo único que tuve que hacer
manualmente fue el traspaso de los contactos y el calendario, pero el
tiempo que pierdes "afinando" la migración ganas en tranquilidad y
seguridad, es decir, creo que merece la pena.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kicqq3$cpo$7...@ger.gmane.org

[Camaleón]

El Wed, 20 Mar 2013 13:59:36 -0300, Martin Mantaras escribió:

> Hola, si la idea es utilizar dos ISP en la misma red te recomiento
> utilizar un Microtik [1].
> Con esta maravilla podrás hacer lo que necesitas y muchisimo mas.

Me parece que en este extenso hilo no hablamos de eso ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kicqug$cpo$8...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: miércoles, 20 de marzo de 2013 18:15

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

-----------------------

Claro, es que cuando yo entré con mi primera pregunta es porque era sí porque sí, que sí se sumaba el BW y punto, incluso hubo compañeros de la lista que tenía pinta de que le pegaban a las comunicaciones, que defendían lo de que NO se puede sumar el BW y punto, y abandonaron el hilo.

Después pasaste los enlaces y estuve hablando con ellos, y salió lo de que solo podían hacerlo con HTTP, y empezó la matización del HTTP. Sin embargo, la historia seguía en que sí porque sí, que se sumaban los BW y punto...

Camaleón, yo no he dicho que no le vea uso a ese appliance, por favor, busca entre los posts y me lo pegas, la historia ha sido en que no es sí porque sí, que es bajo algunas condiciones específicas y concretas.

Lo de migrar a otro cliente, ya sabes, si es por "perrera" muchas veces, y como ya se le tiene cariño, pues...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/006201ce2594$fa4e3520$eeea9f60$@gmail.com

[Camaleón]

El Wed, 20 Mar 2013 19:01:40 +0100, Ramses II escribió:

(...)

> Claro, es que cuando yo entré con mi primera pregunta es porque era sí
> porque sí, que sí se sumaba el BW y punto, incluso hubo compañeros de la
> lista que tenía pinta de que le pegaban a las comunicaciones, que
> defendían lo de que NO se puede sumar el BW y punto, y abandonaron el
> hilo.

Bueno, no siempre se puede estar actualizado y al día de las últimas
novedades o productos del mercado, es normal.

En su día (de esto hace ya 4 o 5 años) busqué información sobre esa
opción porque nosotros también tenemos varios enlaces en la oficina
(antes RDSI, luego ADSL y ahora la fibra óptica) y siempre me pareció
interesante la opción de poder aumentar el ancho de banda sobre todo para
el ADSL sobre RDSI que tiene la velocidad muy baja, y encontré en
Internet un extracto de un artículo del IEEE (el artículo completo
requería suscripción) donde hablaban de esta posibilidad.

> Después pasaste los enlaces y estuve hablando con ellos, y salió lo de
> que solo podían hacerlo con HTTP, y empezó la matización del HTTP. Sin
> embargo, la historia seguía en que sí porque sí, que se sumaban los BW y
> punto...

No, la historia no seguía en "que sí porque sí", de hecho creo recordar
que fui yo quien mandó en enlace a la FAQ donde se detallaban las
características de los dispositivos.

> Camaleón, yo no he dicho que no le vea uso a ese appliance, por favor,
> busca entre los posts y me lo pegas, la historia ha sido en que no es sí
> porque sí, que es bajo algunas condiciones específicas y concretas.

(...)

No me refería a ti, sino en general: hay quien no le pueda parecer útil
porque las prestaciones del aparato no le sirven en un entorno
determinado pero que eso no quita para que el concepto "base" (que es de
lo que estamos hablando) sea posible obtenerlo con este dispositivo.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kicuuf$cpo$9...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: miércoles, 20 de marzo de 2013 19:25

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

El Wed, 20 Mar 2013 19:01:40 +0100, Ramses II escribió:

(...)

> Claro, es que cuando yo entré con mi primera pregunta es porque era sí
> porque sí, que sí se sumaba el BW y punto, incluso hubo compañeros de
> la lista que tenía pinta de que le pegaban a las comunicaciones, que
> defendían lo de que NO se puede sumar el BW y punto, y abandonaron el
> hilo.

Bueno, no siempre se puede estar actualizado y al día de las últimas novedades o productos del mercado, es normal.

En su día (de esto hace ya 4 o 5 años) busqué información sobre esa opción porque nosotros también tenemos varios enlaces en la oficina (antes RDSI, luego ADSL y ahora la fibra óptica) y siempre me pareció interesante la opción de poder aumentar el ancho de banda sobre todo para el ADSL sobre RDSI que tiene la velocidad muy baja, y encontré en Internet un extracto de un artículo del IEEE (el artículo completo requería suscripción) donde hablaban de esta posibilidad.

> Después pasaste los enlaces y estuve hablando con ellos, y salió lo de
> que solo podían hacerlo con HTTP, y empezó la matización del HTTP. Sin
> embargo, la historia seguía en que sí porque sí, que se sumaban los BW
> y punto...

No, la historia no seguía en "que sí porque sí", de hecho creo recordar que fui yo quien mandó en enlace a la FAQ donde se detallaban las características de los dispositivos.

> Camaleón, yo no he dicho que no le vea uso a ese appliance, por favor,
> busca entre los posts y me lo pegas, la historia ha sido en que no es
> sí porque sí, que es bajo algunas condiciones específicas y concretas.

(...)

No me refería a ti, sino en general: hay quien no le pueda parecer útil porque las prestaciones del aparato no le sirven en un entorno determinado pero que eso no quita para que el concepto "base" (que es de lo que estamos hablando) sea posible obtenerlo con este dispositivo.

------------------------------------
Ya no es tanto de productos, sino como de protocolos y RFC's...

Esa es la que yo estoy buscando, la que tiene que definir bajo qué protocolos y condiciones se puede dar el bonding..., pero no la tengo por aquí...

Bueno, bueno, solo tradujiste la parte del párrafo que ponía que se sumaban los BW, ni la frase de antes, que decía lo del HTTP, ni la de después, que decía que el resto del tráfico lo balanceaba... ;-)

Claro, evidentemente que un cacharro de estos, dependiendo de qué tráfico te puede salvar la vida y ahorrarte dinero, porque desde el punto de vista de la LAN, puede salir/entrar el "doble" de tráfico, pero que hay que estudiar antes de qué tráfico estamos hablando...

Porque tu tienes una cámara que te tira ficheros de 4Mb a un FTP en Internet y desde otro punto de Internet los estás recuperando vía FTP a través de una ADSL de 2Mbps. Si a esa persona le dices que montando un cacharro de estos va a descargar más rápido los ficheros, pues cuando lo pincha, como que se queda con dos palmos de narices...

Hombreeee, es que yo me en encontrado situaciones de empresas que tienen un enlace de 100Mbps en fibra para dar acceso en estrella a sus servicios todas sus sedes y con una ADSL de 8Mb/640Kb de respaldo...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/006701ce259c$b324c3a0$196e4ae0$@gmail.com

[Ricardo]

El mar 20, 2013 2:17 p.m., "Camaleón" <noel...@gmail.com> escribió:
>
> El Wed, 20 Mar 2013 13:59:36 -0300, Martin Mantaras escribió:
>
> > Hola, si la idea es utilizar dos ISP en la misma red te recomiento
> > utilizar un Microtik [1].
> > Con esta maravilla podrás hacer lo que necesitas y muchisimo mas.
>
> Me parece que en este extenso hilo no hablamos de eso ;-)
>
> Saludos,
>
> --
> Camaleón
>
>
> --

Hola lista, veo que  en la lista hablan de unir dos ISP, el Mikrotik RB mas básico lo hace sin problemas, por eso que un usuario comenta mas arriba lo de el Mikrotik, yo personalmente la uso con una pc x86?

saludos

Ricardo

[Camaleón]

El Wed, 20 Mar 2013 19:56:57 +0100, Ramses II escribió:

> Ya no es tanto de productos, sino como de protocolos y RFC's...

¿Protocolos y RFC de qué exactamente? Creo que me he perdido.

> Esa es la que yo estoy buscando, la que tiene que definir bajo qué
> protocolos y condiciones se puede dar el bonding..., pero no la tengo
> por aquí...

¿Mande? ¿Todavía seguimos así? Caray :-)

Todo eso estaba especidicado en la FAQ del Truffle Lite:

https://www.mushroomnetworks.com/product/products.aspx?product_id=1002&tab=faqs

Y la hoja de producto:

https://www.mushroomnetworks.com/get_file.aspx?id=3DF83487-2300-46E5-AA2E-67E32D367399&name=brochure%20Truffle%20Lite.pdf

> Bueno, bueno, solo tradujiste la parte del párrafo que ponía que se
> sumaban los BW, ni la frase de antes, que decía lo del HTTP, ni la de
> después, que decía que el resto del tráfico lo balanceaba... ;-)

Traduje el quid de la cuestión, obviamente.

> Claro, evidentemente que un cacharro de estos, dependiendo de qué
> tráfico te puede salvar la vida y ahorrarte dinero, porque desde el
> punto de vista de la LAN, puede salir/entrar el "doble" de tráfico, pero
> que hay que estudiar antes de qué tráfico estamos hablando...

No estamos hablando -al menos yo no- del tráfico generado en local (LAN)
sino en la WAN, en remoto. Y por cierto, el aparatito tiene 4 bocas
gigabit para conexiones de banda ancha (pensaba que sólo eran 2) y un par
de puertos USB para conexiones 3G/4G, vamos, que está muy bien dotado.

> Porque tu tienes una cámara que te tira ficheros de 4Mb a un FTP en
> Internet y desde otro punto de Internet los estás recuperando vía FTP a
> través de una ADSL de 2Mbps. Si a esa persona le dices que montando un
> cacharro de estos va a descargar más rápido los ficheros, pues cuando lo
> pincha, como que se queda con dos palmos de narices...

Es que a esa persona no le puedes decir eso :-)

En ese escenario no se aprovecharía la características de la suma del
ancho de banda de las conexiones WAN que estén conectadas al aparato,
pero igualmente sigue siendo interesante el balanceo de carga (que
también puede acelerar la conexión descartando el enlace que esté más
saturado) y la capacidad de failover para no dejar a la cámara web
"caída".

Lo cual no quita para que el el resto de situaciones SÍ se pueda
aprovechar de las conexiones ADSL que tenga conectadas sumando anchos de
banda.

> Hombreeee, es que yo me en encontrado situaciones de empresas que tienen
> un enlace de 100Mbps en fibra para dar acceso en estrella a sus
> servicios todas sus sedes y con una ADSL de 8Mb/640Kb de respaldo...

Se supone que el ADSL de respaldo sólo actúa de uvas a peras (¿una vez al
año?). Además, no hace mucho los enlaces primarios eran los ADSL de 2
Mbps y la conexión de backup la gestionaba modems RDSI ;-)

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kif5mv$kp3$1...@ger.gmane.org

[Camaleón]

El Thu, 21 Mar 2013 08:15:37 -0300, Ricardo escribió:

(ese html...)

> El mar 20, 2013 2:17 p.m., "Camaleón" <noel...@gmail.com> escribió:
>>
>> El Wed, 20 Mar 2013 13:59:36 -0300, Martin Mantaras escribió:
>>
>> > Hola, si la idea es utilizar dos ISP en la misma red te recomiento
>> > utilizar un Microtik [1].
>> > Con esta maravilla podrás hacer lo que necesitas y muchisimo mas.
>>
>> Me parece que en este extenso hilo no hablamos de eso ;-)
>>

> Hola lista, veo que en la lista hablan de unir dos ISP,

Sí, pero "con matices" ;-)

> el Mikrotik RB mas básico lo hace sin problemas, por eso que un usuario
> comenta mas arriba lo de el Mikrotik, yo personalmente la uso con una
> pc x86?

Te aseguro que el Mikrotik no permite sumar los anchos de banda (en modo
de "agregación", no de "balanceo de carga" ni de "failover") de las
conexiones WAN.

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kif5r9$kp3$2...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: jueves, 21 de marzo de 2013 15:33

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

---------------------------

Sencillo, estoy hablando de esas cosas que tienen que cumplir todo cacharro para poder interoperar con otro de otra marca sin que haya problemas y no tengan que se todos del mismo fabricante como pasaba antes, porque cada protocolo era privativo de cada marca... Vamos, que en algún sitio tiene que haber algo escrito de que si a un servidor HTTP le piden la descarga de un mismo fichero desde 2 IP distintas, lo trocee y mande un cachito por cada IP. Porque si no están usando estándares, mal van a poder negociar eso con el servidor unilateralmente...

Sí, si ya he visto las FAQ. Si pasa lo mismo que aquí, en la 1 dice que suma y en la 10 dice que solo el tráfico HTTP.

Cuando lo de la traducción ya andábamos afinando que si HTTP, que si todo...

Perdón: Claro, evidentemente que un cacharro de estos, dependiendo de qué tráfico te puede salvar la vida y ahorrarte dinero, porque desde el punto de vista de la LAN, puede entrar el "doble" de tráfico, pero que hay que estudiar antes de qué tráfico estamos hablando...

Es que esa persona no te va a plantear la situación de que las descargas las hace con FTP o HTTP, es que para esa persona es una descarga desde Internet.

Sí, sí, los Backups solo actúan de uvas a peras, pues cuando una retroexcavadora le mete la cuchara y te arranca una fibra por la que estás dando servicio a todas las delegaciones con un BW medio de 50Mbps y te levanta una ADSL de 8Mb/640Kb, donde todos dicen, "leches" 8Mb está bien...", no, no, campeón, son 640Kb, que eres tú el que estás sirviendo... Vamos, que no puedes hacer ni un Ping...

Ya hace mucho que trabajo en empresas con líneas principales más gordas.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/001e01ce2651$db4bd6b0$91e38410$@gmail.com

[Camaleón]

El Thu, 21 Mar 2013 17:33:32 +0100, Ramses II escribió:

> Sencillo, estoy hablando de esas cosas que tienen que cumplir todo
> cacharro para poder interoperar con otro de otra marca sin que haya
> problemas y no tengan que se todos del mismo fabricante como pasaba
> antes, porque cada protocolo era privativo de cada marca... Vamos, que
> en algún sitio tiene que haber algo escrito de que si a un servidor HTTP
> le piden la descarga de un mismo fichero desde 2 IP distintas, lo trocee
> y mande un cachito por cada IP. Porque si no están usando estándares,
> mal van a poder negociar eso con el servidor unilateralmente...

Bueno, ya sabes que de lo que está escrito sobre el papel a la realidad
va un buen trecho. Un buen ejemplo de dispositivos "suyos" son los
routers de Cisco... Que sí, cumplen con los estándares y protocolos x, y,
z pero cuando los integras en tu red empiezan los problemas e
incompatibilidades con el resto de sistemas y aparatos de tu red.

> Sí, si ya he visto las FAQ. Si pasa lo mismo que aquí, en la 1 dice que
> suma y en la 10 dice que solo el tráfico HTTP.

No veo ninguna contradicción en los dos párrafos.

> Cuando lo de la traducción ya andábamos afinando que si HTTP, que si
> todo...

HTTP y sólo descarga, no subida. Lo dice bien claro. También podría poner
algunos ejemplos de uso donde el ancho de banda se suma para que los
usuarios se hagan una idea de si les conviene o no pero entiendo que por
el tipo de dispositivo de que se trata está enfocado a administradores
que se supone saben lo que se hacen y son capaces de discernir si el
chisme les sirve para lo que quieren o no.

> Perdón: Claro, evidentemente que un cacharro de estos, dependiendo de
> qué tráfico te puede salvar la vida y ahorrarte dinero, porque desde el
> punto de vista de la LAN, puede entrar el "doble" de tráfico, pero que
> hay que estudiar antes de qué tráfico estamos hablando...

Y dale con la LAN, le has cogido perrica ¿eh? :-)

> Es que esa persona no te va a plantear la situación de que las descargas
> las hace con FTP o HTTP, es que para esa persona es una descarga desde
> Internet.

Ni falta que hace. El dispositivo usará lo que tenga disponible en cada
momento de manera transparente: cuando pueda sumar ancho de banda para
acelerar una descarga lo hará y cuando no, pues aplicará el balanceo de
carga. No hay más misterio. Si este funcionamiento no te sirve (no a ti,
sino a quien quiera que esté interesado en este aparato) pues es obvio
que no lo comprará.

> Sí, sí, los Backups solo actúan de uvas a peras, pues cuando una
> retroexcavadora le mete la cuchara y te arranca una fibra por la que
> estás dando servicio a todas las delegaciones con un BW medio de 50Mbps
> y te levanta una ADSL de 8Mb/640Kb, donde todos dicen, "leches" 8Mb está
> bien...", no, no, campeón, son 640Kb, que eres tú el que estás
> sirviendo... Vamos, que no puedes hacer ni un Ping...
>
> Ya hace mucho que trabajo en empresas con líneas principales más gordas.

Hombre, si necesitas un ancho de banda determinado en todo momento lo
normal es que la línea de respaldo sea de iguales características que la
principal ¿no?

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kifheh$kp3$7...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: jueves, 21 de marzo de 2013 18:53

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

--------------------------------------------------

Hombre, CISCO igual que todo fabricante, cumplen con los estándares y protocolos x, y, z, y después tiene sus protocolos propietarios como HSRP, EIGRP, IS-IS,...., pero usando estándares, yo no he tenido ningún problema integrando CISCO en una red, encontrando la IOS de tu que tiene un bug... Lo que no pretenderemos es hacer VRRP con un CISCO y un 3COM. O que cada fabricante defina trunk de una forma, que te puede volver loco...

¿No ves diferencia?. Pues si tiramos del 1, estamos diciendo que SUMAMOS y punto, y si tiramos del 10, estamos diciendo que SUMAMOS solo HTTP y con el resto hacemos balanceo...

Claro, es que son dos puntos de vista distintos, desde la LAN y desde un PC de la LAN...

Claro que hace falta que te lo diga, ¿cómo no va a hacer falta que te lo diga?, ¿cómo vas a recomendar algo para trastear con tráfico sin saber de qué tipo de tráfico estamos hablando?. Ah, bueno, sí, si no te lo aclaran, entonces es cuando hay que matizar y decir que solo suma el BW para descargas HTTP.

Sí, sí, claro, o cuanto menos, otra línea con un BW que te permita medianamente trabajar ante una caída de la principal, aunque sea más lento, de Operador y tecnología distinta la principal... De nada vale contratar una fibra principal con Operador A y una de Backup con Operador B, cuando Operador B le contrata la fibra a Operador A...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/000d01ce2665$b0f87b70$12e97250$@gmail.com

[Camaleón]

El Thu, 21 Mar 2013 19:55:37 +0100, Ramses II escribió:


> Hombre, CISCO igual que todo fabricante, cumplen con los estándares y
> protocolos x, y, z, y después tiene sus protocolos propietarios como
> HSRP, EIGRP, IS-IS,...., pero usando estándares, yo no he tenido ningún
> problema integrando CISCO en una red, encontrando la IOS de tu que tiene
> un bug... Lo que no pretenderemos es hacer VRRP con un CISCO y un 3COM.
> O que cada fabricante defina trunk de una forma, que te puede volver
> loco...
>
> ¿No ves diferencia?. Pues si tiramos del 1, estamos diciendo que SUMAMOS
> y punto, y si tiramos del 10, estamos diciendo que SUMAMOS solo HTTP y
> con el resto hacemos balanceo...

No, hombre... a ver, si necesitas los detalles técnicos de cómo gestiona
ese "canuto" virtual donde suma el ancho de banda de las conexiones WAN
que tenga pinchadas con el tráfico HTTP de bajada pues les pides las
especificaciones (la hoja de producto es muy sencilla y no dan más datos,
tampoco sobre la configuración del dispositivo).

> Claro, es que son dos puntos de vista distintos, desde la LAN y desde un
> PC de la LAN...

Y dale con la LAN. A mí lo que suceda en local no me interesa y al OP
tampoco porque habla de "2 ISP".

> Claro que hace falta que te lo diga, ¿cómo no va a hacer falta que te lo
> diga?, ¿cómo vas a recomendar algo para trastear con tráfico sin saber
> de qué tipo de tráfico estamos hablando?. Ah, bueno, sí, si no te lo
> aclaran, entonces es cuando hay que matizar y decir que solo suma el BW
> para descargas HTTP.

Oye, pues si no te crees lo que te están diciendo no compres el
dispositivo que nadie te obliga. Y si necesitas más datos antes de
comprarlo se lo pides, y si no te lo dan pues no lo compras y punto.

Yo no recomiendo nada a nadie, estoy diciendo que EXISTE un aparato que
permite conectar dos/cuatro modems ADSL y sumar los anchos de banda de
todos ellos para descargar archivos de la web más rápidamente. Cómo lo
hacen no es mi problema.

Parecemos dos hamsters dando vueltas a una rueda :-)

> Sí, sí, claro, o cuanto menos, otra línea con un BW que te permita
> medianamente trabajar ante una caída de la principal, aunque sea más
> lento, de Operador y tecnología distinta la principal... De nada vale
> contratar una fibra principal con Operador A y una de Backup con
> Operador B, cuando Operador B le contrata la fibra a Operador A...

Ah... amigo, ahí tienes que quejarte a la CMT por falta de competencia en
el mercado de la banda ancha.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kiflpr$kp3$1...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: jueves, 21 de marzo de 2013 20:08

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

-----------------------------------------------------------

Si está claro, si lo que se está hablando aquí es que sólo lo hace con tráfico HTTP. Y si lo hace controlando un único extremo, es porque esa prestación/funcionalidad/o como le queramos llamar, tiene que estar escrita en los estándares... Lo que está claro es que no te van a contar el cómo lo implementa, pero estar, tiene que estar escrita, porque el servidor remoto tiene que cumplirla...

Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que hablemos de descargas, solo las HTTP.

No creo que la CMT tenga nada que ver aquí, hablamos de que lo recomendable a la hora de contratar la línea de backup es que sea de Operador y Tecnología distinta a la principal. Que quitando los casos de las ADSL's que he comentado antes, no sería la primera vez que el que se dedica a estas cosillas en una empresa, ha decidido contratar una fibra de principal con Operador A, y como es muy precavido, pues ha contratado una fibra de backup con el Operador B, por si le falla la principal... Pero vaya, ahora resulta que no ha tenido en cuenta que el Operador B le alquila la fibra al Operador A. Vamos, que si cortan el mazo, se va a colgar bastantes medallas...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/001701ce266e$c1e4abd0$45ae0370$@gmail.com

[Camaleón]

El Thu, 21 Mar 2013 21:00:35 +0100, Ramses II escribió:

> Si está claro, si lo que se está hablando aquí es que sólo lo hace con
> tráfico HTTP. Y si lo hace controlando un único extremo, es porque esa
> prestación/funcionalidad/o como le queramos llamar, tiene que estar
> escrita en los estándares... Lo que está claro es que no te van a contar
> el cómo lo implementa, pero estar, tiene que estar escrita, porque el
> servidor remoto tiene que cumplirla...

Bueno, ellos hablan de líneas DSL, cable-modem o servicios T1 (y 3G/4G)
como posibles conexiones en las que se puede unir el ancho de banda sin
especificar nada más como requisito (p. ej., podría indicar que sólo
admiten conexiones de "x" proveedor o que su aparato sólo trabaja con "y"
módems de banda ancha pero no es así).

Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares y
protocolos así que ese aparato tiene que saber interpretarlos y
gestionarlos para que sea un dispositivo útil, que lo hayan podido
patentar y que además se venda en el mercado. Sinceramente, pensar en
teorías "conspiranoicas" está bien como guión de una película pero poco
más.

> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
> hablemos de descargas, solo las HTTP.

Hombre, menos mal.

> No creo que la CMT tenga nada que ver aquí, hablamos de que lo
> recomendable a la hora de contratar la línea de backup es que sea de
> Operador y Tecnología distinta a la principal.

Hombre, pues tiene que ver porque una entidad que debería velar por la
libre competencia (real) en un mercado tan importante y vital para un
país como es el de las telecomunicaciones, no hace nada: se lava las
manos y permite que a día de hoy sólo una empresa -Telefónica- por una
mera cuestión de capacidad efectiva ya que ha sido el único operador de
telefonía en España durante muchos años, sea el único al que le salga
rentable tirar cable de fibra y comercializarla.

Salvo que, o bien vivas en una comunidad donde tengas la suerte de que
haya otros operadores de fibra (como Asturias o Euskadi, si mal no
recuerdo) o que vivas en la Calle Rue del Percebe, 1º-B donde Ono te
pueda dar cobertura, pues no tienes más bemoles que pedir por duplicado
al mismo operador la línea de respaldo con la misma capacidad que la
primaria. No hay más. O eso o contratas 4 ADSL de hasta 20 Mbps y los
enganchas a un dispositivo Truffle Lite de cierta compañía de cuyo nombre
no quiero acordarme ;-)

> Que quitando los casos de las ADSL's que he comentado antes, no sería
> la primera vez que el que se dedica a estas cosillas en una empresa, ha
> decidido contratar una fibra de principal con Operador A, y como es muy
> precavido, pues ha contratado una fibra de backup con el Operador B,
> por si le falla la principal... Pero vaya, ahora resulta que no ha
> tenido en cuenta que el Operador B le alquila la fibra al Operador A.
> Vamos, que si cortan el mazo, se va a colgar bastantes medallas...

Pues por eso te comentaba que _no hay competencia real_ en el sector, de
lo contrario tendrías operadores B, C y D con líneas, servicios y
cableados propios y con buenos precios porque todos estarían dándose de
tortas para captar clientes.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kifu5u$kp3$1...@ger.gmane.org

[Ramses]

Buenas,

El 21/03/2013, a las 22:30, Camaleón <noel...@gmail.com> escribió:

> El Thu, 21 Mar 2013 21:00:35 +0100, Ramses II escribió:
>
>> Si está claro, si lo que se está hablando aquí es que sólo lo hace con
>> tráfico HTTP. Y si lo hace controlando un único extremo, es porque esa
>> prestación/funcionalidad/o como le queramos llamar, tiene que estar
>> escrita en los estándares... Lo que está claro es que no te van a contar
>> el cómo lo implementa, pero estar, tiene que estar escrita, porque el
>> servidor remoto tiene que cumplirla...
>
> Bueno, ellos hablan de líneas DSL, cable-modem o servicios T1 (y 3G/4G)
> como posibles conexiones en las que se puede unir el ancho de banda sin
> especificar nada más como requisito (p. ej., podría indicar que sólo
> admiten conexiones de "x" proveedor o que su aparato sólo trabaja con "y"
> módems de banda ancha pero no es así).
>
> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares y
> protocolos así que ese aparato tiene que saber interpretarlos y
> gestionarlos para que sea un dispositivo útil, que lo hayan podido
> patentar y que además se venda en el mercado. Sinceramente, pensar en
> teorías "conspiranoicas" está bien como guión de una película pero poco
> más.

Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...

Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque el tema está a Nivel 7.

>> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
>> hablemos de descargas, solo las HTTP.
>
> Hombre, menos mal.

Lo llevo diciendo desde que hablé con ellos, tira de histórico, que dicen que suman BW solo y exclusivamente para el caso de tráfico con protocolo HTTP.

>> No creo que la CMT tenga nada que ver aquí, hablamos de que lo
>> recomendable a la hora de contratar la línea de backup es que sea de
>> Operador y Tecnología distinta a la principal.
>
> Hombre, pues tiene que ver porque una entidad que debería velar por la
> libre competencia (real) en un mercado tan importante y vital para un
> país como es el de las telecomunicaciones, no hace nada: se lava las
> manos y permite que a día de hoy sólo una empresa -Telefónica- por una
> mera cuestión de capacidad efectiva ya que ha sido el único operador de
> telefonía en España durante muchos años, sea el único al que le salga
> rentable tirar cable de fibra y comercializarla.
>
> Salvo que, o bien vivas en una comunidad donde tengas la suerte de que
> haya otros operadores de fibra (como Asturias o Euskadi, si mal no
> recuerdo) o que vivas en la Calle Rue del Percebe, 1º-B donde Ono te
> pueda dar cobertura, pues no tienes más bemoles que pedir por duplicado
> al mismo operador la línea de respaldo con la misma capacidad que la
> primaria. No hay más. O eso o contratas 4 ADSL de hasta 20 Mbps y los
> enganchas a un dispositivo Truffle Lite de cierta compañía de cuyo nombre
> no quiero acordarme ;-)

Bueno, ya hay alguno más que está haciendo sus pinitos tirando su propia fibra...

>> Que quitando los casos de las ADSL's que he comentado antes, no sería
>> la primera vez que el que se dedica a estas cosillas en una empresa, ha
>> decidido contratar una fibra de principal con Operador A, y como es muy
>> precavido, pues ha contratado una fibra de backup con el Operador B,
>> por si le falla la principal... Pero vaya, ahora resulta que no ha
>> tenido en cuenta que el Operador B le alquila la fibra al Operador A.
>> Vamos, que si cortan el mazo, se va a colgar bastantes medallas...
>
> Pues por eso te comentaba que _no hay competencia real_ en el sector, de
> lo contrario tendrías operadores B, C y D con líneas, servicios y
> cableados propios y con buenos precios porque todos estarían dándose de
> tortas para captar clientes.

Uuuffff, tu ya hablas de cuando se ha tenido en cuenta a la hora de contratar un backup y no hay alternativa, y yo estoy hablando de que ni se tiene en cuenta, sino que, contrato otra fibra (o ADSL, da igual) con otro Operador y ya estoy cubierto por sí se cae la principal, sin pensar en que al final es el mismo cable...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/24F5FB2E-D476-4EA9...@gmail.com

[Camaleón]

El Fri, 22 Mar 2013 01:53:09 +0100, Ramses escribió:

¿Citas correctas? No me lo creo :-)

> El 21/03/2013, a las 22:30, Camaleón <noel...@gmail.com> escribió:

(...)

>> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares y
>> protocolos así que ese aparato tiene que saber interpretarlos y
>> gestionarlos para que sea un dispositivo útil, que lo hayan podido
>> patentar y que además se venda en el mercado. Sinceramente, pensar en
>> teorías "conspiranoicas" está bien como guión de una película pero poco
>> más.
>
> Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...

Si la cuerda cumple con los estándares y le crimpado un par de "ganchos"
RJ-45 pues a saber.

> Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en
> HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque el
> tema está a Nivel 7.

Nivel 4, o eso dicen.

>>> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
>>> hablemos de descargas, solo las HTTP.
>>
>> Hombre, menos mal.
>
> Lo llevo diciendo desde que hablé con ellos, tira de histórico, que
> dicen que suman BW solo y exclusivamente para el caso de tráfico con
> protocolo HTTP.

Pues entonces no sé qué seguimos discutiendo, exactamente.

>>> Que quitando los casos de las ADSL's que he comentado antes, no sería
>>> la primera vez que el que se dedica a estas cosillas en una empresa,
>>> ha decidido contratar una fibra de principal con Operador A, y como es
>>> muy precavido, pues ha contratado una fibra de backup con el Operador
>>> B, por si le falla la principal... Pero vaya, ahora resulta que no ha
>>> tenido en cuenta que el Operador B le alquila la fibra al Operador A.
>>> Vamos, que si cortan el mazo, se va a colgar bastantes medallas...
>>
>> Pues por eso te comentaba que _no hay competencia real_ en el sector,
>> de lo contrario tendrías operadores B, C y D con líneas, servicios y
>> cableados propios y con buenos precios porque todos estarían dándose de
>> tortas para captar clientes.
>
> Uuuffff, tu ya hablas de cuando se ha tenido en cuenta a la hora de
> contratar un backup y no hay alternativa, y yo estoy hablando de que ni
> se tiene en cuenta, sino que, contrato otra fibra (o ADSL, da igual) con
> otro Operador y ya estoy cubierto por sí se cae la principal, sin pensar
> en que al final es el mismo cable...

Es que no puede ser el mismo cable siempre y cuando se cumplan los
siguientes requisitos básicos para una línea de seguridad:

1/ Estar contratada con un proveedor (y carrier) distinto de la línea
principal que cuente con infraestructura propia.

2/ Instalación (cableado local) independiente.

3/ Conectada a un sistema de alimentación redundante.

De todas formas, no parece plausible que ADSL y fifra óptica compartan
cable. Además, el hecho de que se caiga un enlace no implica que el resto
sigan la misma suerte aún siendo del mismo proveedor (en no pocas
ocasiones nos ha fallado un ADSL y hemos seguido funcionado con otros
routers, de ADSL igualmente y de la misma empresa). Es decir, todo
depende del tipo de avería que tenga el proveedor.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kihra0$gst$1...@ger.gmane.org

[Ramses]

Buenas tardes,

El 22/03/2013, a las 15:53, Camaleón <noel...@gmail.com> escribió:

> El Fri, 22 Mar 2013 01:53:09 +0100, Ramses escribió:
>
> ¿Citas correctas? No me lo creo :-)

Con el coraje que te dan los móviles... ;-)

>> El 21/03/2013, a las 22:30, Camaleón <noel...@gmail.com> escribió:
>
> (...)
>
>>> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares y
>>> protocolos así que ese aparato tiene que saber interpretarlos y
>>> gestionarlos para que sea un dispositivo útil, que lo hayan podido
>>> patentar y que además se venda en el mercado. Sinceramente, pensar en
>>> teorías "conspiranoicas" está bien como guión de una película pero poco
>>> más.
>>
>> Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...
>
> Si la cuerda cumple con los estándares y le crimpado un par de "ganchos"
> RJ-45 pues a saber.

Por eso se pueden usar todos esos tipos de enlaces, porque al final se lo van a entregar en ethernet con IP por encima.

>> Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en
>> HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque el
>> tema está a Nivel 7.
>
> Nivel 4, o eso dicen.

Nivel 4 en el modelo TCP/IP, que consolida los Niveles 5, 6 y 7 de OSI, y en el OSI está en el Nivel 7, así que...

>>>> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
>>>> hablemos de descargas, solo las HTTP.
>>>
>>> Hombre, menos mal.
>>
>> Lo llevo diciendo desde que hablé con ellos, tira de histórico, que
>> dicen que suman BW solo y exclusivamente para el caso de tráfico con
>> protocolo HTTP.

¿Discutir?, nada, sólo estamos intercambiando opiniones...

> Pues entonces no sé qué seguimos discutiendo, exactamente.
>
>>>> Que quitando los casos de las ADSL's que he comentado antes, no sería
>>>> la primera vez que el que se dedica a estas cosillas en una empresa,
>>>> ha decidido contratar una fibra de principal con Operador A, y como es
>>>> muy precavido, pues ha contratado una fibra de backup con el Operador
>>>> B, por si le falla la principal... Pero vaya, ahora resulta que no ha
>>>> tenido en cuenta que el Operador B le alquila la fibra al Operador A.
>>>> Vamos, que si cortan el mazo, se va a colgar bastantes medallas...
>>>
>>> Pues por eso te comentaba que _no hay competencia real_ en el sector,
>>> de lo contrario tendrías operadores B, C y D con líneas, servicios y
>>> cableados propios y con buenos precios porque todos estarían dándose de
>>> tortas para captar clientes.
>>
>> Uuuffff, tu ya hablas de cuando se ha tenido en cuenta a la hora de
>> contratar un backup y no hay alternativa, y yo estoy hablando de que ni
>> se tiene en cuenta, sino que, contrato otra fibra (o ADSL, da igual) con
>> otro Operador y ya estoy cubierto por sí se cae la principal, sin pensar
>> en que al final es el mismo cable...
>
> Es que no puede ser el mismo cable siempre y cuando se cumplan los
> siguientes requisitos básicos para una línea de seguridad:
>
> 1/ Estar contratada con un proveedor (y carrier) distinto de la línea
> principal que cuente con infraestructura propia.
>
> 2/ Instalación (cableado local) independiente.
>
> 3/ Conectada a un sistema de alimentación redundante.

Claro, por eso digo, que eso sería lo que debiera de comprobarse, pero no siempre lo hacen antes de contratar... :-)

> De todas formas, no parece plausible que ADSL y fifra óptica compartan
> cable. Además, el hecho de que se caiga un enlace no implica que el resto
> sigan la misma suerte aún siendo del mismo proveedor (en no pocas
> ocasiones nos ha fallado un ADSL y hemos seguido funcionado con otros
> routers, de ADSL igualmente y de la misma empresa). Es decir, todo
> depende del tipo de avería que tenga el proveedor.

Je, je, no, a lo mejor cable no, pero sí canalización o un tubo está junto al otro, y cuando una retroescavadora contra-ataca, no perdona...

Pero claro, serían casos ideales...


Saludos,

Ramses

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/7D1A66F5-56B7-4268...@gmail.com

[Camaleón]

El Fri, 22 Mar 2013 16:18:42 +0100, Ramses escribió:

> El 22/03/2013, a las 15:53, Camaleón <noel...@gmail.com> escribió:
>
>> El Fri, 22 Mar 2013 01:53:09 +0100, Ramses escribió:
>>
>> ¿Citas correctas? No me lo creo :-)
>
> Con el coraje que te dan los móviles... ;-)

Y más aún los iPhone que les tengo una tírria... pero mira, si respetan
los hilados bienvenidos sean.

>>> El 21/03/2013, a las 22:30, Camaleón <noel...@gmail.com> escribió:
>>
>> (...)
>>
>>>> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares
>>>> y protocolos así que ese aparato tiene que saber interpretarlos y
>>>> gestionarlos para que sea un dispositivo útil, que lo hayan podido
>>>> patentar y que además se venda en el mercado. Sinceramente, pensar en
>>>> teorías "conspiranoicas" está bien como guión de una película pero
>>>> poco más.
>>>
>>> Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...
>>
>> Si la cuerda cumple con los estándares y le crimpado un par de
>> "ganchos" RJ-45 pues a saber.
>
> Por eso se pueden usar todos esos tipos de enlaces, porque al final se
> lo van a entregar en ethernet con IP por encima.

¿Y qué te hace pensar que el dispositivo Truffle Lite no cumple con los
estándares y protocolos? Si así fuera no funcionaría, sería un simple
ladrillo de kilo y medio de peso.

Vuelvo a recordarte que esa tecnología ya la están usando los propios ISP
con sus enlaces, internamente, en ubicaciones donde no llega más
velocidad y donde se usa MLPPP. De todas formas, creo que ya dije antes
que este tipo de dispositivos se basaban en MPLS aunque este
concretamente de Mushroom Networks lo desconozco.

>>> Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en
>>> HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque el
>>> tema está a Nivel 7.
>>
>> Nivel 4, o eso dicen.
>
> Nivel 4 en el modelo TCP/IP, que consolida los Niveles 5, 6 y 7 de OSI,
> y en el OSI está en el Nivel 7, así que...

Y al que se le suman el 1, 2 y 3. Vamos, todo el OSI completo, ya que
estamos.

>>>>> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
>>>>> hablemos de descargas, solo las HTTP.
>>>>
>>>> Hombre, menos mal.
>>>
>>> Lo llevo diciendo desde que hablé con ellos, tira de histórico, que
>>> dicen que suman BW solo y exclusivamente para el caso de tráfico con
>>> protocolo HTTP.
>
> ¿Discutir?, nada, sólo estamos intercambiando opiniones...
>
>> Pues entonces no sé qué seguimos discutiendo, exactamente.

Pues eso, "discutir" :-)

***
(Del lat. discutĕre, disipar, resolver).

1. tr. Dicho de dos o más personas: Examinar atenta y particularmente una
materia.

2. tr. Contender y alegar razones contra el parecer de alguien. Todos
discutían sus decisiones. U. m. c. intr. Discutieron con el contratista
sobre el precio de la obra.
***

>>> Uuuffff, tu ya hablas de cuando se ha tenido en cuenta a la hora de
>>> contratar un backup y no hay alternativa, y yo estoy hablando de que
>>> ni se tiene en cuenta, sino que, contrato otra fibra (o ADSL, da
>>> igual) con otro Operador y ya estoy cubierto por sí se cae la
>>> principal, sin pensar en que al final es el mismo cable...
>>
>> Es que no puede ser el mismo cable siempre y cuando se cumplan los
>> siguientes requisitos básicos para una línea de seguridad:
>>
>> 1/ Estar contratada con un proveedor (y carrier) distinto de la línea
>> principal que cuente con infraestructura propia.
>>
>> 2/ Instalación (cableado local) independiente.
>>
>> 3/ Conectada a un sistema de alimentación redundante.
>
>
> Claro, por eso digo, que eso sería lo que debiera de comprobarse, pero
> no siempre lo hacen antes de contratar... :-)

Ah, pensaba que eras tú mismo quién se encargaba de eso. Pues ya puedes
ir pidiendo un aumento de sueldo y asignarte nuevas funciones ;-)

>> De todas formas, no parece plausible que ADSL y fifra óptica compartan
>> cable. Además, el hecho de que se caiga un enlace no implica que el
>> resto sigan la misma suerte aún siendo del mismo proveedor (en no pocas
>> ocasiones nos ha fallado un ADSL y hemos seguido funcionado con otros
>> routers, de ADSL igualmente y de la misma empresa). Es decir, todo
>> depende del tipo de avería que tenga el proveedor.
>
> Je, je, no, a lo mejor cable no, pero sí canalización o un tubo está
> junto al otro, y cuando una retroescavadora contra-ataca, no perdona...
>
> Pero claro, serían casos ideales...

Para eso están los enlaces inalámbricos (3G/4G -que por cierto, el
Truffle Lite ese los tiene-, wireless wan, satélite...).

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kihumn$gst$3...@ger.gmane.org

[Ramses]

Buenas tardes,

El 22/03/2013, a las 16:51, Camaleón <noel...@gmail.com> escribió:

> El Fri, 22 Mar 2013 16:18:42 +0100, Ramses escribió:
>
>> El 22/03/2013, a las 15:53, Camaleón <noel...@gmail.com> escribió:
>>
>>> El Fri, 22 Mar 2013 01:53:09 +0100, Ramses escribió:
>>>
>>> ¿Citas correctas? No me lo creo :-)
>>
>> Con el coraje que te dan los móviles... ;-)
>
> Y más aún los iPhone que les tengo una tírria... pero mira, si respetan
> los hilados bienvenidos sean.
>
>>>> El 21/03/2013, a las 22:30, Camaleón <noel...@gmail.com> escribió:
>>>
>>> (...)
>>>
>>>>> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos estándares
>>>>> y protocolos así que ese aparato tiene que saber interpretarlos y
>>>>> gestionarlos para que sea un dispositivo útil, que lo hayan podido
>>>>> patentar y que además se venda en el mercado. Sinceramente, pensar en
>>>>> teorías "conspiranoicas" está bien como guión de una película pero
>>>>> poco más.
>>>>
>>>> Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...
>>>
>>> Si la cuerda cumple con los estándares y le crimpado un par de
>>> "ganchos" RJ-45 pues a saber.
>>
>> Por eso se pueden usar todos esos tipos de enlaces, porque al final se
>> lo van a entregar en ethernet con IP por encima.
>
> ¿Y qué te hace pensar que el dispositivo Truffle Lite no cumple con los
> estándares y protocolos? Si así fuera no funcionaría, sería un simple
> ladrillo de kilo y medio de peso.

Yo no he dicho que no cumpla los estándares, al contrario, he dicho que sí suma el BW para las descargas HTTP poniendo un cacharro en un único extremo, es porque es porque tiene que estar definido en el estándar, porque si no, el server HTTP le diría "tururú".

> Vuelvo a recordarte que esa tecnología ya la están usando los propios ISP
> con sus enlaces, internamente, en ubicaciones donde no llega más
> velocidad y donde se usa MLPPP. De todas formas, creo que ya dije antes
> que este tipo de dispositivos se basaban en MPLS aunque este
> concretamente de Mushroom Networks lo desconozco.

Claro, con MLPPP lo hacen, pero controlando ambos extremos, haciendo peering, ahí no hay problema. De hecho, con algunos puedes contratarlo...

Si fuera a nivel MPLS, no habría problema si el tráfico es HTTP o FTP, porque estos están muy por encima del nivel MPLS.

>>>> Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en
>>>> HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque el
>>>> tema está a Nivel 7.
>>>
>>> Nivel 4, o eso dicen.
>>
>> Nivel 4 en el modelo TCP/IP, que consolida los Niveles 5, 6 y 7 de OSI,
>> y en el OSI está en el Nivel 7, así que...
>
> Y al que se le suman el 1, 2 y 3. Vamos, todo el OSI completo, ya que
> estamos.

Je, je, yo te hablaba del Nivel 7 del OSI y tú me dices que es el 4 del modelo TCP/IP. Ya ves...

>>>>>> Sí, sí, si yo estoy contigo, sumar el BW pero, para los casos que
>>>>>> hablemos de descargas, solo las HTTP.
>>>>>
>>>>> Hombre, menos mal.
>>>>
>>>> Lo llevo diciendo desde que hablé con ellos, tira de histórico, que
>>>> dicen que suman BW solo y exclusivamente para el caso de tráfico con
>>>> protocolo HTTP.
>>
>> ¿Discutir?, nada, sólo estamos intercambiando opiniones...
>>
>>> Pues entonces no sé qué seguimos discutiendo, exactamente.
>
> Pues eso, "discutir" :-)
>
> ***
> (Del lat. discutĕre, disipar, resolver).
>
> 1. tr. Dicho de dos o más personas: Examinar atenta y particularmente una
> materia.
>
> 2. tr. Contender y alegar razones contra el parecer de alguien. Todos
> discutían sus decisiones. U. m. c. intr. Discutieron con el contratista
> sobre el precio de la obra.
> ***

Uuufff, es que está muy feo, discutir, contienda,..., al final, es que se habían peleado...

>>>> Uuuffff, tu ya hablas de cuando se ha tenido en cuenta a la hora de
>>>> contratar un backup y no hay alternativa, y yo estoy hablando de que
>>>> ni se tiene en cuenta, sino que, contrato otra fibra (o ADSL, da
>>>> igual) con otro Operador y ya estoy cubierto por sí se cae la
>>>> principal, sin pensar en que al final es el mismo cable...
>>>
>>> Es que no puede ser el mismo cable siempre y cuando se cumplan los
>>> siguientes requisitos básicos para una línea de seguridad:
>>>
>>> 1/ Estar contratada con un proveedor (y carrier) distinto de la línea
>>> principal que cuente con infraestructura propia.
>>>
>>> 2/ Instalación (cableado local) independiente.
>>>
>>> 3/ Conectada a un sistema de alimentación redundante.
>>
>>
>> Claro, por eso digo, que eso sería lo que debiera de comprobarse, pero
>> no siempre lo hacen antes de contratar... :-)
>
> Ah, pensaba que eras tú mismo quién se encargaba de eso. Pues ya puedes
> ir pidiendo un aumento de sueldo y asignarte nuevas funciones ;-)

Es algunos casos sí, pero en otros, me toca ir a arreglar los "desaguisados" que montan los que tienen atribuidas tanto las funciones como el sueldo... ;-)

>>> De todas formas, no parece plausible que ADSL y fifra óptica compartan
>>> cable. Además, el hecho de que se caiga un enlace no implica que el
>>> resto sigan la misma suerte aún siendo del mismo proveedor (en no pocas
>>> ocasiones nos ha fallado un ADSL y hemos seguido funcionado con otros
>>> routers, de ADSL igualmente y de la misma empresa). Es decir, todo
>>> depende del tipo de avería que tenga el proveedor.
>>
>> Je, je, no, a lo mejor cable no, pero sí canalización o un tubo está
>> junto al otro, y cuando una retroescavadora contra-ataca, no perdona...
>>
>> Pero claro, serían casos ideales...
>
> Para eso están los enlaces inalámbricos (3G/4G -que por cierto, el
> Truffle Lite ese los tiene-, wireless wan, satélite...).

Claro, lo que comentaba, distinto Operador, distinta tecnología, distinto camino,...


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/A8AFE008-B419-48DD...@gmail.com

[Camaleón]

El Fri, 22 Mar 2013 17:40:34 +0100, Ramses escribió:

> El 22/03/2013, a las 16:51, Camaleón <noel...@gmail.com> escribió:

(...)

>>>>>> Todas esas conexiones (DSL, DOCSIS y T1) cumplen con unos
>>>>>> estándares y protocolos así que ese aparato tiene que saber
>>>>>> interpretarlos y gestionarlos para que sea un dispositivo útil, que
>>>>>> lo hayan podido patentar y que además se venda en el mercado.
>>>>>> Sinceramente, pensar en teorías "conspiranoicas" está bien como
>>>>>> guión de una película pero poco más.
>>>>>
>>>>> Claro, como si conectas una cuerda, si sobre la cuerda fuese IP...
>>>>
>>>> Si la cuerda cumple con los estándares y le crimpado un par de
>>>> "ganchos" RJ-45 pues a saber.
>>>
>>> Por eso se pueden usar todos esos tipos de enlaces, porque al final se
>>> lo van a entregar en ethernet con IP por encima.
>>
>> ¿Y qué te hace pensar que el dispositivo Truffle Lite no cumple con los
>> estándares y protocolos? Si así fuera no funcionaría, sería un simple
>> ladrillo de kilo y medio de peso.
>
> Yo no he dicho que no cumpla los estándares, al contrario, he dicho que
> sí suma el BW para las descargas HTTP poniendo un cacharro en un único
> extremo, es porque es porque tiene que estar definido en el estándar,
> porque si no, el server HTTP le diría "tururú".

Ah, vale :-)

>> Vuelvo a recordarte que esa tecnología ya la están usando los propios
>> ISP con sus enlaces, internamente, en ubicaciones donde no llega más
>> velocidad y donde se usa MLPPP. De todas formas, creo que ya dije antes
>> que este tipo de dispositivos se basaban en MPLS aunque este
>> concretamente de Mushroom Networks lo desconozco.
>
> Claro, con MLPPP lo hacen, pero controlando ambos extremos, haciendo
> peering, ahí no hay problema. De hecho, con algunos puedes
> contratarlo...

Exacto. Y parece que en Reino Unido es bastante habitual:

http://www.broadbandgenie.co.uk/blog/20120214-double-speed-rural-broadband-beginners-guide-bonded-dsl-part-1

Aquí en España no he oído nada de eso, al menos no "comercialmente".
Quizá si lo solicitas a Telefónica (siendo empresa) te puedan ofrecer
algún apaño (p. ej., antes de contratar fibra pedimos presupuesto para
enlaces ADSL simétricos -que no se ofertan en su web o al menos no les
dan mucha publicidad- pero lo descartamos eran *muy* caros).

> Si fuera a nivel MPLS, no habría problema si el tráfico es HTTP o FTP,
> porque estos están muy por encima del nivel MPLS.

Pues tanto el MLPPP como MPLS están quedando desfasados.

>>>>> Es que si la historia fuese a Nivel 2, sumarían tanto en FTP como en
>>>>> HTTP, pero cuando lo pueden hacer en uno y no en el otro, es porque
>>>>> el tema está a Nivel 7.
>>>>
>>>> Nivel 4, o eso dicen.
>>>
>>> Nivel 4 en el modelo TCP/IP, que consolida los Niveles 5, 6 y 7 de
>>> OSI, y en el OSI está en el Nivel 7, así que...
>>
>> Y al que se le suman el 1, 2 y 3. Vamos, todo el OSI completo, ya que
>> estamos.
>
> Je, je, yo te hablaba del Nivel 7 del OSI y tú me dices que es el 4 del
> modelo TCP/IP. Ya ves...

Estamos hablando (o al menos yo estaba hablando) de las capas OSI, la
capa de transporte que corresponde a la 4, para ser más exactos.

>>> ¿Discutir?, nada, sólo estamos intercambiando opiniones...
>>>
>>>> Pues entonces no sé qué seguimos discutiendo, exactamente.
>>
>> Pues eso, "discutir" :-)
>>
>> ***
>> (Del lat. discutĕre, disipar, resolver).

(...)

> Uuufff, es que está muy feo, discutir, contienda,..., al final, es que
> se habían peleado...

El término tiene mala fama porque casi siempre se usa como algo
peyorativo pero no tiene por qué. También hay discusiones productivas.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kii3qp$gst$6...@ger.gmane.org

[Ramses II]

Buenos días,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: viernes, 22 de marzo de 2013 18:19

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

------------------------------------

Claro, estos de Eclipse ponen varias ADSL's y hacen bonding, pero todas son suyas y controlan todo desde los niveles inferiores.

Aquí hay algún operador que creo que te lo puede llegar a hacer extraoficialmente. O por lo menos, eso cuentan las malas lenguas por ahí...

Lo que yo comenté de los niveles, es que si los de Mushroom Networks estarán haciendo el tema de la suma del BW para HTTP en el Nivel 7 de OSI, porque si lo estuvieran haciendo en los niveles inferiores, por ejemplo el Nivel 2 de OSI, no existiría el problema de si es un tipo de tráfico u otro, lo sumarían todo. Por eso comentaba, que tiene que existir alguna facilidad/funcionalidad, o como queramos llamarlo, definido en el protocolo HTTP, para que, sin controlar ambos extremos, se pueda sumar el BW de varias conexiones para el tráfico HTTP, ya que el servidor HTTP remoto tiene que aclararse de qué hacer cuando le llegue una petición para la descarga de un mismo fichero desde dos IP's distintas, y mandar un trocito a cada IP en vez de mandar el fichero completo a cada IP.

Estoy contigo en lo de hay discusiones productivas...


P.D.: Ya he vuelto a las andadas con el Cliente de Correo... :-)

Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/01a001ce2958$f5ed8d10$e1c8a730$@gmail.com

[Camaleón]

El Mon, 25 Mar 2013 14:02:02 +0100, Ramses II escribió:

> Buenos días,

(ouch... vuelve "Er Cliente Maldito")

> Claro, estos de Eclipse ponen varias ADSL's y hacen bonding, pero todas
> son suyas y controlan todo desde los niveles inferiores.

¿Qué o quiénes son "esos de Eclipse"? (buscando...) Ah, un operador (ISP)
británico, okay.

> Aquí hay algún operador que creo que te lo puede llegar a hacer
> extraoficialmente. O por lo menos, eso cuentan las malas lenguas por
> ahí...

¿Dices en España? No me extrañaría nada que lo permitan, al menos a
ciertos clientes y a cierto nivel (es decir, con "$$$" de por medio).

Colt y BT son poco conocidas para los usuarios de a pie pero ofrecen (u
ofrecían al menos) servicios majetes para empresas. Y si mal no recuerdo,
estos tiene red propia.

> Lo que yo comenté de los niveles, es que si los de Mushroom Networks
> estarán haciendo el tema de la suma del BW para HTTP en el Nivel 7 de
> OSI,

Es que creo que lo hacen desde la capa de transporte (4).

> porque si lo estuvieran haciendo en los niveles inferiores, por ejemplo
> el Nivel 2 de OSI, no existiría el problema de si es un tipo de tráfico
> u otro, lo sumarían todo. Por eso comentaba, que tiene que existir
> alguna facilidad/funcionalidad, o como queramos llamarlo, definido en
> el protocolo HTTP, para que, sin controlar ambos extremos, se pueda
> sumar el BW de varias conexiones para el tráfico HTTP, ya que el
> servidor HTTP remoto tiene que aclararse de qué hacer cuando le llegue
> una petición para la descarga de un mismo fichero desde dos IP's
> distintas, y mandar un trocito a cada IP en vez de mandar el fichero
> completo a cada IP.

Pues no lo sé, pero entiendo que se inicia en la capa 4 y después
necesitarán la colaboración necesaria para gestionar el tráfico del que
se trate (http en este caso) y esto sí se gestiona en la capa 7.

> Estoy contigo en lo de hay discusiones productivas...
>
>
> P.D.: Ya he vuelto a las andadas con el Cliente de Correo... :-)

Sí, ya lo vi venir...

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kipo1i$dte$4...@ger.gmane.org

[Ramses]

Buenas tardes,

El 25/03/2013, a las 15:47, Camaleón <noel...@gmail.com> escribió:

> El Mon, 25 Mar 2013 14:02:02 +0100, Ramses II escribió:
>
>> Buenos días,
>
> (ouch... vuelve "Er Cliente Maldito")
>
>> Claro, estos de Eclipse ponen varias ADSL's y hacen bonding, pero todas
>> son suyas y controlan todo desde los niveles inferiores.
>
> ¿Qué o quiénes son "esos de Eclipse"? (buscando...) Ah, un operador (ISP)
> británico, okay.

Sí, son de los que se hablan en el enlace que me mandaste...

>> Aquí hay algún operador que creo que te lo puede llegar a hacer
>> extraoficialmente. O por lo menos, eso cuentan las malas lenguas por
>> ahí...
>
> ¿Dices en España? No me extrañaría nada que lo permitan, al menos a
> ciertos clientes y a cierto nivel (es decir, con "$$$" de por medio).

;-)

> Colt y BT son poco conocidas para los usuarios de a pie pero ofrecen (u
> ofrecían al menos) servicios majetes para empresas. Y si mal no recuerdo,
> estos tiene red propia.

Bueno, sí, aunque también te puedes encontrar con que alguno de ellos use la infraestructura de algún otro... ;-)

>> Lo que yo comenté de los niveles, es que si los de Mushroom Networks
>> estarán haciendo el tema de la suma del BW para HTTP en el Nivel 7 de
>> OSI,
>
> Es que creo que lo hacen desde la capa de transporte (4).

¿Crees qué si lo hicieran desde el Nivel 4 importaría qué protocolo del Nivel 7 fuese el transportado?.

¿No se pensó precisamente en el modelo OSI, entre otras cosas, para independizar los niveles?

>> porque si lo estuvieran haciendo en los niveles inferiores, por ejemplo
>> el Nivel 2 de OSI, no existiría el problema de si es un tipo de tráfico
>> u otro, lo sumarían todo. Por eso comentaba, que tiene que existir
>> alguna facilidad/funcionalidad, o como queramos llamarlo, definido en
>> el protocolo HTTP, para que, sin controlar ambos extremos, se pueda
>> sumar el BW de varias conexiones para el tráfico HTTP, ya que el
>> servidor HTTP remoto tiene que aclararse de qué hacer cuando le llegue
>> una petición para la descarga de un mismo fichero desde dos IP's
>> distintas, y mandar un trocito a cada IP en vez de mandar el fichero
>> completo a cada IP.
>
> Pues no lo sé, pero entiendo que se inicia en la capa 4 y después
> necesitarán la colaboración necesaria para gestionar el tráfico del que
> se trate (http en este caso) y esto sí se gestiona en la capa 7.

Si se iniciara en el Nivel 4 creo que se podría hacer la suma con cualquier protocolo de la Capa de Aplicación.

>> Estoy contigo en lo de hay discusiones productivas...
>>
>>
>> P.D.: Ya he vuelto a las andadas con el Cliente de Correo... :-)
>
> Sí, ya lo vi venir...

:-(

Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/13B7BFC5-36B2-450C...@gmail.com

[Camaleón]

El Mon, 25 Mar 2013 17:22:35 +0100, Ramses escribió:

> El 25/03/2013, a las 15:47, Camaleón <noel...@gmail.com> escribió:

(...)

>>> Claro, estos de Eclipse ponen varias ADSL's y hacen bonding, pero
>>> todas son suyas y controlan todo desde los niveles inferiores.
>>
>> ¿Qué o quiénes son "esos de Eclipse"? (buscando...) Ah, un operador
>> (ISP) británico, okay.
>
> Sí, son de los que se hablan en el enlace que me mandaste...

O:-)

A BT y O2 (y me parece que esta última ya no existe) sí las tengo en mi
radar automático de British-ISP pero no a Eclipse (y mira que en el
artículo ponen una imagen bien gordota). Entre eso y el tiempo que ha
pasado desde que mandé el enlace... pues ya ves, ni me acordaba.

>>> Aquí hay algún operador que creo que te lo puede llegar a hacer
>>> extraoficialmente. O por lo menos, eso cuentan las malas lenguas por
>>> ahí...

(...)

>> Colt y BT son poco conocidas para los usuarios de a pie pero ofrecen (u
>> ofrecían al menos) servicios majetes para empresas. Y si mal no
>> recuerdo, estos tiene red propia.
>
> Bueno, sí, aunque también te puedes encontrar con que alguno de ellos
> use la infraestructura de algún otro... ;-)

Cuenta, cuenta... que esas cosas son interesantes.

>>> Lo que yo comenté de los niveles, es que si los de Mushroom Networks
>>> estarán haciendo el tema de la suma del BW para HTTP en el Nivel 7 de
>>> OSI,
>>
>> Es que creo que lo hacen desde la capa de transporte (4).
>
> ¿Crees qué si lo hicieran desde el Nivel 4 importaría qué protocolo del
> Nivel 7 fuese el transportado?.

Pues eso es lo que dicen las "malas lenguas" (léase, el artículo de
Wikipedia¹), que este tipo de "bonding" modernico se inicia en esta capa.

> ¿No se pensó precisamente en el modelo OSI, entre otras cosas, para
> independizar los niveles?

El nombre lo dice (casi) todo: Modelo de *Interconexión* de Sistemas
Abiertos (je, "MISA", será que estamos en semana santa).

>>> porque si lo estuvieran haciendo en los niveles inferiores, por
>>> ejemplo el Nivel 2 de OSI, no existiría el problema de si es un tipo
>>> de tráfico u otro, lo sumarían todo. Por eso comentaba, que tiene que
>>> existir alguna facilidad/funcionalidad, o como queramos llamarlo,
>>> definido en el protocolo HTTP, para que, sin controlar ambos extremos,
>>> se pueda sumar el BW de varias conexiones para el tráfico HTTP, ya que
>>> el servidor HTTP remoto tiene que aclararse de qué hacer cuando le
>>> llegue una petición para la descarga de un mismo fichero desde dos
>>> IP's distintas, y mandar un trocito a cada IP en vez de mandar el
>>> fichero completo a cada IP.
>>
>> Pues no lo sé, pero entiendo que se inicia en la capa 4 y después
>> necesitarán la colaboración necesaria para gestionar el tráfico del que
>> se trate (http en este caso) y esto sí se gestiona en la capa 7.
>
> Si se iniciara en el Nivel 4 creo que se podría hacer la suma con
> cualquier protocolo de la Capa de Aplicación.

(...)

Ya ves.

¹http://en.wikipedia.org/wiki/Broadband_bonding

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kipupv$dte$7...@ger.gmane.org

[Ramses II]

Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noel...@gmail.com]

Enviado el: lunes, 25 de marzo de 2013 17:43

Para: debian-us...@lists.debian.org
Asunto: Re: 2 isp [ot]

----------------------------
Si Mushroom se basara en esto, y realmente se estuviese haciendo el bonding a Nivel 4, podrían sumar tanto FTP como HTTP...

En el link que has pasado dice que: "Broadband bonding is a type of channel bonding that refers to aggregation of multiple channels at OSI layers at level four or above."

Así que, los de Mushroom lo estarán haciendo "above", porque si lo hicieran a Nivel 4 sería transparente para el Nivel 7, ¿no crees?.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/002701ce2985$199b4b40$4cd1e1c0$@gmail.com

[Camaleón]

El Mon, 25 Mar 2013 19:17:55 +0100, Ramses II escribió:

(...)

>>> Si se iniciara en el Nivel 4 creo que se podría hacer la suma con
>>> cualquier protocolo de la Capa de Aplicación.
>>
>> (...)
>>
>> Ya ves.
>>
>> ¹http://en.wikipedia.org/wiki/Broadband_bonding

> Si Mushroom se basara en esto, y realmente se estuviese haciendo el
> bonding a Nivel 4, podrían sumar tanto FTP como HTTP...

Quizá sea una mera cuestión de marketing, no una limitación técnica, es
decir, que les interesa que se suscriban al servicio "completo" y el
"cebo" es precisamente lo que la gente usa más (descargas HTTP) ya que de
lo contrario ¿por qué aplicarlo a la subida HTTP también?

> En el link que has pasado dice que: "Broadband bonding is a type of
> channel bonding that refers to aggregation of multiple channels at OSI
> layers at level four or above."

Sí, exacto, dice textualmente: "(...) en la capa 4 o superiores".

> Así que, los de Mushroom lo estarán haciendo "above", porque si lo
> hicieran a Nivel 4 sería transparente para el Nivel 7, ¿no crees?.

Entiendo que usarán la capa de transporte para generar esa tubería
virtual con la agregación de los canales de los enlaces de las conexiones
de banda ancha y la capa de aplicación que afecta sólo al tráfico HTTP de
bajada.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kiq5r3$dte$8...@ger.gmane.org

[Ramses]

Buenas tardes,

El 25/03/2013, a las 19:42, Camaleón <noel...@gmail.com> escribió:

> El Mon, 25 Mar 2013 19:17:55 +0100, Ramses II escribió:
>
> (...)
>
>>>> Si se iniciara en el Nivel 4 creo que se podría hacer la suma con
>>>> cualquier protocolo de la Capa de Aplicación.
>>>
>>> (...)
>>>
>>> Ya ves.
>>>
>>> ¹http://en.wikipedia.org/wiki/Broadband_bonding
>
>> Si Mushroom se basara en esto, y realmente se estuviese haciendo el
>> bonding a Nivel 4, podrían sumar tanto FTP como HTTP...
>
> Quizá sea una mera cuestión de marketing, no una limitación técnica, es
> decir, que les interesa que se suscriban al servicio "completo" y el
> "cebo" es precisamente lo que la gente usa más (descargas HTTP) ya que de
> lo contrario ¿por qué aplicarlo a la subida HTTP también?

No entiendo por qué no aplicarlo en ambos sentidos...

>> En el link que has pasado dice que: "Broadband bonding is a type of
>> channel bonding that refers to aggregation of multiple channels at OSI
>> layers at level four or above."
>
> Sí, exacto, dice textualmente: "(...) en la capa 4 o superiores".
>
>> Así que, los de Mushroom lo estarán haciendo "above", porque si lo
>> hicieran a Nivel 4 sería transparente para el Nivel 7, ¿no crees?.
>
> Entiendo que usarán la capa de transporte para generar esa tubería
> virtual con la agregación de los canales de los enlaces de las conexiones
> de banda ancha y la capa de aplicación que afecta sólo al tráfico HTTP de
> bajada.

Creo que dicen que suman el BW en ambos sentidos.


Saludos,

Ramsés

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/0C083ED3-30E3-4F69...@gmail.com

[Camaleón]

El Mon, 25 Mar 2013 20:04:09 +0100, Ramses escribió:

> El 25/03/2013, a las 19:42, Camaleón <noel...@gmail.com> escribió:

(...)

>>>> ¹http://en.wikipedia.org/wiki/Broadband_bonding
>>
>>> Si Mushroom se basara en esto, y realmente se estuviese haciendo el
>>> bonding a Nivel 4, podrían sumar tanto FTP como HTTP...
>>
>> Quizá sea una mera cuestión de marketing, no una limitación técnica, es
>> decir, que les interesa que se suscriban al servicio "completo" y el
>> "cebo" es precisamente lo que la gente usa más (descargas HTTP) ya que
>> de lo contrario ¿por qué aplicarlo a la subida HTTP también?
>
> No entiendo por qué no aplicarlo en ambos sentidos...

¿Verdad? A mí me parece una decisión arbitraria y por lo general este
tipo de decisiones ilógicas vienen inducidas por el departamento de
marketing más que por un impedimento puramente técnico.

>>> En el link que has pasado dice que: "Broadband bonding is a type of
>>> channel bonding that refers to aggregation of multiple channels at OSI
>>> layers at level four or above."
>>
>> Sí, exacto, dice textualmente: "(...) en la capa 4 o superiores".
>>
>>> Así que, los de Mushroom lo estarán haciendo "above", porque si lo
>>> hicieran a Nivel 4 sería transparente para el Nivel 7, ¿no crees?.
>>
>> Entiendo que usarán la capa de transporte para generar esa tubería
>> virtual con la agregación de los canales de los enlaces de las
>> conexiones de banda ancha y la capa de aplicación que afecta sólo al
>> tráfico HTTP de bajada.
>
> Creo que dicen que suman el BW en ambos sentidos.

Pues si no recuerdo mal era sólo para la descarga, pero para estar
seguros podemos volver a consultarlo en su FAQ:

***
1. Let's say I have 4 DSL lines with 6Mbps downlink speed each, after I
install Internet load balancer, Truffle Lite, how fast will I be able to
download files?

Truffle Lite will aggregate all the 4 DSL lines that are connected to the
WAN ports and file downloads will be around 4 x 6 = 24 Mbps. Truffle Lite
can provide aggregate throughputs of up to 95Mbps.
***

En este punto habla de descargas (downloads).

***
10. Do I need the "Broadband Bonding Service" subscription with my
Truffle Lite device?

No. All Truffle devices will provide http downlink bonding and
intelligent load-balancing for uplink and non-http traffic without
requiring the monthly Broadband Bonding Service. Broadband Bonding
Service will however provide additional bonding capability enabling
bonding for all protocols in uplink and downlink.
***

Y aquí vuelve a remarcar que el bonding es para el tráfico HTTP de bajada.

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/kisa6i$tml$1...@ger.gmane.org