martes, 30 de octubre de 2012

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

lunes, 22 de octubre de 2012

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

lunes, 15 de octubre de 2012

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.

viernes, 12 de octubre de 2012

NetRiders 2012 - Resultados de la Fase 1

http://viewonline.fromdoppler.com/nfxy/dAmthl/c/a/a
NetRiders - Fase 2
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 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 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 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

martes, 9 de octubre de 2012

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.

lunes, 8 de octubre de 2012

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)                            |
   +---------------------------------------------------------------+

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


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