PROTOCOLOS
- TCP/P
- ARP
- STP
- VTP
- VTY
- ETERCHANNEL
- POR-SEGURITY
TCP/P
Transmission Control Protocol (en español Protocolo de Control de Transmisión) o TCP, es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y Robert Kahn.
Muchos programas dentro de una red de datos compuesta por computadoras, pueden usar TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y FTP.
Información Técnica
TCP es un protocolo de comunicación orientado a conexión y fiable del nivel de transporte, actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 según el modelo OSI.
Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe libre de errores, sin pérdidas y con seguridad.
Formato de los Segmentos TCP
En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo TCP se llaman "segmentos".
El formato de los segmentos TCP se muestra en el siguiente esquema: Segmento TCP
Funcionamiento del protocolo en detalle
Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Para la desconexión se usa una negociación en cuatro pasos (4-way handshake). Durante el establecimiento de la conexión, se configuran algunos parámetros tales como el número de secuencia con el fin de asegurar la entrega ordenada de los datos y la robustez de la comunicación.
Establecimiento de la conexión (negociación en tres pasos)
Negociación en tres pasos o Three-way handshake
Aunque es posible que un par de entidades finales comiencen una conexión entre ellas simultáneamente, normalmente una de ellas abre un socket en un determinado puerto TCP y se queda a la escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y determina el lado servidor de una conexión. El lado cliente de una conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociación en tres pasos. En el lado del servidor se comprueba si el puerto está abierto, es decir, si existe algún proceso escuchando en ese puerto. En caso de no estarlo, se envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería responderle al servidor con un ACK, completando así la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión.
Transferencia de datos
Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, y asentimientos y temporizadores para detectar pérdidas y retrasos.
Durante el establecimiento de conexión TCP, los números iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos números de secuencia son usados para identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de los datos de la aplicación. Siempre hay un par de números de secuencia incluidos en todo segmento TCP, referidos al número de secuencia y al número de asentimiento. Un emisor TCP se refiere a su propio número de secuencia cuando habla de número de secuencia, mientras que con el número de asentimiento se refiere al número de secuencia del receptor. Para mantener la fiabilidad, un receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK, Selective Acknowledgement) permite a un receptor TCP asentir los datos que se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan.
A través del uso de números de secuencia y asentimiento, TCP puede pasar los segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicación receptora. Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte después del 232-1. Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la selección del número inicial de secuencia (ISN, Initial Sequence Number).
Un checksum de 16 bits, consistente en el complemento a uno de la suma en complemento a uno del contenido de la cabecera y datos del segmento TCP, es calculado por el emisor, e incluido en la transmisión del segmento. Se usa la suma en complemento a uno porque el acarreo final de ese método puede ser calculado en cualquier múltiplo de su tamaño (16-bit, 32-bit, 64-bit...) y el resultado, una vez plegado, será el mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos. El complemento es usado para que el receptor no tenga que poner a cero el campo del checksum de la cabecera antes de hacer los cálculos, salvando en algún lugar el valor del checksum recibido; en vez de eso, el receptor simplemente calcula la suma en complemento a uno con el checksum incluido, y el resultado debe ser igual a 0. Si es así, se asume que el segmento ha llegado intacto y sin errores.
Hay que fijarse en que el checksum de TCP también cubre los 96 bit de la cabecera que contiene la dirección origen, la dirección destino, el protocolo y el tamaño TCP. Esto proporciona protección contra paquetes mal dirigidos por errores en las direcciones.
El checksum de TCP es una comprobación bastante débil. En niveles de enlace con una alta probabilidad de error de bit quizá requiera una capacidad adicional de corrección/detección de errores de enlace. Si TCP fuese rediseñado hoy, muy probablemente tendría un código de redundancia cíclica (CRC) para control de errores en vez del actual checksum. La debilidad del checksum está parcialmente compensada por el extendido uso de un CRC en el nivel de enlace, bajo TCP e IP, como el usado en elPPP o en Ethernet. Sin embargo, esto no significa que el checksum de 16 bits es redundante: sorprendentemente, inspecciones sobre el tráfico de Internet han mostrado que son comunes los errores de software y hardware[cita requerida] que introducen errores en los paquetes protegidos con un CRC, y que el checksum de 16 bits de TCP detecta la mayoría de estos errores simples.
Los asentimientos (ACKs o Acknowledgments) de los datos enviados o la falta de ellos, son usados por los emisores para interpretar las condiciones de la red entre el emisor y receptor TCP. Unido a los temporizadores, los emisores y receptores TCP pueden alterar el comportamiento del movimiento de datos. TCP usa una serie de mecanismos para conseguir un alto rendimiento y evitar la congestión de la red (la idea es enviar tan rápido como el receptor pueda recibir). Estos mecanismos incluyen el uso de ventana deslizante, que controla que el transmisor mande información dentro de los límites del buffer del receptor, y algoritmos de control de flujo, tales como el algoritmo de Evitación de la Congestión (congestion avoidance), el de comienzo lento (Slow-start), el de retransmisión rápida, el de recuperación rápida (Fast Recovery), y otros.
El tamaño de la ventana de recepción TCP es la cantidad de datos recibidos (en bytes) que pueden ser metidos en el buffer de recepción durante la conexión. La entidad emisora puede enviar una cantidad determinada de datos pero antes debe esperar un asentimiento con la actualización del tamaño de ventana por parte del receptor.
Un ejemplo sería el siguiente: un receptor comienza con un tamaño de ventana x y recibe y bytes, entonces su tamaño de ventana será (x - y) y el transmisor sólo podrá mandar paquetes con un tamaño máximo de datos de (x - y) bytes. Los siguientes paquetes recibidos seguirán restando tamaño a la ventana de recepción. Esta situación seguirá así hasta que la aplicación receptora recoja los datos del buffer de recepción.
Escalado de ventana
Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamaño de ventana mayor. El campo TCP de tamaño de ventana controla el movimiento de datos y está limitado a 16 bits, es decir, a un tamaño de ventana de 65.535 bytes.
Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de ventana TCP (TCP window scale) es una opción usada para incrementar el máximo tamaño de ventana desde 65.535 bytes, a 1 Gigabyte.
La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos que constituye el comienzo de la conexión. El valor de la escala representa el número de bits desplazados a la izquierda de los 16 bits que forman el campo del tamaño de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un número binario desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2.
Fin de la conexión
Cierre de una conexión según el estándar.
La fase de finalización de la conexión usa una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Cuando uno de los dos extremos de la conexión desea parar su "mitad" de conexión transmite un paquete FIN, que el otro interlocutor asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.
Una conexión puede estar "medio abierta" en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos pero la otra parte si podrá.
Puertos TCP
TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías: bien conocidos, registrados y dinámicos/privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80). Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 números, del 0 al 65535)
TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas han sido propuestas y llevadas a cabo a lo largo de los años, ha conservado las operaciones más básicas sin cambios desde el RFC 793, publicado en 1981. El documento RFC 1122 (Host Requirements for Internet Hosts), especifica el número de requisitos de una implementación del protocolo TCP. El RFC 2581 (Control de Congestión TCP) es uno de los más importantes documentos relativos a TCP de los últimos años, describe nuevos algoritmos para evitar la congestión excesiva. En 2001, el RFC 3168 fue escrito para describir la Notificación de Congestión Explícita (ECN), una forma de eludir la congestión con mecanismos de señalización. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet. Entre las aplicaciones más comunes que usan TCP están HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrónico) y FTP (transferencia de ficheros). Su amplia extensión ha sido la prueba para los desarrolladores originales de que su creación estaba excepcionalmente bien hecha.
Recientemente, un nuevo algoritmo de control de congestión fue desarrollado y nombrado como FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los científicos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestión a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todavía hay un debate abierto sobre si éste es un síntoma apropiado para el control de la congestión.
El User Datagram Protocol ( UDP ) es uno de los principales miembros de la suite de protocolo de Internet , el conjunto de protocolos de red utilizados para la Internet . Con UDP, las aplicaciones informáticas pueden enviar mensajes, en este caso referido como datagramas , a otros hosts en un protocolo de Internet (IP) de la red sin comunicación previa para establecer canales especiales de transporte o rutas de datos. El protocolo fue diseñado porDavid P. Reed en 1980 y formalmente se define en el RFC 768 .
UDP utiliza un modelo simple transmisión con un mínimo de mecanismo de protocolo. [ 1 ] No tiene handshakingdiálogos, y por lo tanto expone cualquier falta de fiabilidad del protocolo de red subyacente para el programa del usuario.Como este es normalmente IP a través de medios poco fiables, no hay garantía de entrega, de pedido o protección duplicado. UDP proporciona las sumas de comprobación de la integridad de los datos y los números de puerto para abordar diferentes funciones en el origen y destino de los datagramas.
UDP es adecuado para los propósitos donde la comprobación de errores y corrección no es necesaria o realizan en la aplicación, evitando la sobrecarga de procesamiento en el nivel de dicha interfaz de red. Aplicaciones sensibles al tiempo menudo utilizan UDP porque dejar caer los paquetes es preferible a la espera de paquetes retrasados, que pueden no ser una opción en un sistema en tiempo real. [ 2 ] Si las instalaciones de corrección de errores se necesitan a nivel de interfaz de red, una aplicación puede utilizar el Protocolo de Control de Transmisión (TCP) o Stream Transmission Control Protocol (SCTP), que están diseñados para este propósito.
Un número de atributos UDP hacen que sea especialmente adecuado para ciertas aplicaciones.
Aplicaciones UDP usar sockets de datagramas para establecer host-a-host de comunicaciones. Una aplicación enlaza un conector a su punto final de la transmisión de datos, que es una combinación de una dirección IP y un puerto de servicio. Un puerto es una estructura de software que se identifica por el número de puerto , un 16 pocovalor entero, lo que permite números de puerto entre 0 y 65 535 . Puerto 0 está reservado, pero es un valor permisible de puerto de origen si el proceso de envío no espera mensajes en respuesta.
La Internet Assigned Numbers Authority ha dividido a los números de puerto en tres rangos. [ 3 ] Los números de puerto 0 y 1023 se utilizan para comunes y bien conocidos servicios. En Unix -como sistemas operativos , utilizando uno de estos puertos requiere superusuario permiso de operación. Los números de puerto 1024 a través de 49 151son los puertos registrados utilizados para la IANA registradas en los servicios. Puertos 49 152 a través de 65 535 son puertos dinámicos que no están oficialmente designados para ningún servicio específico, y pueden ser utilizados para cualquier propósito. También se utilizan como puertos efímeros , de los que el software que se ejecuta en el anfitrión puede elegir al azar un puerto para definirse a sí misma. [ 3 ] En efecto, son utilizados como puertos temporales sobre todo por los clientes al comunicarse con los servidores .
[ editar ]Estructura del paquete
UDP no ofrece garantías para el protocolo de capa superior para la entrega de mensajes y la capa de protocolo UDP no retiene el estado de los mensajes UDP una vez enviados. Por esta razón, UDP se refiere a veces como no fiable Protocolo de datagramas. [ 4 ]
| Cabecera UDP |
| Compensaciones | Octeto | 0 | 1 | 2 | 3 |
| Octeto | Poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Puerto de origen | Puerto de destino |
| 4 | 32 | Longitud | Checksum |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
La cabecera UDP consta de 4 campos, cada uno de los cuales es de 2 bytes (16 bits). El uso de los campos "suma de comprobación" y "puerto de origen" es opcional en IPv4 (fondo de color rosa en la tabla). En IPv6 sólo el puerto de origen es opcional (véase más adelante).
Fuente número de puerto
Este campo identifica el puerto del remitente cuando significativa y debe ser asumida a ser el puerto para responder a si es necesario. Si no se utiliza, entonces debería ser cero. Si el host de origen es el cliente, el número de puerto es probable que sea un número de puerto efímero. Si el host de origen es el servidor, el número de puerto es probable que sea un número de puerto conocido.
Destino número de puerto
Este campo identifica el puerto del receptor y es necesario. Al igual que el número de puerto de origen, si el cliente es el host de destino y luego el número de puerto, será probablemente un número de puerto efímero y si el host de destino es el servidor y luego el número de puerto que probablemente será un número de puerto bien conocido.
Longitud
Un campo que especifica la longitud en bytes del datagrama completo: cabecera y datos. La longitud mínima es de 8 bytes ya que es la longitud de la cabecera. El tamaño del campo establece un límite teórico de 65.535 bytes (8 bytes de cabecera + 65.527 bytes de datos) para un datagrama UDP. El límite práctico para la longitud de datos que es impuesta por el subyacente IPv4 protocolo es 65.507 bytes (65.535 - 8 byte de la cabecera UDP - 20 cabecera IP byte).
En Jumbograms IPv6 es posible tener paquetes UDP de tamaño mayor que 65.535 bytes. Esto permite un valor de longitud máxima de 4294967295 bytes (2 ^ 32 - 1) con 8 bytes que representan la cabecera y 4294967287 bytes de datos.
Checksum
La suma de comprobación de campo se utiliza para la comprobación de errores de la cabecera y los datos. Si no hay suma de control es generada por el transmisor, el campo utiliza el valor de todos ceros. Este campo no es opcional para IPv6.
ARP
ARP Son las siglas en inglés de Address Resolution Protocol (Protocolo de resolución de direcciones).
Es un protocolo de la capa de enlace de datos responsable de encontrar la dirección hardware (Ethernet MAC) que corresponde a una determinada dirección IP. Para ello se envía un paquete (ARP request) a la dirección de difusión de la red (broadcast (MAC = FF FF FF FF FF FF)) que contiene la dirección IP por la que se pregunta, y se espera a que esa máquina (u otra) responda (ARP reply) con la dirección Ethernet que le corresponde. Cada máquina mantiene una caché con las direcciones traducidas para reducir el retardo y la carga. ARP permite a la dirección de Internet ser independiente de la dirección Ethernet, pero esto sólo funciona si todas las máquinas lo soportan.
El protocolo RARP realiza la operación inversa y se encuentra descrito en el RFC 903.
En Ethernet, la capa de enlace trabaja con direcciones físicas. El protocolo ARP se encarga de traducir las direcciones IP a direcciones MAC (direcciones físicas). Para realizar esta conversión, el nivel de enlace utiliza las tablas ARP, cada interfaz tiene tanto una dirección IP como una dirección física MAC.
ARP se utiliza en 4 casos referentes a la comunicación entre 2 hosts:
1. Cuando 2 hosts están en la misma red y uno quiere enviar un paquete a otro. 2. Cuando 2 host están sobre redes diferentes y deben usar un gateway/router para alcanzar otro host. 3. Cuando un router necesita enviar un paquete a un host a través de otro router. 4. Cuando un router necesita enviar un paquete a un host de la misma red.
Tablas ARP
La filosofía es la misma que tendríamos para localizar al señor "X" entre 150 personas: preguntar por su nombre a todo el mundo, y el señor "X" nos responderá. Así, cuando a "A" le llegue un mensaje con dirección origen IP y no tenga esa dirección en su caché de la tabla ARP, enviará su trama ARP a la dirección broadcast (física = FF:FF:FF:FF:FF:FF), con la IP de la que quiere conocer su dirección física. Entonces, el equipo cuya dirección IP coincida con la preguntada, responderá a "A" enviándole su dirección física. En este momento "A" ya puede agregar la entrada de esa IP a la caché de su tabla ARP. Las entradas de la tabla se borran cada cierto tiempo, ya que las direcciones físicas de la red pueden cambiar (Ej: si se estropea una tarjeta de red y hay que sustituirla, o simplemente algún usuario de la red cambia de dirección IP).
Si A quiere enviar un mensaje a C (un nodo que no esté en la misma red), el mensaje deberá salir de la red. Así, A envía la trama a la dirección física de salida del router. Esta dirección física la obtendrá a partir de la IP del router, utilizando la tabla ARP. Si esta entrada no está en la tabla, mandará un mensaje ARP a esa IP (llegará a todos), para que le conteste indicándole su dirección física.
Ejemplo Address Resolution Protocol.
Una vez en el router, éste consultará su tabla de encaminamiento, obteniendo el próximo nodo (salto) para llegar al destino, y saca el mensaje por la interfaz correspondiente. Esto se repite por todos los nodos, hasta llegar al último router, que es el que comparte el medio con el host destino. Aquí el proceso cambia: la interfaz del router tendrá que averiguar la dirección física de la IPdestino que le ha llegado. Lo hace mirando su tabla ARP, y en caso de no existir la entrada correspondiente a la IP, mandará un mensaje ARP a esa IP (llegará a todos), para que le conteste indicándole su dirección física.
STP
(Spanning Tree Protocol) (SmmTPr o STP) es un protocolo de red de nivel 2 de la capa OSI (nivel de enlace de datos). Está basado en un algoritmo diseñado por Radia Perlman mientras trabajaba para DEC. Hay 2 versiones del STP: la original (DEC STP) y la estandarizada por el IEEE (IEEE 802.1D), que no son compatibles entre sí. En la actualidad, se recomienda utilizar la versión estandarizada por el IEEE.
Su función es la de gestionar la presencia de bucles en topologías de red debido a la existencia de enlaces redundantes (necesarios en muchos casos para garantizar la disponibilidad de las conexiones). El protocolo permite a los dispositivos de interconexión activar o desactivar automáticamente los enlaces de conexión, de forma que se garantice la eliminación de bucles. STP es transparente a las estaciones de usuario.
Los bucles infinitos ocurren cuando hay rutas alternativas hacia una misma máquina o segmento de red destino. Estas rutas alternativas son necesarias para proporcionar redundancia, ofreciendo una mayor fiabilidad a la red. Si existen varios enlaces, en el caso que uno falle, otro enlace puede seguir soportando el tráfico de la red. Los problemas aparecen cuando utilizamos dispositivos de interconexión de nivel de enlace, como un puente de red o un conmutador de paquetes.
Cuando existen bucles en la topología de red, los dispositivos de interconexión de nivel de enlace de datos reenvían indefinidamente las tramas Broadcast y multicast creando un bucle infinito que consume tanto ancho de banda en la red como CPU de los dispositivos de enrutamiento. Esto provoca que la red degrade en muy poco tiempo pudiéndose quedar inutilizable. Al no existir un campo TTL (Time To Live, Tiempo de Vida) en las tramas de capa 2 se quedan atrapadas indefinidamente hasta que un administrador de sistemas rompe el bucle. Un router, por el contrario, sí podría evitar este tipo de reenvíos indefinidos. La solución consiste en permitir la existencia de enlaces físicos redundantes, pero creando una topología lógica libre de bucles. STP calcula una ruta única libre de bucles entre los dispositivos de la red pero manteniendo los enlaces redundantes desactivados como reserva, para activarlos en caso de falla.
Si la configuración de STP cambia, o si un segmento en la red redundante llega a ser inalcanzable, el algoritmo reconfigura los enlaces y restablece la conectividad, activando uno de los enlaces de reserva. Si el protocolo falla, es posible que ambas conexiones estén activas simultáneamente, lo que podrían dar lugar a un bucle de tráfico infinito en la LAN.
Existen múltiples variantes del Spaning Tree Protocol, debido principalmente al tiempo que tarda el algoritmo utilizado en converger. Una de estas variantes es el Rapid Spanning Tree Protocol, estándart IEEE 802.1D-2004 que hoy en día ha reemplazado el uso del STP original.
El árbol de expansión (Spanning tree) permanece vigente hasta que ocurre un cambio en la topología, situación que el protocolo es capaz de detectar de forma automática. El máximo tiempo de duración del árbol de expansión es de cinco minutos. Cuando ocurre uno de estos cambios, el puente raíz actual redefine la topología del árbol de expansión o se elige un nuevo puente raíz.
VTP
VTP son las siglas de Trunking Protocol, un protocolo de mensajes de nivel 2 usado para configurar y administrar VLANs en equipos Cisco. Permite centralizar y simplificar la administración en un domino de VLANs, pudiendo crear, borrar y renombrar las mismas, reduciendo así la necesidad de configurar la misma VLAN en todos los nodos. El protocolo VTP nace como una herramienta de administración para redes de cierto tamaño, donde la gestión manual se vuelve inabordable.
VTP opera en 3 modos distintos:
· Servidor · Visible · Transparente
Servidor:
Es el modo por defecto. Desde él se pueden crear, eliminar o modificar VLANs. Su cometido es anunciar su configuración al resto de switches del mismo dominio VTP y sincronizar dicha configuración con la de otros servidores, basándose en los mensajes VTP recibidos a través de sus enlaces trunk. Debe haber al menos un servidor. Se recomienda autenticación MD5.
Cliente:
En este modo no se pueden crear, eliminar o modificar VLANs, tan sólo sincronizar esta información basándose en los mensajes VTP recibidos de servidores en el propio dominio. Un cliente VTP sólo guarda la información de la VLAN para el dominio completo mientras el switch está activado. Un reinicio del switch borra la información de la VLAN.
Transparente:
Desde este modo tampoco se pueden crear, eliminar o modificar VLANs que afecten a los demás switches. La información VLAN en los switches que trabajen en este modo sólo se puede modificar localmente. Su nombre se debe a que no procesa las actualizaciones VTP recibidas, tan sólo las reenvía a los switches del mismo dominio.
Los administradores cambian la configuración de las VLANs en el switch en modo servidor. Después de realizar cambios, estos son distribuidos a todos los demás dispositivos en el dominio VTP a través de los enlaces permitidos en el trunk (VLAN 1, por defecto), lo que minimiza los problemas causados por las configuraciones incorrectas y las inconsistencias. Los dispositivos que operan en modo transparente no aplican las configuraciones VLAN que reciben, ni envían las suyas a otros dispositivos. Sin embargo, aquellos que usan la versión 2 del protocolo VTP, enviarán la información que reciban (publicaciones VTP) a otros dispositivos a los que estén conectados con una frecuencia de 5 minutos. Los dispositivos que operen en modo cliente, automáticamente aplicarán la configuración que reciban del dominio VTP. En este modo no se podrán crear VLANs, sino que sólo se podrá aplicar la información que reciba de las publicaciones VTP.
Para que dos equipos que utilizan VTP puedan compartir información sobre VLAN, es necesario que pertenezcan al mismo dominio. Los switches descartan mensajes de otro dominio VTP.
Las configuraciones VTP en una red son controladas por un número de revisión. Si el número de revisión de una actualización recibida por un switch en modo cliente o servidor es más alto que la revisión anterior, entonces se aplicará la nueva configuración. De lo contrario se ignoran los cambios recibidos. Cuando se añaden nuevos dispositivos a un dominio VTP, se deben resetear los números de revisión de todo el dominio VTP para evitar conflictos. Se recomienda tener mucho cuidado al usar VTP cuando haya cambios de topología, ya sean lógicos o físicos. Realmente no es necesario resetear todos los números de revisión del dominio. Sólo hay que asegurarse de que los switches nuevos que se agregen al dominio VTP tengan números de revisión más bajos que los que están configurados en la red. Si no fuese así, bastaría con eliminar el nombre del dominio del switch que se agrega. Esa operación vuelve a poner a cero su contador de revisión.
El VTP sólo aprende sobre las VLAN de rango normal (ID de VLAN 1 a 1005). Las VLAN de rango extendido (ID mayor a 1005) no son admitidas por el VTP. El VTP guarda las configuraciones de la VLAN en la base de datos de la VLAN, denominada vlan.dat.
VTY
Sí, ellos son lógicos "puntos de conexión" al router, que son utilizados por Telnet y SSH para acceso remoto a su router.
Algunos routers y switches, pueden soportar más que los 5 (0-4). Echa un vistazo al diagrama:
Con la siguiente configuración en R3, cuando un usuario se conecta a través de telnet, se le pedirá un nombre de usuario y el nombre de usuario se comprueban en R3 de la configuración.
R3 (config) # line vty 0 4
R3 (config-line) # login locales
R3 (config-line) # exit
R3 (config) # nombre de usuario Steve contraseña cisco
Cuando telnet desde la dirección de red remota de 10.0.0.1, a R3, y ejecute el comando "que" me va a mostrar quien está conectado.
R1 # telnet 3.3.3.3
Tratando 3.3.3.3 ... Abierto
Verificación de acceso de usuario
Nombre de usuario: steve
Contraseña: la contraseña no aparece en la pantalla R3>
R3> que
la línea Host Usuario (s) Idle Ubicación
0 con 0 ociosa 00:02:53
* 98 vty 0 steve inactividad 00:00:00 10.0.0.1
El resultado anterior refleja que el usuario está conectado (Steve) que viene de 10.0.0.1, y está conectado actualmente a través de la interfaz lógica de "vty 0". Si otro usuario conectado, que estarían conectados en vty 1 y así sucesivamente. Si todas las líneas vty estaban en uso, el sexto usuario no se le permitirá el acceso.
La salida también muestra que alguien está conectado al puerto de consola serie así.
ETERCHANNEL
EtherChannel es una tecnología de Cisco construida de acuerdo con los estándares 802.3 full-duplex Fast Ethernet. Permite la agrupación lógica de varios enlaces físicos Ethernet, esta agrupación es tratada como un único enlace y permite sumar la velocidad nominal de cada puerto físico Ethernet usado y así obtener un enlace troncal de alta velocidad.
La tecnología EtherChannel es una extensión de una tecnología ofrecida por Kalpana en sus switch en los 90. Un máximo de 8 puertos Fast Ethernet u 8 puertos 10Gigabit Ethernet pueden ser agrupados juntos para formar un EtherChannel. Con esta ultima agrupación podemos conseguir un máximo de 80 Gbps de ancho de banda. Las conexiones EtherChannel pueden interconectar switches, routers, servidores y clientes.
Los puertos usados deben tener las mismas características y configuración.
Configuración
La configuración de un EtherChannel se puede hacer de dos formas diferentes: negociación o manual. En negociación se pueden identificar también dos formas, Port Aggregation Protocol (PAgP) o Link Aggregation Control Protocol (LACP).
Ambos extremos se deben de configurar en el mismo modo.
PAgP es un protocolo propietario de Cisco. El switch negocia con el otro extremo cuales son los puertos que deben ponerse activos. El propio protocolo se encarga de agrupar puertos con características similares (por velocidad, troncales, por pertenecer a una misma VLAN,…). Se puede configurar de dos modos:
· Auto. Pone el puerto en modo pasivo, solo responderá paquetes PAgP cuando los reciba y nunca iniciará una negociación.
Dos puertos auto nunca podrán formar grupo, ya que ninguno puede iniciar una negociación.
· Desirable. Establece el puerto en modo activo, negociará el estado cuando reciba paquetes PAgP y puede iniciar negociaciones con otros puertos.
LACP es muy similar a PAgP ya que también puede agrupar puertos con características similares. Es un protocolo definido en el estándar 802.3ad.
Los modos de configuración de LACP son:
· Activo. Está habilitado para iniciar negociaciones con otros puertos.
· Pasivo. No puede iniciar negociaciones, pero si responde a las negociaciones generadas por otros puertos.
Dos puertos pasivos tampoco podrán nunca formar grupo. Es necesario que al menos uno de los dos puertos sea activos.
En el modo manual toda la configuración del puerto se realiza de forma manual, no existe ningún tipo de negociación entre los puertos.
PORT-SEGURITY
.Port-Security es una feature de los switches Cisco que nos permite retener las direcciones MACconectadas a un puerto y permitir solamente esas direcciones MAC registradas comunicarse a través de ese puerto del switch.
Nos permite restringir:
- Restringir el acceso a los puertos del switch según la MAC.
- Restringir el número de MACs por puerto en el switch.
- Reaccionar de diferentes maneras a violaciones de las restricciones anteriores.
- Establecer la duración de las asociaciones MAC-Puerto.
Si un dispositivo con otra dirección MAC intenta comunicarse a través de un puerto de la LAN, port-security deshabilitará el puerto.
Configuración de Port-Security
El proceso de configuración requiere ingresar a la configuración de la interfaz en cuestión y ejecutar el comando port-security. En el siguiente ejemplo vamos a tomar el puerto 15 del switch:
switch# configure terminal
switch(config)# int fa0/15
switch(config-if)# switchport port-security ?
aging Port-security aging commands
mac-address Secure mac address
maximum Max secure addresses
violation Security violation mode
Asumir valores por defecto
Si se ejecuta el comando básico se asumen los valores por defecto: solo se permite 1 dirección MAC en el puerto, que será la primera que se conecte al mismo. En caso de que otra dirección MAC intente conectarse utilizando el mismo puerto, este será deshabilitado o bloqueado:
switch(config-if)# switch port-security
Número de direcciones MAC permitidas
Para definir el número de direcciones MAC permitidas que se conecten a través de la interfaz del switch ejecutamos:
switch(config-if)# switchport port-security maximum 2
Acciones a realizar
Para establecer la acción que tomará el switch en caso de que se supera el número de direcciones MACestablecidas ejecutamos:
switch(config-if)# switchport port-security violation protect
switch(config-if)# switchport port-security violation restrict
switch(config-if)# switchport port-security violation shutdown
Opciones:
- protect: que deje de prender.
- restrict: que envíe una alerta administrativa.
- shutdown: que deshabilite el puerto.
Volver a habilitar un puerto
Si un puerto ha sido deshabilitado por recibir conexiones de direcciones MACs indeseadas podemos volver habilitarlo de la siguiente manera:
switch(config-if)# switchport port-security mac-address 0.3.ba.ae.59.8f
switch(config-if)# shutdown
switch(config-if)# no shutdown
Con el parámetro "mac-address" podemos definir manualmente la MAC que aceptaremos. Si no conocemos la MAC de un equipo podemos establecer que la MAC se aprenda dinámicamente:
switch(config-if)# switchport port-security mac-address sticky
Deshabilitar Port-Security de un puerto
Para deshabilitar el port-security de un puerto especifico ejecutamos:
switch(config)# no switchport port-security
