[uylug-varios] [uylug-linux] Analizar si una conexión está saturada

[Carlos M. Martinez]

Hola!
On 10/17/12 12:59 PM, Eduardo Trápani wrote:
>> Estrictamente lo que esta haciendo el modem no es nisiquiera picar PPP,
>> esta picando Ethernet. Yo tiendo (y pido disculpas) a abusar del
>> lenguaje y a omitir las L2 y las L1 porque las tengo asumidas como
>> overhead :-) Si queres verlo como stack, lo que tenes en el modem es:
> ¡Flor de explicación!  ¡Gracias!  Ta, ahora está clarísimo.  Volviendo
> al origen, entonces para que un modem "sienta" algo diferente por las
> conexiones IP en el tráfico tendría que ser alguna condición de borde
> relacionada con el tamaño de los paquetes, casi un error de firmware,
> ¿no?  ¿O alguna otra cosa en el tráfico lo podría jorobar?
¡Un gusto! :-) Efectivamente, para que el modem fuera causa de este
problema se tendria que dar, me parece, alguna condicion de borde con
respecto al flujo de paquetes, básicamente muchos paquetes chicos
llegando a la vez, que disparen algun bug en la performance de la
'picadora' (el SAR de la ATM Adaptation Layer).

Es lo que pasa cuando los dispositivos dejan de ser totalmente tontos.
¿Quien escucho de un bug en un puerto RS232 o en un modem de 9600? Eran
dispositivos muy tontos, y por ello debugeables e incluso, verificables
formalmente en algunos casos.
> Y, che, pobres L1 y L2 ;).  Sí, fue eso lo que me perdió.  Para mí es al
> revés, intento arrancar desde el "cable" todas las veces para poder
> entender y conversar, sobre todo cuando hay problemas.  Porque sino me
> pierdo :).  Aunque es cierto que para el trabajo del día a día la enorme
> mayoría de las cosas (por suerte) pasa más arriba.
Por eso un poco es que tiendo a olvidarme de ellas. No ayuda que el 90%
de mi vida profesional lo he vivido entre L3 y L4. Pero hablando con
otros compañeros, p.ej. que les ha tocado o bien trabajar en redes
móviles, o en el mundillo del ATM y el Frame Relay, ellos tienden a
olvidarse de que en realidad transportan IP, y su foco son las capas mas
bajas. Todos tendemos a ver la realidad coloreada por los lentes que
tenemos puestos :-)
>> Por lo pronto, IMO, el PPPoE y el ATM sobran (tuvieron sentido en su
>> momento, pero ahora ya no hacen falta). Se pueden sustituir por DHCP y
>> transporte puro ethernet. Quitar el PPPoE es resorte de ANTEL, el ATM,
>> lamentablemente no.
> ¿Te parece que DHCP podría sustuir el PPP?  El DHCP básico no tiene
> autenticación y las extensiones (tipo RFC 3046, ese RFC es justo para
> este uso que proponés) no sé si están implementadas en muchos clientes.
>  En los dispositivos veo siempre la opción de DHCP sin más, sin
> credenciales.
>
> PPP por el otro lado tiene ya cifrado, autenticación, transporte
> simultáneo de múltiples protocolos (incluído IPv6 con su propia
> negociación), compresión, envío de información de ruteo (que DHCPv6 no
> tiene), etc.  Te permite estar preparado para lo que sea.  Si mañana se
> rompe la fibra y te quieren poner un enlace de respaldo sobre cualquier
> otra cosa, PPP va a seguir andando, igualito.  Y desde el punto de vista
> de la seguridad es mucho mejor.
Para el uso que se le da al PPP en un escenario de una red ADSL, ya no
aporta nada, y se puede hacer todo con DHCP mas algunos atributos
particulares que hacen a la facturación. En realidad, ni siquiera el
usuario y password que todos perdemos alguna vez sirve para algo porque
igual se pueden controlar el establecimiento de sesiones en función del
puerto del DSLAM y de la MAC address del modem.

Es mas, el uso del PPPoE te lleva a tener 'puntos calientes' en la red,
los BRASes, equipos que terminan teniendo decenas de miles de sesiones
PPP donde una falla te deja media red sin servicio.

Ningun ISP te va a dar cifrado sobre PPPoE justamente porque te bajaria
la performance de los BRASes muchisimo. Eventualmente alguno se lo podra
ofrecer a algun cliente como servicio de valor agregado.

Creo que el uso continuado de PPPoE ahora esta mas atado a la inversión
en desarrollo de software de gestión e integración con la facturación
que a una ventaja técnica concreta. Personalmente tenía esperanza de que
con la fibra se empezara a darle salida al PPPoE, pero me comentaron que
no, que sigue estando.

> No sé, tal vez sea porque lo vi andar arriba de tanta cosa (como covert
> channels, cables, modems telefónicos, enlaces dedicados), o porque tiene
> requerimientos mínimos de la capa de abajo, realmente mínimos, con
> poquita sobrecarga.  No sé si lo cambiaría por otra cosa y menos con un
> mundo donde conviven IPv6 e IPv4.  Fijate que con PPP podés sin nada
> adicional permitir que un equipo tenga simultáneamente una IPv4 y una
> IPv6.  O la que decida tener.  El control del lado del cliente.  Cifrar
> si es necesario.  Me cuesta pensar cómo reproducir ese escenario sin PPP
> sobre el local loop.  ¿DHCPv4 + DHCPv6 + RA + IPSec?  Se ve mucho más
> engorroso.  ¿Le ves ventaja?
IPSec lo podes usar de manera oportunista y bajo tu control. El cifrado
de PPP depende de que el otro extremo te lo acepte.

En el caso de IPv6 lo que se usa es algo llamado 'prefix delegation' en
el cual por DHCPv6 se te 'delega' un prefijo que el modem/router a su
vez sirve por SLAAC ('RA') hacia tu red interna. IPv6 es otro argumento
aca. Los BRASes son equipos dedicados que saben hacer una cosa bien en
hardware, y en general manejan las sesiones PPPoE que transportan IPv6
por _software_ lo que hace que la cantidad de sesiones que puedan
manejar tambien baje de manera muy apreciable.

Como todo, el tema es argumentable. En mi opinion, el PPPoE tuvo sentido
en un momento, ahora no lo tiene mas. En su momento incluso analizamos
que hacia falta para quitarlo, pero el atributo que servia para
establecer sesiones y facturar (me suena algo de attribute-id 82, pero
mi memoria me puede estar fallando) no estaba muy soportado por modems o
clientes de software. Esto fue alrededor de 2004-2005, por lo que me
atrevo a decir que ya debe ser un tema superado.
> Yo no lo cambiaría.
>
> Eduardo.
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy