Soporte IEEE 802.11w en el cliente wireless de Windows 8

http://librosnetworking.blogspot.com/2012/10/soporte-ieee-80211w-en-el-cliente.html

Con el reciente lanzamiento de Windows 8 algunas empresas están comenzado a considerar la posibilidad de migrar hacia este nuevo sistema operativo.

Windows 8 incluye un cliente para redes inalámbricas (IEEE 802.11 o WiFi) que es el primero en soportar el estándar IEEE 802.11w.

¿Qué es esto?

IEEE 802.11w es el estándar (aprobado en el año 2009) para dar seguridad a las tramas de management en redes 802.11 o WiFi. 

Cuando hablamos de seguridad en redes WiFi estamos acostumbrados a referirnos a WEP, WPA o WPA2. Sin embargo, en la operación de nuestras redes inalámbricas hay 3 grandes tipos de tramas: las tramas de control, las tramas de management y las tramas de datos. WEP, WPA y WPA2 sólo tienen como objeto asegurar las tramas de datos. 802.11w tiene como objeto asegurar las tramas de management.

Cisco dió respuesta hace ya algún tiempo a este requerimiento de seguridad con un feature propietario que conocemos como MFP (Management Frame Protection), y de hecho MFP ha sido la base del desarrollo de este estándar. Sin embargo, las actuales versiones de sistema operativo para wireless LAN controllers (7.3) soportan MFP pero no todavía la versión definitiva de 802.11w.

La protección de las tramas de management es un aspecto muy importante para una red inalámbrica verdaderamente segura, y no puede dejar de contemplarse sobre todo en redes de tipo corporativo. En este sentido la incorporación de 802.11w en el cliente de Win8 es una excelente noticia, pero también impone ´la necesidad de una adecuación en la infraestructura.

Cisco ya anunció para diciembre próximo el lanzamiento de la versión 7.4 del firmware de los wireless LAN controllers (WLC), con soporte completo para 802.11w. En el mientras tanto, la sugerencia de Cisco es:

• Hacer un upgrade del firmware de los WLC a la versión 7.3.101.0, 7.2.111.3, 7.0.235.3.
• Hacer uso de versiones específicas (no las últimas) de los drivers de las placas de red. Caso contrario pueden experimentar un bug identificado como CSCua29504.

Enlace de referencia en la página de Cisco: http://blogs.cisco.com/wireless/get-your-wi-fi-network-ready-for-windows-8

IEEE 802.11ac

http://librosnetworking.blogspot.com.ar/2012/10/ieee-80211ac.html

Por Oscar Gerometta

Ya están disponibles en el mercados los primeros dispositivos que operan de acuerdo a la norma 802.11ac. Por eso me parece oportuno repasar y ampliar un poco la información que tenemos sobre el tema.
Ventajas que se esperan
Con la implementación de 802.11ac se espera:

• Aumentar la cantidad de clientes conectados por access point.
• Mejorar la experiencia de los usuarios.
• Aumentar el ancho de banda disponible.
• Mejorar la duración de las baterías de los dispositivos móviles.

Las claves de la mejora
Respecto de 802.11n, hay 3 mejoras que son claves para poder lograr la performance que el nuevo estándar prevé:

• Se extiende el concepto de channel bonding que permite operar equipos 802.11n con canales de 40 MHz. (2 canales de 20 MHz.).
  En la llamada primera ola de dispositivos se pueden utilizar canales de hasta 80 MHz., mientras que en la segunda ola se anuncian canales de hasta 160 MHz. Esto permite una mejora del 117% en la primera ola, y del 333% en la segunda.
• Se aplican modulación de mayor densidad: 256 QAM.
  Hasta el momento la modulación más densa utilizada es 64 QAM. Esto agrega una mejora del orden del 33%.
• Mayor cantidad de cadenas de transmisión/recepción simultáneas.
  802.11n permite definir hasta 4 cadenas de transmisión simultáneas; en 802.11ac esta capacidad se lleva hasta 8 cadenas simultáneas. Consecuentemente introduce una mejora del 100%.

En todos los casos el estándar prevé y asegura la compatibilidad con dispositivos 802.11a/n.Las presentaciones comerciales
Indudablemente, la incorporación de estas novedades en la operación de radios de 5 GHz. supone un incremento en el costo, lo que impone limitaciones comerciales para la presentación de dispositivos que soporten la totalidad de las opciones disponibles.
Al escribir estas líneas, solamente algunos dispositivos 802.11n de los presentes en el mercado llegan a una capacidad de 450 Mbps (de los 600 posibles); algo semejantes está ocurriendo con el lanzamiento de productos 802.11ac.
Comercialmente se habla de 2 olas de dispositivos. Una primer ola (que ya está apareciendo en el mercado) que utiliza canales de hasta 80 MHz con una performance posible de hasta 1,3 Mbps.; una segunda ola de dispositivos que podrá llegar hasta los 3,47 Mbps.
En esos equipos de segunda generación, no sólo se espera ampliar el channel bonding y la cantidad de cadenas simultáneas sino también incorporar MU-MIMO (Multiple User MIMO) que permitirá mejorar la performance en entornos BYOD, en los que la mayoría de los smartphones y tablets pueden lenvantar una única cadena de transmisión mientras que el access point puede utilizar varias simultáneamente.
Adicionalmente, dado que 802.11ac es una tecnología que opera exclusivamente en 5GHz., se anuncian equipos de radio dual que operan 802.11n en la radio de 2,4 GHz. y 802.11ac en la radio de 5 GHz.
Cronología del nuevo estándar

• Enero de 2012 - Se aprobó el Draft 2 de 802.11ac.
• Mayo de 2012 - Se aprobó el Draft 3 del estándar.
• Inicios de 2013 - Se espera la certificación de la Alianza WiFi para los dispositivos de la primera ola.
• Diciembre de 2013 - Se prevé la aprobación del estándar definitivo.
• Enero de 2014 o más adelante - La Alianza WiFi lanzará la certificación para los dispositivos de la segunda ola.

Se recomienda esperar a la aprobación de la certificación de interoperabilidad de la Alianza WiFi de los dispositivos de la primera ola para iniciar la implementación, a fin de poder asegurar el funcionamiento sin inconvenientes de access points y clientes de diferentes fabricantes.
Enlaces relacionados

• Introducción a redes IEEE 802.11ac
• Presentación del AP Linksys AC 1750 HD Video Pro
• Presentación del AP Router 5700 (DIR-865L) de D-Link
• Netgear R6300 WiFi Router

Orígenes de TCP/IP

http://librosnetworking.blogspot.com.ar/2012/10/origenes-de-tcpip.html

Por Oscar Gerometta

Durante la década de 1970 se desarrolló el modelo TCP/IP con el objetivo de construir una red de comunicaciones que pudiera mantenerse operativa ante cualquier circunstancia operacional adversa. 
 
El concepto de base es la idea de un planeta cruzado por numerosos tendidos de cables, alambres de cobre y fibra óptica, a los que se sumarían enlaces de microondas y satelitales. En esta coyuntura era necesario diseñar una red que permita transmitir datos independientemente de la ubicación o red particular a la que pueda encontrarse conectado una terminal o centro de cómputos. 
 
El objetivo planteado requería de una transmisión de datos que pudiera ser considerada confiable, que lograra alcanzar cualquier destino dentro de la red global, y bajo cualquier circunstancia.

 
Luego de varias propuestas alternativas, las primeras especificaciones del protocolo TCP (RFC 675) fueron elaboradas en la universidad de Stanford entre los años 1973 y 1974. Sobre esta base se establece en el año 1975 la primera comunicación utilizando TCP/IP entre la Universidad de Stanford y el University College London.
 
El desarrollo de una versión operativa del protocolo sobre diferentes plataformas de hardware estuvo a cargo de ambas instituciones universitarias, dando lugar a diferentes versiones del mismo: TCP v1, TCP v2, una versión de transición TCP v3 e IP v3 (en la que ambos protocolos se separan), y finalmente la versión estable actual: TCPv4 /IPv4.
 
La introducción del modelo TCP/IP fue la propuesta que permitió dar respuesta a este desafío de diseño. Desde ese momento TCP/IP se ha convertido en el estándar de base para el funcionamiento de Internet.
 
ARPANET migró completamente al stack TCP/IP el 1 de enero de 1983, con lo que la arquitectura de comunicaciones más utilizada de la historia de la humanidad lleva operando a la fecha más de 25 años.

