Re: [OT] ¿Cambian los ISP el ToS?
Vamos por partes porque veo que no me estás entendiendo ...
----- Mensaje original -----
> De: "José Miguel (sio2)" <sio2.sio2+lista.debian@gmail.com>
> Para: debian-user-spanish@lists.debian.org
> Enviados: Miércoles, 13 de Mayo 2015 19:37:01
> Asunto: Re: [OT] ¿Cambian los ISP el ToS?
> El Wed, 13 de May de 2015, a las 07:56:42PM +0200, Raúl Alexis Betancor Santana
> dijo:
>
>> Es que estás cometiendo varios errores de base ...
>
> A ver.
>
>> 1- En el router que te hace NAT (porque supongo que lo tienes en
>> multipuesto y el router te hace NAT), es el propio router quien SEGÚN
>> su politica de QoS ... cambiará los valores que envía a la WAN, esto
>> es lo más normal del mundo.
>
> Bueno, he dicho que esa es una posibilidad y por eso pregunto. Lo que
> ocurre es que he hecho pruebas con cuatro sitios distintos:
>
> 1. Dos cuyos router tendría que ver si realmente modifican el byte, porque
> disponen de sistemas de estos de administración por web y una interfaz
> telnet.
>
> 2. Otro que es un VPN con IP compartida. Ahí, obviamente no controlo más
> allá de la propia máquina virtual.
>
> 3. Otro que es el de mi casa y tiene instalado openWRT. Aquí se
> fehacientemente que no hay aplicada ninguna política. El problema es
> que no tengo contratado con Telefónica sino con otro operador
> (Vodafone).
>
> Pues bien escoja el origen y el destino que sea, siempre se produce el
> mismo resultado. Si los ISP no hicieran ninguna modificación en el
> camino y todo fuera culpa de mis routers, como sé que el que lleva
> openwrt no hace ningún tipo de modificación, en caso de que comunicara éste
> con cualquiera de las máquinas que hay detrás de los otros tres, en estas
> máquinas vería llegar el paquete con el DSCP original. Pero eso no
> ocurre.
Que da igual si es tu router, o el del operador .. TU no puedes controlar por donde va a pasar ese paquete ... y entre todos los routers/switches por los que pase, UNO habrá que borrarrá los campos, es que no hay ningún RFC que diga que esos campos se tengan que respetar extremo a extremo ... y como tál NADIE los respeta.
>> 2- Los operados NO RESPETAN, los valores de QoS que tu utilices ...,
>> no tienen porque hacerlo y de hecho, no lo hacen, ya que aplican sus
>> propias políticas.
>
> Desde mi más completa ignorancia de los protocolos de enrutamiento que
> usan en sus routers. ¿Forzosamente lo tienen que hacer a través del
> byte ToS de la cabecera IP? Sí, ya sé que está para eso.
Lo puedes hacer, y lo hacen, por cuarentamil parámetros diferentes, eso es política del operador, política que puede variar interfaz a interfaz, de router en router, conclusión = no te bases en eso.
>> 3- Sigue el consejo que te puse en el otro correo ... preocupate de
>> clasificar, prioritizar y limitar LO QUE ENVIAS, lo que recibes ... no
>> lo puedes controlar, en todo caso ... no en la eth0 ... sino en la
>> eth1, osea ... dale la vuelta a la 'tortilla'.
>
> Eso no es cierto, lo que recibo lo puedo clasificar perfectamente, no
> ciertamente en la planificación ingress de eth0, sino en la salida de
> una interfaz virtual ifb a la que puedo redirigir los paquetes. La única
> limitación que hay es que no puedo hacer una clasificación "stateful"
> (pues para eso necesito netfilter)
Te demuestro cuando quieras, que TU no puedes controlar lo que te entra, ni puedes clasificarlo.
Clasificas lo que tu entrégas, no lo que recibes.
Yo ahora cojo tu IP, y me meto un flood de 4Gb/s ... y te dejo frito, por mucha regla de iptables o de tc que pongas para clasificar o descartar ese tráfico.
TU no controlas lo que te llega a tu interfaz WAN, lo controla TU OPERADOR.
> En eth1 es bastante inútil hacerlo, porque hay tráfico que se queda en
> el servidor y porque en mi caso hay muchas interfaces internas.
No lo has entendido ... los protocolos de control de flujo de TCP, están diseñados para eso ..., como no puedes CONTROLAR lo que te entra por el eth0 ... pero SI lo que tu entregas (proveniente del eth0) al eth1 ... si limitas el tráfico que le entregas a los servidores internos ... AUTOMAGICAMENTE, verás como se empieza a estabilizar el tráfico que te llega al eth0 desde la WAN.
De hecho es el típico ejemplo de porque en la mayoría de los casos, no se puede aprovechar al 100% el ancho de banda de bajada de una ADSL/FTTH, porque sino eres capaz de enviar los ACK's de salida ... el servidor remoto irá reduciendo la tasa a la que te manda tráfico de entrada, hasta llegar a un equilibrio.
El script de QoS que yo uso .. genera clasificadores y colas para la interfaz WAN, de forma que NO permito que SALGA más tráfico de los equipos de LAN, del que yo establezca ... AUNQUE ME ESTE LLEGANDO MAS, lo encolo .. o lo descarto, de esa manera ... fuerzo a los protocolos de control de flujo a hacer su trabajo ...
Lás únicas reglas que tengo para el downlink .. en todo el script ... son:
########## downlink #############
# s1ow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter TCP(Not UDP) traffic from everywhere (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 100 u32 match ip src \
0.0.0.0/0 match ip protocol 6 0xff police rate $[70*$DOWNLINK/100]kbit burst 10k drop flowid :1
Todo lo demás en el script es para controlar el UPLINK, punto pelota.
Repito, NO PUEDES CONTROLAR LO QUE TE LLEGA ... SOLO LO QUE TU MANDAS (ya sea LAN -> WAN ... o WAN -> LAN ... pero JAMÁS puedes controlar lo que llega de Operador -> WAN), la forma 'truquera' de controlarlo ... es no permitir que los equipos manden los ACK's a tasas superiores a las que te interese.
Saludos
Reply to: