Práctica 1 (2015)

Pràctica Español
Universidad Universidad Politécnica de Madrid (UPM)
Grado Ingeniería de Tecnologías y Servicios de Telecomunicación - 4º curso
Asignatura Redes corporativas
Año del apunte 2015
Páginas 9
Fecha de subida 28/03/2016
Descargas 5
Subido por

Vista previa del texto

RECO PRÁCTICA 1 Por: Mikel Goig Encuentra mucho más en: Mikel Goig RECO - Práctica 1 Ethernet sobre MPLS y calidad de servicio Memoria de la práctica (curso 15-16) Nombre del alumno 1: Pablo Arcones Castrillo Login1: pablo.arcones.castrillo Nombre del alumno 2: Mikel Goig Fernández de Mendiola Login2: m.goig Nombre del alumno 3: Javier Ochoa Serna Login3: j.ochoas Para la realización de esta práctica hemos utilizado el ordenador L059 perteneciente al banco 1.
Parte I. Infraestructura MPLS del proveedor de servicio.
Pruebas de conectividad.
Verificación de existencia de conectividad: PING desde PE1 a la dirección de loopback de PE2.
Router#ping 192.168.139.24 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.139.24, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Estudio del comportamiento del sistema.
Resultado de ejecutar la orden show mpls forwarding-table en todos los equipos del núcleo MPLS.
PE1 Router#show mpls forwarding-table Local tag 16 17 18 19 20 Outgoing tag or VC Pop tag 17 Pop tag 18 19 Prefix or Tunnel Id 192.168.139.22/32 192.168.139.23/32 192.168.230.4/30 192.168.230.8/30 192.168.139.24/32 Bytes tag switched 0 0 0 0 0 Outgoing interface Fa0/1 Fa0/1 Fa0/1 Fa0/1 Fa0/1 Bytes tag switched 0 0 0 0 0 Outgoing interface Fa0/1 Fa0/1 Fa0/1 Fa0/1 Fa0/1 Next Hop 192.168.230.2 192.168.230.2 192.168.230.2 192.168.230.2 192.168.230.2 PE2 Router#show mpls forwarding-table Local tag 16 17 18 19 20 Outgoing tag or VC 16 17 18 Pop tag Pop tag Prefix or Tunnel Id 192.168.230.0/30 192.168.139.21/32 192.168.139.22/32 192.168.139.23/32 192.168.230.4/30 Next Hop 192.168.230.9 192.168.230.9 192.168.230.9 192.168.230.9 192.168.230.9 Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig P1 Router#show mpls forwarding-table Local tag 16 17 18 19 Outgoing tag or VC Pop tag Pop tag Pop tag 19 Prefix or Tunnel Id 192.168.139.21/32 192.168.139.23/32 192.168.230.8/30 192.168.139.24/32 Bytes tag switched 0 0 0 540 Outgoing interface Fa0/1 Se0/2/1 Se0/2/1 Se0/2/1 Bytes tag switched 520 0 0 570 Outgoing interface Se0/2/0 Se0/2/0 Se0/2/0 Fa0/1 Next Hop 192.168.230.1 point2point point2point point2point P2 Router#show mpls forwarding-table Local tag 16 17 18 19 Outgoing tag or VC Pop tag 16 Pop tag Pop tag Prefix or Tunnel Id 192.168.230.0/30 192.168.139.21/32 192.168.139.22/32 192.168.139.24/32 Next Hop point2point point2point point2point 192.168.230.10 Resultado de ejecutar la orden show ip cef dirIPdeLoopbackDelOtroPE detail en los equipos PE.
PE1 Router#show ip cef 192.168.139.24 detail 192.168.139.24/32, version 15, epoch 0, cached adjacency 192.168.230.2 0 packets, 0 bytes tag information set local tag: 20 fast tag rewrite with Fa0/1, 192.168.230.2, tags imposed: {19} via 192.168.230.2, FastEthernet0/1, 0 dependencies next hop 192.168.230.2, FastEthernet0/1 valid cached adjacency tag rewrite with Fa0/1, 192.168.230.2, tags imposed: {19} PE2 Router#show ip cef 192.168.139.21 detail 192.168.139.21/32, version 12, epoch 0, cached adjacency 192.168.230.9 0 packets, 0 bytes tag information set local tag: 17 fast tag rewrite with Fa0/1, 192.168.230.9, tags imposed: {17} via 192.168.230.9, FastEthernet0/1, 0 dependencies next hop 192.168.230.9, FastEthernet0/1 valid cached adjacency tag rewrite with Fa0/1, 192.168.230.9, tags imposed: {17} Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Explicación de la información dada por dichas órdenes y relación con la conmutación de paquetes.
El comando show mpls forwarding-table muestra la “tabla de forwarding MPLS” de los equipos PE (enrutadores, Provider Edge) basados en el protocolo MPLS. Así, hay dos primeras columnas que indican como se relacionan las etiquetas (Labels) de entrada y de salida, la primera es una etiqueta local, es decir, la que el enrutador asigna a un destino concreto, y la segunda es la etiqueta con la que saldrá del enrutador para llegar al destino especificado (“Prefix or Tunel ID”). También nos aporta información sobre la interfaz de salida del paquete a enviar y sobre el próximo salto, especifica la dirección IP de la interfaz por la que tiene que entrar al siguiente enrutador. Podemos observar que en el caso particular en el que el paquete vaya por la línea situada entre P1 y P2 en la información sobre “Next Hop” aparecerá “point2point”.
El comando show ip cef dirIPSubredLANdelOtroPE detail muestra de forma detallada las “tablas de forwarding” Cisco hacia el otro enrutador. Así pues, recibimos información como la etiqueta local que el enrutador desde el que lanzamos el comando ha asignado para paquetes que vayan al enrutador destino, o el interfaz por el que saldrá del enrutador. Además podemos observar que también se nos aporta información sobre la etiqueta de salida que se les pondrá a los paquetes que vayan a la dirección del enrutador destino, para que en su camino de direccionamiento, el resto de equipos de esta ruta la reconozca y comprueben que coincide con la que tienen guardada en su “tabla de forwarding” como “local tag” para dicho destino.
Explicación de la aparición de cabeceras Ethernet, MPLS e IP en el trayecto que lleva desde PE1 a la dirección IP de “loopback” de PE2.
Al paquete perteneciente a PE1 se le añaden la cabecera Ethernet (capa de enlace), la cabecera MPLS y la cabecera IP (capa de red). Con respecto a la etiqueta MPLS, tendrá como valor 20 y saldrá por fa0/1 con valor 19. En cada uno de los saltos posteriores a lo largo de todo el núcleo MPLS, se mantienen sin cambios el campo origen y destino de la cabecera IP (cabecera de la capa de red). Al llegar al siguiente enrutador, en nuestro caso P1, éste consultara su “tabla de forwarding” y buscará en “local tag” coincidencias con la etiqueta asociada por el enrutador destino a la interfaz de salida (valor de la etiqueta MPLS:19), y una vez encontrada se cambiará por la etiqueta de la comlumna “outgoing tag VC” (valor de la etiqueta MPLS:19).
Explicación de la aparición de cabeceras Ethernet, MPLS e IP en el trayecto que lleva desde PE1 a la dirección IP de la interfaz fa0/1 de PE2.
Las cabeceras Ethernet (capa de enlace), MPLS e IP (capa de red) ya estarán añadidas en la cabecera inicial del paquete creado. De la etiqueta MPLS del enrutador P1 podemos decir que tendrá valor 18 y saldrá de dicho enrutador con valor “Pop tag”.
Explicación de las diferencias existentes entre los dos casos anteriores en términos de PHP.
Fijándonos en las “tablas forwarding” podemos observar que, en el primer caso el último POP es realizado por el enrutador P2 (debido a que se trata de la dirección de loopback de PE2, dirección con prefijo 32), pero que en el segundo caso, dicho POP es realizado por P1 (al tratarse de la subred de fa0/1 con prefijo 30).
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Realización de traceroutes a las direcciones de “loopback” y de fa0/1 de PE2 PE1 → PE2 “loopback” Router#traceroute 192.168.139.24 Type escape sequence to abort.
Tracing the route to 192.168.139.24 1 192.168.230.2 [MPLS: Label 19 Exp 0] 0 msec 0 msec 4 msec 2 192.168.230.6 [MPLS: Label 19 Exp 0] 4 msec 0 msec 4 msec 3 192.168.230.10 0 msec * 0 msec PE1 → PE2 “fa0/1” Router#traceroute 192.168.230.10 Type escape sequence to abort.
Tracing the route to 192.168.230.10 1 192.168.230.2 [MPLS: Label 18 Exp 0] 0 msec 4 msec 4 msec 2 192.168.230.6 0 msec 4 msec 0 msec 3 192.168.230.10 4 msec * 0 msec Análisis de la captura y explicación del encapsulado de paquetes relacionándolo con la respuesta del punto anterior. ¿Tienen los ICMP Echo Request el mismo encapsulado que los ICMP Echo Reply? En el traceroute realizado, y en la captura de trafico analizada, se pueden observar que se añade una cabecera MPLS (a las “tradicionales” cabeceras Ethernet e IP que hay en todos los saltos), que se utiliza en los saltos 192.168.230.2 y 192.168.230.6 que corresponden a los equipos P del núcleo MPLS. Podemos observar también en la captura que los ICMP Echo Reply no tienen cabecera MPLS, ya que están dando el último salto hacia el router frontera y la red usa PHP (Pop realizado en el penúltimo salto), a diferencia de los ICMP Echo Request, que sí que presentan encapsulado sobre MPLS.
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Parte II: EoMPLS, con pseudocable asociado a puerto.
Pruebas de conectividad.
Verificación de existencia de conectividad: traceroute entre los ordenadores configurados.
j.ochoas@l059:~$ traceroute 192.168.161.2 traceroute to 192.168.161.2 (192.168.161.2), 30 hops max, 60 byte packets 1 192.168.161.2 (192.168.161.2) 1.828 ms 2.218 ms 2.663 ms ¿Cómo explica el resultado de traceroute en relación a la topología de la red? La principal diferencia que podemos observar aquí con respecto a la primera parte es que el número de saltos se reduce a uno debido a que hemos establecido un pseudocable entre los extremos PE1 y PE2 del núcleo MPLS. Al haber realizado la configuración de un pseudocable entre ambos extremos, observamos que es como si tuviéramos un enlace que los conecta directamente, conexionando los dos extremos como si perteneciesen a la misma subred, debido a esto, en el traceroute aparece un único salto.
Resultado de ejecutar la orden show mpls l2transport vc en los equipos del núcleo MPLS.
PE1 Router#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------Fa0/0 Ethernet 192.168.139.24 400 UP PE2 Router#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------Fa0/0 Ethernet 192.168.139.21 400 UP P1 Router#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------- P2 Router#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------- Este comando muestra la información acerca de los circuitos virtuales sobre AToM y los pseudocables establecidos. Podemos observar varios datos de cada uno de nuestros routers: para empezar se nos muestran las interfaces que se han habilitado para transportar los paquetes a través del nivel 2, apareciendo en PE1 y PE2 fa0/0 y sin información en P1 y P2, ya que en la nueva configuración no participan en el envío de paquetes a través del pseudocable, por lo que no aparecerá nada de información en las tablas correspondientes a estos dos últimos routers, asique nos centraremos en la información de PE1 y PE2. Tras las interfaces habilitadas, seguidamente se nos muestra el tipo de circuito local, en nuestro caso Ethernet, lo único que tenemos asignado.
Posteriormente se nos muestra la dirección IP del “loopback” del otro extremo del pseudocable y el identificador del pseudocable, y, por último el estado del circuito virtual. Así pues, podemos concluir que nuestro pseudocable con identificador 400 se encuentra preparado para transportar tráfico y en estado operativo.
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Análisis de la captura y explicación de las diferencias que se observan en el encapsulado.
Como podemos observar en la captura, la situación es similar a la anterior, en este nuevo caso los paquetes ICMP Echo Request tienen dos cabeceras: una externa, correspondiente a la conmutación MPLS, y otra interna correspondiente al pseudocable. Al igual ocurre con las cabeceras MAC, existe una correspondiente a la conmutación dentro del núcleo MPLS y otra a la conmutación entre cliente y servidor. Sin embargo en los paquetes ICMP Echo Reply aparece una única cabecera MPLS, correspondiente al establecimiento del pseudocable ya que la otra cabecera (correspondiente a la conmutación MPLS) se ha eliminado en el salto anterior (P1) antes de llegar al destino (PE2).
Resultado de ejecutar show stp instance en el conmutador C1 (muestra estado del protocolo STP).
El pseudocable está configurado para dejar pasar las tramas BPDU de STP encapsuladas en MPLS hasta su destino, ya que actúa como un enlace directo de nivel 2 entre los conmutadores CE1 y CE2. En la captura de tráfico anterior estas tramas son las que aparecen con el protocolo STP.
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Resultado de ejecutar show fdb en el conmutador C1 para mostrar la tabla de reenvío del conmutador. Identifique la dirección MAC del servidor y el puerto por el que se reenvían las tramas dirigidas a ella.
SW10:4#show fdb Command: show fdb Unicast MAC Address Aging Time = 300 VID VLAN Name MAC Address Port Type Status ---- -------------------------------- ----------------- ----- ------- ------1 default 00-02-B3-1F-06-72 2 Dynamic Forward 1 default 00-17-08-0E-C1-E 10 Dynamic Forward 1 default 00-1A-2F-7E-8A-48 10 Dynamic Forward 1 default 00-D0-B7-0A-86-77 10 Dynamic Forward 1 default 5C-D9-98-0A-62-8F CPU Self Forward Total Entries: 5 La dirección MAC de nuestro ordenador (L059) es la del puerto 2, por lo que ésta no puede ser la dirección MAC del servidor. Capturando el tráfico mientras hacemos un PING al servidor, observamos que la dirección MAC destino de uno de los paquetes ICMP Echo Request es 00-D0B7-0A-86-77, por lo que podemos concluir que esta será la dirección MAC pedida del servidor.
Parte III: EoMPLS, con pseudocable asociado a VLAN.
Realice PING al servidor y explique los encapsulados MPLS de los paquetes Echo del PING.
Observando tanto las peticiones como las respuestas, trate de averiguar entre que identificadores VLAN está haciendo la traducción el pseudocable configurado.
j.ochoas@l059:~$ ping 192.168.241.2 PING 192.168.241.2 (192.168.241.2) 56(84) bytes of data.
64 bytes from 192.168.241.2: icmp_seq=1 ttl=64 time=1.97 ms 64 bytes from 192.168.241.2: icmp_seq=2 ttl=64 time=2.02 ms 64 bytes from 192.168.241.2: icmp_seq=3 ttl=64 time=1.99 ms 64 bytes from 192.168.241.2: icmp_seq=4 ttl=64 time=1.94 ms --- 192.168.241.2 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 3124ms rtt min/avg/max/mdev = 1.941/1.981/2.023/0.158 ms j.ochoas@l059:~$ traceroute 192.168.241.2 traceroute to 192.168.241.2 (192.168.241.2), 30 hops max, 60 byte packets 1 192.168.241.2 (192.168.241.2) 2.234 ms 2.472 ms 2.966 ms El encapsulamiento sobre MPLS es igual al del apartado anterior, la diferencia reside en que ahora existe un campo para identificación de VLAN y el pseudocable realiza traducción de direcciones entre los dos identificadores de las VLAN, ya que los paquetes ICMP Echo Reply se envían por la VLAN 721 y los paquetes ICMP Echo Request por la VLAN 2001.
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer Mikel Goig Parte IV: Calidad de servicio.
Múltiples tráficos compitiendo por recursos.
¿Cambia en algo la calidad del video recibido?¿Por qué? La calidad del video recibido es peor en el caso en el que hay tráfico de fondo, ya que dicho tráfico consume capacidad de enlace.
Si existe degradación, ¿dónde cree que se produce el cuello de botella? La degradación en la calidad del video se produce porque existe cuello de botella entre los enrutadores P1 y P2, ya que están unidos por una línea serie de baja velocidad, que contrasta en términos de velocidad con el resto de enlaces Ethernet.
Configuración de la calidad de servicio.
¿Mejora la calidad del video recibido? Cuando establecemos la calidad de servicio con prioridad 7, imponemos unas reglas que nos permiten garantizar la prioridad de este tráfico con respecto a otros, mejorando la calidad del video recibido considerablemente.
¿Cree que la garantía de recursos que se hace para el tráfico de vídeo (1500 kbps) excluye que toda esa capacidad se pueda usar para otros tráficos, en caso de que el vídeo no llegue a consumirla toda? Como se trata de una asignación dinámica de recursos en función de varios factores como el tamaño de los paquetes, la prioridad o la calidad del servicio, el hecho de que asignemos una capacidad de 1500 kbps al video, no excluye que dicha capacidad pueda ser asignada al tráfico de fondo cuando no se esté utilizando para transmitir video.
Si necesitas más apuntes puedes encontrarlos en unybook.com buscando el usuario mgoigfer ...

Comprar Previsualizar