Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la oficina sucursal

All contents are Copyright © 1992–2010 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 1 of 15
CCNPv6 ROUTE
Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la
oficina sucursal
Topología
Objectives
• Configura NAT.
• Configura una VPN IPsec.
• Configura un túnel GRE sobre IPsec.
• Habilita protocolo de enrutamiento dinámico sobre un túnel GRE.
• Verifica la configuración y operación usando comandos show y debug.
Paso 1: Prepara los routers y configura el hostname de router y direccionamiento de
interfaces.
a. Cablea la red como se muestra en el diagrama topológico. Borre el startup configuration y reinicie los
router para limpiar las configuraciones previas. Configure direccionamiento IP.
Branch (R1)
hostname Branch
!
interface Loopback1
description Branch LAN

CCNPv6 ROUTE
Modificado por Nicolás Contador. DuocUC Viña del Mar Page 2 of 15
ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0/1
description Connection to ISP
ip address 209.165.200.242 255.255.255.248
bandwidth 64
no shut
!
end
HQ (R2)
hostname HQ
!
interface Loopback1
description Headquarters LAN
ip address 10.10.10.1 255.255.255.0
!
description Connection to ISP
ip address 209.165.200.226 255.255.255.248
clock rate 64000
bandwidth 64
no shut
!
end
ISP (R3)
hostname ISP
!
interface Loopback1
description Simulating the Internet
ip address 209.165.202.129 255.255.255.240
!
description Connection to Branch
ip address 209.165.200.241 255.255.255.248
clock rate 64000
bandwidth 64
no shut
!
description Connection to HQ
ip address 209.165.200.225 255.255.255.248
bandwidth 64
no shut
ip route 209.165.200.232 255.255.255.248 Serial0/0/1
ip route 209.165.200.248 255.255.255.248 Serial0/0/0
!
end
b. Verifica tu configuración usando el comando show ip interface brief.
Branch# show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
FastEthernet0/1 unassigned YES unset administratively down down
Serial0/0/0 unassigned YES unset administratively down down

CCNPv6 ROUTE
Serial0/0/1 209.165.200.242 YES manual up up
Loopback1 192.168.1.1 YES manual up up
c. Verifique conectividad desde Branch usando el siguiente tclsh.
Branch# tclsh
foreach address {
209.165.200.241
209.165.202.129
209.165.200.226
} { ping $address}
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/32 ms
.....
Success rate is 0 percent (0/5)
.....
Branch(tcl)#
El ping falla debido a que los routers Branch y HQ requieren una ruta por defecto al router al router ISP.
d. Configure una ruta por defecto al ISP en los routers Branch y HQ.
Branch(config)# ip route 0.0.0.0 0.0.0.0 209.165.200.241
HQ(config)# ip route 0.0.0.0 0.0.0.0 209.165.200.225
e. Verifique nuevamente la conectividad.
Branch# tclsh
foreach address {
209.165.200.241
209.165.202.129
209.165.200.226
+>} { ping $address}
!!!!!
!!!!!
!!!!!
Branch(tcl)#

CCNPv6 ROUTE
f. Pruebe conectividad desde la LAN de Branch.
Branch# tclsh
foreach address {
209.165.200.241
209.165.202.129
209.165.200.226
} { ping $address source 192.168.1.1}
Packet sent with a source address of 192.168.1.1
.....
.....
.....
Branch(tcl)#
Paso 2: Configure NAT en los routers Branch y HQ.
Las direcciones privadas de la LAN serán traducidas a direcciones IP públicas globales usando NAT. El ISP
proveerá a los sitios HQ y Branch con los siguientes pool de direccionamiento público:
• HQ: 209.165.200.233 – 209.165.200.238 (209.165.200.232/29)
• Branch: 209.165.200.249 – 209.165.200.254 (209.165.200.248/29)
El sitio HQ también tiene un servidor email que debe ser accesible a usuarios móviles y usuarios de Branch.
Por lo tanto, NAT estático también debe ser configurado para usar un direccionamiento público para alcanzar
el servidor de email.
a. El pool NAT identifica direcciones IP pública, mientras la ACL NAT identifica cuales hosts internos
pueden usar estas direcciones IP públicas. Para el router Branch, esto significa que la ACL NAT debe
identificar la LAN 192.168.1.0, y el pool NAT debe identificar direcciones 209.165.200.248 /29. La
interfaz LAN debe ser identificada como una interfaz NAT interna, y la interfaz Internet debe ser
identificada como una interfaz NAT externa.
Nota: La ACL NAT no debe traducir las direcciones de la LAN de Branch si ellas son destinadas a la LAN
corporativa de HQ. Por lo tanto, la ACL NAT deniega las direcciones públicas de la LAN de Branch de
ser traducidas cuando están intentando conectarse a las LANs de HQ. Esto será requerido cuando la
VPN IPsec sea configurada.
Branch Router
ip access-list extended BRANCH-NAT-ACL
remark Do not translate Local LAN to HQ LAN addresses
deny ip 192.168.1.0 0.0.0.255 10.10.0.0 0.0.255.255
remark Translate Local LAN to all other Internet destinations
permit ip 192.168.1.0 0.0.0.255 any

