Para empezar vamos a dar una definición de protocolo. Un protocolo es un conjunto de reglas que definen cómo funciona algo.

Y aplicando el término al networking podemos decir que un protocolo de routing es un conjunto de reglas que definen como los routers van a enviarse entre si actualizaciones sobre las redes conocidas.

Ni que decir tiene que los protocolos de routing operan en la capa 3 del modelo OSI.

Pero ¿cómo funciona exactamente un protocolo de routing?, para verlo podemos seguir los siguientes pasos:

• El protocolo de routing envia la información sobre las redes que conoce
• El protocolo de routing recibe dicha información y la reenvia a otros routers
• El proceso de reenvío termina cuando los routers de dentro de un mismo ámbito tienen el mismo conocimiento de la red

Obviamente para ir de una red a otra pueden existir muchos caminos, pero los protocolos de routing para calcular el camino óptimo pueden utilizar

• métricas
• longitud del prefijo
• distancia administrativa
• etc

Cada protocolo realiza sus propios cálculos basados en variables como las arriba descritas, pero claro, cada uno realiza la decisión de forma distinta, esa es la razón por la que varios protocolos de routing nos pueden dar resultados distintos, si no, pensad como calcularía RIP una ruta y cómo lo haría OSPF, por poner un ejemplo.

Un tema interesante sería la diferencia entre protocolo de routing y protocolo enrutado.

Un protocolo de routing será aquel protocolo que tomará la decisión de qué camino elegir y el protocolo enrutado será aquel protocolo que proporcione la capacidad de direccionamiento de capa 3, por esta razón hay protocolos como NetBEUI que no pueden ser enrutados, porque no tienen direccionamiento de capa 3 .

Vía: ccnp.eduangi.com

El nivel de aplicación es el superior, o más cercano al usuario dentro de la pila o arquitectura de protocolos TCP/IP y por tanto es el nivel donde corren los protocolos como por ejemplo HTTP y aplicaciones como un navegador web con el que estás leyendo este post.

Este nivel es el responsable de hacer que el usuario entienda la información.

Nivel de Transporte

En el nivel de transporte nos encontramos con dos de los protocolos más importantes, TCP (Transmission Control Protocol) y UDP (User Datagram Protocol).

Este nivel nos interesa mucho en nuestro CCNA ya que es el nivel donde se realiza un control de errores, control de flujo en el caso de TCP por poner un ejemplo. En UDP no tendríamos ni control de errores ni de flujo, pero esto lo veremos más adelante.

Es en este nivel donde ya hablamos de los famosos puertos, un puerto no es más que el interfaz con el protocolo del nivel de aplicación superior.

Por poner un ejemplo, HTTP funcionaría sobre TCP y puerto 80. Con esta información podemos saber que HTTP es un protocolo que va sobre TCP y que por tanto tiene control de errores y control de flujo y que funciona mediante el puerto 80.

Ejemplo
Si ponemos en la dirección del navegador web http://eduangi.com:80 estamos diciendo que utilice el protocolo HTTP utilizando el puerto 80, no es necesario indicar que funciona sobre TCP porque cuando veamos donde va cada protocolo se verá que sólo puede ir sobre TCP.
Si pusieramos http://eduangi.com:443/ intentaríamos ver eduangi.com mediante HTTP, pero utilizando el puerto 443.

Enlace Recomendado
Para poder ver esto cláramente existe un vídeo que os podéis descargar en http://www.warriorsofthe.net/movie.html, se trata de una película de 12 minutos de dibujos animados muy didactica al respecto

Nivel de Interred

Desde luego este es el nivel más importante para un CCNA, CCNP o CCIE, ya que sería el nivel que proporciona el direccionamiento y la forma de llegar a otras direcciones.

Es en este nivel donde nos encontramos al archiconocido protocolo IP y es donde se encontrarían las direcciones IP

En el siguiente ejemplo se puede ver las direcciones IP de la tarjeta de wireless de mi PC, la 192.168.1.25 sería la dirección IP versión 4, la versión más extendida actualmente y la que se utiliza en el examen CCNA, a modo de curiosidad también se muestra una dirección IP versión 6, en este caso la que viene por defecto.

edu@debian:~$ /sbin/ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0F:66:2F:2A:85
inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20f:66ff:fe2f:2a85/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25547 errors:0 dropped:0 overruns:0 frame:0
TX packets:17534 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32067446 (30.5 MiB) TX bytes:1584709 (1.5 MiB)
Memory:20800000-20801fff

Este es el nivel encargado de decirnos cual es el direccionamiento lógico (dirección IP) de cada uno de los hosts y como llegar a otros destinos

edu@debian:~$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

En este ejemplo se puede ver que para llegar a la dirección 0.0.0.0 el siguiente salto es el 192.168.1.1, es decir, es en este nivel donde se nos indica donde mandar la información para que llegue al destino.

Si pusieramos un ejemplo práctico si nos imaginamos la red del metro de Madrid, las estaciones podrían ser las direcciones IP y los posibles recorridos entre estaciones serían las posibles rutas, pero sólo la mejor ruta entre dos estaciones sería la ruta óptima y la siguiente estación para llegar a la de destino sería el siguiente salto o gateway.

Nivel de Interfaz de Red

En este nivel sería donde recaerían protocolos como IEEE802.3 o Ethernet (que no es lo mismo) y obviamente el hardware como tarjetas de red.

Vía: ccna.eduangi.com

bajar en

Ya está disponible el blog para el CCNP, en este blog vamos a tratar los cuatro examenes que componen la certificación CCNP:

• BSCI
• BCMSN
• BCRAN
• CIT

Podéis entrar en el blog en ccnp.eduangi.com

bajar en

Todo candidato que tenga en mente examinarse del CCNA debe conocer perfectamente tanto la arquitectura de protocolos TCP/IP como el modelo de referencia OSI.

TCP/IP define una amplia colección de protocolos que permiten a los hosts comunicarse entre si.

Cada uno de estos protocolos vienen descritos en su correspondiente Request For Comments (RFC). El objetivo prinicipal de definir todos y cada uno de los protocolos que conforman la arquitectura TCP/IP en RFCs persigue que todos los fabricantes de equipos y software involucrados en el networking sigan los mismos estándares de forma que todos los productos sean compatibles entre si.

La arquitectura de protocolos está dividia en cuatro capas o niveles:

• Aplicación: telnet, http, pop3, etc
• Transporte: tcp, udp, etc
• Interred: ip, etc
• Interfaz de red: ethernet, token ring

Esta división en capas se hace porque cada una de ellas tiene que realizar una función bien definida y así conseguir que la arquitectura de protocolos sea modulable.

Esta modulabilidad permite que una empresa u organización se especialice en una o varias de las capas. Por ejemplo Realtek puede fabricar tarjetas de red que funcionan en la capa de interfaz de red y Apple aplicaciones que corran sobre IP y teóricamente una aplicación de software a nivel de aplicación podría tener en la capa de interfaz de red una tarjeta fabricada por Realtek.

Todo candidato a la certificación de Cisco CCNA debe de tener esta idea totalmente clara y asimiada.

Vía: ccna.eduangi.com

HTTP://CCNA.EDUANGI.COM

Ya está activo el blog de CCNA, a partir de ahora en este blog podréis encontrar información para obtener la certificación CCNA de Cisco, empezaremos desde cero hasta completar el temario completo de la certificación.

Se irán publicando un par de entradas a la semana, de forma que se pueda seguir de forma continua.

En la parte superior de las entradas podréis encontrar un botón, y si le dails al play podréis escuchar los posts además de leerlos.

Pues dicho esto el próximo post será para empezar a tratar el temario propiamente dicho.

Disponemos de tres tipos de interfaces:

• Interfaces físicos
• Interfaces punto a punto
• Interfaces punto multipunto

En el examen del CCIE es muy probable que nos encontremos una mezcla entre las diferentes posibilidades, así que es necesario conocer las tres.

Cuando hablamos de los interfaces físicos nos estamos refiriendo a los interfaces tal cual como se puede ver en el ejemplo:

interface serial 0
ip address 131.108.64.2 255.255.255.0
encapsulation frame-relay
keepalive 10
frame-relay map ip 131.108.64.1 43

El interfaz físico es donde todos los DLCIs se asignan a no ser que se le diga que van en otro lado, este es punto principal de la configuración y se trata de interfaces NBMA, es decir no tenemos broadcast, para conseguir el efecto de los broadcast para los protocolos de routing podemos utilizar la siguiente configuración:

interface serial 0
encapsulation frame-relay
ip address 10.0.1.1 255.255.255.0
frame-relay interface-dlci 42 broadcast

