Cmo configurar ACLs?

:
problema/ejercicio completo ACLs
estndar
Hace algn rato escrib una serie de entradas sobre ACLs -Access Control Lists o listas
de control de acceso en espaol. Infortunadamente, no han sido muy exitosas: nadie las
lee, bueno exagero, las leen poco respecto a lo que me esperaba (comparando con la
serie sobre Packet Tracer). La idea es hacer una nueva entrada ms prctica con video
incluido (en la prxima de la serie) que estimule la lectura de las otras entradas.
Disfrtenlo.
Qu son ACL -Access Control Lists o listas de control de acceso-?
Pues si no sabe lea la primera entrada sobre ACLs. En sta entrada vamos a partir de
que se sabe qu es una acl estndar y qu son acls extendidas, partiendo de eso vamos a
configurar en la topologa de ejemplo una poltica de seguridad arbitraria con listas
estndar y listas extendidas y veremos la diferencia.
Topologa de ejemplo
Como base para el ejercicio vamos a tomar la misma topologa de la ltima entrada
sobre ACLs, en ella se conectan 5 enrutadores por cables seriales, a cada uno se le
conecta una subred con la posibilidad de agregar varios equipos. La topologa ya est
configurada y hay conectividad perfecta de punta a punta, es decir, se puede hacer ping
entre los PCs y se puede acceder por Telnet desde cualquier PC a cualquier enrutador.
Las subredes de los PCs (usuarios) estn todas dentro del prefijo 172.16.0.0/12, usando
las subredes 172.16.0.0/16, 172.17.0.0/16 y 172.19.0.0/16, la 172.18.0.0/16 es la
direccin que simular la salida a Internet. Los enlaces y el servidor pertenecen al
prefijo 10.0.0.0/8, es decir, los enlaces son 10.1.1.0/30, 10.1.1.4/30, 10.1.1.8/30,
10.1.1.12/30, 10.1.1.16/30 y el servidor es 10.0.0.5/8. ste esquema de direcciones se
llama direccionamiento no contiguo, es decir, las subredes consecutivas de una misma
clase (A, B o C) no estn asignadas a un slo enrutador (por ejemplo las subredes de los
enlaces pertenecen a la red 10.0.0.0/8 de clase A pero sus subredes se distribuyen por
todos los enrutadores). Cuando en una topologa se da el direccionamiento no contiguo,
hay que deshabilitar el auto resumen en el protocolo de enrutamiento que se est
usando.
El servidor corre http, tftp y dns (hay que activarlo), de hecho, vamos a usar
example.com para hacer pings y telnets, lo anterior slo funciona si se puede acceder al
servidor dns para convertir el nombre de dominio en direccin IP y si el servidor DNS
tiene una entrada para example.com que se traduce a una direccin IP, en nuestro caso la
172.18.0.2.
Recomendaciones previas

Como lo que vamos a hacer es un ejercicio un poco ms realista, lo primero que

deberamos tener en cuenta antes de comenzar es tomar precauciones. Lo primero es
guardar todas las configuraciones actuales, para que en caso de catstrofe (p.e.: se
pierda totalmente la conectividad) se pueda recuperar rpidamente la configuracin. Eso
se puede hacer guardando una copia del archivo de configuracin en un archivo de texto
o en un tftp. Hay que tener muy en cuenta que cuando se configuran ACLs usualmente
uno se conecta por Telnet, es decir, que si el dao hace perder la conectividad del
enrutador que se est configurando con el PC en el que estamos trabajando
Despedidos!. En una entrada anterior describo un comando para evitar catstrofes de
ste tipo (cuando el IOS lo soporta), que consiste en establecer un timer de reinicio, por
lo tanto si no guardamos la configuracin que estamos haciendo y perdemos la
conectividad hay garanta de que el enrutador/switch se reinicie y arranque con la
configuracin original (antes del cambio).
Lo otro que hay que verificar Y DOCUMENTAR es el estado de la conectividad previa
a la configuracin. No perdamos el tiempo tratando de arreglar lo que est malo (a
menos que sea nuestra responsabilidad directa), slo documentemos cmo est,
haciendo unos pings selectos y unos telnets que muestren qu se poda hacer antes de la
instalacin de las ACLs. Recuerden que una forma de verificar conectividad de capa 4 y
superior es usar un telnet al enrutador al que queremos verificar la conectividad (previa
configuracin correcta de las lineas de vty en el equipo al que apuntamos).
Poltica de seguridad de ejemplo
Ya descrita la topologa, creemos una poltica de seguridad impuesta por un superior
administrativo.
1. El servidor es de la intranet, es decir que de las redes del Router4 y Router2
deben poder acceder a la web interna.
2. Los PCs de la red del enrutador Router1 son invitados, por lo tanto slo pueden
acceder a Internet, no al servidor ni a las redes internas (las de Router4, Router2
ni a los enrutadores mismos)
3. De los PCs de las redes internas, slo quienes tengan direcciones IP impar
pueden acceder a Internet, el resto no.
4. Los PCs internos (excepto los invitados) pueden acceder a sus recursos y a los
enrutadores.
5. El PC 5 no puede acceder a ningn enrutador por ningn medio.
6. Cualquier trfico no contemplado debe ser bloqueado.
Lo anterior hay que ponerlo en trminos de filtrado de trfico con ACLs. El servidor
tiene la direccin IP 10.1.1.1, por lo tanto el trfico proveniente o destinado al servidor
cumple la condicin de que su direccin (origen o destino) debe ser exactamente
10.1.1.1. Una regla de ACL que coincida con el servidor sera host 10.1.1.1, en qu
posicin de la ACL poner esta condicin (direccin origen o destino) ya es cuestin de
si usamos ACLs extendidas o estndar y en qu direccin de trfico: de entrada o salida

de la interfaz. El trfico proveniente de los PCs de la red de Router1 tiene el patrn

172.16.0.0 0.0.255.255, es decir, todos tienen en alguna de sus direcciones IP (origen o
destino) los primeros 16 bits iguales a 172.16. La mscara wilcard dice que lo que est
en 1 lo ignore, no lo compare con la direccin de referencia, en otras palabras, la mezcla
de direccin de referencia con mscara wildcard se podra escribir 172.16.X.X, ya que
el trfico de la red slo se mirar en los bits que diga la mscara wildcard (los 0s
solamente) y cualquier otro bit se ignorar (los 1s). El patrn de trfico que identifica
las direcciones impares es el siguiente 0.0.0.1 255.255.255.254, que significa compare
slo el ltimo bit del paquete y quienes tengan ah un 1 cumplen la condicin sealada
(todo nmero impar tiene en binario un 1 en su bit menos significativo y todo nmero
par tiene un 0 en su ltimo bit). Como ejemplo adicional, si quisiramos condicionar el
trfico de cualquier red pero slo para las direcciones pares slo habra que poner
0.0.0.0 255.255.255.254, regla que se cumplira slo para los paquetes que tengan un 0
en su ltimo bit. El trfico de los PCs internos es el mismo ejemplo que para la red del
Router1 y el trfico del PC5 es el mismo ejemplo del servidor: PCs del Router2 =
172.19.0.0 0.0.255.255 y PC5 host 172.19.0.3
Los ejemplos anteriores son complejos y todava no hemos decidido en qu interfaces
de qu enrutadores y en qu direccin de trfico (entrada/salida) vamos a ubicar las
listas. Si hacemos la configuracin slo con listas estndar (por evitar sobrecarga del
enrutador o porque el enrutador no soporta -por alguna extraa razn- listas extendidas),
todas las condiciones que mencion en el prrafo anterior se deben aplicar a las
direcciones origen de los paquetes, porque las acls estndar slo permiten filtrar por
direccin IP origen.
Configuracin con listas estndar
Una de las cosas interesantes a notar es que la configuracin se puede hacer con listas
estndar o extendidas, el problema es qu tan difcil sea configurar todo sto. Primero
intentaremos con listas estndar. El orden de las listas afecta el resultado, por lo tanto
hay que poner las ms restrictivas primero y luego las ms generales, adems hay que
seleccionar dnde ponerlas. Para las listas estndar, la ubicacin debe ser lo ms
cercano posible del destino, por lo tanto para el trfico que se dirige al servidor lo ms
cercano al destino es su enrutador, en la interfaz que da hacia el servidor y en la
direccin de entrada (recuerden que las ACLs estndar slo pueden filtrar con base en la
dir. origen). Esa es la mejor opcin, otras opciones seran en las otras interfaces de
salida, pero probablemente sea necesario ponerlas en todas las interfaces.
Me alargara demasiado si explico cada regla, pero yo creo que queda claro con la
eleccin de la lista del servidor, as que voy a escribir el listado y la ubicacin:
Poltica 1:
Router0, fa 0/0 out
access-list 1 permit 172.16.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255
Poltica 2:
Router4, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any

Router2, ser 0/0/0, in

access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any
Router3, ser 0/0/0, in
access-list 1 permit 172.17.0.0 0.0.255.255
Poltica 3:
Router3, ser 0/0/0, in
access-list 1 permit 172.17.0.0 0.0.255.255
access-list 1 permit 0.0.0.1 255.255.255.254
Poltica 4:
Router4, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255
Router2, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit 172.16.0.0 0.0.255.255
Router0, Router1, Router2, Router3 y Router4 en las vty.
access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255
Poltica 5:
Router0, Router1, Router2, Router3 y Router4 en las vty.
access-list 2 deny host 172.19.0.3
access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255
Poltica
6:
Todas las listas de acceso terminan en un deny implcito, es recomendable usar un deny
any explcito para poder llevar control de cuntos paquetes son filtrados por sta ltima
regla.
Adicionales:
1) Dado que las listas escritas tambin bloquean el protocolo de enrutamiento, una
vez instaladas las listas anteriores, las tablas de enrutamiento se empiezan a daar
(faltan rutas), se pierde la conectividad y la convergencia de la red. Por lo anterior, hay
que permitir el trfico que provenga de los enrutadores, en las interfaces habra que
poner
una
regla
como
sta
access-list 1 permit 10.1.1.0 0.0.0.255
y en las vty, una como sta para incluir el servidor en la posibilidad de hacer telnets
access-list 1 permit 10.0.0.0 0.255.255.255

2) Con las listas propuestas, el trfico de Internet de las estaciones impares puede
salir de la red, pero pasa las listas en los enrutadores finales? No, y el problema es
que el trfico proveniente de internet no tiene un patrn de direcciones IP origen, por lo
tanto la nica regla que permitira el trfico de internet sera permit any, lo cual violara
la poltica de bloquear cualquier otro trfico.
3) No hay forma de permitir el trfico desde la red de invitados hacia el servidor
slo para web, dns y tftp. Si slo hubiera la opcin de usar listas estndar, habra que
ubicar un servidor por fuera de la zona protegida o no protegerlo de la red de invitados,
algo que es inaceptable en las redes modernas.
Segn las consideraciones anteriores, las listas de acceso seran:
Router0, fa 0/0 out
access-list 1 permit 172.16.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255
Router3, ser 0/0/0, in
access-list 1 permit 172.17.0.0 0.0.255.255
access-list 1 permit 0.0.0.1 255.255.255.254
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 1 deny any
Router4, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any
Router2, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any
Router0, Router1, Router2, Router3 y Router4 en las vty.
access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255
Para terminar, los comandos con los cuales se instalan las listas son ip access-group N
in/out si se va a instalar en las interfaces (serial o fastethernet) pero si se van a instalar
en las lneas vty se usa el comando access-class N in/out.
Conclusiones
Las ACLs estndar tienen una potencia limitada, pero en ciertos casos puede ser
necesario usarlas. Las ACLs estndar se usan en otros contextos en los que las
limitaciones no son tan importantes, como definir un conjunto de direcciones para
usarse en NAT o en otro proceso que parta de un bloque de direcciones IP, en ste caso,
la idea de direccin destino pierde sentido y las ACLs estndar son perfectas para una
aplicacin como stas. En el ejemplo propuesto se ilustra mucho de lo que se puede
hacer con las ACLs estndar y tambin lo que no se puede hacer: filtrado por puertos.
La prxima entrada ser la misma poltica, pero implementada con listas extendidas. Si

