En construcción.

Aqui pongo, intervenciones interesantes del foro de Administrador de redes Cisco CCNA módulo 2.

De la página http://www.canarias-digital.org/educanarias/

ASUNTO: Re: exámen 3, pregunta 12 (y añado)

AUTOR: Javier Castañón

FECHA: 26/05/05

Si introduces el comando show interfaces, por ejemplo
para el interface serial 0/0

#show interfaces serial 0/0
!podrás tener las 4 siguientes posibles respuestas

Serial 0/0 is up, line protocol is up : Que indica
que está operacional

Serial 0/0 is up, line protocol is down: Que indica
que hay un problema en la conexión

Serial 0/0 is down, line protocol is down: Que idica
problema en el interface

Serial 0/0 is administratively down, line protocol is
down: Que indica que el interface está desactivado

Todo esto está aclarado en 9.3.1 Diagnóstico de
fallas de la Capa 1 utilizando el comando show
interfaces.

Un saludo

ASUNTO: Re: exámen 3, pregunta 12 (y añado)

AUTOR: Carlos Mena Mesa

FECHA: 26/05/05

Hola.

Javier ha dado en el clavo, el apartado 9.3.1 explica
este asunto.

Básicamente la diferencia entre "administratively
down" y "down" es si el administrador ha indicado
intencionadamente que el interfaz se "caiga" shutdown
o es que hay problemas de otra índole respectivamente.

Cuando el interfaz y la línea están up, es que
funciona correctamente.

Cuando el interfaz está "administratively down", es
que el administrador no ha hecho "no shutdown" en el
interfaz.

Serial 0/0 is up, line protocol is down podría
deberse a que no hay señal de reloj (en nuestros
laboratorios correspondería a no haber activado el
reloj en el DCE o cables DTE/DCE al revés).

Serial 0/0 is down, line protocol is down podría
deberse a que el cable está desconectado.

Un saludo

ASUNTO: Pregunta exámen 3

AUTOR: Rafael Acosta

FECHA: 26/05/05

Quisiera plantear en el foro una pregunta del exámen
3, que aún hoy después de haberla leido 20 veces sigo
sin entender.
El enunciado de la pregunta era el siguiente:

"Se puede establecer una sesión de telnet si se usa
una dirección IP de un router pero no el nombre del
router ¿Cuál de las siguientes opciones es la causa
más probable del problema?"

Las respuestas eran las siguientes:

1)una entrada en la tabla de host incorrecta
2)una entrada de tabla ARP incorrecta
3)una entrada de tabla de enrutamiento incorrecta
4)un protocolo configurado incorrecto
5)una máscara de subred incorrecta

y la respuesta que da cisco es la 1ª... y mi me
parecen todas correctas menos la 1ª.

En principio no se a que tabla de hosts se refiere...

Si se refiere a la tabla de Hosts del router, da
igual lo que tenga en la tabla... ya que quien tiene
que resolver el nombre de host en dirección IP y
luego en MAC, es el cliente Telnet desde donde
queremos establecer la sesión. La tabla de hosts del
router, en todo caso, serviría para resolver
peticiones de conectividad a otros "hosts" de red, y
no para resolver las peticiones que se realicen
hacia "el".

En el caso de que se refiriera a la tabla de hosts
del cliente telnet, entonces SI sería correcta la
primera respuesta. Pero claro... en este tema solo se
ha hablado de la resolución de nombres en routers.

en fin... no lo se... igual es mas facil que todo
esto y yo estoy "emparanoyado" con la pregunta.

Si alguien puede aportar un poco de luz... se lo
agradecería.

Salu2.

ASUNTO: Re: Pregunta exámen 3

AUTOR: Carlos Mena Mesa

FECHA: 28/05/05

Hola.

Yo estoy con Karina en que, aunque la pregunta no lo
menciona, se refiere a un cliente telnet de un
router.

Si que se puede hacer telnet desde el clinete telnet
de un router hacia otro router. De hecho es habitual
saltar de router en router, en una cadena de telnets,
sobre todo en detección de problemas donde se quiere
ir paso a paso hasta descubrir el error. A veces
incluso es la única manera, porque puede que los
telnet directos desde el origen estén filtrados.