En este tipo de interfaces tenemos que tener en cuenta el problema del horizonte dividido, en Frame Relay tenemos multiples puntos que se conectan a un punto concreto y es posible que se produzca el problema del horizonte dividido y tendremos que tener en cuenta el protocolo de encaminamiento que usemos.

Para ver donde tenemos el DLCI podemos utilizar el comando

Router#sh frame-relay pvc

Este comando nos dirá donde está el DLCI cual es el estado del mismo. Con el comando show frame-relay map vermos básicamente la misma información.

En los subinterfaces punto a punto podemos añadir subinterfaces lógicos a los interfaces físicos, y tenemos que decirle al router que vamos a configurar en el subinterfaz, es decir, el DLCI y la IP.

Este sería un ejemplo:

interface serial 0
encapsulation frame-relay
interface serial 0.1 point-to-point
ip address 10.0.1.1 255.255.255.0
frame-relay interface-dlci 42

Es interesante observar que el comando encapsulation frame-relay va en el interfaz físico, ya que el subinterfaz como ya hemos dicho es lógico.

Los broadcast en un punto a punto funcionarán automáticamente, así que no tendremos que hacer nada para que estos funcionen.

Si tenemos punto a punto en un extremo y cualquier otro tipo en otro como interfaz físico o punto a multipunto tendremos type mismach en protocolos como OSPF.

En los subinterfaces punto a multipunto podemos añadir subinterfaces lógicos a los interfaces físicos, y tenemos que decirle al router que vamos a configurar en el subinterfaz, es decir, el/los DLCI y la/s IP.

Este sería un ejemplo:

interface serial 0
encapsulation frame-relay
interface serial 0.2 multipoint
ip address 10.0.2.1 255.255.255.0
frame-relay map ip 10.0.2.2 18

En el examen de CCIE para hacer el mapping entre direcciones IP y DLCIs tenemos que usar el comando frame-relay map.

escuchar post

Para realizar el mapeo de direcciones de capa 2 a capa 3 tenemos varias opciones, pero la primera sin duda será el arp inverso, esta será la función principal de Frame Relay.

Tan pronto como se configure el interfaz Frame Relay el router empezará a enviar mensajes por ese DLCI indicando su dirección IP y le permitirá descubrir vecinos en la nube.

interface Serial0.103 multipoint
ip address 172.21.177.18 255.255.255.0
frame-relay interface-dlci 300

Obviamente no todas las configuraciones van a ser tan simples, y es más parece ser que en el examen del CCIE no está permitido utilizar el arp inverso y para ello es necesario desactivarlo nada más empezar a trabajar con el interfaz, lo primero de todo.

Para poder ver qué tipo de mapeo entre capas 2 y 3 tenemos un comando muy útil va a ser show frame-relay map.

Router> show frame-relay map
Serial 1 (administratively down): ip 131.108.177.177
dlci 177 (0xB1,0×2C10), static,
broadcast,
CISCO
TCP/IP Header Compression (inherited), passive (inherited)

Si en la salida del comando show frame-relay map vemos la palabra dynamic implica que ha aprendido la dirección vía arp inverso, si no desactivamos el arp inverso al principio, incluso antes del no shutdown, podemos obtener conexión con elementos que no esperabamos. Para deshabilitar el arp inverso:

Router(config-if)#no frame-relay inverse-arp

Para deshabilitar el arp inverso podemos seguir este procedimiento:

Router(config)#int serial 2/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#no frame-relay inverse-arp
Router(config-if)#no shutdown

De todos modos si se nos ha olvidado deshabilitar el arp inverso y el router ya ha aprendido direcciones lo más rápido, aunque parezca mentira es rebotar el router, ya que el comando clear frame-relay invarp no siempre funciona como es debido, pero ahí está:

Router#clear frame-relay inarp interface serial 2/0 dlci 17

Fijaros que hemos dicho el serial 2/0 dlci 17 porque lo hemos visto en el comando show frame-relay pvc:

Router#sh frame-relay pvc

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

Active Inactive Deleted Static
Local 0 0 1 0
Switched 0 0 0 0
Unused 0 0 0 0

DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial2/0

input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:04:05, last time pvc status changed 00:03:18
Router#

Del post de hoy tenemos que recordar que hay dos comandos fundamentales show frame-relay map y show frame-relay pvc, estos nos ayudarán muchísimo en nuestro trabajo.

