<div dir="ltr">Eso depende del modelo de CGN que implementes, si es centralizado pierdes visibilidad de la información del usuario conectado en el equipo de agregación como BRAS-BNG-CMTS-etc., por lo tanto la información de NAT que debes almacenar es prácticamente el data-plane (toda la tabla de NAT de la CGN) y eso si es bastante información, por ejemplo en pruebas que hice con 20 usuarios se generó un archivo de Syslog de casi +5Gigas en apenas 2 días.<div><br></div><div>En el modelo distribuido, la CGN está en el equipo de agregación por lo tanto tienes toda la información del usuario ahí mismo entonces puedes usar Radius para almacenar únicamente el control-plane del NAT (dirección privada, dirección pública, rango de puertos asignados) y nada más, en ese sentido la información ocupa unos cuantos Bytes ya que es lo mismo que se almacena por temas de AAA.</div><div><br></div><div>Saludos!!!<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">El 9 de marzo de 2015, 8:25 p. m., Tomas Lynch<span dir="ltr"><<a href="mailto:tomas.lynch@gmail.com" target="_blank">tomas.lynch@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Decile a tu operador amigo que vaya juntando mucho dinero para comprar<br>
servidores en cuanto pongan alguna ley que lo obligue a guardar los<br>
NATs durante 5 años. Eso es un costo que muchos no lo tienen en<br>
cuenta.<br>
<br>
2015-03-09 20:19 GMT-04:00 Ariel Weher <<a href="mailto:ariel@weher.net">ariel@weher.net</a>>:<br>
> Gracias por sus comentarios.<br>
><br>
> **Antes que nada aclaro que no quiero iniciar un flame war**.<br>
><br>
> Tengo un "operador" amigo que dice que puede NATear alrededor de 1000<br>
> clientes broadband atrás de una única IPv4 y dilatar la implementación de<br>
> v6.<br>
><br>
> Me estoy armando de información para destruir su creencia 'a lo Rambo'.<br>
><br>
> Toda la información que pasaron es muy útil y de hecho valida mi<br>
> investigación. De todas formas si saben de algún estudio acerca del tema por<br>
> favor compartan el link. Yo hasta ahora no encontré nada.<br>
><br>
> Saludos y gracias de nuevo!!!!<br>
><br>
> 2015-03-09 20:54 GMT-03:00 Tomas Lynch <<a href="mailto:tomas.lynch@gmail.com">tomas.lynch@gmail.com</a>>:<br>
><br>
>> netstat de mi máquina ahora me da unas 50 conexiones. en mi casa en<br>
>> este momento tenemos 3 computadoras, 2 teléfonos, 2 ipads y netflix<br>
>> funcionando en un bluray. supongamos 50 conexiones cada uno, dan unas<br>
>> 400 conexiones y no estamos haciendo nada muy complicado: un par de<br>
>> páginas abiertas, vpn, nada de bajar mp3s, películas, etc.<br>
>><br>
>> 2015-03-09 19:45 GMT-04:00 JORDI PALET MARTINEZ<br>
>> <<a href="mailto:jordi.palet@consulintel.es">jordi.palet@consulintel.es</a>>:<br>
>> > Hola Ariel,<br>
>> ><br>
>> > SPDY o HTTP/2 o ambos ? Porque teoricamente los grandes sitios web que<br>
>> > usan SPDY van a dejar de usarlo en pocos meses en favor de HTTP/2 Š<br>
>> ><br>
>> > Ademas hay que tener en cuenta que no todos los sitios web tienen<br>
>> > implementado SPDY, creo que se hablaba solo del 14% aprox hace unos<br>
>> > meses<br>
>> > ? Y aunque los grandes (google, yahoo, Facebook, si que lo tienen, al<br>
>> > igual que tienen soporte IPv6), tambien esta el problema de los clientes<br>
>> > que no actualizan navegadores y por tanto no soportan SPDY y/o no<br>
>> > soportaran a corto plazo HTTP/2.<br>
>> ><br>
>> > SPDY requiere usar HTTPS, y creo que la mayoria de los sitios web no lo<br>
>> > emplean, no se muy bien cual es el porcentaje. Además solo se garantiza<br>
>> > el<br>
>> > uso de SPDY si se emplea HSTS (Strict Transport Security) y se ³obliga²<br>
>> > al<br>
>> > cliente, si lo admite, a usar solo HTTPS.<br>
>> ><br>
>> > Por otro lado, algunos clientes, incluso navegadores, por ejemplo XP, no<br>
>> > soportan todas las versiones de HTTPS, lo que impide en todos los casos<br>
>> > usar SPDY, y por ende, impedira a esos clientes usar HTTP/2.<br>
>> ><br>
>> > Creo ademas que lo que indicas de SPDY, solo es correcto si ademas se<br>
>> > usa<br>
>> > persistencia de puertos, que no siempre esta configurado.<br>
>> ><br>
>> > Te cuento todo esto de SPDY, porque creo que pretender que resuelve el<br>
>> > problema de CGN es ser demasiado ³confiado², salvo que en una red<br>
>> > concreta<br>
>> > se pueda determinar, por estadisticas previas, que las versiones de los<br>
>> > clientes soportan SPDY, el trafico en un % ³x² es a servidores con<br>
>> > soporte<br>
>> > de SPDY, etc.<br>
>> ><br>
>> > Por otro lado, hay varias presentaciones (recuerdo una de NTT) que<br>
>> > demuestran que CGN es muy perjudicial, creo que es precisamente lo que<br>
>> > tu<br>
>> > has mencionado de google maps.<br>
>> ><br>
>> > Mi experiencia ha sido con algunos despliegues de CGN, que pensaban<br>
>> > compartir 1 IP entre 30-32 clientes, asignando un limite de 2.000<br>
>> > puertos<br>
>> > por cliente, que ha fallado estrepitosamente y se han tenido que usar en<br>
>> > algunos casos 1 IP solo para cada 8 clientes, pero depende mucho de<br>
>> > ³como²<br>
>> > sea de grande la red de cada cliente. Hay usuarios residenciales que<br>
>> > hacen<br>
>> > poco uso de la red, y hay otros que tienen una ³familia numerosa² con<br>
>> > muchos niños, muchos juegos, muchos dispositivos, etc., y por tanto<br>
>> > limitando el numero de puertos a 2.000 como inicialmente se pretendia<br>
>> > cuando se diseño CGN, es muy arriesgado.<br>
>> ><br>
>> > Saludos,<br>
>> > Jordi<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > -----Mensaje original-----<br>
>> > De: Ariel Weher <<a href="mailto:ariel@weher.net">ariel@weher.net</a>><br>
>> > Responder a: Latin America and Caribbean Region Network Operators Group<br>
>> > <<a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net</a>><br>
>> > Fecha: martes, 10 de marzo de 2015, 0:08<br>
>> > Para: Latin America and Caribbean Region Network Operators Group<br>
>> > <<a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net</a>><br>
>> > Asunto: [lacnog] Consulta sobre CGN<br>
>> ><br>
>> >>Estimados amigos:<br>
>> >><br>
>> >>Hace ya varios años que venimos hablando acerca de NAT y sobre todo<br>
>> >>cuando tratamos el tema del agotamiento IP, en donde siempre mencionamos<br>
>> >>Carrier Grade NAT.<br>
>> >><br>
>> >>El gran tema que siempre se trata es la cantidad de puertos que cada<br>
>> >>cliente necesita tener traducidos para que muchas aplicaciones funcionen<br>
>> >>correctamente y google maps es un ejemplo concurrente de aplicación 2.0<br>
>> >>(10.0 en mi opinión) que necesita muchas conexiones simultáneas para<br>
>> >>operar.<br>
>> >><br>
>> >>Sin embargo tengo entendido que con la implementación de SPDY se reduce<br>
>> >>drásticamente la necesidad de puertos traducidos.<br>
>> >><br>
>> >>Mi pregunta es si alguien tiene información acerca de la cantidad<br>
>> >>promedio de puertos que consume un usuario de broadband (una casa tipo).<br>
>> >>También me sirve algún dato como "usamos X IP's cada Y cantidad de<br>
>> >>abonados".<br>
>> >><br>
>> >>No es que pienso empezar a NATear, todo lo contrario, es para defender<br>
>> >>una causa (IPv6).<br>
>> >><br>
>> >>Saludos y gracias.<br>
>> >><br>
>> >>_______________________________________________<br>
>> >>LACNOG mailing list<br>
>> >><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
>> >><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
>> >>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > LACNOG mailing list<br>
>> > <a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
>> > <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
>> > Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
>> _______________________________________________<br>
>> LACNOG mailing list<br>
>> <a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
>> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
>> Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
><br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><br></div>