CCNPv6 ROUTE
exit
!
ip nat pool BRANCH-NAT-POOL 209.165.200.249 209.165.200.254 prefix-length 29
!
ip nat inside source list BRANCH-NAT-ACL pool BRANCH-NAT-POOL
!
interface Loopback 1
ip nat inside
exit
!
ip nat outside
end
b. En el router HQ, la ACL NAT debe identificar las LANS 10.10.10.0 y 10.10.20.0. El pool NAT pool debe
identificar las direcciones 209.165.200.232 /29. La interfaz LAN debe ser identificada como una interfaz
NAT interna, y la interfaz Internet debe ser identificada como una interfaz NAT externa.
El servidor email con dirección IP privada 10.10.20.238 será asignada estáticamente a la última dirección
IP pública del pool NAT, 209.165.200.238. La interfaz loopback 0 en HQ simula este servidor.
Nota: De Nuevo la ACL NAT deniega las direcciones públicas de LAN HQ de ser traducidas cuando
están intentando conectar a la LAN de Branch la cual será requerida cuando la VPN IPsec es
configurada.
HQ Router
description direccion del servidor email de HQ
ip add 10.10.20.238 255.255.255.0
!
ip nat pool HQ-NAT-POOL 209.165.200.233 209.165.200.237 prefix-length 29
ip nat inside source list HQ-NAT-ACL pool HQ-NAT-POOL
ip nat inside source static 10.10.20.238 209.165.200.238
!
ip access-list extended HQ-NAT-ACL
remark No traduce HQ LAN a direcciones Branch LAN
deny ip 10.10.0.0 0.0.255.255 192.168.1.0 0.0.0.255
remark Traduce Local LAN a todos los otros destinos de Internet
permit ip 10.10.0.0 0.0.255.255 any
exit
!
ip nat inside
!
ip nat inside
!
ip nat outside
end
c. Verifica configuración NAT usando los comandos show ip nat statistics y show ip nat translations.
Branch# show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Peak translations: 0, occurred 00:018:28 ago
Outside interfaces:
Serial0/0/1
Inside interfaces:

CCNPv6 ROUTE
Loopback1
Hits: 0 Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list BRANCH-NAT-ACL pool BRANCH-NAT-POOL refcount 0
pool BRANCH-NAT-POOL: netmask 255.255.255.248
start 209.165.200.249 end 209.165.200.254
type generic, total addresses 6, allocated 0 (0%), misses 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0
La salida del comando show ip nat translations confirma que no hay traducciones NAT:
Branch# show ip nat translations
d. Inicia tráfico NAT con un ping a ISP.
Branch# tclsh
foreach address {
209.165.200.241
209.165.202.129
209.165.200.226
209.165.200.238
} { ping $address source 192.168.1.1}
!!!!!
!!!!!
!!!!!
!!!!!
Branch(tcl)#
e. Verifica que NAT está ocurriendo usando los comandos show ip nat statistics y show ip nat
translations.
Branch# show ip nat statistics
Total active translations: 5 (0 static, 5 dynamic; 4 extended)
Peak translations: 5, occurred 00:00:12 ago
Outside interfaces:

CCNPv6 ROUTE
Serial0/0/1
Inside interfaces:
Loopback1
Hits: 40 Misses: 0
CEF Translated packets: 20, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list BRANCH-NAT-ACL pool BRANCH-NAT-POOL refcount 5
pool BRANCH-NAT-POOL: netmask 255.255.255.248
start 209.165.200.249 end 209.165.200.254
type generic, total addresses 6, allocated 1 (16%), misses 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0
Branch#
Pro Inside global Inside local Outside local Outside global
icmp 209.165.200.249:9 192.168.1.1:9 209.165.200.241:9 209.165.200.241:9
icmp 209.165.200.249:10 192.168.1.1:10 209.165.202.129:10 209.165.202.129:10
icmp 209.165.200.249:11 192.168.1.1:11 209.165.200.226:11 209.165.200.226:11
icmp 209.165.200.249:12 192.168.1.1:12 209.165.200.238:12 209.165.200.238:12
--- 209.165.200.249 192.168.1.1 --- ---
Branch#
La dirección 192.168.1.1 será traducida a la IP pública 209.165.200.249.
f. Limpia la traducción NAT, verifica conectividad y verifica traducciones NAT.
Branch# clear ip nat translation *
Branch#
Branch# ping 10.10.10.1 source 192.168.1.1
.....
Branch#
Como se esperaba, el tráfico de LAN Branch yendo a la LAN de HQ no es traducida por NAT.
Tráfico originado en la LAN de Branch yendo a la Internet es traducido, mientras el tráfico originado en la
LAN de Branch a la LAN de HQ no es traducida. Sin embargo, este tráfico debería ser protegido cuando
atraviesa la Internet pública. Para resolver este problema, una VPN IPsec sera configurada después.
Paso 3: Implementa una VPN IPsec entre los sitios Branch y HQ.
Una VPN IPsec puede asegurar y proteger todo el tráfico IP unicast dentro de ella. IPsec no puede reenviar
tráfico multicast o broadcast, lo cual significa que no puede soportar un protocolo de gateway interior como
EIGRP y OSPF.
Para este lab, asume que el equipo de seguridad de la red a provisto una configuración VPN IPsec básica
con la cual probar tu diseño de red.

CCNPv6 ROUTE
• La política ISAKMP identifica los parámetros se seguridad específicos para el intercambio de clave
inicial.
• Los detalles IPsec definen cómo los paquetes IP son encapsulados.
• La información de túnel VPN es identificada en una crypto map nombrada, la cual combina las
políticas ISAKMP, detalle de paquete IPsec, las direcciones par, y la crypto ACL.
• La crypto ACL identifica el tráfico que gatillará el túnel para activarlo. Este componente, a veces,
debe ser ajustado cuando es implementado junto con otros servicios como NAT y GRE.
• La crypto map es entonces aplicada a la interfaz túnel.
Branch Router
crypto isakmp policy 1
encryption aes
authentication pre-share
group 2
crypto isakmp key cisco123 address 209.165.200.226
!
crypto ipsec transform-set HQ-VPN esp-3des esp-sha-hmac
!
crypto map HQ-MAP 10 ipsec-isakmp
set peer 209.165.200.226
set transform-set HQ-VPN
match address HQ-VPN-ACL
!
ip access-list extended HQ-VPN-ACL
remark Branch to HQ traffic to trigger VPN
permit ip 192.168.1.0 0.0.0.255 10.10.0.0 0.0.255.255
!

CCNPv6 ROUTE
crypto map HQ-MAP
end
HQ Router
crypto isakmp policy 1
encryption aes
authentication pre-share
group 2
crypto isakmp key cisco123 address 209.165.200.242
!
crypto ipsec transform-set Branch-VPN esp-3des esp-sha-hmac
!
crypto map Branch-MAP 10 ipsec-isakmp
set peer 209.165.200.242
set transform-set Branch-VPN
match address Branch-VPN-ACL
!
ip access-list extended Branch-VPN-ACL
remark HQ to Branch traffic to trigger VPN
permit ip 10.10.0.0 0.0.255.255 192.168.1.0 0.0.0.255
!
crypto map Branch-MAP
end
Nota que las crypto ACLs son referenciadas a las direcciones IP públicas y no a las direcciones IP
privadas. Esto es debido a que el crypto map aplica al tráfico después de que NAT realmente haya
tomado lugar. Otra alternativa sería la de eximir el tráfico site-to-site del pool de traducciones NAT y tener
el disparador crypto ACLs basado en direcciones privadas en lugar del pool de direcciones públicas.
a. Usa el comando show crypto session detail en el router Branch para verificar la configuración
complete de la VPN IPsec.
Branch# show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Serial0/0/1
Session status: DOWN
Peer: 209.165.200.226 port 500 fvrf: (none) ivrf: (none)
Desc: (none)
Phase1_id: (none)
IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 10.10.0.0/255.255.0.0
Active SAs: 0, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0
Branch#
El túnel está caído debido a que el tráfico identificado en el IPSEC FLOW aún no ha sido procesado.

CCNPv6 ROUTE
b. Para probar el enlace VPN, usa el siguiente ping.
.!!!!
Branch#
Esta vez el 80% de los pings fueron exitosos. Esto es típico debido a que el túnel VPN requiere algunos
segundos para negociar los parámetros de seguridad especificadas en el crypto map.
c. Muestra los detalles del túnel VPN de nuevo.
Uptime: 00:00:10
Session status: UP-ACTIVE
Phase1_id: 209.165.200.226
Desc: (none)
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Active
Capabilities:(none) connid:1001 lifetime:23:59:49
Branch#
El túnel VPN se activó como el estado de la sesión UP-ACTIVE lo indica. También nota que la
declaración permit está referenciando a la dirección privada definida en la crypto ACL y que encripta y
desencripta cuatro paquetes, con sólo un paquetes descartado (drop), debido a la negociación IPsec.
d. Antes de proceder, deshabilita manualmente el túnel VPN IPsec VPN usando los comandos clear crypto
isakmp y clear crypto sa en el router Branch.
Branch# clear crypto isakmp
Branch# clear crypto sa
Branch#
Ahora tienes conectividad encriptada desde la LAN de Branch a la LAN de HQ. el problema con una
VPN IPsec es que no permite operar protocolos de enrutamiento dinámico sobre ella. Sin embargo, GRE
puede ayudar a solucionar este problema.

CCNPv6 ROUTE
Paso 4: Implementa GRE sobre IPsec.
Un túnel GRE sobre IPsec puede ser implementado entre los sitios de Branch y HQ. El túnel protegerá todo
el tráfico corporativo LAN. Como un agregado, GRE puede reenviar tráfico multicast y broadcast, por lo tanto
enrutamiento dinámico también puede ser habilitado.
a. Configura las interfaces túnel en los routers Branch y HQ con encapsulamiento GRE.
Branch Router
interface Tunnel0
ip address 172.16.100.2 255.255.255.252
tunnel source 209.165.200.242
tunnel destination 209.165.200.226
HQ Router
interface Tunnel0
ip address 172.16.100.1 255.255.255.252
tunnel source 209.165.200.226
tunnel destination 209.165.200.242
El estado de la interfaz túnel se active en ambos routers.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
b. Verifica el estado de la interfaz túnel con el comando show interface tunnel 0.
Branch# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.100.2/30
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 209.165.200.242, destination 209.165.200.226
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
También nota que el encapsulamiento y protocolo de transporte túnel es GRE/IP.
c. Verifica conectividad a través del túnel.
Branch# ping 172.16.100.1
!!!!!
d. Los pings exitosamente alcanzan el otro lado del túnel. Pero, el tráfico está siendo encriptado?

CCNPv6 ROUTE
Session status: DOWN-NEGOTIATING
Desc: (none)
Phase1_id: (none)
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Inactive
Capabilities:(none) connid:1001 lifetime:0
Branch#
La VPN IPsec está caída debido a que el tráfico túnel no ha sido identificado con la crypto ACL.
e. Para resolver este problema, reemplaza la crypto ACL para hacer el tráfico GRE interesante en los
routers Branch y HQ.
Branch Router
no ip access-list extended HQ-VPN-ACL
ip access-list extended HQ-VPN-ACL
remark HQ to Branch GRE traffic to trigger VPN
permit gre host 209.165.200.242 host 209.165.200.226
HQ Router
no ip access-list extended Branch-VPN-ACL
ip access-list extended Branch-VPN-ACL
remark Branch to HQ GRE traffic to trigger VPN
permit gre host 209.165.200.226 host 209.165.200.242
f. Prueba de nuevo. Nota que el 80% es exitoso.
Branch# ping 172.16.100.1
.!!!!
g. Muestra detalles de la sesión IPsec.
Uptime: 00:00:05
Phase1_id: 209.165.200.226
Desc: (none)
IPSEC FLOW: permit 47 host 209.165.200.242 host 209.165.200.226