Pues bien, me comenta lo siguiente sobre un emulador de Cisco 7200. Por mi parte ya lo he descargado, y estoy a la espera de conseguir la IOS que me hace falta.

La verdad es que los comentarios de Carlos son siempre muy importantes para mi y aquí tenéis un trozo del mail que me mandó.

…….has construido un Blog especial del cual quiero hacerte un comentario al tema de Frame-Relay. Dices que esa tecnología no forma parte del actual Lab; todo lo contrario, es necesario conocer FR a fondo porque la parte WAN se fundamenta en FR, HDLC y PPP, siendo la primera la más importante. Existen muchas situaciones particulares de los protocolos de enrutamiento y de tecnologías como Multicast y QoS que necesitan ajustes sobre FR y eso hay que conocerlo a fondo.

Por otra parte, quisiera que analizaras un excelente producto que encontré en http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator y que sirve como excelente herramienta para la preparación del CCIE y otras certificaciones Cisco. Le veo mucho futuro a esa herramienta ya que el autor la está mejorando constantemente. Sería interesante que publicaras una nota en tu Blog para llamar la atención a las personas que se estén preparando para transitar éste largo y arduo camino que conduce al CCIE.

escuchar post

En cuanto al estado de los DLCIs en Frame Relay tenemos tres posibilidades al hacer un

Router# show frame-relay pvc

• Active: implica que todo está funcionando correctamente.
• Inactive: implica que algo está fallando en el otro extremo, normalmente en el FR switch.
• Deleted: implica que el FR switch indica que el DLCI ha sido borrado o que no existe.

Ejemplo:

Router# show frame-relay pvc 100
PVC Statistics for interface Serial4/0/1:0 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK UP), INTERFACE = Serial4/0/1:0.1
input pkts 4360 output pkts 4361 in bytes 146364
out bytes 130252 dropped pkts 3735 in pkts dropped 0
out pkts dropped 3735 out bytes dropped 1919790
late-dropped out pkts 3735 late-dropped out bytes 1919790
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 337 out bcast bytes 102084
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 05:34:06, last time pvc status changed 05:33:38

escuchar post

Frame Relay aunque ya no es temario para el examen práctico actual, sí que es una tecnología importante a conocer, así que vamos a hablar un poco de ella.

Para nosotros lo importante de Frame Relay va a ser la parte cliente (DTE) y no la nube Frame Relay.

En Frame Relay es muy importante conocer la relación entre el cliente de Frame Relay y el switch. Si miramos en la parte de cliente tendremos que fijarnos tanto en el nivel 1 y en el nivel 2.

En el nivel físico tendremos que ver si tenemos que proporcionar el clocking al interfaz, que esto podemos hacerlo aunque seamos el cliente de nivel 2.

En el nivel 2 tendremos que ver la encapsulacion, DTE si somos el cliente o DCE si somos el Frame Relay Switch (situación que no suele ocurrir).

También tenemos que fijarnos que no hay relación directa entre el nivel 1 y el nivel 2 en el caso de DCE ya que aunque se esté proporcionando el reloj esto no implica que sea el Frame Relay switch.

Es muy importante conocer como hablan entre sí los dos equipos de Frame Relay, esto lo hacen con el LMI (Link Management Interface). El LMI proporciona la comunicación entre el cliente Frame Relay y el Frame Relay switch.

Es fundamental conocer como funciona el LMI y conocer los tipos de LMI que existen, porque aunque el LMI sea autoconfigurable desde la IOS 11.3 es importante tenerlo en cuenta porque en el examen puede ser que nos encontremos un equipo en el lab que no sea Cisco o tal vez que en el enunciado del examen se expecifique que el LMI tenga que ser de un tipo determinado.

• Cisco
• ANSI
• ITU-T Q922

La comunicación del LMI tiene lugar durante el intervalo del keepalive del serial que por defecto es cada 10 segundos, así que cada 10 segundo se envía una query de LMI al LMI switch y se obtiene una respuesta, de esta forma se consigue la continuidad de DLCIs.

Cada 6 LMI paquetes se llama full LMI status y se prduce cuando el FR switch confirma toda la información de sus DLCIs.

Gracias al LMI da la impresión que todo funciona a la primera, pero es posible que en el examen nos indiquen que modifiquemos algún timer de LM