Hay algunas prácticas que trabajan con todo este
asunto y nos ayudarán mucho. Estoy deseando llegar a
la parte presencial.

Saludos

ASUNTO: Re: Módulo 5

AUTOR: Carlos Mena Mesa

FECHA: 02/06/05

Hola Ángel.

Discúlpame si la respuesta no es lo que esperas, pero
es que no entiendo bien la pregunta. Si no te quedas
satisfecho, te ruego que vuelvas a preguntar.

El resgistro de configuración es una "variable" que
guarda el router, y según el valor que se le asigne,
el router se comporta de una u otra forma.
Fundamentalmente tiene que ver con la manera en que
el router inicia. Más que indicar donde están la IOS
o el archivo de configuración, dice donde ir a
buscarlos (porque puede que no estén).

En la guía de instrucciones de los routers, que
puedes descargar de mi página
(http://cmena.ulpgc.es/publico/cisco/ccna2) tienes un
breve resumen de diferentes valores del registro de
configuración para el Cisco2600 que es el que
usaremos en los laboratorios de la fase práctica.

Te lo transcribo:

11.- Registro de configuración
Mostrar
C2600#show version
Cambiar
C2600#config-register 0x21AB
B=0 modo monitor
B=2 cargar IOS de la flash
A=0 cargar startup-config
A=4 ignorar startup-config
Es decir que un valor de registro de configuración de
* 0x2102 normal (IOS+start) hace que el router inicie
cargando la IOS de la flash y cargando el archivo de
configuración de la NVRAM
* 0x2142 hace que el router inicie cargando la IOS de
la flash pero que se salte el archivo de
configuración de la NVRAM
* 0x0 hace que el router inicie sin cargar ni la IOS
ni el archivo de configuración de la NVRAM

A través de los parámetros boot system, se puede
indicar que la configuración del sistema se lea de un
servidor tftp de la red.

Espero haber aclarado algo. Sugiero que una vez leido
y releido, des una pasada rápida a las cinco páginas
que habla de esto (5.1.1 a 5.1.5) para pillar el
extracto.

En cualquier caso coméntame si tienes dudas.

Saludos

ASUNTO: Re: Módulo 6. Pregunta 4. ¿Con trampa?

AUTOR: Rafael Acosta

FECHA: 03/06/05

Hola,

echandole un vistazo al foro, y sin haberme leido aún
el tema 6... voy a hacer yo también un comentario
acerca de lo que comentan... ;)

Las tablas ARP, para resolución IP-MAC se encuentran
tanto en los routers como en los PC's. Las tablas de
enrutamiento se encuentran tanto en los PC's como en
los routers. Además, tanto a un router como a un PC
se les puede denominar "Hosts"... ambos disponen de
un Stack IP completo. Ahora, la diferencia solo está
en la cantidad de interfaces y la capacidad de
redirigir los paquetes a la interfaz correcta en
función precisamente de lo que diga la tabla de
enrutamiento... si a un PC le metemos varias tarjetas
de red, y un software adecuado de enrutamiento, se
tranforma en un router.

Bueno, lo dejo ahí...

Un Saludo.

ASUNTO: Re: Módulo 6. Pregunta 4. ¿Con trampa?

AUTOR: Javier Castañón

FECHA: 04/06/05

Se me olvidaba citar otra curiosidad.
Windows (al menos WXP pro SP3) tiene un servicio de
escucha de RIPv1. Es decir que si instalas este
subservicio de red (agregar/quitar componentes de
Windows > servicios de red >...) tu pc atenderá a las
actualizaciones de rutas de RIPv1 que escuche en la
red. Y con esto y el sniffer (ethereal,..) a la
escucha en el puerto local 520UDP (¿era este para
rip?) verias el trafico de actualizaciones de ruta si
las hubiese. ¿Que utilidad tiene esto? Pues imaginate
que no puedes acceder a un router que ejecute rip,
administrador con gripe, y quieres comprobar si se
efectuan las actualizaciones correctamente, coges tu
portatil te conectas a la red y a escuchar. Esto sin
necesidad de poner la nic en modo promiscuo, que en
muchas redes hace que salten las "alarmas" (los log's
se disparan) de control de red y luego no hay quien
les convenza de que era por trabajo.

