Guardar running-config en un servidor externo

Muchas veces tenemos la necesidad de hacer una copia de la configuración para guardarla en un lugar seguro.

En este breve ejemplo vamos a aprovechar algunos features del IOS 12.3 para:

1. Al momento de grabar la configuración, que se copie automáticamente en un servidor externo.
2. Que se guarde la configuración todos los días a una hora en particular.

Dado que esto es un tip como para -copiar y pegar- voy directamente al grano:

Para guardar una copia de la config en un servidor FTP al momneto de hacer copy running-config startup-config pegamos los siguientes comandos en el modo de configuración global (conf t):

archive
path ftp://usuario:[email protected]/$h-$t
write-memory

Las variables $h y $t representan el hostname y la hora, por ejemplo quedarían archivos llamados

Router-Mar--4-00:05:40.732-UTC

Ahora vamos a hacer que la config y sus respectivos backups se graben todos los dias a las 00:05:

kron occurrence daily-config-backup at 0:05 recurring
policy-list backup-config
!
kron policy-list backup-config
cli write memory
!

Espero que les sea de utilidad.

Saludos

Trucos para el enrutamiento estático

El enrutamiento estático puede ser una solución muy conveniente para cuando la cantidad de nodos en nuestra red no es tan amplia como para que valga la pena un protocolo dinámico. Pero puede transformarse en un verdadero dolor de cabeza en caso de que no tengamos en cuenta determinadas pautas.

Veamos el siguiente diagrama:

Supongamos que en esta red WAN todos los vínculos entre equipos son del mismo ancho de banda y tienen la misma tasa de error y confiabilidad.

Si tomamos el ejemplo de una comunicación entre Córdoba y Buenos Aires sería prudente realizar enrutamiento estático de tal forma que se balancee la carga entre los tres enlaces que están directamente conectados a ellos. De esta forma, en principio (sin tener en cuenta CEF y otras pautas) podemos decir que cuando sale un paquete desde Córdoba siempre irá por un camino distinto al anterior.

Por ejemplo los paquetes con numeración:

1. Sale por Tucumán.
2. Sale por Rosario.
3. Sale por La Plata.
4. Sale por Tucumán.
5. Sale por Rosario.
6. Sale por La Plata.
7. [...]

Ahora,  supongamos que se cae el enlace entre Rosario y BsAs, Córdoba no se va a enterar porque no está directamente conectado y no hay un protocolo de enrutamiento que nos avise del fallo. Entonces se seguirá enviando tráfico a Rosario y este último lo descartará por tener el enlace caído.

Por esto podemos decir que 1/3 del tráfico que Córdoba envíe hacia BsAs se va a perder. Esto trae muchos problemas a la red y sus aplicaciones.

Afortunadamente contamos con algunas herramientas para lidiar con este tipo de problema:

La que utilizaremos en este caso se llama IP SLA, y está disponible desde la versión 12.3T de IOS.

La idea es que Córdoba va a estar todo el tiempo tirando un proceso ping a Buenos Aires a través de cada una de las interfases.

Dicho proceso será vinculado a una ruta estática, y por ende cuando un proceso falle se retira la ruta de la tabla automágicamente. A esto se llama 'hacer tracking' a un objeto.

Veamos en principio la configuración de Cordoba  y Buenos Aires:

Router CORDOBA:

interface FastEthernet0/0
description Enlace a Tucuman
ip address 192.168.7.2 255.255.255.252
!
interface FastEthernet0/1
description Enlace a Rosario
ip address 192.168.7.10 255.255.255.252
!
interface FastEthernet1/0
description Enlace a La Plata
ip address 192.168.7.18 255.255.255.252
!
interface FastEthernet1/1
description LAN
ip address 192.168.7.33 255.255.255.224
!
ip route 192.168.7.4 255.255.255.252 192.168.7.1 name TUCUMAN-BAIRES
ip route 192.168.7.12 255.255.255.252 192.168.7.9 name ROSARIO-BAIRES
ip route 192.168.7.20 255.255.255.252 192.168.7.17 name LAPLATA-BAIRES
ip route 0.0.0.0 0.0.0.0 192.168.7.1 name viaTUCUMAN
ip route 0.0.0.0 0.0.0.0 192.168.7.9 name viaROSARIO
ip route 0.0.0.0 0.0.0.0 192.168.7.17 name viaLAPLATA
!