ya comprenden el tema, vayan trabajandolo a ver si coincide con mi propuesta (o es

mejor).
P.D.: Esta entrada la empec a escribir, la dej programada pero se me olvid y se
public incompleta. Me toc terminarla rpidamente porque ya me ha pasado antes y
me da pena que aparezcan y desaparezcan entradas, as que si hay muchos errores me
perdonarn. Ah la iremos corrigiendo.

Cmo funcionan las ACLs?: V Ejemplos

Finalmente lleg la ltima entrada de la serie sobre ACLs, los ejemplos de uso. Espero
finalizar mostrando algunos ejemplos que se puedan verificar en la prctica y algunos
usos adicionales de las ACLs que van ms all del currculo de CCNA. Disfrtenlo.
Siguiendo la serie de publicaciones sobre ACLs, voy a hacer ejemplos de configuracin
y funcionamiento del tema de cada una de las entradas anteriores, es decir, Conceptos,
ACLs estndar, ACLs extendidas y ACLs complejas. Primero recordemos las bases de
siempre.
Conceptos bsicos
Hay que recordar que las ACLs son fundamentalmente un mecanismo de seleccin de
trfico, generalmente, por medio de parmetros de los campos del encabezado IP o los
encabezados TCP y UDP. En algunos casos, el protocolo de capa 4 se puede cambiar
para establecer conrrespondencias con otros encabezados como los de EIGRP, OSPF,
entre otros. Una vez que la seleccin se establece, se puede usar para mltiples
finalidades, por ejemplo en CCNA se usa como mecanismo bsico de seguridad, es
decir, el trfico seleccionado se puede bloquear o permitir segn las necesidades de la
organizacin. Otros usos son la definicin de las direcciones que van a ser traducidas en
un enrutador de borde que usa NAT entre otras muchas tecnologas que usan las ACLs
para definir conjuntos de direcciones o flujos de trfico seleccionados entre muchos
otros.
La seleccin de trfico o direcciones en las ACLs consiste en definir un conjunto de
reglas bajo un mismo identificador, sea numrico o alfanumrico, con la forma

<id> <accin> <condicin> > Comando: access-list <n> [permit|

deny] <ref_origen> <wildcard_origen> [<ref_destino>
<wilcard_destino>]

<id> <accin2> <condicin2>

donde id es el nombre/nmero de la ACL, accin es permitir o denegar. La condicin es

lo que usualmente nos exige ms cuidado, las condiciones se basan en direcciones
origen en las estndar y origen/destino en las extendidas y nombradas. Las direcciones
origen o destino se definen cada una mediante una direccin de referencia y una
mscara wildcard y pueden definir arbitrariamente la seleccin, es decir, la direccin de
referencia no tiene que corresponder exactamente con una subred sino con cualquier
conjunto de direcciones, incluso de varias subredes. Si la explicacin anterior no es

clara, por favor lea la entrada inicial de la serie: Cmo funcionan las ACLs?: I
Conceptos.
Topologa de ejemplo
La siguiente es nuestra topologa de ejemplo. Infortunadamente el Packet Tracer no
soporta las ACLs reflexivas ni dinmicas, as que si usted desea hacer el ejercicio
completo debe hacerlo o bien con enrutadores reales o con GNS3. La topologa consiste
en 5 enrutadores interconectados por enlaces seriales. Uno de ellos el el enrutador
central que conecta con el servidor y el resto tienen slo una subred conectada. Las
direcciones de las subredes pertenecen al prefijo 172.16.0.0/12, asignandolas en orden
de izquierda a derecha 172.16.0.0/24, 172.17.0.0/24, 172.18.0.0/24 (PC4) y
172.19.0.0/24 (PC5). El servidor tiene la direccin 10.1.1.1 y los enlaces son
10.0.0.0/30, 10.0.0.4/30, 10.0.0.8/30, 10.0.0.12/30. El enrutamiento se lleva a cabo con
eigrp de AS 1 sin autoresmen por el hecho de haber redes discontiguas (10.0.0.0). Los
requerimientos de la topologa son los siguientes:

Estndar: Filtrar el acceso de la red del PC1 al servidor

Extendidas: Filtrar el acceso del PC2 al servidor

Dinmicas (No soportadas): Acceder al servidor desde PC5 slo si se autentica

previamente por telnet.

Reflexivas (No soportadas): Permitir el trfico de ICMP que se ogirine en PC4,

pero no al revs

Un aspecto importante, antes de hacer cualquier cosa con ACLs es verificar que exista
conectividad completa en la red objetivo. Si no comprobamos eso, podramos ignorar
problemas de conectividad previos en la red y creamos que eso es efecto de la
instalacin de las acls y el diagnstico de un problema de esa naturaleza puede ser muy
difcil de hacerse y ms difcil an de solucionar. Otra consideracin que hay que hacer
es verificar que la instalacin de una ACL afecta la red estrictamente como se espera y
no genera efectos no previstos e indeseados. Lo anterior hay que hacerlo por cada acl y
verificando la conectividad total -o la ms importante si la red es muy grande-.

Listas de Control de Acceso Estndar

En el ejemplo, el requerimiento de filtrar la red del PC1 con ACL estndar nos enfrenta
al primer problema: dnde instalar la ACL?. La respuesta tiene dos sentidos, en qu
enrutador y en qu interfaz de ese enrutador. Como las ACL estndar slo filtran el
trfico con base en las direcciones de origen, si la acl se instala en el enrutador 1, eso
filtrara todo el trfico de la red hacia todos los destinos, por lo tanto no es viable esa
decisin. Una alternativa, si no es posible instalarla en otro enrutador, sera filtrar el
trfico proveniente del servidor en el enrutador 1. Cualquiera de las dos alternativas
cumple con la regla de oro de las acls estndar: instale lo ms cerca posible del destino.
En ste caso, en el que podemos configurar el enrutador ms cercano al servidor, la
instalamos en la interfaz por la que se conecta el servidor en la direccin de salida,
filtrando efectivamente la red del PC1.
El resto es carpintera como deca un antiguo profesor que tuve:

access-list 1 deny 172.16.0.0 0.0.0.255

access-list 1 permit any

interface FastEthernet0/0

ip address 10.0.0.1 255.255.0.0

ip access-group 1 out

Lo anterior en el enrutador central, donde se conecta el servidor. Una vez que se instala
esta acl, los paquetes originados en cualquier pc de la red del pc1 no llegarn al servidor
pero s a cualquier otro pc de la red. La conectividad del resto de las redes de la
topologa sigue inalterada.
ACL extendidas
El segundo requerimiento es filtrar el trfico desde el PC2 hasta el Servidor.
Evidentemente no se puede hacer un filtrado as con una sola acl estndar. La respuesta
a la pregunta sobre la ubicacin de la acl es en el enrutador ms cercano al origen. El
razonamiento es que haciendolo de esa manera evitamos que trfico inecesario corra por
la red.

access-list 101 deny ip host 172.17.0.3 host 10.0.0.5

access-list 101 permit ip any any

interface FastEthernet0/0

ip address 172.17.0.1 255.255.0.0

ip access-group 101 in

Lo anterior en el enrutador Router1, donde se conecta el host que se quiere filtrar. De

nuevo, hay que verificar que otros pcs no quedan afectados por la acl, eso lo
verificamos enviando y recibiendo paquetes exitosamente desde el PC6 al servidor. La
conectividad del resto de las redes de la topologa sigue inalterada, eso incluye la
conectividad de otras redes al pc2.
ACLs dinmicas y reflexivas
Infortunadamente el PT 5.1 no soporta ninguno de estos tipos de acls. Para poder hacer
el ejercicio habra que usar gns3, netlab o enrutadores reales. De todas formas ilustrar
cmo sera la configuracin correspondiente en esta topologa.
Recordemos que las dinmicas son, entre otras cosas, un mecanismo de autenticacin
simple. Lo primero que haremos ser crear un nombre de usuario y contrasea para
autenticar al PC 5, luego crearemos la acl que incluya la palabra reservada dynamic,
cuidando que la misma acl permita el trfico de telnet desde el pc en cuestin,
instalamos la acl y luego en la configuracin de las vty agregamos el comando que
vincula estas dos instrucciones.

username cesarcabrera password cecab123

access-list 101 permit ip any host 172.19.0.1 eq telnet

access-list 101 dynamic testlist timeout 15 permit ip host 172.19.0.3 host

10.0.0.5

interface fa 0/0

ip access-group 101 in

Lo anterior, una vez instalado en el enrutador Router2, slo permitir el acceso del PC5
al servidor si primero se intenta hacer un telnet al enrutador y se autentica exitosamente
al mismo.
El requerimiento de acl reflexiva se debe instalar en el ltimo enrutador, Router3,
usando una acl nombrada extendida -no numerada- y con dos palabras clave
adicionales: reflect/evaluate. En la direccin de salida se permite el trfico pero se
establece que se creen las acls necesarias para el trfico de retorno con reflect y de
entrada se le indica a la acl que evale las entradas dinmicas creadas por la acl de
salida.

ip access-list extended SALIDA

permit icmp 172.18.0.0.0.0.0.255 any reflect TICMP

ip access-list extended ENTRADA

evaluate TICMP

interface ser 0/0/0

ip access-group SALIDA out

ip access-group ENTRADA in

Note que una vez que se instalan estos comandos en el ltimo enrutador, lo nico que se
puede hacer desde la red 172.18.0.0n es enviar exitosamente pings, pero no sern
exitosos si se originan en otras redes hacia sta ltima.
Otros usos de las ACLs
Finalmente, como les he venido mencionando en otras entradas, las acls son un
mecanismo de clasificacin de trfico y por eso son tiles en otros contextos. Voy a citar
dos, uno de ccna y otro de ccnp, particularmente de BSCI. En el ltimo semestre de
CCNA se estudia el tema de NAT, NAT se usa para tener una red con direccionamiento
privado arbitrariamente grande conectada a una red pblica usando slo un pequeo
conjunto de direcciones pblicas. El mecanismo consiste en examinar los paquetes
provenientes de la red privada y cambiar las direcciones IP y puertos TCP/UDP del
encabezado por las direcciones pblicas disponibles. De ese proceso se guarda en
memoria una registro de qu puertos origen han sido asignados a qu direccin privada,
de tal manera que cuando se recibe la respuesta de la red pblica con IP destino pblica
(o global como dice el currculo), el puerto TCP/UDP destino determina la direccin IP
de host local al que hay que cambiar la direccin IP para enviar el paquete al interior de
nuestra red (en otra ocasin escribo ms en detalle el proceso).
NAT debe especificar dos conjuntos de direcciones: las direcciones privadas a traducir a
direcciones pblicas y el conjunto de direcciones pblicas. El conjunto de direcciones
pblicas es un rango de direcciones arbitrarias que dificilmente correspondern con una
regla tipo acl, pero las direcciones privadas s deben tener un patrn que se corresponda
con una acl estndar, en la que las direcciones a las que se aplique la accin permit
sern las direcciones que hay que traducir a direcciones pblicas (o globales). En otras
palabras, para crear una regla de traduccin de direcciones, se especifica por medio de
una acl qu direcciones privadas (o locales) deben ser traducidas.
En BSCI se habla de un mecanismo de manipulacin de trfico llamado mapas de ruta
(route-map). Los mapas de ruta permiten manipular la forma en que se realiza el
enrutamiento por ejemplo yo podra arbitrariamente y sin contar con la tabla de
enrutamiento, decir que el trfico de cierta red debe usar siempre un enlace en
particular. se es el ejemplo ms simple de un mapa de ruta, pero los mapas de ruta
permiten muchas cosas ms, como cambiar parmetros de enrutamiento como mtricas
o filtrar actualizaciones de enrutamiento que provengan de otro enrutador. El
mecanismo bsico por el que se especifica qu trfico ser afectado por las reglas del
mapa de ruta son las acl extendidas.