Un saludo

ASUNTO: Re: Módulo 6. ¿Qué es la IANA?

AUTOR: Javier Castañón

FECHA: 03/06/05

Iana ,creo, no se nombra nunca en el módulo 6. Se
nombra a ARIN que,creo, es la versión Americana de
IANA, para asignar numeros de identificación de los
AS (sistemas autónomos). Pero si miras esta dirección
http://www.iana.org veras lo que es = Internet
Assigned Numbers Authority.
De todas formas, Cisco hila fino... hay que hacerse
los examenes , tranquilamente (música new age u otra
preferencia, chiil out,...) y reflexionar.
Aunque si nos ponemos ortodoxos, un término que no
se encuentra en el temario,(IANA solo se cita en
CCNA2 en 10.2.1 Múltiples conversaciones entre
hosts )
pero que se puede deducir de este da lugar a
¿reclamación o no?....
De todas formas si buscas en Cisco IANA te dá:
"Sistema autónomo
Conjunto de redes bajo una administración común que
comparte una estrategia de enrutamiento común. Los
sistemas autónomos se subdividen por áreas. IANA le
debe asignar un número exclusivo de 16 bits al
sistema autónomo. A veces se abrevia como AS. Ver
también área e IANA."

Un saludo.

ASUNTO: A cerca de la seguridad en Networking

AUTOR: Javier Castañón

FECHA: 12/06/05

Hola, en no sé que hilo se citaban el tema de los
sniffers y de las nic's (tarjetas de red)
en modo promiscuo y la posibilidad de detectarlas o
no. Pues bueno os mando esto
que siempre vendrá bien para los admdores de red

Este tema se documenta en parte bastante bién en el
siguiente artículo en la web
http://www.gwolf.cx/seguridad/Sniffers_Ethernet/Sniffe
rs_Ethernet.html

.Reflexionando un poco se llega al siguiente
resumen , conclusiones, comentarios y divagaciones
sobre seguridad en Networking:

* ARP poisson o envenenamiento ARP: Técnica usada
para engañar a los componentes de una red , que uno
es otro , es decir
que se tiene la mac address de otra nic para poder
recibir el trafico dirigido a esa nic y una vez
escuchado redirigirlo a su dueño legitimo
(tecnica man in the midle) su filosofia se parece al
ip spoofing....si les interesa buscar en google

* Un sniffer con nic en modo normal,ya sea en medio
conmutado (switch) o compartido (hub) solo podra
escuchar el trafico de la red:
-todo el saliente de la nic
-solo el entrante dirigido a esa nic o el trafico
broadcast

* Un sniffer sin arp poisson con nic en modo
promiscuo en medio conmutado (switch) solo podra
escuchar el trafico de la red:
- todo el saliente de la nic
- solo el entrante dirigido a esa nic o el trafico
broadcast

* Un sniffer con nic en modo promiscuo en medio
compartido (hub) escuchara todo el trafico del medio.
-todo el saliente de la nic
-todo el trafico dirigido a cualquiera

* Un sniffer con nic en modo promiscuo en cualquier
medio con arp poisson, escuchara todo el trafico.

* Luego el limite de un sniffer es como maximo el
dominio de colision. Si se desea capturar el trafico
del dominio de broadcast y más alla habria que
emplear otras tecnicas, tal como hacerse con el
control del router
donde penda el segmento de red o sub red a capturar y
configurarlo de tal manera que el host del atacante
sea el gw y
reciba todo el trafico de ese router y redirigirlo
luego correctamente a sus destinos ( otra vez man in
the midle)

* Un sniffer casi siempre es detectable.... (los muy
sofisticados con nuevas técnicas es bastante dificil)
normalmente con otro sniffer.
hay varias herramientas (ver google)

* Evitar (todo depende del presupuesto) uso de hub y
emplear switch (los switchs han bajado bastante el
precio)

* Si administras una red seria y contemplas la
posibilidad de usuarios de perfil avanzado (derechos
de instalar Sw y cambiar la config
o simplemente que tengan privilegios de
administradores locales de su equipo ) instala un
monitorizador de actividades
de sniffers, de envios de ficheros de keyloggers....

* Sniffer ideal (al menos para mi) para medio
compartido: Ethereal, para medio conmutado: etercap,
cain...

Todo esto se puede aplicar a wifi, aclarando que ,
la nic wireless deberá soportar poder activar por su
driver el modo promiscuo.
Y aclarando también que normalmente se suele
encriptar el trafico en las redes wifi, aunque segun
el algoritmo empleado
(tipos de encriptacion....como WEP de 64 o de 128)

se suelen emplear tecnicas de desencriptacion
basandose en la captura de los llamado paquetes
debiles (como el tema es amplio no me extiendo)
(ver google)

De hay la necesidad de: - Evitar telnet (password
viaja en texto plano = sin encriptacion) intentar
usar SSH,pero su última version, ya hay
sniffers que rompen la encriptacion de SSH1
- Encriptar la información que viaja por la red
- No olvidarnos que esto esta previsto por los
desarrolladores de la web y en sus aplcaciones de
validacion de usuario
suelen usar encriptacion fuerte de 128 bits. Si
intentas esniffar una password de validacion de un
usuario de yahoo
solo obtendras el hash . es decir el resultado es una
ristra de caracteres extraños que es la password
encriptada
(claro que existen desencriptadores, bruta
fuerza,keyloggers) pero es bastante seguro....
Bueno no me enrrollo más. A mi el tema me parece
apasionante pero tampoco es el tema central del CCNA2.
Un saludo
(Todo o casi,de lo que comento está probado en un
curso de redes, bajo wxp, w2k y linux debian y el
campeon en deteccion de sniffers
se lo llevo , no me acuerdo que aplicacion, sobre
linux debian)

ASUNTO: RIP

AUTOR: Angel santana

FECHA: 13/06/05

Hola
Hice, con RouterSim, una topología con 6 sedes, cada
una con un router.
Los routers están unidos a través de los seriales
formando un anillo, por lo que para ir a cualquier
equipo hay dos caminos posibles.
Activé RIP y se produce la actualización de rutas sin
problema. Sin embargo, veo que a cada router llegan
las actualizaciones SIEMPRE desde una misma
interface, cosa que me sorprende, pues, salvo para un
nodo que se encuentre en el polo extremo, siempre hay
un camino más corto.
Rompí el anillo y se produce la actualización
correctamente. Al restaurar el anillo, tras un ratito
veo que otra vez se producen las actualizaciones
desde la misma interface. ¿se debe ésto a algún
parámetro por defecto que no he controlado?

Saludos

ASUNTO: Re: RIP

AUTOR: Rafael Acosta

FECHA: 13/06/05

Hola Angel,

A mi me pasó algo parecido con el simulador, al
implementar una topología parecida en anillo ( pero
en mi caso de solo 3 routers ). Ya en su momento hice
un post en el foro plantendo esta duda (si quieres
míratelo).

A mi lo que me pasaba es que el último router al que
le activaba RIP, rompía toda la convergencia que los
anteriores habían adquirido. Con el debugger pude ver
que habian paquetes de actualización que superaban
los 15 saltos, y los routers los desechaban... al
final y despúes de pegarme toda una noche en vela, me
di cuenta que el orden de publicación de las
interfaces influía en la convergencia.. ¿¿??

Prueba a publicar primero las interfaces seriales y
luego las ethernet que conectan a las LAN´s... el
tema es que en la primera actualización RIP, los
routers tengan constancia de las interfaces que los
unen y luego.. una vez que converjan, publica las
interfaces de 2º salto que son las Ethernet...

a mi me funcionó asi.

De todas maneras espero que Carlos "reaparezca en
escena" y no aclare a todos estas dudas que tanto nos
atormentan y nos hacen perder horas de sueño...

Salu2.

ASUNTO: Limitaciones de RIP (Re: RIP)

AUTOR: Javier Castañón

FECHA: 14/06/05