NetRiders 2012 - Resultados de la Fase 1

http://viewonline.fromdoppler.com/nfxy/dAmthl/c/a/a

La Fase 1 de la competencia ha finalizado. Ha sido una etapa de grandes desafíos en la que los competidores midieron sus conocimientos entre más de 5.000 participantes de toda la región. En pocos días más comenzará la Fase 2, que tendrá lugar entre el 17 y el 26 de octubre próximos. Como coordinadores de la competencia, en Fundación Proydesa estamos orgullosos de saludar a todos los alumnos de la Red Proydesa que —no sin esfuerzo— han logrado pasar a la Fase 2 de NetRiders Latinoamérica y el Caribe 2012: Argentina Centro Investigación Tecnológico para la Capacitación Humana (C.I.T.E.C.H.) Juan Pablo Cabello Carasso Nicolas Alberto Briozzo Fundacion Proydesa Juan Pablo Azar Ricciardi Natalia Susana Caporale Campaña Pablo Antonio Loberto Pablo Komesu Sandro Lucas Villanueva Universidad Nacional del Noroeste de la Provincia de Buenos Aires Gaston Calvente Universidad Tecnologica Nacional - Facultad Regional Avellaneda Federico Hernan Mangini Julio Cesar Couselo Omar Lucio Diz Santiago Javier Fernandez Universidad Tecnologica Nacional - Facultad Regional Cordoba Emmanuel Maximiliano Stark Fabricio Javier Zappegno Horacio Javier Oggero Marcos Rubio Alvaro Matias Ezequiel Cantarero Universidad Tecnologica Nacional - Facultad Regional Mendoza Mauro Hertlein Universidad Tecnologica Nacional - Facultad Regional Tucuman Ernesto Moyano Universidad Tecnologica Nacional - Facultad Regional Villa Maria Enrique Destefanis Jose Escobar Juan Pablo Torres Ramiro Bertalot Bolivia Centro de Especializacion en Computacion y Estudios Comerciales Pedro Shogun Shomose Perez TEKHNE - Cochabamba  Bruno Marcelo Lara Sainz Andrea Cruz Gutierrez Carlos Alberto Quiñones Vila Giovanny Samuel Uscamaita Jimenez Raul Cristhian Tapia Torrico TEKHNE - La Paz Gisela Fernandez Chavez Janneth Condori Limachi Silvana Llanque Perez Wilson Sebastian Zapana Calderon Universidad Mayor San Francisco Xavier de Chuquisaca Hebert Wilfredo Condori Montalvo Marcelo Ferrufino Murillo Universidad Tecnologica Privada de Santa Cruz de la Sierra Herlan Willy Valverde Valverde Paraguay Universidad del Cono Sur de las Americas Benicio Centurion Blas Rene Rodriguez Vargas Edgar Daniel Lopez Arce Oscar Fernando Vazquez Carvallo Victor Ramon Guzman Cantero
Nuestras más sinceras felicitaciones a todos ellos y a los instructores que brindan su tiempo para apoyarlos y supervisarlos. Fundación Proydesa, octubre de 2012.
academia@proydesa.org | [+54] 11 4327.1888 | Buenos Aires | Argentina

Asignación de direcciones IP

http://librosnetworking.blogspot.com/2012/10/asignacion-de-direcciones-ip.html

Por Oscar Gerometta

Todo dispositivo que opera en una red IP necesita contar con una configuración IP básica (identificador de interfaz, default gateway, DNS, etc.). Esta configuración puede lograrse a partir de diferentes mecanismos.
 
IPv4 prevé en la actualidad varios mecanismos para asignar la configuración IP, los más frecuentemente utilizados son:

• Configuración estática.
• Asignación automática utilizando DHCP.

A estos mecanismos hay que sumar RARP y BOOTP, ambos hoy en desuso en la mayoría de los dispositivos.
 
IPv6, por su parte, introduce junto a estos mecanismos ya en uso nuevas modalidades de realizar esta tarea:

• Asignación estática definiendo manualmente el ID de interfaz.
• Asignación estática definiendo el ID de interfaz por EUI-64.
• Asignación dinámica utilizando autoconfiguración stateless.
• Asignación dinámica utilizando DHCPv6.

