Hola todos,
Es un honor para mi escribir en esta ocasión y compartir mis
impresiones de la 11va. edición del FLIP6 (Foro Latino Americano de
IPv6) en la ciudad de Medellin - Colombia durante los días 7 y 9 de
Mayo de 2013.
Cada evento es un desafío. es un reto nuevo; cosas inesperadas pueden
ocurrir, tanto cosas buenas como cosas malas. Lo importante es saber
manejar las situaciones, poderlas llevar y eventualmente poder
superarlas. Tuvimos un gran evento, tanto en el especto técnico,
académico y social.
Antes de entrar de lleno en el resumen del evento, deseo mencionar que
cuando en la vida se presentan situaciones complicadas no hay que
colocar mala cara y mucho menos rendirse, todo lo contrario, hay que
saber canalizar las preocupaciones y angustias en energía y
entusiasmo, esta es la única manera para poder salir adelante.
Recientemente me enteré que Thomas Alva Edison tenía problemas
auditivos, él, en vez de quejarse decía que menos mal, con ello podía
concentrarse más en sus inventos
Resumen del evento:
Antes de cada evento siempre existe un grado de preocupación, las
preocupaciones van desde “ójala no falte ningún speaker”, que el salón
este lleno y que ójala tengamos tiempo para la agenda completa. Me
complace indicar que en esta oportunidad -igual que las anteriores- el
Foro fue un éxito total y hemos salido aún con más fuerza para seguir
trabajando por la promoción de IPv6 en Latinoamérica y Caribe.
El evento tuvo una duración de casi 7 horas dividido en dos días. Por
primera vez compartirmos un espacio de 3 horas con LACSEC, el objetivo
era unir en la agenda aquellas presentaciones con contenido de
seguridad e IPv6. Más adelante les doy los detalles.
Se contó con la asistencia de unas 400 personas en total, que se apreciaba con
el salón lleno en todo momento. Existen muchos puntos a destacar en
esta oportunidad:
- El cumplimiento de los horarios de los ponentes fue excepcional.
- Cantidad de preguntas realizadas
- El evento estuvo acompañado por una gran difusión vía Twitter,
Facebooks y listas de correo.
- Calidad de los expositores
- Temas novedosos en el foro
Como siempre, hay que destacar al comité evaluador de LACTF quienes tuvieron la
importante labor de seleccionar los trabajos presentados en la 11va.
edición del FLIP6. Sin el comité el evento no sería lo mismo. Es
sensacional los estudios y charlas que existen tras bastidores para
seleccionar los temas.
A continuación un breve resumen de cada una de las ponencias:
- Evaluación de la seguridad y diagnóstico de problemas en redes IPv6
- Fernando Gont
Fernando tuvo la oportunidad de abrir FLIP6, con su tradicional estilo
de exposición: sencillo pero con un alto contenido de nivel técnico
expuso una combinación muy llamativa del toolkit de seguridad de IPv6
y problemas existentes en el área. Vale la pena volver a ver.
- El caso de negocio para IPv6 - Mark Townsley, Cisco.
Nuestra presentación Keynote vino dada por el Ing. Mark Townsley,
quien es co-chair del WG Homenet de la IETF y además fellow de Cisco.
Expuso un tema sumamente interesante y necesario: “El caso de negocio
para IPv6”. Su presentación fue dinámica y amena, una vez más quedó
expresado porque es importante la implementación de IPv6. Es una
exposición cuya láminas sin duda muchos de nosotros volveremos a
revisar.
- Conexión a Internet IPv6 de redes corporativas - Álvaro Retana, Cisco.
El Ing Alvaro Retana (Ing distinguido de Cisco) realizó una
presentación de mucho impacto sobre las posibilidades, modalidades y
alternativas de las conexiones a Internet IPv6 en redes corporativas.
Muy interesante, gracias por compartir esta información. Esperemos que
crezca significativamente el sector corporativo en su implementación
de IPv6 en los próximos años.
- Mejores prácticas en nubes públicas para garantizar su seguridad,
respaldo y alta disponibilidad - Efraín Soler, CEO de O4IT.
Efarin Soler realizó una exposición sobre la plataforma,
tecnología implementada, marco de seguridad y la sencilla interfaz Web
que O4IT tiene para ofrecer. Sin duda alguna muchos de los asistentes
apredimos de este prestigioso sponsor.
- Actualización sobre IPv6 en redes de Gobierno - Jordi Palet, Consulintel.
Jordi, con su acostumbrado estilo de enseñar y transmitir
información brindó un rápido repaso pero muy importante sobre los
avances en la implementación en algunos países y gobiernos. Mil
gracias por compartir esta información con nosotros. Te esperamos para
que compartas nuevos avances.
- Casos de éxito en implementaciones de IPv6. Evandro Varonil,
Guillermo Cicileo.
Los Ingenieros Evandro Varonil y Guillermo Cicileo
expusieron muy vividamente sus experiencias implementando IPv6 en sus
organizaciones. Desde FLIP6 estamos muy agradecidos por compartir este
contenido debido a que el mismo ayuda a los interesados que aún no lo
han hecho a prever algunas situaciones.
- Mobile IPv6 Test Bed: una implementación actualizada - Sebastián
Tobar y Cristian Pérez Monte, Grupo UTN GridTICS (AR)
Sebastian Tobas y Cristian Perez Monte realizaron una
llamativa exposición sobre IPv6 y movilidad. La ponencia fue muy
ilustrativa y decarácterr novedoso. Ojalá tengamos la oportunidad de
conocer los avances en los próximos meses y/o años.
- Análisis de las técnicas de transición para un mundo sin IPv4 -
Rodrigo Regis dos Santos, NIC.br.
El Ing. Rodrigo Regis dos Santos realizó una exposición muy
completa cubriendo la mayoría los métodos de transición puntualizando
muy bien las ventajas y desventajas de cada uno de ellos.
¡Muchas gracias por una presentación tan agradable!
- Consideraciones operativas sobre planificación y despliegue de IPv6
- Álvaro Retana, Cisco
Alvaro Retana le tocó aperturar el estreno en el espacio
compartido de LACSEC/FLIP6. Una vez más realizó una fantástica
presentación sobre las consideraciones operativas durante el
despliegue de IPv6, hizo mucho énfasis en la planificación. Fue
probablemente unas de las presentaciones con mayor participación de
los asistentes, Hubo al menos una hora de preguntas, respuestas y
comentarios luego de finalizar la ponencia. Ojala podamos repetir esta
experiencia.
- Avances recientes en seguridad de IPv6 - Fernando Gont, SI6 Networks.
Fernando Gont, por segunda vez durante FLIP6 de 2013 conversó sobre
IPv6 y la seguridad, dejando como moraleja que las implementaciones de
este protocolo a su vez deben venir acompañado de políticas de
seguridad, existen problemas que son similares a IPv4 y otros que son
únicamente de IPv6. Ojala contemos con Fernando Gont en futuras
reuniones de FLIP6.
Conclusión:
Para concluir, tuvimos otra edición de FLIP6 inolvidable, una vez más
intentamos empujar difundir már IPv6 en los asistentes. Después de
cada evento nos despedimos con la intención de que regresen a sus
casas y oficinas con el objetivo de implementar IPv6. Una vez escuché:
“IPv6 is not optional anymore, it’s a must.” (IPv6 ya no es opcional,
es obligatorio)
Para finalizar una pequeña cita para que siga la evolución informática
y con ello IPv6:
“El verdadero progreso es el que pone la tecnología al alcance de todos.”
— Henry Ford
Att.
Alejandro Acosta
Chair LACTF/FLIP6 2013
http://aaaa.acostasite.com
Twitter: @lactf
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
lunes, 15 de julio de 2013
jueves, 30 de mayo de 2013
domingo, 14 de abril de 2013
viernes, 22 de febrero de 2013
Publicar prefijos IPv4 sobre una sesión eBGP IPv6
Situación:
Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6
Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones.
Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.
Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).
R1:
!
interface Ethernet0
ip address 22.22.22.21 255.255.255.252
ipv6 address 2001:DB8::1/64
!
router bgp 1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 2
neighbor 2001:DB8::2 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::2 activate
neighbor 2001:DB8::2 route-map IPv4 in
no auto-summary
no synchronization
exit-address-family
!
route-map IPv4 permit 5
set ip next-hop 22.22.22.22
!
R2:
!
interface Ethernet0
ip address 22.22.22.22 255.255.255.252
half-duplex
ipv6 address 2001:DB8::2/64
!
router bgp 2
bgp log-neighbor-changes
neighbor 2001:DB8::1 remote-as 1
neighbor 2001:DB8::1 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::1 activate
no auto-summary
no synchronization
network 2.2.2.0 mask 255.255.255.0
exit-address-family
!
"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2
Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco
Espero sea útil!
Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6
Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones.
Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.
Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).
R1:
!
interface Ethernet0
ip address 22.22.22.21 255.255.255.252
ipv6 address 2001:DB8::1/64
!
router bgp 1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 2
neighbor 2001:DB8::2 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::2 activate
neighbor 2001:DB8::2 route-map IPv4 in
no auto-summary
no synchronization
exit-address-family
!
route-map IPv4 permit 5
set ip next-hop 22.22.22.22
!
R2:
!
interface Ethernet0
ip address 22.22.22.22 255.255.255.252
half-duplex
ipv6 address 2001:DB8::2/64
!
router bgp 2
bgp log-neighbor-changes
neighbor 2001:DB8::1 remote-as 1
neighbor 2001:DB8::1 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::1 activate
no auto-summary
no synchronization
network 2.2.2.0 mask 255.255.255.0
exit-address-family
!
"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2
Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco
Espero sea útil!
domingo, 17 de febrero de 2013
Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco
Situación:
Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4
Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6
Error:
Mensaje que quizás estas recibiendo y el mismo te trajo a esta página :)
*Mar 1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar 1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar 1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar 1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0
Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.
Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).
R1:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::1/64
ipv6 enable
!
router bgp 1
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 2
neighbor 1.1.1.2 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.2 activate
network 2001:db8::/32
no synchronization
redistribute static
exit-address-family
!
ipv6 route 2001:db8::/32 Null0
R2:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::2/64
ipv6 enable
!
router bgp 2
no synchronization
bgp router-id 1.1.1.2
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-map IPv6-NextHop in
exit-address-family
!
route-map IPv6-NextHop permit 10
set ipv6 next-hop 2001:db8::1
!
"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1
Después de aplicar ebgp-multihop (todo funciona):
*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar 1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table
Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx
Espero sea útil!
Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4
Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6
Error:
Mensaje que quizás estas recibiendo y el mismo te trajo a esta página :)
*Mar 1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar 1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar 1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar 1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0
Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.
Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).
R1:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::1/64
ipv6 enable
!
router bgp 1
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 2
neighbor 1.1.1.2 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.2 activate
network 2001:db8::/32
no synchronization
redistribute static
exit-address-family
!
ipv6 route 2001:db8::/32 Null0
R2:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::2/64
ipv6 enable
!
router bgp 2
no synchronization
bgp router-id 1.1.1.2
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-map IPv6-NextHop in
exit-address-family
!
route-map IPv6-NextHop permit 10
set ipv6 next-hop 2001:db8::1
!
"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1
Después de aplicar ebgp-multihop (todo funciona):
*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar 1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table
Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx
Espero sea útil!
lunes, 21 de enero de 2013
Convertir un Access point Cisco Aironet 1242 modo Lightweigth a Access point modo Autónomo/Stand Alone
Situacion:
La mayoría de estos equipos Cisco Aironet vienen con la IOS (Internetwork
Operating System) para que funcione en modo Lightweigth y por más que trates de
configurarlos por cualquier vía no lo vas a poder hacer si no tienes un WLC
(Wireless Lan Controller) los cuales son algo costosos.
El problema de los Access Point (AP) en modo Lighweigth es que toman la
configuración del WLC (Wireless Lan Controller) que esté presente en la red, por
esto estos AP se les conoce como zero touch debido a que no hace falta
realizarle casi ninguna configuración. En
resumen si no tenemos un WLC no podremos configurar el AP vía web ni vía
consola.
Si ingresas vía consola (Hiperterminal u otro) te va a pedir la contraseña de modo privilegiado la cual por defecto es “Cisco”
después de eso cuando intentes pasar a modo global ejecutando el comando
“configure terminal” como en el cualquier dispositivo CISCO te aparecerá el siguiente
mensaje ”command not found”, yo también me preocupé en ese momento pensé que el
dispositivo tenía algún tipo de problema, ejecuté cualquier cantidad de comandos existentes para pasar a modo de
configuración pero nada.
Intenté conectarme vía web, por defecto el AP viene con la
dirección 10.0.0.1 simplemente lo conecte mediante su puerto Ethernet a mi computadora a la cual le asigne la
dirección 10.0.0.2, probé la conectividad con el comando ping entre ellos y
todo estaba perfecto pero en el momento de intentaba ingresar vía web (mediante
un explorador de internet e.g Internet Explorer ,Mozilla Firefox ,colocaba la
dirección 10.0.0.1) no me dejaba ,simplemente es que en el modo Lightweight no
tenemos acceso al AP vía web.
La solución:
La solución es cambiarle la IOS al AP para que este funcione
en modo Autónomo o Stand Alone en vez de Lightweight y así poder configurar el AP normalmente
ya sea vía Web o mediante consola.
Procedimiento:
Los siguientes son los pasos para revertir un AP que esta en
modo LWAPP a modo Autónomo cargando un Cisco IOS utilizando un servidor TFTP.
1.- En nuestra PC cargamos un servidor TFTP en esta misma
maquina configuraremos el AP.
2.- El PC se comportara como el servidor TFTP le asignaremos
por ejemplo la dirección 10.0.0.2 (acordémonos que el AP por defecto tiene la
10.0.0.1)al mismo tiempo nos conectamos mediante el cable de consola al AP
mediante la aplicación Hiperterminal.
3.- Después que conseguimos la nueva IOS (c1240-k9w7-tar.default)
la copiamos a la carpeta donde guarda el
servidor TFTP los archivos por defecto. (debemos que asegurarnos de que tenemos
la nueva IOS en el PC que esta como
servidor TFTP)
4.- El siguiente paso simplemente es conectar el AP a nuestro PC
(servidor TFTP) mediante un cable utp.
5.- Desconecte el AP de la corriente eléctrica.
6.- Conectamos el AP a la corriente eléctrica al mismo tiempo
que mantenemos presionado el botón MODE
en el AP.
7.- Esto lo hacemos alrededor de 20 a 30 segundos el LED de AP
se coloca de color lila, como tenemos abierta la aplicación Hiperterminal en ella nos debería aparecer el
siguiente mensaje “button is pressed ,wait for button to be released…”
8.- En este momento la nueva IOS se esta copiando desde el servidor
TFTP a la flash del AP, simplemente debemos esperar a que se termine de copiar.
9.- Automáticamente la nueva IOS reemplazara a la anterior.
10.- Lo único que nos queda es por fin empezar a configurar
nuestro AP ya sea vía consola o vía web.
Nota: para
conseguir la IOS que necesitamos solo debemos colocar en google lo siguiente “ c1240-k9w7-tar.default shared “ abrimos
el primer resultado que nos arroje, y la descargamos.
Nota: para poder
ingresar vía web al AP este necesita tener configurado una dirección ip, además
de un usuario con nivel 15 de privilegio, lo creamos de la siguiente manera:
AP (config)
username “nombre usuario” privilege 15 password “password”.
Nota: para
descargar el servidor TFTP simplemente hazlo desde esta página
http://www.winagents.com/en/downloads/download-tftp-server.php.
1.-Le colocamos
nombre al AP
Router (config)hostname AP
2.-Configuramos un
SSID al AP podemos tener varios SSID.(por ejemplo le colocamos WIRELESS)
AP (config)dot11 ssid WIRELESS
AP (config-ssid)authentication open
AP (config-ssid)infraestructura ssid
AP (config-ssid) guest mode
(el AP divulgara el SSID para
que los clientes lo puedan ver)
AP (config-ssid) authentication key management wpa versión
2(opcional le configuramos el protocolo WPA versión 2 para la forma en que
administrara las claves)
AP (config-ssid)wpa-psk
ascii “clave”(definimos la contraseña para que los clientes puedan
conectarse al AP)
El AP posee 2 interfaces dot11radio0 (2.4 GHz) y dot11radio1
( 5 GHz)
3.-Asociamos el
SSID a la interface a cual queremos que los clientes se conecten.
Interface
Dot11radio0
AP (config-if)
ssid WIRELESS
AP (config-if)
station-role root (por defecto viene así)
AP (config-if) encryption mode ciphers aes-ccm (opcional,
definimos AES como el algoritmo de encriptamiento)
AP (config-if) no shutdown (levantamos la interface)
4.-Le asignamos
una ip al AP estáticamente para administración (por ejemplo 192.168.1.1) o si
existe un servidor DHCP simplemente dejamos que el AP reciba un IP del mismo.
(config)
interface BVI 1
(config-if)
ip address 192.168.1.1 255.255.255.0
(config-if) no shutdown
Procedimiento realizado por: @AlejandroFerrer
lunes, 14 de enero de 2013
Suscribirse a:
Entradas (Atom)
Una mejora práctica en el Transporte DNS sobre UDP en IPv6
Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...