\textclass article
\language spanish
\inputencoding auto
-\fontscheme default
+\fontscheme palatino
\graphics default
\paperfontsize default
-\papersize Default
-\paperpackage a4
+\spacing single
+\papersize a4paper
+\paperpackage widemarginsa4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\quotes_times 2
\papercolumns 1
\papersides 1
-\paperpagestyle default
+\paperpagestyle fancy
\layout Title
\layout Section
Protocolo PPP
+\layout Subsection
+
+Introducción
+\layout Standard
+
+El protocolo PPP es muy utilizado para establecer una comunicación entre
+ 2 redes (routers), ya sea entre LANs o entre una LAN y WAN u otras redes
+ más grandes.
+ Incluso es útil para comunicar un sólo host a una red distante (donde no
+ sería viable tender un cable o utilizar un medio inalámbrico).
+ Al poder ser montado sobre líneas telefónicas conmutadas, este protocolo
+ fue (y es) muy utilizado para proveer acceso a internet.
+\layout Subsection
+
+Protocolo
+\layout Standard
+
+
+\begin_inset Float figure
+wide false
+collapsed true
+
+\layout Caption
+
+
+\begin_inset LatexCommand \label{cap:Diagrama-de-estados-ppp}
+
+\end_inset
+
+Diagrama de estados de una conexión PPP
+\layout Standard
+
+
+\begin_inset Graphics
+ filename ppp.eps
+ scale 65
+
+\end_inset
+
+
+\end_inset
+
+Lo primero que debe hacer el protocolo es establecer una conexión física
+ entre las dos puntas de la comunicación, para esto debe discar el número
+ si se utiliza sobre una línea telefónica conmutada, para establecer el
+ canal.
+ Una vez establecido el canal, empieza a actuar el LCP (Link Control Protocol)
+ que negocia, enviando frames PPP, los parámetros de la conexión.
+ Una vez acordados estos parámetros, puede realizarse una etapa de autenticación
+, para verificar la identidad de las puntas y así permitir o no que la comunicac
+ión se establezca.
+ Finalmente, si todo resultó bien, se envía una serie de paquetes NCP (Network
+ Control Protocol) para configurar la capa de red (como la dirección IP,
+ si se quisiera utilizar el protocolo TCP/IP en dicha capa).
+\layout Standard
+
+En este momento las dos puntas de la conexión están comunicadas y pueden
+ realizar todas sus tareas como si estuvieran conectadas en una LAN.
+\layout Standard
+
+Un vez finalizado, se procede prácticamente de forma inversa a como se estableci
+ó la conexión para liberarla.
+ Primero se libera la IP a través del procotocolo NCP, luego se libera el
+ enlace cerrando la conexión de la capa LCP y finalmente se cierra la conexión
+ física (se corta el módem), si fuera necesario.
+\layout Standard
+
+Se puede ver un diagrama de estados de este proceso en la figura
+\begin_inset LatexCommand \vref{cap:Diagrama-de-estados-ppp}
+
+\end_inset
+
+.
+\layout Subsection
+
+Configuración
+\layout Standard
+
+Entre las cosas que se pueden configurar (negociando a través del protocolo
+ LCP) está el tamaño de la cabecera del frame (ya que los campos
+\emph on
+address
+\emph default
+ y
+\emph on
+control
+\emph default
+ generalmente son fijos y pueden evitarse, el campo
+\emph on
+protocol
+\emph default
+ puede ser de 1 o 2 bytes y el
+\emph on
+checksum
+\emph default
+ de 2 o 4) y el máximo tamaño del
+\emph on
+payload
+\emph default
+ del frame.
+ Estos parámetros se establecen con valores por omisión para poder ser negociado
+s luego con el protocolo LCP.
+\layout Standard
+
+El protocolo NCP es muy específico sobre qué protocolo de red se quiera
+ negociar, por lo que es muy difícil hablar en términos generales de él.
+ Para el caso más común, donde se configura una capa de red IP, se utiliza
+ el protocolo IPCP (IP Control Protocol) cuya tarea se limita prácticamente
+ a la asignación de la IP (aunque puede negociar compresión de cabeceras
+ también).
+ Hay también extensiones, como la extensión para configurar servidores de
+ nombre (definido en la RFC 1877
+\begin_inset Quotes eld
+\end_inset
+
+PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
+\begin_inset Quotes erd
+\end_inset
+
+).
+\layout Subsection
+
+Configuración de los routes sobre línea dedicada
+\layout Subsubsection
+
+Con modems
+\layout Standard
+
+Lo primero que hay que hacer si utilizamos un modem sobre una línea telefónica
+ conmutada, es establecer el canal de la capa física.
+ Esto significa que una de las puntas debe discar el número de la otra y
+ establecer el canal utilizando algún programa de comunicación que permita
+ salir sin
+\emph on
+resetear
+\emph default
+ el modem (como
+\family typewriter
+minicom
+\family default
+, con el que podemos hacerlo utilizando la combinación de teclas
+\family typewriter
+ALT-Q
+\family default
+).
+\layout Standard
+
+Con el canal establecido, ejecutamos en ambas puntas el comando:
+\layout LyX-Code
+
+pppd -detach <IP local>:<IP remota> /dev/ttyS<N> <baudios> &
+\layout Standard
+
+Donde
+\family typewriter
+<IP local>
+\family default
+ es la IP que se usará en la punta donde se ejectuta el comando,
+\family typewriter
+<IP remota>
+\family default
+ la IP del par,
+\family typewriter
+<N>
+\family default
+ el número de puerto serie (empezando de 0, que equivaldría al puerto más
+ conocido como COM1) y
+\family typewriter
+<baudios>
+\family default
+ la velocidad en baudios del puerto serie.
+ Recordemos que estamos usando como NCP al protocolo IPCP, para establecer
+ una capa de red IP.
+\layout Standard
+
+Esta es una forma muy precaria y no autenticada de establecer la conexión
+ PPP.
+ La forma correcta sería dejando que una de las puntas actúe como
+\emph on
+servidor
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+Técnicamente no es un servidor, ya que no existe tal cosa en el protocolo
+ PPP (en el que ambas puntas son pares), pero suele utilizarse este término
+ para la punta que recibe las llamadas, las atiende y asigna IPs.
+\end_inset
+
+
+\emph default
+ PPP, encargándose de atender a la llamada entrante automáticamente, autenticand
+o y asignando la IP a la otra punta, pero esta configuración es bastante
+ más compleja y poco realizable en el laboratorio.
+\layout Subsubsection
+
+Sin modems (null modems)
+\layout Standard
+
+En ambas puntas de la conexión via null modem hay que ejecutar el siguiente
+ comando:
+\layout LyX-Code
+
+pppd -detach crtscts lock <IP local>:<IP remota> /dev/ttyS<N> <baudios>
+ &
+\layout Standard
+
+Donde
+\family typewriter
+<IP local>
+\family default
+ es la IP que se usará en la punta donde se ejectuta el comando,
+\family typewriter
+<IP remota>
+\family default
+ la IP del par,
+\family typewriter
+<N>
+\family default
+ el número de puerto serie (empezando de 0, que equivaldría al puerto más
+ conocido como COM1) y
+\family typewriter
+<baudios>
+\family default
+ la velocidad en baudios del puerto serie.
+ Recordemos que estamos usando como NCP al protocolo IPCP, para establecer
+ una capa de red IP.
+\layout Standard
+
+Esto no establece ninguna tabla de ruteo, por lo que hay que cargarlas a
+ mano en caso de ser un router o de querer especificar un
+\emph on
+default gateway
+\emph default
+ en alguna de las puntas.
+ También es probable que haya que configurar los parámetros del puerto serie
+ con el comando
+\family typewriter
+setserial
+\family default
+, de manera tal que ambas puntas tenga los mismos parámetros (como paridad,
+ baudios, etc).
\layout Section
Tablas de ruteo
La captura fue realizada transfiriendo un archivo binario de 1.9 Mb, llamado
db4o-4.5-mono.tar.gz.
- Para la transferencia se han interfambiado 16 mensajes FTP 8 response y
+ Para la transferencia se han intercambiado 16 mensajes FTP 8 response y
6 requests.
\layout Standard
-Lo primero que se recibe el el response del server dando su identificacion
+Lo primero que se recibe es el response del server dando su identificacion
(hostname).
Luego un request del comando USER y la respuesta del servidor diciendo
que se necesita password para dicho usuario.
la respuesta de que estamos loggeados.
\layout Standard
-El cliente envia un SYST para saber el tipo de sistema que hay del otro
+El cliente envía un SYST para saber el tipo de sistema que hay del otro
lado, a lo que el server responde UNIX Type: L8.
- Luego se cambia el tipo de modo de transferencia con TYPE y a continuacion
+ Luego se cambia el tipo de modo de transferencia con TYPE y a continuación
se hace un PORT para establecer un canal de comunicación.
\layout Standard
cuando se completo la transferencia.
\layout Standard
-También se registraron 68 paquetes FTP-DATA intercambiados durante la transferen
-cia del archivo.
+También se registraron 1346 paquetes FTP-DATA intercambiados durante la
+ transferencia del archivo.
Once de dichos paquetes correspondieron a paquetes de control conteniendo
- TCP Previows segment lost.
- El resto corresponden a envio de 16384 bytes de datos transferidos.
+ TCP Previous segment lost.
+ El resto corresponden a envío de 1448 bytes de datos transferidos.
\layout Subsection
Segmentos TCP
\layout Standard
Lo primero que se observa son 3 segmentos para establecer la conexión (SYN
- y ACK) entre un puerto alto (35631) y el puerto ftp del server.
+ y ACK) entre un puerto alto (35631) y el puerto FTP del server.
Luego 2 paquetes para la autenticación de usuario y a continuación está
la negociación del puerto y el comando RETR usando 34 segmentos.
\layout Standard
Sigue a continuación la transferencia del archivo entre el puerto ftp-data
- del servidor y el puero local 32985.
+ del servidor y el puerto local 32985.
\layout Standard
-La transferencia consume 65 paquetes, de los cuales tenemos algunos de control.
- Hay 5 paquetes TCP ACKed lost segment y 3 de TCP Window Update.
+La transferencia consume 1466 paquetes, de los cuales tenemos algunos de
+ control.
+ Hay 112 ACK, 5 paquetes TCP ACKed lost segment y 3 de TCP Window Update.
\layout Standard
La comunicación termina con 11 segmentos TCP.
Paquetes IP
\layout Standard
-En total se utilizan 104 paquetes IP.
+En total se utilizan 1516 paquetes IP.
\layout Subsection
Frames Ethernet
\layout Standard
-En total se utilizan 104 paquetes IP.
+En total se utilizan 1516 frames ethernet.
\layout Section
Análisis de la captura Telnet
-\layout Section
+\layout Standard
+
+Se realizó la captura al inicio de una conexión mediante telnet al servidor
+ donde se encontraba el archivo RFC792 al cual se le modificaron 5 líneas
+ (una en cada hoja) se lo guardó y luego se desconecto del servidor cerrando
+ la conexión telnet.
+\layout Subsection
+
+Mensajes Telnet
+\layout Standard
+
+Se contaron en total 717 mensajes telnet, donde en su mayoría contenían
+ cada uno de ellos, un caracter correspondiente a una tecla presionada y
+ en algunas ocasiones líneas completas transmitidas por el servidor hacia
+ el cliente.
+ Tambíen se puede notar que los primeros mensajes pertenecen a la negociación
+ del protocolo e intercambio de parámetros.
+\layout Subsection
+
+Segmentos TCP
+\layout Standard
+
+Como en los protocolos anteriores se puede observar que se utilizan 3 segmentos
+ para establecer la conexión (SYN, ACK), y que todos los mensajes telnet
+ van montados en un segmento TCP.
+ Por lo tanto tendremos tantos segmentos TCP como mensajes de telnet haya
+ sumando además los segmentos TCP de control, en total 1005 segmentos fueron
+ contabilizados.
+
+\layout Subsection
+
+Paquetes IP
+\layout Standard
+
+Cada segmento TCP va acompañado por un paquete IP, en total 1005 paquetes
+ IP.
+\layout Subsection
+
+Frames Ethernet
+\layout Standard
-Cálculo de eficiencia sobre la red
+Analogamente al caso anterior, podemos observar 1005 frames ethernet.
\the_end
projects / z.facultad / 75.43 / tp2.git / blobdiff