CCNPv6 ROUTE
El túnel IPsec está ahora arriba y activo. El “permit 47” identifica el tráfico GRE como interesante. El valor
47 se refiere al número de protocolo GRE.
h. Ping de LAN a LAN.
.....
Branch#
Los pings son exitosos. El router Branch tiene una entrada a la red 10.10.10.0?
i. Verifica la tabla de enrutamiento.
Branch# show ip route
<output omitted>
Gateway of last resort is 209.165.200.241 to network 0.0.0.0
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.100.0 is directly connected, Tunnel0
C 209.165.200.240 is directly connected, Serial0/0/1
C 192.168.1.0/24 is directly connected, Loopback1
S* 0.0.0.0/0 [1/0] via 209.165.200.241
Branch#
Los pings no son exitosos, debido a que no hay una ruta específica a la otra LAN. El tráfico es finalmente
ruteado usando la ruta por defecto, la cual bypasea el túnel GRE. El router Branch y el router HQ router
deben ser configurados para compartir cada una la información LAN de la otra.
Esto se debería cumplir usando rutas estáticas apuntando a la dirección IP destino del túnel GRE.
Aunque esto es una opción válida, túneles GRE también soportan tráfico multicast y broadcast. Por lo
tanto, un protocolo de enrutamiento dinámico debería ser configurado.
j. Configure EIGRP, y advierta las LANs y el segmento túnel en los routers Branch y HQ.
Branch Router
router eigrp 1
network 192.168.1.0 0.0.0.255
network 172.16.100.0 0.0.0.3
HQ Router
router eigrp 1
network 10.10.0.0 0.0.255.255
network 172.16.100.0 0.0.0.3
Un mensaje de adyacencia de vecindad EIGRP debería aparecer de inmediato.
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.100.2 (Tunnel0) is up: new
adjacency

CCNPv6 ROUTE
k. Verifica la tabla de enrutamiento.
Branch# show ip route
<output omitted>
Gateway of last resort is 209.165.200.241 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:00:22, Null0
C 172.16.100.0/30 is directly connected, Tunnel0
C 209.165.200.240 is directly connected, Serial0/0/1
D 10.0.0.0/8 [90/27008000] via 172.16.100.1, 00:00:10, Tunnel0
C 192.168.1.0/24 is directly connected, Loopback1
S* 0.0.0.0/0 [1/0] via 209.165.200.241
l. Muestra detalles de la sesión IPsec.
Uptime: 00:02:36
Phase1_id: 209.165.200.226
Desc: (none)
m. Prueba la conectividad de LAN-a-LAN y muestra detalles de la sesión IPsec.
!!!!!
Uptime: 00:03:15

CCNPv6 ROUTE
Phase1_id: 209.165.200.226
Desc: (none)
Los pings son exitosos, pero nota que los contadores de paquetes han incrementado por más de 5
paquetes ping. La razón es debido a que EIGRP también intercambia paquetes hello y por lo tanto
incrementa los contadores.
n. Traza la ruta que siguen los paquetes desde la LAN de Branch LAN al servidor de email usando la
dirección IP privada.
Branch# trace 10.10.20.238 source 192.168.1.1
Tracing the route to 10.10.20.238
1 172.16.100.1 68 msec 68 msec *
Nota que los paquetes saltan solo al extreme del túnel. No es consciente de que atraviesa la Internet
pública.
o. Para probar que aún hay acceso a la Internet sin ir a través del túnel GRE, traza la ruta desde la LAN de
Branch al servidor de email, usando la dirección NAT estática externa.
Branch# trace 209.165.200.238 source 192.168.1.1
Tracing the route to 209.165.200.238
1 209.165.200.241 12 msec 12 msec 16 msec
2 209.165.200.238 28 msec 28 msec *
Los paquetes ahora saltan al router ISP y entonces al router HQ. En esencia, esto demuestra que el
tráfico con destino a la Internet no se cifra.

Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la oficina sucursal

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la oficina sucursal

Similar a Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la oficina sucursal (20)

Más de Andy Juan Sarango Veliz

Más de Andy Juan Sarango Veliz (20)

Último

Último (20)

Capítulo 7 Lab 7-1, Configure Enrutamiento en instalaciones a la oficina sucursal