Por si vale de algo:
Rip es un protocolo IGP por vector distancia que
presenta ciertas limitaciones:
"Con el Split horizon con poisoned reverse se evita
cualquier bucle que implique sólo dos pasarelas. Sin
embargo, aún es posible acabar con situaciones en las
de este tipo. Por ejemplo, A puede creer que tiene
una ruta a través de B, B a través de C, y C a través
de A. Esto no se puede solucionar con el método split
horizon. Este bucle sólo se arreglará cuando la
métrica alcance infinito y la red o el host
implicados se declaren inaccesibles. El método
triggered updates es un intento de acelerar esta
convergencia. Siempre que un "router" cambia la
métrica de una ruta, se le requiere que envía
mensajes casi inmediatemente, incluso aunque no sea
el momento de una actualización(RIP especifica un
pequeño intervalo, entre 1 y 5 segundos, con el fin
de evitar que estas actualizaciones generen un
tráfico de red excesivo)."...
"RIP no está diseñado para resolver cualquier posible
problema de encaminamiento. El RFC 1720 (STD 1)
describe estas limitaciones técnicas de RIP
como "graves" y el IETF está evaluando candidatos
para reemplazarlo. Entre los posibles candidatos
están OSPF("Open Shortest Path First Protocol"
Versión 2) y el IS-IS de OSI IS-IS (ver IS-IS
("Intermediate System to Intermediate System" de
OSI)). Sin embargo, RIP está muy extendido y es
probable que permanezca sin sustituir durante algún
tiempo. "

ASUNTO: Re: RIP

AUTOR: Carlos Mena Mesa

FECHA: 16/06/05

Hola.

En mi página

http://cmena.ulpgc.es/publico/cisco/CCNA2/

he dejado un documento de PowerPoint, Traza de RIP.ppt
con los resultados de implantar esa topología con
tres routers. Como puede verse el funcionamiento es
acorde a la teoría y al sentido común.

No olvicemos que el simulador es un programa, y que
como tal, puede tener errores.

Algunos de los laboratorios que vamos a montar tratan
este aspecto de las rutas alternativas. Trabajaremos
con ellos y haremos variantes, sea balancear el
tráfico, paquete a paquete o por conexión, elegir el
más adecuado...

Un saludo

ASUNTO: Definición de "Socket"

AUTOR: Rafael Acosta

FECHA: 18/06/05

Me gustaría saber cual es la definición "formal" de
socket.

Salu2.

ASUNTO: Re: Definición de Socket

AUTOR: Javier Castañón

FECHA: 19/06/05

Según el Glosario de Cisco:
"Socket
Estructura de software que opera como un punto de
terminación de comunicaciones dentro de un
dispositivo de red."

Como el término es Inglés (Socket <->
IP_address+Protocolo+Puerto):
Internet sockets
In RFC documents relating to TCP or UDP, a socket on
a certain host is defined as the combination of an IP
address, a protocol, and a port number.

Y el termino dá para rato...

"A CPU socket is a physical and electrical
specification of how to connect a CPU to a
motherboard.

In electronics, a socket is also used as a synonym
for a jack.

An electrical socket is a synonym of electrical
outlet: an electrical device connected to a power
source onto which another device can be plugged or
screwed in. Typical examples are wall sockets and
light bulb sockets. See Domestic AC power plugs and
sockets.

In the world of computers, there are two types of
sockets: Internet sockets and IPC sockets (IPC is
short for inter-process communication).

A socket can be used in computer networking to form
one end of a bi-directional communication link
between two programs, likely over a computer network,
though exceptions like the X Window System exist.

Sockets can also be used for IPC, without IP
addresses or any other staples of TCP/IP.

The BSD operating system introduced network sockets
in 1983: see the Berkeley sockets API. Each socket
gets bound to a given port, which lets the transport
layer protocol (typically UDP or TCP) identify which
application to send the data to.

Unix domain sockets, IPC sockets
Another type of socket is used by POSIX compliant
systems, and are called Unix domain sockets (the
correct standard POSIX term is POSIX Local IPC
Sockets). Their primary function is as a means for
inter-process communication and are therefore also
called IPC sockets. These connections are from the
local computer to itself, not actually a connection
transmitted over a physical network."

Todo esto lo tienes en www.wikipedia.org
Un saludo

ASUNTO: Re: Definición de Socket

AUTOR: Carlos Mena Mesa

FECHA: 19/06/05

Hola.

Efectivamente un socket es la combinación de
IP+protocolo+puerto.

Una pareja de sockets, en el emisor y en el receptor,
identifica una conexión de red.

Abrir un socket es establecer esa conexión. Cerrarla
es darla por finalizada.

Un saludo

ASUNTO: Practica 11.2.1 ACL estándar

AUTOR: Javier Castañón

FECHA: 19/06/05

En la última práctica del 11.2.1 ACL estándar
.Que en este caso es de lab-electrónico, es decir
simulada.
Nos piden para el router Sofia crear una ACL que
permita solo el acceso a su red interna 12.0.0.0/24.

router>enable

router#configure terminal

router(config)#access-list 1 permit 12.0.0.0
0.255.255.255

!esto seria redundante pues va implicito ->router
(config)#access-list 1 deny any

router(config)#interface serial 0/0

router(config-if)#ip access-group 1 in

Nos preguntan en la práctica en que otra interfaz se
podria aplicar la ACL 1, ¿Tendriamos el mismo efecto
si lo aplicaramos a la interface fastethernet 0/0,
donde suponemos pende la red 12.0.0.0/24? seria la
respuesta correcta ¿o no?.

Un saludo.

ASUNTO: Re: Practica 11.2.1 ACL estándar

AUTOR: Carlos Mena Mesa

FECHA: 19/06/05

Hola Javier.

Si sólo queremos dejar pasar tráfico hacia la red 12,
el otro lugar para poner una regla se me ocurre que
sería en el interfaz de la red 13 (Fastethernet0/1),
denegando el tráfico de salida hacia esa red.
¿Qué te parece?

Por cierto, la práctica falla en el paso 4, cuando
hay que introducir el interfaz, ¿no?

Saludos

ASUNTO: Re: Practica 11.2.1 ACL estándar

AUTOR: Javier Castañón

FECHA: 20/06/05

