[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: 2 isp [ot]



Buenas tardes,

-----Mensaje original-----
De: Camaleón [mailto:noelamac@gmail.com] 
Enviado el: jueves, 21 de marzo de 2013 18:53
Para: debian-user-spanish@lists.debian.org
Asunto: Re: 2 isp [ot]

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?
--------------------------------------------------

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


Reply to: