Comandos de configuración de interfaces en dispositivos Cisco - Actualización

Por Oscar Gerometta
 
Continuando con la revisión de las publicaciones más visitadas en estos años la siguiente es esta. Escrita también durante el primer año de este blog, es la segunda más visitada, con lo que también supongo que su información es útil para muchos y por lo tanto también decidí revisarla y actualizarla.
 
Este es el resultado.

Durante el proceso de configuración de dispositivos de infraestructura llega siempre el momento de realizar o modificar la configuración de una interfaz o varias interfaces. En este sentido es fundamental que tengamos en cuenta algunos comandos Cisco IOS claves, que son comunes a todas las interfaces de los dispositivos Cisco IOS.

Ante todo, todos los comandos relacionados con la configuración de las interfaces de dispositivos IOS se ejecutan en el modo configuración de interfaz:

Router#configure terminal
Router(config)#interface [tipo] [módulo/interfaz.subinterfaz]

Un ejemplo:
Router(config)#interface GigabitEthernet 0/0

De esta forma se ingresa al modo de configuración de la interfaz tanto de routers como switches o firewalls Cisco.
 
Es necesario indicar la interfaz que se desea configurar o crear, según sea el caso.

Alternativamente, cuando debemos realizar la configuración de un grupo de interfaces de igual tipo y con los mismos parámetros (algo habitual en el caso de los switches) se puede utilizar el comando interface range:

Switch(config)#interface range FastEthernet 0/1 - 10
Switch(config-if-range)#_

Una vez en el modo configuración de interfaz se puede consultar el listado de comandos disponibles utilizando el comando de ayuda habitual: ? debemos tener presente que la lista de comandos que se genera varía de acuerdo al tipo de interfaz, la plataforma y la versión de IOS de que se trate.
 
En esta lista de comandos, algunos de los básicos son:

Router(config-if)#no shutdown
 
Las interfaces de los routers Cisco IOS tienen sus interfaces inactivas por defecto por lo que requieren ser activadas por configuración para que sean operativas.
 
Los switches Cisco Catalyst, en cambio, tienen todas sus bocas activas por defecto, motivo por el cual se sugiere que aquellas que no sean utilizadas sean desactivadas por configuración.
 
Para que una interfaz sea activa debe encontrarse en estado up/up, para lo cual en el caso de los routers es necesario que los puertos sean habilitados manualmente por el administrador utilizando el comando:

Router(config-if)#no shutdown

Al hacer copias de respaldo de los archivos de configuración es preciso recordar que este comando no se guarda en el archivo de configuración por lo que es conveniente editar esos archivos para agregar este comando en cada interfaz para facilitar que los puertos sean inmediatamente operativos cuando se haga una restauración de esa configuración.

Router(config-if)#ip address x.x.x.x x.x.x.x
 
Este comando que permite asignar una dirección IPv4 a una interfaz. El comando requiere que se ingrese tanto una dirección IPv4 como una máscara de subred, de lo contrario devolverá un mensaje de comando incompleto.

Router(config-if)#ip address 172.16.15.1 255.255.255.0

Una variante posible es activar el cliente DHCP de IOS en la interfaz de modo que obtenga una dirección IPv4 utilizando el protocolo DHCP:
Router(config-if)#ip address dhcp


Router(config-if)#ipv6 enable
Cuando se trata de implementar redes IPv6 este comando activa el protocolo enrutado en la interfaz.
 
Consecuencia inmediata de la activación del protocolo es la generación automática en la misma interfaz de la dirección IPv6 link-local (FE80::/10) correspondiente, utilizando EUI-64 para derivar la porción de nodo.
 
Cuando se ha de configurar una dirección IPv6 unicast global o unique-local este comando es opcional ya que al configurar la dirección se activa automáticamente el protocolo en la interfaz.


Router(config-if)#ipv6 address xxxx::/XX
Comando que permite asignar una dirección IPv6 a una interfaz.
 
Con diferentes variantes permite definir una dirección completamente estática o asignar solamente un prefijo de red y requerir que el ID de nodo se asigne automáticamente utilizando EUI-64. 