Ahora vamos a configurar el IP SLA en CORDOBA para que detecte las caídas del servicio:

ip sla 1
icmp-echo 192.168.7.6 source-ip 192.168.7.2
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 192.168.7.14 source-ip 192.168.7.10
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 192.168.7.22 source-ip 192.168.7.18
ip sla schedule 3 life forever start-time now

Ahora vinculamos tres objetos track con el ID de IP SLA correspondiente:

track 1 rtr 1 reachability
track 2 rtr 2 reachability
track 3 rtr 3 reachability

Y luego configuramos las rutas estáticas para que sean dependientes de cada track que le corresponda:

ip route 0.0.0.0 0.0.0.0 192.168.7.1 name viaTUCUMAN track 1
ip route 0.0.0.0 0.0.0.0 192.168.7.9 name viaROSARIO track 2
ip route 0.0.0.0 0.0.0.0 192.168.7.17 name viaLAPLATA track 3

Ahora solo hay que dejar que el IP SLA haga su trabajo sacando las rutas estáticas cuando el vecino no sea alcanzable. Obviamente en cualquier momento podemos verificar la configuración:

CORDOBA#show track
Track 1
Response Time Reporter 1 reachability
Reachability is Up
12 changes, last change 10w1d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0
Track 2
Response Time Reporter 2 reachability
Reachability is Up
6 changes, last change 15w4d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0
Track 3
Response Time Reporter 3 reachability
Reachability is Up
38 changes, last change 1w2d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0

También podemos verificar los niveles de SLA que nos dan nuestros proveedores:

CORDOBA#show ip sla statistics details  

Round Trip Time (RTT) for       Index 1
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 40
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Round Trip Time (RTT) for       Index 2
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 35
Number of failures: 5
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Round Trip Time (RTT) for       Index 3
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 38
Number of failures: 2
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Con esta configuración básica podemos ver que el proveedor de WAN que mejor servicio nos da es el correspondiente al SLA 1 (Index 1), que es el que nos provee el enlace contra Tucumán.

La configuración de IP SLA en IOS puede ser tremendamente compleja, y puede permitirnos incluso dejar scripts de configuración que se accionan en caso de algún evento preconfigurado.

Podemos no solamente hacer ping, sino realizar consultas HTTP, DNS y varios más para determinar que el servicio monitoreado está andando bien.

Esta es la config más básica, pero creo que les va a ser muy útil en sus redes.

Hasta el próximo post.

Limitar tamaño del AS-PATH en BGP

Tal cual como expliqué en este post, hace un par de semanas se descubrió un bug de BGP que trajo problemas en internet a nivel mundial.

En este nuevo post vamos a ver como podríamos prevenir de que nos pase (de nuevo) el mismo problema.

Como siempre, Cisco tenía en su IOS un feature que no acepta updates que contengan un AS-PATH más largo que el valor configurado, pero evidentemente nadie lo usaba. Hoy vamos a aprender a usarlo:

Tengamos en cuenta el siguiente caso:

Obviamente estamos analizando un caso simplificado y no representa el backbone de internet de ninguna forma.

Resulta que BuenosAires tiene dos redes para publicar:

• 192.168.100.0/24
• 192.168.50.0/24

El administrador novato que trabaja en este sistema autónomo decide que quiere hacer más largo el AS-PATH de la red 192.168.50.0/24 para que el tráfico llegue por otro enlace (que no está dibujado) distinto del que lo vincula con el Router Rosario.

Veamos las configuraciones iniciales de los equipos:

BuenosAires:

!
interface Loopback0
description Red para publicar
ip address 192.168.100.1 255.255.255.0
!
interface Loopback1
description Red para publicar con AS-PATH largo
ip address 192.168.50.1 255.255.255.0
!
interface Serial1/0
description Enlace a Rosario
ip address 192.168.1.1 255.255.255.252
serial restart-delay 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 192.168.50.0
network 192.168.100.0
neighbor 192.168.1.2 remote-as 200
neighbor 192.168.1.2 description Rosario
neighbor 192.168.1.2 password 100200
neighbor 192.168.1.2 version 4
neighbor 192.168.1.2 soft-reconfiguration inbound
 neighbor 192.168.1.2 route-map Cambiar-ASPATH-a-10 out
no auto-summary
!
access-list 10 permit 192.168.50.0 0.0.0.255
!
route-map Cambiar-ASPATH-a-10 permit 10
match ip address 10
set as-path prepend 100 100 100 100 100 100 100 100 100 100
!
route-map Cambiar-ASPATH-a-10 permit 20
!

Rosario:

!
interface Serial1/0
description Enlace a BuenosAires
ip address 192.168.1.2 255.255.255.252
serial restart-delay 0
!
interface Serial1/1
description Enlace a Cordoba
ip address 192.168.1.5 255.255.255.252
serial restart-delay 0
!
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.1.1 description Peering con BuenosAires
neighbor 192.168.1.1 password 100200
neighbor 192.168.1.1 version 4
neighbor 192.168.1.1 soft-reconfiguration inbound
neighbor 192.168.1.6 remote-as 300
neighbor 192.168.1.6 description Peering con Cordoba
neighbor 192.168.1.6 password 200300
neighbor 192.168.1.6 version 4
neighbor 192.168.1.6 soft-reconfiguration inbound
no auto-summary
!

Cordoba

!
interface Serial1/0
description Enlace a Rosario
ip address 192.168.1.6 255.255.255.252
serial restart-delay 0
!
router bgp 300
no synchronization
bgp log-neighbor-changes
neighbor 192.168.1.5 remote-as 200
neighbor 192.168.1.5 description Rosario
neighbor 192.168.1.5 password 200300
neighbor 192.168.1.5 version 4
neighbor 192.168.1.5 soft-reconfiguration inbound
no auto-summary
!

Como vemos no hay nada extraño, salvo las configuraciones básicasde BGP  (sin filtrado de rutas) en cada equipo, salvo en BuenosAires donde aplicamos un Route-Map a las actualizaciones salientes para cambiar el AS-PATH de la red 192.168.50.0/24.

Ahora vamos a ver las tablas de enrutamiento y de BGP de todos los equipos.

BuenosAires:

BuenosAires#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.50.0/24 is directly connected, Loopback1
192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.0 is directly connected, Serial1/0
C    192.168.100.0/24 is directly connected, Loopback0

BuenosAires#show ip bgp
BGP table version is 3, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.50.0     0.0.0.0                  0         32768 i
*> 192.168.100.0    0.0.0.0                  0         32768 i

Rosario:

Rosario#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.50.0/24 [20/0] via 192.168.1.1, 00:02:00
192.168.1.0/30 is subnetted, 2 subnets
C       192.168.1.0 is directly connected, Serial1/0
C       192.168.1.4 is directly connected, Serial1/1
B    192.168.100.0/24 [20/0] via 192.168.1.1, 00:02:00

Rosario#show ip bgp
BGP table version is 3, local router ID is 192.168.1.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.50.0     192.168.1.1              0             0 100 100 100 100 100 100 100 100 100 100 100 i
*> 192.168.100.0    192.168.1.1              0             0 100 i

Cordoba:

Cordoba#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.50.0/24 [20/0] via 192.168.1.5, 00:02:43
192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.4 is directly connected, Serial1/0
B    192.168.100.0/24 [20/0] via 192.168.1.5, 00:02:43
Cordoba#
Cordoba#show ip bgp
BGP table version is 3, local router ID is 192.168.1.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.50.0     192.168.1.5                            0 200 100 100 100 100 100 100 100 100 100 100 100 i
*> 192.168.100.0    192.168.1.5                            0 200 100 i