La amplitud del espacio de direccionamiento ofrecido por IPv6 ha permitido la implementación de sistemas de asignación automática de la porción del ID del puerto tales como EUI-64 y la configuración stateless; lo que simplifica y facilita los procedimientos de puesta en producción de dispositivos IP.

Prueba de cantidad máxima de redes publicadas en RIP

Por Ernesto Vilarrasa -- Rosario - Argentina
Tomado de: http://www.vilarrasa.com.ar/rip_con_25_redes.htm

Prueba de cantidad máxima de redes publicadas en RIP

Fecha: 4 de Octubre del 2012 Clase: Exploration 2

Detalle

Repasando el tema para la clase del 4 de Octubre, me quedo con un gráfico de la currícula donde está el scope de un

paquete RIP y detalla un máximo de 25 redes publicadas, esto no sebe confundirse con la cantidad máxima de saltos,

que es 15. ¿ Entonces, que pasaría si hay mas de 25 redes ? allí vamos, pasemos los límites.

Puntos 7.1.3  y 7.2.1 de Exploration 2

Buscamos en la RFC de RIP v2

3. Protocol Extensions

   This document does not change the RIP protocol per se.  Rather, it

   provides extensions to the message format which allows routers to

   share important additional information.

   The first four octets of a RIP message contain the RIP header.  The

   remainder of the message is composed of 1 - 25 route entries (20

   octets each).  The new RIP message format is:

    0                   1                   2                   3 3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Command (1)   | Version (1)   |           unused              |

   +---------------+---------------+-------------------------------+

   | Address Family Identifier (2) |        Route Tag (2)          |

   +-------------------------------+-------------------------------+

   |                         IP Address (4)                        |

   +---------------------------------------------------------------+

   |                         Subnet Mask (4)                       |

   +---------------------------------------------------------------+

   |                         Next Hop (4)                          |

   +---------------------------------------------------------------+

   |                         Metric (4)                            |

   +---------------------------------------------------------------+

Fuente: http://www.ietf.org/rfc/rfc1723.txt

Escenario

Configuramos en Packet Tracer un router 1841 con 29 interfaces loopback para simular las 29 redes, y realizamos el  debug

de RIP para ver tanto las actualizaciones salientes, como las entrantes en router Borde, que tiene dos  segmentos: 10.x.x.x

y 192.168.x.x , compartiendo la 10.0.0.0 /24, y por lo tanto, no hay sumarización.

Borde#sh ip route (verificamos convergencia)

---resumido---

     10.0.0.0/24 is subnetted, 26 subnets

C       10.0.0.0 is directly connected, FastEthernet0/0

R       10.0.1.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0 (1ra red)

R       10.0.2.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.3.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.4.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.5.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.6.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.7.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.8.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.9.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.10.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.11.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.12.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.13.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.14.0 [120/1] via 10.0.0.1, 00:00:20, FastEthernet0/0

R       10.0.15.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.16.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.17.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.18.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.19.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.20.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.21.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.22.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.23.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.24.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.25.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0 (25ta red)

R       10.0.26.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.27.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.28.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

R       10.0.29.0 [120/1] via 10.0.0.1, 00:00:19, FastEthernet0/0

C    192.168.0.0/24 is directly connected, FastEthernet0/1

Borde#deb ip rip

RIP protocol debugging is on

Borde#

RIP: sending  v1 update to 255.255.255.255 via FastEthernet0/0 (10.0.0.2)

RIP: build update entries

      network 192.168.0.0 metric 1

RIP: received v1 update from 10.0.0.1 on FastEthernet0/0

      10.0.1.0 in 1 hops

      10.0.2.0 in 1 hops

      10.0.3.0 in 1 hops

      10.0.4.0 in 1 hops

      10.0.5.0 in 1 hops

      10.0.6.0 in 1 hops

      10.0.7.0 in 1 hops

      10.0.8.0 in 1 hops

      10.0.9.0 in 1 hops

      10.0.10.0 in 1 hops

      10.0.11.0 in 1 hops

      10.0.12.0 in 1 hops

      10.0.13.0 in 1 hops

      10.0.14.0 in 1 hops

      10.0.15.0 in 1 hops

      10.0.15.0 in 1 hops

      10.0.16.0 in 1 hops

      10.0.17.0 in 1 hops

      10.0.18.0 in 1 hops

      10.0.19.0 in 1 hops

      10.0.20.0 in 1 hops

      10.0.21.0 in 1 hops

      10.0.22.0 in 1 hops

      10.0.23.0 in 1 hops

      10.0.24.0 in 1 hops

      10.0.25.0 in 1 hops

RIP: received v1 update from 10.0.0.1 on FastEthernet0/0 (actualización extra,

      10.0.26.0 in 1 hops       instantánea, no es a los próximos 30 segundos)

      10.0.27.0 in 1 hops

      10.0.28.0 in 1 hops

      10.0.29.0 in 1 hops

Borde#undebug all

All possible debugging has been turned off

Borde#

Router_1#debug ip rip

RIP protocol debugging is on

Router_1#

RIP: received v1 update from 10.0.0.2 on FastEthernet0/0 (desde Borde)

      192.168.0.0 in 1 hops

RIP: sending  v1 update to 255.255.255.255 via Loopback29 (10.0.29.1)

RIP: build update entries

      network 10.0.0.0 metric 1

      network 10.0.1.0 metric 1

      network 10.0.2.0 metric 1

      network 10.0.3.0 metric 1

      network 10.0.4.0 metric 1

      network 10.0.5.0 metric 1

      network 10.0.6.0 metric 1

      network 10.0.7.0 metric 1

      network 10.0.8.0 metric 1

      network 10.0.9.0 metric 1

      network 10.0.10.0 metric 1

      network 10.0.11.0 metric 1

      network 10.0.12.0 metric 1

      network 10.0.13.0 metric 1

      network 10.0.14.0 metric 1

      network 10.0.15.0 metric 1

      network 10.0.16.0 metric 1

      network 10.0.17.0 metric 1

      network 10.0.18.0 metric 1

      network 10.0.19.0 metric 1

      network 10.0.20.0 metric 1

      network 10.0.21.0 metric 1

      network 10.0.22.0 metric 1

      network 10.0.23.0 metric 1

      network 10.0.24.0 metric 1

RIP: sending  v1 update to 255.255.255.255 via Loopback29 (10.0.29.1)

RIP: build update entries (actualización extra)

      network 10.0.25.0 metric 1

      network 10.0.26.0 metric 1

      network 10.0.27.0 metric 1

      network 10.0.28.0 metric 1

      network 192.168.0.0 metric 2

Router_1#undebug all

All possible debugging has been turned off

Router_1#

Borde#sh runn

Building configuration...

Current configuration : 524 bytes

!

!

hostname Borde

!

interface FastEthernet0/0

 ip address 10.0.0.2 255.255.255.0

!

interface FastEthernet0/1

 ip address 192.168.0.1 255.255.255.0

!

router rip

 network 10.0.0.0

 network 192.168.0.0

!

end

Borde#

Router_1#sh runn

Building configuration...

Current configuration : 1312 bytes

!

!

hostname Router_1

!

interface Loopback1

 ip address 10.0.1.1 255.255.255.0

!

interface Loopback2

 ip address 10.0.2.1 255.255.255.0

!

interface Loopback3

 ip address 10.0.3.1 255.255.255.0

!

interface Loopback4

 ip address 10.0.4.1 255.255.255.0

!

interface Loopback5

 ip address 10.0.5.1 255.255.255.0

!

interface Loopback6

 ip address 10.0.6.1 255.255.255.0

!

interface Loopback7

 ip address 10.0.7.1 255.255.255.0

!

interface Loopback8

 ip address 10.0.8.1 255.255.255.0

!

interface Loopback9

 ip address 10.0.9.1 255.255.255.0

!

interface Loopback10

 ip address 10.0.10.1 255.255.255.0

!

interface Loopback11

 ip address 10.0.11.1 255.255.255.0

!

interface Loopback12

 ip address 10.0.12.1 255.255.255.0

!

interface Loopback13

 ip address 10.0.13.1 255.255.255.0

!

interface Loopback14

 ip address 10.0.14.1 255.255.255.0

!

interface Loopback15

 ip address 10.0.15.1 255.255.255.0

!

interface Loopback16

 ip address 10.0.16.1 255.255.255.0

!

interface Loopback17

 ip address 10.0.17.1 255.255.255.0

!

interface Loopback18

 ip address 10.0.18.1 255.255.255.0

