Algo sobre tecnologías 4G

http://librosnetworking.blogspot.com/2012/11/algo-sobre-tecnologias-4g.html

El desarrollo de las tecnologías de telefonía celular ha generado un fenómeno social singular, como la integración del teléfono celular como terminal de acceso permanente a un conjunto de recursos que va mucho más allá de la simple llamada telefónica: mensajes de texto, navegación de Internet, acceso a correo electrónico, acceso remoto a equipos y bases de datos, implementación de múltiples aplicaciones, etc.

El número de abonados de telefonía celular crece constantemente, al mismo tiempo que se reduce la demanda de telefonía fija y la presencia de teléfonos públicos.

Esta tendencia tiene una dirección definida: creciente requerimiento de ancho de banda disponible para lograr acceso a Internet desde cualquier punto y en todo momento.

Algo de historia
La denominación 4G alude a que se trata de tecnología de 4° Generación. ¿Cómo es que se llega hasta esta cuarta generación de tecnología celular?

Se consideran 1G las tecnologías de comunicaciones móviles iniciales desarrolladas sobre AMPS (Advanced Mobile Phone Systems). El siguiente paso de evolución (lo que hoy llamaríamos 2G) fueron los sistemas de telefonía celular digital GSM (Global System for Mobile communications) y CDMA-one (Code Division Multiple Access).

Los sistemas GSM utilizan GPRS (General Packet Radio Services) y EDGE (Enhanced Data rates for GSM Evolution) para el transporte de datos sobre sistemas que utilizan tecnología de circuito conmutado.

Las tecnologías 2G han sido sucedidas por UMTS (Universal Mobile Telecommunications System) y EV-DO (EVolution-Data Optimized) que son las que hoy llamamos sistemas 3G. 

Estos sistemas ofrecen mayor eficiencia en el aprovechamiento del espectro de frecuencias y disponibilidad de ancho de banda para las redes móviles.

En la actualidad, en el advenimiento de los sistemas 4G para redes móviles, dos son las tecnologías que suelen ser reseñadas como aptas para esta tarea: LTE-Advanced (Long Term Evolution) y WiMAX2 (Worldwide interoperability for Microwave Access - 802.16m).

• 1G - AMPS
• 2G - GSM y CDMA-one
• 3G - UMTS y EV-DO
• 4G - LTE y WiMAX2

Especificaciones de las tecnologías 4G
La ITU (International Telecommunications Union) ha definido los requerimientos que deben cumplirse para que una tecnología sea considerada de Cuarta Generación: 

• El primer requerimiento es respecto de la movilidad.
  Los sistemas 4G deben soportar alta movilidad (hight mobility).
  Se considera movilidad a la posibilidad de que un dispositivo se desplace asociándose a múltiples radio bases sin que se corte la conexión establecida inicialmente. Hay 2 tipos de movilidad: low mobility es la que cubre el desplazamiento de una persona caminando; hight mobility cubre la posibilidad de un vehículo desplazándose a aproximadamente 100 km/h.
• El segundo requerimiento está referido a la eficiencia en el aprovechamiento del espectro de frecuencias, de modo de lograr el mayor throughput posible para cada velocidad de desplazamiento según el ancho de banda de frecuencia empleado.
  Por ejemplo, con anchos de banda de 100 MHz, se debieran lograr velocidades de 1,5 Gbps. de download y 0,675 Gbps. de upload en condiciones de low mobility.

Otra característica específica de las redes 4G, es que ya no se trata de tecnologías de conmutación de circuitos, sino de conmutación de paquetes que utilizan direccionamiento IP en la capa de red.

Un tema aparte es la disponibilidad de frecuencias para este despliegue. En términos generales, las bandas de frecuencias disponibles son reducidas, y muchas veces en ciertas regiones se trata de porciones fragmentarias del espectro de radiofrecuencias. Esto genera la necesidad de poder utilizar porciones fragmentarias del espectro, por lo que se requieren tecnologías que permitan hacer "agregación" de portadoras tales como Carrier Aggregation y MIMO.

De acuerdo a lo establecido por la ITU, tanto LTE-Advanced como WiMAX2 cubren estos requerimientos y especificaciones para poder ser consideradas entonces como tecnologías 4G. Ambas pueden ser implementadas a partir de la actualización de las redes LTE y WiMAX actualmente disponibles.

Cisco adquiere empresa pionera de WiFi por 1,2 mil millones de dólares

http://www.diarioti.com/noticia/Cisco_adquiere_empresa_pionera_de_WiFi_por_1_coma_2_mil_millones_de_dolares/33442

 [ 19/11/2012 - 10:39 EST ]

El domingo 18 noviembre se anunció que Meraki ha sido adquirida por el gigante de las redes Cisco.

Diario Ti: Hace seis años, tres ingenieros del Instituto tecnológico de Massachusetts crearon la empresa Meraki, dedicada a distribuir soluciones simplificadas para la instalación de redes inalámbricas en empresas. El domingo 18 noviembre se anunció que Meraki ha sido adquirida por el gigante de las redes Cisco por 1,2 mil millones de dólares.

La compra se explica con la estrategia de Cisco de incrementar su participación en el mercado de software de administración de redes, que es precisamente el segmento donde Meraki ha destacado.

El éxito de Meraki comenzó en 2009 con la distribución de un servicio basado en la nube, que permitía a los usuarios administrar sus redes inalámbricas. Con ello, los responsables de redes podían controlar de manera remota todas las unidades que hacen funcionar las redes. Actualmente, la empresa ofrece soluciones completas para empresas, con productos que abarcan redes inalámbricas, soluciones VPN y cortafuegos, seguridad y gestión de dispositivos inalámbricos.

Uno de los primeros clientes de la empresa fue Google. Según el blog de la empresa de capital de riesgo Sequoia Capital, que aportó financiamiento a la empresa en sus comienzos, Meraki vendió 1000 routers al gigante de las búsquedas.

Junto a dos socios, el emprendedor Sanjit Biswas fundó Meraki en 2006. Cuando Cisco golpeó a sus puertas la idea inicial era responder con una negativa, debido a los planes de sus fundadores de llevarla a la bolsa de valores. La empresa creció rápidamente de 120 a 3.430 empleados, conservando la vez un flujo de caja positivo.

En una carta dirigida a los empleados de la empresa, Biswas escribe que a pesar de la intención de salir a bolsa, fue imposible negarse a la oferta de Cisco.

El nuevo plan de la empresa es alcanzar los mil millones de dólares de facturación, algo que Meraki confía será posible con el aparato global de ventas de Cisco.

Procedimiento para presentar un examen de certificación de Cisco

http://librosnetworking.blogspot.com/2012/11/procedimiento-para-presentar-un-examen.html

Por Oscar Gerometta

Cuando se rinde por primera vez un examen de certificación son más las incógnitas con las certezas. ¿Qué tengo que estudiar? ¿Cómo es el examen? ¿Cómo califica el examen? ¿Cuándo se el resultado?... pero hay también una exclusivamente operativa ¿Qué tengo que hacer para presentarme? ¿Cómo me registro? ¿En qué fecha?

En realidad es mucho más simple de lo que parece, pero como todo, la primera vez si no se sabe, parece complejo.

¿Ante quién rindo el examen?

Los exámenes de certificación de Cisco son administrados desde el año 2007 únicamente por Pearson VUE. Se puede presentar el examen en cualquier Autorized Testing Center VUE.

Para verificar cuál es el Testing Center más cercano y la información de contacto pertinente consulte la página web de la empresa aquí.

¿Dónde rindo el examen?

El candidato tiene total libertad de elegir el Testing Center de su preferencia. Simplemente hay que revisar la lista de TC autorizados y elegir el que resulte más conveniente.

No hay obligación de rendir en un TC en particular.

Sin embargo, tenga presente que algunos TC no están autorizados a tomar exámenes de todas las certificación que administra VUE, por lo que es importante verificar antes.

La información de localización y contacto de cada TC está en esta misma página.

¿En qué fecha debo rendir?

La fecha para presentar el examen es decisión del candidato y solamente depende de la disponibilidad del Testing Center en la fecha y horario que haya elegido.

No hay llamados a examen o fechas predeterminadas de ningún tipo. Sólo la disponibilidad de turnos en el TC elegido para poder presentar el examen.
En este sentido, elija una fecha estimada de examen y organice su estudio en función de esa fecha y su disponibilidad de tiempo para estudiar. Reserve el turno con tiempo para asegurarse de poder rendir en la fecha que elija.

Tenga en cuenta que cada Testing Center tiene asignados días y horarios en los que puede habilitar exámenes. Consulte los horarios y formas de pago que hay disponibles en cada caso. Puede verlos en la página web de Pearson VUE. También tenga en cuenta que en algunos Testing Center se requiere registrarse con cierta anticipación a la fecha. No deje este trámite para último momento y asegúrese su fecha de examen.

¿Cómo me registro y reservo la fecha?

El registro y reserva de turno para presentar el examen se puede hacer en línea a través de la página web de Pearson VUE. Para hacerlo deberá registrarse en la página de Pearson VUE.

Algunos TC admiten que el registro se realice personalmente en sus instalaciones. Consulte directamente con el TC que ha seleccionado.

¿Como se realiza el pago del arancel?

El modo de pago estándar para todos los TC es a través de tarjeta de crédito internacional, y se realiza durante el registro y reserva de fecha.

Para consultar respecto de disponibilidad de otras formas de pago, es necesario consultar con cada TC.

Respuestas varias

• Nadie está obligado a rendir en un TC en particular. Cada candidato elige el TC de su preferencia.
• No hay fechas pre establecidas. El candidato la elige en función de la disponibilidad que hay en el TC de su elección.
• No hay períodos o llamados a examen.
• Si se cuenta con un voucher de descuento, durante el proceso de registro se solicitará ingrese el número del voucher para aplicar el descuento en ese momento.

ICMP

http://librosnetworking.blogspot.com/2012/11/icmp.html 

Por Oscar Gerometta

 
ICMP (Internet Control Message Protocol) es uno de los protocolos "olvidados" del stack TCP/IP. En muchos casos, incluso es reducido a nuestra pobre utilización de ping y tracert, que en definitiva son 2 programas que se apoyan en la operación de un protocolo que es fundamental para la operación de nuestras redes.

Es el protocolo responsable de proporcionar a las redes IP un conjunto de mensajes de control y error que permiten detectar y resolver problemas en la red de modo automático. Permite el reporte de errores en un entorno IP ya que el mismo protocolo IP no tiene posibilidad alguna de detectar o reportar errores a nivel de capa de red. 

Hoy tenemos 2 versiones operativas del protocolo, ICMPv4 que opera en redes IPv4 e ICMPv6 que opera como parte de las redes IPv6. Son 2 versiones diferentes del mismo protocolo, incompatibles entre sí.

ICMP genera diferentes tipos de mensajes diferentes que se agrupan en 2 funciones básicas: mensajes de error y mensajes de control:

ICMPv4 es generalmente bloqueado en redes corporativas para evitar algunos ataques conocidos que se basan en el funcionamiento de ICMP.

ICMPv6 no es diferente de su predecesor pero puede implementar autenticación y encriptación IPsec, lo que reduce las posibilidades de que sea aprovechado para un ataque. 

Esto es importante ya que en el caso de IPv6 ICMP se utiliza en múltiples procedimientos tales como la determinación del MTU, en el descubrimiento de vecinos, y reemplaza ARP.

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