Requiere la identificación de la longitud del prefijo que identifica el segmento de red al que pertenece la interfaz.

Router(config-if)#ipv6 address 2001:db8:1:1::1/64
Router(config-if)#ipv6 address 2001:db8:1::/64 eui-64
Router(config-if)#ipv6 address FE80::1 link-local
En este caso también es posible activar el cliente dhcpv6 a la asignación de IPv6 utilizando la autoconfiguración stateless propia del protocolo.

Router(config-if)#ipv6 address autoconfig
Router(config-if)#ipv6 address dhcp



Router(config-if)#description
Si bien la incorporación de una descripción a la interfaz es un feature opcional es un recurso importante a tener en cuenta para facilitar la identificación de interfaces y las tareas de diagnóstico y resolución de fallos. La inclusión de una descripción clara y precisa ahorra tiempo y simplifica tareas futuras.
 
La forma de agregar una descripción en la configuración es la siguiente:
 
Router(config-if)#description LAN de ventas
 
También se puede agregar información de referencia tal como:

Router(config-if)#description enlace Eth con Acme soporte 0800-444-4444

Este tipo de anotaciones o referencias es de utilidad para facilitar tareas de resolución de problemas.


Router(config-if)#bandwitdh
Este es también un comando opcional pero necesario ya que es utilizado por diferentes algoritmos de cálculo que utiliza el sistema operativo. 

Entre ellos el algoritmo de aquellos protocolos de enrutamiento que utilizan el ancho de banda para sus cálculos de métrica, los algoritmos de asignación de recursos (QoS), los cálculos de nivel de utilización de las interfaces.
 
Es importante tener en cuenta que este comando declara el ancho de banda en Kbits. Los valores por defecto son diferentes en interfaces LAN o WAN.
 
En interfaces Ethernet se toma como valor BW la velocidad a la que ha negociado la interfaz cuando está habilitada la autonegociación, o la velocidad definida en el puerto cuando se ha optado por una configuración estática. 
 
En interfaces seriales el valor por defecto es el correspondiente a una interfaz E1: 1544 Kb.

Router(config-if)#bandwidth 1024

El valor efectivamente en uso en cada interfaz puede ser consultado utilizando el comando show interfaces.


Router(config-if)#duplex auto
Router(config-if)#speed auto
Se trata de comandos relacionados con las interfaces de la familia Ethernet de routers y switches.
 
Estos son dos comandos de suma importancia, ya que los valores de operación de ambos extremos de un enlace deben coincidir y en definitiva determinan la operación y performance de un segmento de red.
 
Por ejemplo, para configurar una interface como Fastethernet en modo full dúplex:

Router(config-if)#speed 100
Router(config-if)#duplex full

Los valores de velocidad (speed) posibles dependen del hardware del dispositivo.  En general, por defecto, las interfaces están en modo autosensitivo:

Router(config-if)#speed auto
Router(config-if)#duplex auto


Switch(config-if)#switchport xxxxx
Se trata de un comando propio de switches (no en routers), que permite colocar definir características de operación de puertos que operan en capa 2. De este comando dependen diferentes prestaciones: enlace troncal o de acceso, port-security, etc.
 
Por ejemplo, para configurar una interfaz en modo acceso o troncal:

Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 14
Switch(config-if)#switchport mode trunk

También se utiliza este comando en switches capa 3 para definir un puerto específico como puerto capa 2 o capa 3. Por ejemplo, para que un puerto comience a operar como interfaz ruteada:

Switch(config-if)#no switchport

• El post original
• Cisco IOS 15.4 Command Reference

Tomado de: http://librosnetworking.blogspot.com/2017/10/comandos-de-configuracion-de-interfaces.html

Solucionado: Denegación de servicio en Cisco IOS XR

Cisco ha confirmado una vulnerabilidad en routers Cisco ASR 9001 Aggregation Services con Cisco IOS XR que podría permitir a un atacante remoto sin autenticar provocar condiciones de denegación de servicio.

El problema, con CVE-2016-6355, reside en el tratamiento inadecuado de paquetes fragmentados específicamente creados dirigidos al dispositivo afectado. 

Un ataque exitoso podría provocar una fuga de memoria en el procesador de rutas del dispositivo que provocaría la caída de los paneles de control de protocolo y la consiguiente condición de denegación de servicio.

El problema afecta a Cisco IOS XR versions 5.1.x, 5.2.x y 5.3.x, en routers Cisco ASR 9001 Aggregation Services.

Se ha solucionado en la versión de Cisco IOS XR 5.3.3, con las siguientes Software Maintenance Updates (SMUs):

• asr9k-px-5.3.2.CSCux26791.pie para versiones 5.3.x
• asr9k-px-5.2.4.CSCux26791.pie para versiones 5.2.x
• asr9k-px-5.1.3.CSCux26791.pie para versiones 5.1.x

Más información:

Cisco IOS XR Software for Cisco ASR 9001 Aggregation Services Routers Fragmented Packet Denial of Service Vulnerability
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160810-iosxr


Antonio Ropero -  antonior@hispasec.com - Twitter: @aropero

Tomado de: http://unaaldia.hispasec.com/2016/08/denegacion-de-servicio-en-cisco-ios-xr.html

El virtual link en OSPF

Por Oscar Gerometta

OSPF es un protocolo de estado de enlace que aplica un esquema jerárquico de red en el que el área 0 es el área de backbone que interconecta todas las áreas no backbone.

Cada área debe tener continuidad física, y uno de los desafíos en redes que tienen gran extensión geográfico puede ser mantener la continuidad del área 0.

Para estos casos (u otros semejantes) en los que el esquema jerárquico de OSPF se ve afectado por la falta de continuidad física de un área, la implementación de enlaces virtuales (virtual links) permite dar continuidad a las áreas de modo transitorio.

Cisco insiste especialmente en que esta es una solución transitoria y no permanente, y que el problema debiera ser luego resuelto a partir del rediseño de la red.

En estos casos:

• El área a través de la cual se constituye el enlace virtual se denomina área de tránsito.

• La posibilidad de enlaces virtuales está contemplada en el estándar.

• Permiten solucionar discontinuidades temporales en una red. No deben ser una solución permanente.

• Opera como una adyacencia estándar OSPF, pero no requiere que estén directamente conectados.

• El protocolo hello intercambia paquetes cada 10 segundos sobre el enlace.

• Los LSAs aprendidos sobre enlaces virtuales utilizan la configuración DNA (DoNotAge) para prevenir tráfico excesivo.

Configuración: 
Router(config)#router ospf [process id] 
Router(config-router)#area [ID área de tránsito] virtual-link [router ID] 

Tomado de: http://librosnetworking.blogspot.com/2015/08/el-virtual-link-en-ospf.html

Los 3 Principios de enrutamiento

En algunas secciones de este curso haremos referencia a tres principios relacionados con las tablas de enrutamiento que lo ayudarán a comprender, configurar y solucionar problemas de enrutamiento.

Estos principios se extraen del libro de Alex Zinin, Cisco IP Routing.

1. Cada router toma su decisión en forma independiente, según la información de su propia tabla de enrutamiento.

2. El hecho de que un router tenga cierta información en su tabla de enrutamiento no significa que los otros routers tengan la misma información.

3. La información de enrutamiento sobre una ruta desde una red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso.

¿Cuál es el efecto de estos principios? Observemos el ejemplo en la figura.

 

 
1. Después de tomar su decisión de enrutamiento, el router R1 envía al router R2 el paquete destinado a la PC2. R1 sólo conoce la información de su propia tabla de enrutamiento, que indica que el router R2 es el router del siguiente salto. R1 no sabe si R2 efectivamente tiene o no una ruta hacia la red de destino.

2. Es responsabilidad del administrador de red asegurarse de que todos los routers bajo su control tengan información de enrutamiento completa y precisa de manera tal que los paquetes puedan enviarse entre cualquiera de las dos redes. Esto puede lograrse mediante el uso de rutas estáticas, un protocolo de enrutamiento dinámico o una combinación de ambas opciones.

3. El router R2 logró enviar el paquete hacia la red de destino de la PC2. Sin embargo, R2 descartó el paquete desde la PC2 a la PC1. Aunque R2 tiene información en su tabla de enrutamiento sobre la red de destino de la PC2, no sabemos si tiene la información para la ruta de regreso hacia la red de la PC1.

Enrutamiento asimétrico

Dado que los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, los paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se denomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa el protocolo de enrutamiento BGP, que en la mayoría de las redes internas.

Este ejemplo implica que cuando se diseña una red y se resuelven problemas en ella, el administrador de red debe verificar la siguiente información de enrutamiento:

¿Existe una ruta de origen a destino que esté disponible en ambos sentidos?

¿Es la ruta que se tomó en ambos sentidos la misma ruta?  (El enrutamiento asimétrico no es inusual, pero a veces puede causar otros problemas.)

Tomado de: https://cerebrote.wordpress.com/ con algunos aportes del editor del blog.

DHCP Relay en Cisco IOS

Por Oscar Gerometta

Dado que el inicio de la operación del protocolo DHCP se realiza sin contar una dirección de origen y utilizando broadcast como destino, las solicitudes (el discovery generado por el cliente DHCP) no son de suyo ruteables hacias otras subredes. 

De aquí que en principio el protocolo DHCP supone que el servidor y el cliente están conectados a la misma red o subred.

Cuando se desea utilizar servidores DHCP que se encuentran alojados en una red o subred diferente se puede utilizar un agente DHCP relay. 

Un DHCP relay es un dispositivo que recibe las solicitudes de los clientes en formato de broadcast y las reenvía como unicast a la dirección del servidor DHCP.

• DHCP Discovery.
  El cliente DHCP envía una solicitud en formato de broadcast.
• DHCP Relay.
  El agente DHCP relay que recibe el broadcast lo retransmite a uno o más servidores utilizando unicast e incluyendo su dirección como dirección de gateway.
• DHCP Offer.
  El servidor utiliza la dirección de gateway que recibe en la solicitud para determinar a qué subred pertenece el host solicitante y asigna entonces una configuración que corresponda esa subred.
  El servidor DHCP reserva una dirección IP para el cliente y envía la respuesta en un paquete unicast a la dirección del gateway, que luego lo reenvía a la red local.
• DHCP Request.
  El cliente responde en formato broadcast realizando una solicitud explícita de la configuración ofrecida por el servidor.
  El agente DHCP relay interviene nuevamente reenviando la información al servidor DHCP.
• DHCP Acknowledgement.
  Se envía un paquete en formato unicast al DHCP relay que luego lo reenvía al cliente, incluyendo la información de configuración que el cliente ha aceptado.
  Esto completa el proceso.

En estos casos el servidor DHCP responde al DHCP relay y éste se ocupa de reenviarlo al cliente DHCP.

Configuración de un router IOS como DHCP relay

El servicio de DHCP relay se habilita en la interfaz de capa 3 más cercana al cliente DHCP (usualmente, la que opera como default-gateway de la red o subred).

En la configuración es necesario especificar la dirección IP de uno o más servidores DHCP que han de responder las solicitudes. 

Si hay varios servidores DHCP en una misma subred se puede especificar directamente la dirección reservada de subred, de este modo responderá cualquiera de los servidores DHCP de esa subred.

Router#configure terminal
Router(config)#interface GigabitEthernet 0/0
Router(config-if)#ip helper-address [IP servidor DHCP]

Documentación de referencia:

• Configuring the Cisco IOS DHCP Relay Agent

Fuente: Mis libros de Networking

Enrutamiento IP en entornos con VRFs

Por Oscar Gerometta

Cuando implementamos VRFs podemos diferenciar, en principio, 2 redes que están operando e interactuando entre sí:

• La red de servicios que es la que opera brindando conectividad entre extremos distantes. Este es el rol esencial de la red del Proveedor de Servicios clásico.
• La red cliente que es la red dispersa que necesita interconectar puntos remotos a través de la red de servicios. Si bien en la gráfica de más abajo representé una única red cliente para mayor claridad, sobre una red de servicio pueden conectarse múltiples redes cliente diferentes sin que ocurran superposiciones de ningún tipo.

Cada una de estas redes tienen su propio dominio de enrutamiento, completamente independiente. Para que todo esto funcione hay que considerar 3 dominios de enrutamiento diferentes:

• El dominio de enrutamiento de la red cliente que utiliza un protocolo de enrutamiento para gestionar las rutas de la red cliente. Típicamente es un IGP (RIPv2, EIGRP, OSPF), pero también es posible que utilice BGP.
• El dominio de enrutamiento de la red de servicios que utiliza un protocolo de enrutamiento interior para gestionar las rutas de la red de servicios. Típicamente encontramos en este caso OSPF, EIGRP o IS-IS.
• El dominio de enrutamiento BGP de la red de servicios que utiliza un address-family vpnv4  para transportar las rutas de la red cliente a través de la red de servicios.

Para que BGP pueda transportar las rutas de la red cliente es necesario que se redistribuyan las rutas de la red cliente dentro de un address-family asociado a la VRF de la red cliente, del mismo modo que las rutas del address-family luego deben ser redistribuidas dentro de la VRF.

De esta forma, el transporte de rutas de la red cliente sobre la red de servicios puede ser representado de la siguiente manera:

Consecuencias de esto:

• Las rutas de la red cliente solamente se encuentran en la tabla de enrutamiento de las VRFs y los CEs. Nunca se incorporan a la tabla de enrutamiento de la red de servicios (PEs y Ps).
• Las rutas de la red de servicios nunca se mezclan con las rutas de las VRFs.
• Cuando hay múltiples VRFs en un mismo PE, las rutas de cada VRF se mantienen independientemente unas de otras.
• En el router P nunca se encuentran rutas de las redes cliente.

Fuente: http://librosnetworking.blogspot.com/

Diagnóstico de interfaces en Cisco IOS

Por Oscar Gerometa

Hace ya algún tiempo que me solicitaron un esquema de diagnóstico del estado de las interfaces en dispositivos Cisco IOS.

Si bien el proceso de diagnóstico de una situación o dispositivo no es fruto exclusivamente de un procedimiento pre-definido sino que depende en mucho de la experiencia y conocimientos de quien lo realiza, creo que es posible revisar el conjunto de herramientas que ofrece Cisco IOS para el diagnóstico de interfaces de routers de un modo relativamente ordenado.

Lo que elaboro a continuación es un esquema personal, que pretende ordenar un proceso de diagnóstico genérico del estado de interfaces de un router Cisco que utiliza Cisco IOS 15.4 y al que se está accediendo remotamente. En cada comando he agregado el enlace para revisar el comando en la command guide para que quienes quieran profundizar en él puedan hacerlo en la fuente misma.

show ip interface brief

A mi modo de ver, el primer comando de diagnóstico a ejecutar cuando se está accediendo remotamente a un equipo es show ip interface brief.

Este comando nos permite requerir al sistema operativo una tabla sintética que nos permite visualizar de modo rápido y sencilo el estado de cada una de las interfaces que tiene configuración IP:

En un dispositivo operativo:

• La columna IP-Address nos muestra la dirección IP configurada en cada interfaz.
• La columna OK? debe indicarnos YES. La leyenda NO indica que se ha asignado a la interfaz una dirección IP inválida.
• La columna Method indica el método a través del cual se ha obtenido la configuración IP de la interfaz: NVRAM refiere al archivo de configuración almacenado en la NVRAM, manual indica que ha sido cambiada la dirección IP utilizando configuración por CLI, DHCP refiere que la interfaz está configurada como cliente DHCP y ha obtenido dirección por ese método.
• La columna Status muestra el estado de las interfaces (up | down | administratively down). Para estar operativa la interfaz debiera aparecer como up.
• La columna Protocol indica que la interfaz se encuentra operativa a todo nivel.

En condiciones de operación, el comando debiera mostrarnos up/up todas las interfaces en uso, y como administratively down las interfaces que no se encuentran en uso.

Enlace de referencia: aquí.

Si una interfaz aparece como down/down, es posible que tenga inconvenientes a nivel de capa física. Es por esto que para diagnosticar adecuadamente necesitamos revisar capa física.

show controllers

Este comando nos permite revisar la información referente a hardware y software de la interfaz, y consecuentemente el estado físico de la misma.

La información que brinda este comando es variable de acuerdo al tipo de interfaz de la que se trate (Ethernet, FastEthernet, GigabitEthernet, Serial, etc.)

Es un comando con abundante información que generalmente es requerido en solicitudes de soporte a Cisco TAC. Sin embargo, nos brinda información útil también a nosotros, p.e., en interfaces seriales permite verificar si hay cable conectado y si el mismo es DCE o DTE, el clockrate que utiliza, el estado de la interfaz, etc.

Enlace de referencia: aquí.

show interfaces

En interfaces que se encuentran operativas permite visualizar el estado y estadísticas de operación de las interfaces.

Este comando permite verificar: estado de la interfaz, tipo de hardware que utiliza, dirección MAC, dirección IP y máscara de subred, parámetros de operación (MTU, BW, etc.), protocolo de encapsulación, y estadísticas de tráfico tanto entrante como saliente. El resultado específico y los parámetros que se muestran dependen de la configuración y tipo de interfaz.

Este comando lo utilizamos específicamente para, además de verificar el estado de la interfaz, verificar la actividad de la misma utilizando los contadores de paquetes y bytes que nos permiten corroborar la actividad que hay sobre la misma y la tasa y tipo de errores.

Enlace de referencia: aquí.

show interfaces accounting

Este no es más que un subcomando del comando anterior.
 
Si lo que necesitamos es verificar actividad de tráfico entrante y saliente a través de las interfaces, este es un comando que muestra de modo sintético la actividad de tráfico entrante y saliente a través de cada interfaz del dispositivo.

Las interfaces que no se encuentran operativas muestran la leyenda is disabled.

show ip interfaces

Este comando nos permite verificar, además del estado y dirección IP de la interfaz, la configuración y operación de la misma: proxy ARP, ICMP, presencia o no de ACLs asociadas, implementación de políticas, o de CEF, etc. 

Enlace de referencia: aquí.

Sintetizando:

• Revisar el estado de las interfaces utilizando show ip interface brief.
• Si alguna interfaz está down / down, verificar la operación a nivel de capa física utilizando show controllers.
• Si una interfaz está up / down, verificar la operación la operación a nivel de capa de enlace y capa de red utilizando show interfaces.
• Si las interfaces se encuentran up / up, verificar el flujo de tráfico y la tasa de errores utilizando show interfaces o show interfaces accounting.
• Ante dificultades en la operación de la interfaz, verificar el modo de operación y la configuración utilizando show ip interface.

En términos generales, verifique el estado de las interfaces utilizando show ip interface brief según lo que indiquen las columnas status y protocol:

• administratively down / down - la interfaz no ha sido habilitada administrativamente. Requiere no shutdown para ser operativa.
• down / down - posible problema a nivel de la capa física. Inicie verificando la interfaz utilizando show controllers.
• up / down - Posible problema a nivel de capa de enlace de datos o de red puede comenzar utilizando show interfaces.
• up / up - La interfaz se encuentra operativa, verifique la existencia de tráfico a través de la interfaz utilizando show interfaces o show interfaces accounting.
• Si la interfaz está operativa y persisten los problemas de comunicación, verifique la operación de la interfaz utilizando show ip interface.

Vea el video de este post en el canal de YouTube de LibrosNetworking


 

Fuente: http://librosnetworking.blogspot.com/

Como bootear el router desde una memoria USB

Por Oscar Gerometta

http://librosnetworking.blogspot.com/2011/01/booteo-del-router-desde-una-memoria-usb.html

Típicamente los routers Cisco almacenan una copia del sistema operativo (Cisco IOS) en su memoria flash; y por defecto utilizan esa imagen del sistema operativo durante el proceso de inicialización o booteo.

Sin embargo puede ocurrir que por diferentes causas esa imagen del sistema operativo no esté disponible: corrupción del archivo, corrupción de la memoria flash, borrado accidental, etc. 

En ese caso el dispositivo no tiene una imagen válida para cargar y arrancará en modo Monitor de ROM (Rommon). Este modo nos da un conjunto reducido de comandos que esencialmente permiten ejecutar manualmente la secuencia de inicio.

Para estos casos, y aprovechando el modo Rommon, los routers ISR cuentan con 1 o 2 puertos USB que podemos utilizar para cargar la imagen de sistema operativo desde una memoria flash USB.

Booteo desde una memoria USB

El pre-requisito obvio de este procedimiento es contar con una imagen de IOS válida para el dispositivo que deseamos poner en operaciones, guardada en una memoria USB.

Una vez que contamos con este recurso, debemos ingresar al modo Monitor de ROM.

Si el dispositivo no contaba con una imagen válida de IOS en la memoria flash quedará directamente en ese modo. Si no es así, podemos forzar el ingreso al modo Rommon utilizando la secuencia de interrupción del booteo: Ctrl+Break.

A partir de este punto, reconocemos el modo Rommon por el prompt:

rommon 1>

Ya en este modo, podemos acceder al listado de comandos disponibles utilizando el comando de llamada al listado de comandos:

rommon 1>?
o
rommon 1>help

A continuación debemos chequear la imagen que tenemos almacenada en la memoria USB:

rommon 2>dir usbflash0:
program load complete, entry point: 0x8000f000, size: 0x3d240
Directory of usbflash0:
2......14871760..-rw-...c2800nm-ipbase-mz.124-3.bin

Nota: el comando es dir usbflashx: donde x asume el valor de 0 o 1 según en qué puerto del router se ha insertado la memoria USB.

A continuación se ejecuta el comando que ordena el booteo del dispositivo utilizando la imagen almacenada en la memoria USB:

rommon 3>boot usbflash0:c2800nm-ipbase-mz.124-3.bin
program load complete, entry point: 0x8000f000, size: 0x3d240
program load complete, entry point: 0x8000f000, size: 0xe2eb30
Self decompressing the image :
##########################################################################################
############################################################### [OK]

Una vez que el equipo ha booteado y ya opera con la interfaz de línea de comando EXEC tradicional, podemos copiar la imagen que tenemos en nuestra memoria USB a la memoria flash del router:

Router>enable
Router#copy usbflash0:c2800nm-ipbase-mz.124-3.bin flash:c2800nm-ipbase-mz.124-3.bin

Lancom presenta su nuevo router móvil

[ 08/02/2011 - 07:54 CET ]

Combinando tecnología UMTS/HSPA+ con LAN inalámbrica de alta velocidad Lancom 1780EW-3G está pensado para compañías y sucursales que no tienen banda ancha o acceso a Internet por cable, o en aquellos lugares donde se necesita Internet móvil o de manera temporal.

Diario Ti: Lancom Systems presenta Lancom 1780EW-3G, el primero de su serie de 3,5G y 4G de routers móviles. Este router VPN con módem integrado UMTS/HSPA+ utiliza la red móvil para ofrecer conectividad a Internet de banda ancha (con una velocidad de descarga de hasta 21 Mbps y hasta 5,76Mbps de subida). Su módulo de radio LAN inalámbrica 802.11n proporciona una red local inalámbrica con una velocidad de 300 Mbps.

Entre las aplicaciones típicas están la configuración temporal de salas de conferencias en lugares al aire libre, de oficinas móviles en sitios en construcción o en lugares sin línea DSL. HSPA+ da acceso de alta velocidad a Internet o a las redes de la empresa. También se puede usar la conexión HSPA+ como un backup económico para accesos a Internet por cable.

Con 5 canales VPN de serie (opcionalmente se pueden ampliar a 25), el Lancom 1780EW-3G funciona como gateway central para IPsec VPN con encriptación AES de alta seguridad y soporte de certificado digital.

Lancom 1780EW-3G ofrece interfaces Gigabit Ethernet y Fast Ethernet, que pueden usarse para conectar un modem externo. El módulo de radio inalámbrica cumple con el estándar IEEE 802.11 agn y opera en las bandas de 2.4 y 5 GHz. Un filtro opcional de contenidos para un máximo de 100 usuarios previene de un mal uso del acceso a Internet y del uso privado excesivo por parte de los empleados.

Fuente: Lancom Systems.

Tomado de http://www.diarioti.com/

http://ccnabolivia.blogspot.com/