Hola Carlos. Creo que también seria funcional eso
que dices (ACL estandar en fa0/1 de la red 13...)
Sí, en las prácticas simuladas hay algunos errores
sobre todo cuando vas a indicar la orden de
configurar el interfaz (...# interface x), pero
como no dá pie a dudas, se ve claramente que es un
error de la aplicación.
Gracias por la pronta contestación.

ASUNTO: Practica 11.2.2 ACL extendidas

AUTOR: Javier Castañón

FECHA: 19/06/05

En la 6ª práctica del apartado 11.2.2 ACL
extendidas. Que corresponde a una práctica simulada.
Nos piden denegar el tráfico tcp a la red
192.168.13.0 desde la red 192.168.12.0 para el
interface serial saliente.

en la práctica se da por buena la sentencia:
access-list 101 deny tcp 192.168.12.0 0.0.0.255
192.168.13.0 0.255.255.255 ?????

¿Pero por qué aplica esa wildcard en el destino?
¿No seria lo correcto?:
access-list 101 deny tcp 192.168.12.0 0.0.0.255
192.168.13.0 0.0.0.255

Un saludo

ASUNTO: Re: Practica 11.2.2 ACL extendidas

AUTOR: Carlos Mena Mesa

FECHA: 19/06/05

Hola Javier.

Buena observación. A mi juicio se trata de un error.

Por cierto, ¿cuál sería el mejor lugar para poner la
regla de acceso?. ¿Por qué?.

Saludos

ASUNTO: Re: Practica 11.2.2 ACL extendidas

AUTOR: Javier Castañón

FECHA: 20/06/05

Hola Carlos.
Como ya me he leido el 11.2.4 Ubicación de las ACL
(jejeje) te puedo responder a esa pregunta.
La ubicación según la regla de una ACL extendida
seria lo más cerca posible del origen. Y el por qué ,
supongo que es,como cita Cisco, por eficiencia de la
red, ya que eliminamos tráfico indeseado en la mayor
parte posible de la red controlada, y eliminar
trafico no deseado = Mayor Seguridad = Mayor BW
disponible = Menor carga de la red =...

Un saludo

ASUNTO: Última práctica de 11.2.2

AUTOR: Javier Castañón

FECHA: 19/06/05

En la 7ª y última práctica del apartado 11.2.2 ACL
extendidas. Que corresponde a una práctica simulada.
Nos piden: impedir que se hagan peticiones locales de
trafico ftp desde 192.168.12.0 a cualquiera que no
sea 192.168.11.0 y permitir todo el trafico restante,
a traves de a inerface serial.

* a cualquiera que no sea 192.168.11.0 -> implica que
a esta red si se le permite trafico ftp luego:

access-list 101 permit tcp 192.168.12.0 0.0.0.255
192.168.11.0 0.0.0.255 eq ftp ( o 21)

Pero esta sentencia la practica no la contempla
¿¿¿¿??????.
pasando directamente a denegar a cualquiera el
tráfico ftp a 192.168.12.0 y luego permitiendo todo
el tráfico restante. Cosa que veo correcto pero a mi
parecer faltaria permitir a la red 192.168.11.0/24
las peticiones ftp a 192.168.12.0/24

access-list 101 deny tcp 192.168.12.0 0.0.0.255 any
eq 21
access-list 101 permit ip any any

ASUNTO: Re: Última práctica de 11.2.2

AUTOR: Carlos Mena Mesa

FECHA: 19/06/05

Hola Javier.

El punto 3 de la práctica dice a medio parrafo, "Un
estudiante de CCNA sugiere que una forma de hacer
esto es impedir que todas las peticiones de tráfico
ftp salgan de Abuja a través de la interfaz serial."
Con lo cual da a entender que se parte de esa premisa.

Si es así, el planteamiento restante, a mi entender,
sería correcto.

Es decir, el tráfico desde la red 12 a la 11 no tiene
que pasar por el interfaz serial, con lo cual la ACL
no afecta el tráfico de una a otra y no habría que
incluir la regla que sugieres.

¿Qué te parece?

Saludos

ASUNTO: Re: Última práctica de 11.2.2

AUTOR: Javier Castañón

FECHA: 20/06/05

Gracias por la aclaración.
Creo que lo mejor, para estos casos es hacerse
un esquema gráfico del router,sus interfaces y las
redes que penden de ellas, para
no hacerse un lio.
(una imagen vale por 1k ...)

Un saludo

ASUNTO: Duda en 11.2.4 Ubicación de las ACL

AUTOR: Javier Castañón

FECHA: 20/06/05

Hola a todos. Tengo otra duda.
En el ejemplo de 11.2.4 nos indican como situar una
ACL extendida o una ACL estándard para un mismo
objetivo: "...el administrador quiere denegar el
tráfico telnet o FTP del segmento LAN Ethernet del
Router A al segmento LAN Ethernet conmutado Fa0/1 en
el Router D, y al mismo tiempo permitir otros tipos
de tráfico..."

* La posición de la ACL extendida, en FA0/1 del
Router A cumple con la regla: "colocar las ACL
extendidas lo más cerca posible del origen del
tráfico denegado"

* La posición de la ACL estándard, en FA0/0 del
Router D, Creo que no cumple con la regla: "se deben
colocar lo más cerca posible del destino", Pienso que
lo más cerca del destino seria en FA0/1 del router D.

Aunque funcionalmente seria acepable:

¿ Que seria lo más adecuado a la regla ?.
Un saludo.

ASUNTO: Re: Duda en 11.2.4 Ubicación de las ACL

AUTOR: Rafael Acosta

FECHA: 22/06/05

Hola Javier,

En principio ambas interfaces están igual de cerca
del destino, porque en mi opinión el RouterD es el
destino en si... es donde defines la ACL, y donde se
decide si un paquete se acepta o se descarta.

Creo que es correcto colocar la ACL en la FA0/0, ya
que los paquetes que no tengan acceso se descartarían
directamente en la interface... de la otra manera,
poniendo la ACL en la FA0/1, los paquetes
atravesarían el RouterD ( habría que conmutarlos ), y
una vez en la FA0/1 serían descartados...

Al tener que conmutar todos los paquetes se utilizan
recursos del RouterD, tiempo de CPU, RAM... habría
también que consultar la tabla de enrutamiento.. etc.

Es simplemente una cuestión de ahorro de recursos, y
sentido común...

Por cierto he visitado tu página del curso de
CISCO... Te lo curras !!! ;).. de donde sacas el
tiempo??