!

interface Loopback19

 ip address 10.0.19.1 255.255.255.0

!

interface Loopback20

 ip address 10.0.20.1 255.255.255.0

!

interface Loopback21

 ip address 10.0.21.1 255.255.255.0

!

interface Loopback22

 ip address 10.0.22.1 255.255.255.0

!

interface Loopback23

 ip address 10.0.23.1 255.255.255.0

!

interface Loopback24

 ip address 10.0.24.1 255.255.255.0

!

interface Loopback25

 ip address 10.0.25.1 255.255.255.0

!

interface Loopback26

 ip address 10.0.26.1 255.255.255.0

!

interface Loopback27

 ip address 10.0.27.1 255.255.255.0

!

interface Loopback28

 ip address 10.0.28.1 255.255.255.0

!

interface Loopback29

 ip address 10.0.29.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 10.0.0.1 255.255.255.0

!

router rip

 network 10.0.0.0

!

ip classless

!

end

Router_1#

Prueba con equipo real, para sacarnos dudas de la reacción de Packet Tracer.

Router# debug ip rip

*Oct  4 19:12:53.731: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (10.0.0.1)

*Oct  4 19:12:53.731: RIP: build update entries

*Oct  4 19:12:53.731: subnet 10.0.1.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.2.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.3.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.4.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.5.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.6.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.7.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.8.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.9.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.10.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.11.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.12.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.13.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.14.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.15.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.16.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.17.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.18.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.19.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.20.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.21.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.22.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.23.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.24.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.25.0 metric 1

*Oct  4 19:12:53.731: RIP: build update entries  (actualización extra)

*Oct  4 19:12:53.731: subnet 10.0.26.0 metric 1

*Oct  4 19:12:53.731: subnet 10.0.27.0 metric 1

*Oct  4 19:12:53.735: subnet 10.0.28.0 metric 1

*Oct  4 19:12:53.735: subnet 10.0.29.0 metric 1

Detalle de las tramas RIP

Frame 1 (546 bytes on wire, 546 bytes captured)

    Arrival Time: Oct  4, 2012 21:16:04.657240000 (primeras 25 redes)

    [Time delta from previous captured frame: 0.000000000 seconds]

Frame 2 (126 bytes on wire, 126 bytes captured)

    Arrival Time: Oct  4, 2012 21:16:04.657310000 (no es otra publicación a los 30 segundos)

    [Time delta from previous captured frame: 0.000070000 seconds]

No.     Time        Source                Destination           Protocol Info

      1 0.000000    10.0.0.1              255.255.255.255       RIPv1    Response

Ethernet II, Src: 00:1d:46:a5:27:60 (00:1d:46:a5:27:60), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)

Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 255.255.255.255 (255.255.255.255)

User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)

Routing Information Protocol

    Command: Response (2)

    Version: RIPv1 (1)

    IP Address: 10.0.1.0, Metric: 1

    IP Address: 10.0.2.0, Metric: 1

    IP Address: 10.0.3.0, Metric: 1

    IP Address: 10.0.4.0, Metric: 1

    IP Address: 10.0.5.0, Metric: 1

    IP Address: 10.0.6.0, Metric: 1

    IP Address: 10.0.7.0, Metric: 1

    IP Address: 10.0.8.0, Metric: 1

    IP Address: 10.0.9.0, Metric: 1

    IP Address: 10.0.10.0, Metric: 1

    IP Address: 10.0.11.0, Metric: 1

    IP Address: 10.0.12.0, Metric: 1

    IP Address: 10.0.13.0, Metric: 1

    IP Address: 10.0.14.0, Metric: 1

    IP Address: 10.0.15.0, Metric: 1

    IP Address: 10.0.16.0, Metric: 1

    IP Address: 10.0.17.0, Metric: 1

    IP Address: 10.0.18.0, Metric: 1

    IP Address: 10.0.19.0, Metric: 1

    IP Address: 10.0.20.0, Metric: 1

    IP Address: 10.0.21.0, Metric: 1

    IP Address: 10.0.22.0, Metric: 1

    IP Address: 10.0.23.0, Metric: 1

    IP Address: 10.0.24.0, Metric: 1

    IP Address: 10.0.25.0, Metric: 1

No.     Time        Source                Destination           Protocol Info

      2 0.000070    10.0.0.1              255.255.255.255       RIPv1    Response

Ethernet II, Src: 00:1d:46:a5:27:60 (00:1d:46:a5:27:60), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)

Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 255.255.255.255 (255.255.255.255)

User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)

Routing Information Protocol

    Command: Response (2)

    Version: RIPv1 (1)

    IP Address: 10.0.26.0, Metric: 1

    IP Address: 10.0.27.0, Metric: 1

    IP Address: 10.0.28.0, Metric: 1

    IP Address: 10.0.29.0, Metric: 1

Datos del layer 4 de las capturas, según el RFC 1700

utime           519/udp    unixtime

efs             520/tcp    extended file name server

router          520/udp    local routing process (on site);

#                          uses variant of Xerox NS routing

#                          information protocol

#               521-524    Unassigned

timed           525/tcp    timeserver

Fuente: http://www.ietf.org/rfc/rfc1700.txt

Reflexión: entonces, sirve de algo este escenario ? sólo se trata de llevar al límite el protocolo y ver que pasa.

No existen routers reales con  29 interfaces loopback, pero sí un escenario como el siguiente podría ser real,

aunque ningún administrador con amor propio implementaría RIP.

Con OSPF u otro protocolo de enrutamiento esto no sucedería ya que se intercambian bases de datos con información

acerca de las redes conocidas.

Asuncion#show ip route

---resumido---

Gateway of last resort is 172.16.4.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 32 subnets

R       172.16.1.0 [120/1] via 172.16.2.1, 00:00:26, Serial0/1 (ruta aprendida por otra interfaz)

C       172.16.2.0 is directly connected, Serial0/1

C       172.16.3.0 is directly connected, FastEthernet0/0

C       172.16.4.0 is directly connected, Serial0/0

R       172.16.5.0 [120/1] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.6.0 [120/1] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.7.0 [120/2] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.8.0 [120/2] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.9.0 [120/3] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.10.0 [120/3] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.11.0 [120/4] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.12.0 [120/4] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.13.0 [120/5] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.14.0 [120/5] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.15.0 [120/6] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.16.0 [120/6] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.17.0 [120/7] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.18.0 [120/7] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.19.0 [120/8] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.20.0 [120/8] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.21.0 [120/9] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.22.0 [120/9] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.23.0 [120/10] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.24.0 [120/10] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.25.0 [120/11] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.26.0 [120/11] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.27.0 [120/12] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.28.0 [120/12] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.30.0 [120/13] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.31.0 [120/14] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.32.0 [120/14] via 172.16.4.2, 00:00:01, Serial0/0

R       172.16.33.0 [120/15] via 172.16.4.2, 00:00:01, Serial0/0

R*   0.0.0.0/0 [120/13] via 172.16.4.2, 00:00:01, Serial0/0 (29 rutas aprendidas en RIP vía s0/0)

Asuncion#debug ip rip

RIP: received v1 update from 172.16.4.2 on Serial0/0

      0.0.0.0 in 13 hops

      172.16.5.0 in 1 hops

      172.16.6.0 in 1 hops

      172.16.7.0 in 2 hops

      172.16.8.0 in 2 hops

      172.16.9.0 in 3 hops

      172.16.10.0 in 3 hops

      172.16.11.0 in 4 hops

      172.16.12.0 in 4 hops

      172.16.13.0 in 5 hops

      172.16.14.0 in 5 hops

      172.16.15.0 in 6 hops

      172.16.16.0 in 6 hops

      172.16.17.0 in 7 hops

      172.16.18.0 in 7 hops

      172.16.19.0 in 8 hops

      172.16.20.0 in 8 hops

      172.16.21.0 in 9 hops

      172.16.22.0 in 9 hops

      172.16.23.0 in 10 hops

      172.16.24.0 in 10 hops

      172.16.25.0 in 11 hops

      172.16.26.0 in 11 hops

      172.16.27.0 in 12 hops

      172.16.28.0 in 12 hops

RIP: received v1 update from 172.16.4.2 on Serial0/0

      172.16.30.0 in 13 hops

      172.16.31.0 in 14 hops

      172.16.32.0 in 14 hops

      172.16.33.0 in 15 hops

(2012) Networking scare pretty girls

Rosario, Argentina