Vemos que en Cordoba el AS-PATH tiene un largo importante, y si BuenosAires llegase a publicar rutas con un AS-PATH extremadamente largo se produciría el bug que vimos en el post anterior.

Aquí el administrador podría resolver esto de dos formas:

1. Configurar el comando global bgp maxas-limit.
2. Configurar un AS-PATH Access-List por cada peer que tenga.

Es evidente que la segunda opción es la más granular, pero no puede ser utilizada siempre porque puede implicar que se cambie la forma de filtrar rutas y establecer políticas. Además debe hacerse en cada vecino de BGP que tengamos, lo que puede resultar engorroso.

Vamos a configurar el maxas-limit en Rosario para ver que es lo que pasa:

Rosario#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rosario(config)#router bgp 200
Rosario(config-router)#bgp maxas-limit 5
Rosario(config-router)#end
Rosario#
*Mar 11 15:24:36.003: %BGP-6-ASPATH: Long AS path 100 100 100 100 100 100 100 100 100 100 100 received from 192.168.1.1: More than configured MAXAS-LIMIT

El proceso ha recortado la ruta de la tabla de BGP por exceder el largo de AS-PATH permitido en la configuración. Podemos ver los resultados de este comando:

BuenosAires:

BuenosAires#show ip bgp
BGP table version is 3, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.50.0     0.0.0.0                  0         32768 i
*> 192.168.100.0    0.0.0.0                  0         32768 i

Rosario:

Rosario#show ip bgp
BGP table version is 4, local router ID is 192.168.1.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.100.0    192.168.1.1              0             0 100 i

Cordoba:

Cordoba#show ip bgp
BGP table version is 4, local router ID is 192.168.1.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network       Next Hop     Metric LocPrf Weight Path
*> 192.168.100.0 192.168.1.50                      200 100 i

En Rosario tuvimos un aviso de que se descartó de la ruta, y por ende no se la anunció a Cordoba.

Con este sencillo comando podemos proteger nuestros equipos del desastre, hasta que el parche para el mismo sea liberado.

Espero que este post les haya servido.

Saludos!

On Demand Routing (ODR)

Ahora vamos a ver un protocolo de enrutamiento que es casi una curiosidad, no está muy difundido y no conozco que se tome en ninguna certificación.

Es más, solo lo vas a poder usar si:

• Todo tu equipamiento es Cisco.


• Usas CDP en tu toda red o bien sos muy vago como para desactivarlo.


• La topología lógica es Hub n' Spoke o estrella.


• Los equipos no tienen tanto CPU para lidiar con todo eso del protocolo híbrido, estado enlace o el Bellman-Ford.


• Te encantan los protocolos de enrutamiento no autenticados e inseguros.


• Tu religión no te permite un protocolo de enrutamiento con PDU de capa 3 y no querés aprender las simbologías extrañas del IS-IS integrado.


• Querés jugar o aprender un chiche nuevo para guardar en el maletín de soluciones.

Si todas o la mayoría de los ítems presentados anteriormente son afirmativos en tu caso, es hora de aprender ODR!.

Configuración de Switch de Frame Relay

Más de una vez me ha pasado que configuro un lab con GNS3 y tengo problemas con los switches de Frame Relay. Las configuraciones se me borran, o bien se cambian los números de DLCI y de puertos.

El problema pasa habitualmente al momento de cargar una topología guardada, por lo que busqué la solución a mis problemas configurando un router como para conmutar frame relay tal cual como hacíamos en la academia CCNA hace varios años atrás.

Nota: La configuración de un dispositivo Cisco como switch Frame Relay no se incluye dentro de los temas de estudio del exámen CCNA.

En este ejemplo vamos a configurar la siguiente topología:

Para el FR-SW en dynamips utilizamos un Cisco 7200 con varias interfaces serie (también se puede con los otros routers más chicos, incluso con un 1700).