Salu2.

ASUNTO: Re: Duda en 11.2.4 Ubicación de las ACL

AUTOR: Carlos Mena Mesa

FECHA: 25/06/05

Hola.

Respecto a la ubicación de la ACL, entre el interfaz
FA0/0 y el interfaz FA0/1.

Es cierto que ubicándola en el interfaz FA0/0,
ahorramos carga al router, pero ¿se podría en este
caso acceder por telnet al RouterD desde el segmento
LAN Ethernet del Router A?

Un saludo

ASUNTO: Re: Duda en 11.2.4 Ubicación de las ACL

AUTOR: Javier Castañón

FECHA: 26/06/05

Pués va a ser que Carlos lleva la razón, si nos
ceñimos estrictamente al enunciado. El enunciado dice:
"...el administrador quiere denegar el
tráfico telnet o FTP del segmento LAN Ethernet del
Router A al segmento LAN Ethernet conmutado Fa0/1 en
el Router D, y al mismo tiempo permitir otros tipos
de tráfico..."

Es decir que quiere denegar el tráfico telnet (y ftp)
de segmento LAN A al segmento LAN FA0/1-D, pero no
impedir el trafico telnet (y ftp) del router A a D...
(la velocidad y el tocino...).

Tal como sugiere Carlos, habria que ubicar la ACL en
FA0/1 (y aunque le dariamos más carga de trabajo al
router D) para poder permitir , por ejemplo un telnet
desde el router A y/o desde un host del segmentoLAN
de A al D.

Está claro, que como dice un compañero hay que leer
con extremo cuidado
Un saludo

ASUNTO: Algo no cuadra en la Métrica

AUTOR: Diego

FECHA: 22/06/05

Mayor ancho de banda= Mejor Métrica
Menor retardo= Mejor Métrica
Mejor Métrica=Menor valor Métrico
Menor valor Métrico= Mejor Ruta

No me cuadra la formula de la Métrica. MAYOR Ancho de
Banda=Mayor valor Métrica= Peor ruta.
Hay algo que no entiendo o he pasado por alto?

Métrica = Ancho de banda + Retardo.

No será ¿Métrica = K1/Ancho de banda + K3*Retardo ?

Métrica = [K1 * Ancho de banda + (K2 * Ancho de
banda)/(256-Carga) + K3*Retardo] * [K5/(Confiabilidad
+ K4)]

Los valores por defecto de las constantes son K1 = K3
= 1 y K2 = K4 = K5 = 0.

ASUNTO: Re: Algo no cuadra en la Métrica

AUTOR: Carlos Mena Mesa

FECHA: 26/06/05

Hola Diego.

Muy observador. Tienes toda la razón. La explicación
es que el nombre que se ha elegido para estas
variables no corresponde con el cálculo que hay que
hacer para obtenerlas.

Partiendo de la fórmula que tu indicas, y que es
correcta

IGRPmetric = BW + delay

se define (y aquí está el asunto)

BW como el resultado de dividir 10,000,000 por el
más pequeño de los anchos de banda (en Kbps) de los
interfaces (de salida) en la ruta hacia el destino.
Es decir, tal y como tu apuntas, es una variable
inversa al ancho de banda del enlace,

delay es la suma de todos los delays (en
microseconds) de los interfaces de salida en la ruta
hasta el destino, dividido por 10.

Más información en

http://www.cisco.com/en/US/tech/tk365/technologies_tec
h_note09186a008009405c.shtml
http://www.ciscopress.com/articles/article.asp?
p=102174&seqNum=5

Saludos

ASUNTO: Re: conclusión

AUTOR: diego

FECHA: 26/06/05

Por la formula con un BW>10Gbps la metrica en IGRP
puede ser CASI la queda el retardo.

GRACIAS