Esta es un post muy corto.
Otro comando oculto en Cisco. No esta documentado pero tiene información valiosa
2801#show ip eigrp timers
IP-EIGRP timers for process 1111
Hello Process
Expiration Type
| 0.548 (parent)
| 0.548 Hello (FastEthernet0/0.21)
Update Process
Expiration Type
| 10.840 (parent)
| 10.840 (parent)
| 10.840 Peer holding
SIA Process
Expiration Type
| 0.000 (parent)
2801#
Mostrando entradas con la etiqueta cisco. Mostrar todas las entradas
Mostrando entradas con la etiqueta cisco. Mostrar todas las entradas
viernes, 19 de junio de 2009
viernes, 12 de junio de 2009
Policy Based Routing, HSRP y redundancia. Cisco
Necesidad
Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes por el Carrier B, sin embargo en caso de fallar algún proveedor funcione la redundancia.
En el caso descrito anteriormente no se puede utilizar un protocolo de enrutamiento dinámico porque se desea enrutar por dirección fuente. Por otro lado, si pueden existir otros modos de realizar esta tarea.
Escenario
2 Router Cisco 1841
2 Enlaces WAN
HSRP
Redes a enviar por el Carrier 1:
10.1.0.0 0.0.255.255
192.168.30.0 0.0.0.255
Redes a enviar por el Carrier 2:
10.144.192.0 0.0.15.255
Diagrama
Procedimiento
Lo primero que haremos es configurar la parte de HSRP. Para ello utilizaremos la siguiente configuración:
En RTR-1
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.207 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 priority 110
standby 1 preempt
standby 1 authentication CISCO
standby 1 track 1 decrement 20
En RTR-2
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.204 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 preempt
standby 1 authentication CISCO
Con la configuración anterior tendremos en RTR-1 el IP 10.1.1.207 y en RTR-2 el IP 10.1.1.204. El IP virtual es el 10.1.1.206
2) Indicarle a cada router como alcanzar la WAN del router contrario e indicarles las listas de acceso:
En RTR-1
ip route 10.0.0.1 255.255.255.255 10.1.1.204
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any
access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any
En RTR-2
ip route 172.16.100.225 255.255.255.255 10.1.1.207
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any
access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any
3) Es necesario habilitar SLA (Service Level Agreement) y tracks en los routers para mantener el monitoreo vía ping de los enlaces WAN en cada router. Esto es necesario para que a través de PBR los route-maps puedan tomar la decisión de por donde enrutar los paquetes.
En RTR-1
ip sla monitor 2
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now
ip sla monitor 3
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now
track 2 rtr 2 reachability
track 3 rtr 3 reachability
En RTR-2
ip sla monitor 2
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now
ip sla monitor 3
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now
track 2 rtr 2 reachability
track 3 rtr 3 reachability
En el ejemplo anterior, en ambos routers se estan monitoreando los IPs WAN vía ping con un timeout de 1000 ms, un umbral de 50 ms cada 3 segundos.
4) Configurar los route-maps en cada router
RTR-1
route-map CARRIER permit 5
match ip address 120
set ip next-hop verify-availability 172.16.100.225 10 track 2
set ip next-hop verify-availability 10.0.0.1 20 track 3
route-map CARRIER permit 10
match ip address 121
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 172.16.100.225 20 track 2
RTR-2
route-map CARRIER permit 5
match ip address 121
set ip next-hop verify-availability 10.0.0.1 10 track 2
set ip next-hop verify-availability 10.1.1.207 20 track 3
route-map CARRIER permit 10
match ip address 120
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 10.0.0.1 20 track 2
5) Finalmente es necesario aplicar el comando ip policy route-map en la interfaz f0/0 en cada router
#conf termin
(config)#inter f0/0
(config-if)#ip policy route-map CARRIER
Explicación
Ahora bien, vamos a intentar correr esto en frio:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER
4) En RTR-1, el route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.1.0.207
5) Lo recibe la interfaz f0/0 de RTR-1 quien nuevamente aplica la politica CARRIER y sabe que debe enviar el paquete por la interfaz F0/1 con next-hop 172.16.100.225
Ahora bien, vamos a intentar correr esto en frio con el enlace f0/1 caido en RTR-1:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER. El route-map sabe que no puede ser alcanzado el IP 172.16.100.225 gracias a los comandos SLA previamente configurados (el router cada 3 segundos verifica si puede hacerle ping a este IP).
4) El route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.0.0.1
Verificacion
1) Traceroute desde las redes pertinentes
2) #show track 2
3) #show track 3
Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes por el Carrier B, sin embargo en caso de fallar algún proveedor funcione la redundancia.
En el caso descrito anteriormente no se puede utilizar un protocolo de enrutamiento dinámico porque se desea enrutar por dirección fuente. Por otro lado, si pueden existir otros modos de realizar esta tarea.
Escenario
2 Router Cisco 1841
2 Enlaces WAN
HSRP
Redes a enviar por el Carrier 1:
10.1.0.0 0.0.255.255
192.168.30.0 0.0.0.255
Redes a enviar por el Carrier 2:
10.144.192.0 0.0.15.255
Diagrama
Procedimiento
Lo primero que haremos es configurar la parte de HSRP. Para ello utilizaremos la siguiente configuración:
En RTR-1
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.207 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 priority 110
standby 1 preempt
standby 1 authentication CISCO
standby 1 track 1 decrement 20
En RTR-2
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.204 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 preempt
standby 1 authentication CISCO
Con la configuración anterior tendremos en RTR-1 el IP 10.1.1.207 y en RTR-2 el IP 10.1.1.204. El IP virtual es el 10.1.1.206
2) Indicarle a cada router como alcanzar la WAN del router contrario e indicarles las listas de acceso:
En RTR-1
ip route 10.0.0.1 255.255.255.255 10.1.1.204
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any
access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any
En RTR-2
ip route 172.16.100.225 255.255.255.255 10.1.1.207
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any
access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any
3) Es necesario habilitar SLA (Service Level Agreement) y tracks en los routers para mantener el monitoreo vía ping de los enlaces WAN en cada router. Esto es necesario para que a través de PBR los route-maps puedan tomar la decisión de por donde enrutar los paquetes.
En RTR-1
ip sla monitor 2
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now
ip sla monitor 3
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now
track 2 rtr 2 reachability
track 3 rtr 3 reachability
En RTR-2
ip sla monitor 2
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now
ip sla monitor 3
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now
track 2 rtr 2 reachability
track 3 rtr 3 reachability
En el ejemplo anterior, en ambos routers se estan monitoreando los IPs WAN vía ping con un timeout de 1000 ms, un umbral de 50 ms cada 3 segundos.
4) Configurar los route-maps en cada router
RTR-1
route-map CARRIER permit 5
match ip address 120
set ip next-hop verify-availability 172.16.100.225 10 track 2
set ip next-hop verify-availability 10.0.0.1 20 track 3
route-map CARRIER permit 10
match ip address 121
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 172.16.100.225 20 track 2
RTR-2
route-map CARRIER permit 5
match ip address 121
set ip next-hop verify-availability 10.0.0.1 10 track 2
set ip next-hop verify-availability 10.1.1.207 20 track 3
route-map CARRIER permit 10
match ip address 120
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 10.0.0.1 20 track 2
5) Finalmente es necesario aplicar el comando ip policy route-map en la interfaz f0/0 en cada router
#conf termin
(config)#inter f0/0
(config-if)#ip policy route-map CARRIER
Explicación
Ahora bien, vamos a intentar correr esto en frio:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER
4) En RTR-1, el route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.1.0.207
5) Lo recibe la interfaz f0/0 de RTR-1 quien nuevamente aplica la politica CARRIER y sabe que debe enviar el paquete por la interfaz F0/1 con next-hop 172.16.100.225
Ahora bien, vamos a intentar correr esto en frio con el enlace f0/1 caido en RTR-1:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER. El route-map sabe que no puede ser alcanzado el IP 172.16.100.225 gracias a los comandos SLA previamente configurados (el router cada 3 segundos verifica si puede hacerle ping a este IP).
4) El route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.0.0.1
Verificacion
1) Traceroute desde las redes pertinentes
2) #show track 2
3) #show track 3
NAT en Cisco. 2 ISPs diferentes
Necesidad:
Tener un enlace primario y un enlace secundario en un mismo router con dos proveedores a Internet diferentes.
Escenario(abajo la configuración detallada y explicada):
Router Cisco 1760 donde:
Interfaz Fastethernet0/0 LAN (IP 172.20.0.1)
Internaz Serial1/0.1 ISP Primario (IP 10.0.0.58)
Internaz Serial0/0.1 ISP Secundario (IP 10.1.1.58)
Diagrama:
Procedimiento:
Primero es necesario configurar unas rutinas en el router que se van a encargar de monitorear las interfaces WAN.
ip sla monitor 1 (deseo monitorar el next-hop del enlace del ISP primario)
type echo protocol ipIcmpEcho 10.0.0.57 source-interface Serial1/0.1
timeout 1000
threshold 400
frequency 3
ip sla monitor schedule 1 life forever start-time now (esta linea es para activar realmente el monitoreo)
ip sla monitor 2 (deseo monitorar el next-hop del enlace del ISP secundario)
type echo protocol ipIcmpEcho 10.1.1.57 source-interface Serial0/1.1
timeout 2000
threshold 1000
frequency 3
ip sla monitor schedule 2 life forever start-time now (esta linea es para activar realmente el monitoreo)
!
Con las lineas arribas indicadas lo que se hace es monitorear si el next hop en el enlace WAN esta levantado.
Por ejemplo en el primer caso se hace ping (ipIcmpEcho) al IP 10.0.0.57, con un timeout de 2000 ms, un umbral de 1000 ms cada 3 segundos.
Posteriormente es necesario habilitar los comandos track en Cisco. Estos son muy utiles para conocer luego el estado de los SLA previamente configurados. Los comandos son:
track 123 rtr 1 reachability
delay down 15 up 10
!
track 345 rtr 2 reachability
delay down 15 up 10
!
El truco se encuentra en el NAT (tanto asi que lo anterior se puede hacer con rutas flotantes, sin embargo de la manera implementada es la mejor practica).
El NAT debe ser realizado en base a route-maps (no lo intentes de otra manera). Las lineas que personalmente utilice fueron:
ip nat pool POOL-MINAT 200.30.30.30 200.30.30.30 prefix-length 29
ip nat inside source route-map ISP-1 pool POOL-MINAT overload
ip nat inside source route-map ISP-2 interface Serial0/1.1 overload
access-list 150 remark PARA-NAT
access-list 150 permit ip 172.20.0.0 0.0.0.255 any
route-map ISP-1 permit 5
match ip address 150
match interface Serial1/0.1
!
route-map ISP-2 permit 5
match ip address 150
match interface Serial0/1.1
En el ejemplo anterior vemos que el NAT es en base a los route-maps ISP-1 e ISP-2, el ACL a utilizar es el 150 extendido donde estamos nateando toda la red 172.20.0.0/24
Cuando los paquetes salgan por el ISP-1 saldran nateados con el IP 200.30.30.30 y cuando salgan con el ISP-2 saldran con el IP de la interfaz WAN. Logicamente puedes ajustar esto a tu necesidad.
Ahora bien, la ruta de los paquetes de salida son definidas con la siguiente configuracion:
ip route 0.0.0.0 0.0.0.0 Serial1/0.1 track 123
ip route 0.0.0.0 0.0.0.0 Serial0/1.1 track 345
La ruta por default es la interfaz s1/0.1 cuando el IP 10.0.0.57 se encuentre UP, en caso de que se caiga la interfaz y/o el ping al IP 10.0.0.57 NO sea satisfactorio se utilizara la ruta por la interfaz S0/1.1 (enlace secundario)
Verificacion:
1760-WAN#sh track 123
Track 123
Response Time Reporter 1 reachability
Reachability is Up
33 changes, last change 08:27:17
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 11
1760-WAN#sh track 345
Track 345
Response Time Reporter 2 reachability
Reachability is Up
36 changes, last change 3d01h
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 8
1760-WAN
#sh ip nat t
[OUTPUT SUPRESSED]
Links de informacion:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080950834.shtml
y
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml
martes, 12 de mayo de 2009
Calidad de servicio en Asterisk. VoIP
Buenas,
En estos dias necesitaba implementar Calidad de Servicio en una red de VoIP y quería asegurar que la misma fuese óptima.
En este sentido, primero voy a mencionar unos pocos detalles que hay que considerar:
* Tener SIEMPRE redes separadas de Voz y de Datos. Es decir, colocar datos en una VLAN y Voz en otra VLAN. Para ello se recomienda tener LAN Switchs administrables. La experiencia me indica que enseguida se mezclan los paquetes de Voz y Datos, la voz se deteriora inmediatamente.
* Tener teléfonos de calidad. Yo siempre utilizo Polycom y Cisco, sin embargo, SNOM y Linksys son muy buenos. No recomiendo Grandstream
* En enlaces WAN manejar siempre QoS. Cisco tiene muchas maneras de realizar esto. Posteriormente en otro post colocaré una configuración ejemplo de QoS con Cisco sobre Frame Relay.
Ahora bien, en el Asterisk te recomiendo el siguiente extracto de código en /etc/sip.conf:
tos_sip=cs3 ; Sets TOS for SIP packets.
tos_audio=ef ; Sets TOS for RTP audio packets.
y en el teléfono Polycom (en el archivo sip.conf) colocar el siguiente extracto de código
Luego de ello pudieses utilizar wireshark o tcpdump y ver como quedan marcados los paquetes salientes del Asterisk y del Polycom. Revisa el campo DSCP en el datagrama IP.
Suerte!
Traido gracias a http://www.fenixone.com
En estos dias necesitaba implementar Calidad de Servicio en una red de VoIP y quería asegurar que la misma fuese óptima.
En este sentido, primero voy a mencionar unos pocos detalles que hay que considerar:
* Tener SIEMPRE redes separadas de Voz y de Datos. Es decir, colocar datos en una VLAN y Voz en otra VLAN. Para ello se recomienda tener LAN Switchs administrables. La experiencia me indica que enseguida se mezclan los paquetes de Voz y Datos, la voz se deteriora inmediatamente.
* Tener teléfonos de calidad. Yo siempre utilizo Polycom y Cisco, sin embargo, SNOM y Linksys son muy buenos. No recomiendo Grandstream
* En enlaces WAN manejar siempre QoS. Cisco tiene muchas maneras de realizar esto. Posteriormente en otro post colocaré una configuración ejemplo de QoS con Cisco sobre Frame Relay.
Ahora bien, en el Asterisk te recomiendo el siguiente extracto de código en /etc/sip.conf:
tos_sip=cs3 ; Sets TOS for SIP packets.
tos_audio=ef ; Sets TOS for RTP audio packets.
y en el teléfono Polycom (en el archivo sip.conf) colocar el siguiente extracto de código
Luego de ello pudieses utilizar wireshark o tcpdump y ver como quedan marcados los paquetes salientes del Asterisk y del Polycom. Revisa el campo DSCP en el datagrama IP.
Suerte!
Traido gracias a http://www.fenixone.com
sábado, 2 de mayo de 2009
Crear un tunel IPv6 in IPv4 entre Cisco y Linux
Tengo la fortuna de trabajar para un ISP con IPv6 implementado. Voy a explicar el procedimiento para levantar un tunel IPv4 para pasar paquetes IPv6 entre un router Cisco y un PC con Linux.
Topologia:
PC Linux (2820:26:11::/64) ------ RED IPv4 (ISP) ----- Cisco router (Ipv4 e IPv6) ---- RED IPv6
Comenzaremos configurando el Cisco:
Es necesario crear una interfaz tunnel similar a la siguiente:
interface Tunnel0
description Tunel hacia mi casa
no ip address
ipv6 address 2820:26:10::1/64
ipv6 enable
tunnel source 210.57.51.107
tunnel destination 211.28.235.85
tunnel mode ipv6ip
end
ipv6 route 2820:26:11::/64 Tunnel0
Explicacion:
En la configuracion anterior se aprecia que hay que indicarle la direccion IPv4 fuente, la direccion IPv6 destino y una direccion IPv6 al tunel. El modo del tunel es lo mas importante el cual indica que son paquetes ipv6 en ipv4. Recordemos que Cisco soporta muchos tipos de tunel y recomiendo ser explicito. Adicionalmente el modo del tunel concuerda con el tipo de tunel que vamos a utilizar en Linux (modo sit). Notese que la direccion IPv4 origen del tunel puede ser cualquier IPv4 configurado en el router (una loopback, otra interfaz, etc).
Por ultimo, el comando ipv6 route indica la red que va a manejarse del lado del linux. Muy importante para que exista conectividad y enrutamiento dentro del tunel.
A configurar el linux:
Del lado del Linux es mas facil de lo que uno esperaria. Estos son los comandos utilizados por mi persona:
ifconfig eth0 add 2820:26:11::1/64
ifconfig sit0 tunnel ::210.147.51.107
ifconfig sit1 up
route -A inet6 add ::0/ dev sit1
ping6 2820:26:10::1
Explicacion:
El primer comando le indica la red IPv6 a la interfaz eth0.
El segundo comando indica la interfaz sit (modo ipv6 en ipv4) y el IPv4 donde va a terminar el tunel. El comando route indica la ruta por defecto para que sea enviado por la interfaz sit 1.
Luego de esto, estamos listos para probar la conexion. Primero, vamos a ubicarnos del lado del Linux:
Lo primero es realizar un ping al IPv6 del tunel
[root@localhost ~]# ping6 2800:26:10::1 -c 4
PING 2800:26:10::1(2800:26:10::1) 56 data bytes
64 bytes from 2820:26:10::1: icmp_seq=1 ttl=64 time=153 ms
64 bytes from 2820:26:10::1: icmp_seq=2 ttl=64 time=154 ms
64 bytes from 2820:26:10::1: icmp_seq=3 ttl=64 time=153 ms
64 bytes from 2820:26:10::1: icmp_seq=4 ttl=64 time=152 ms
Luego un ping6 a ipv6.google.com:
[root@localhost ~]# ping6 ipv6.google.com -c 4
PING ipv6.google.com(qw-in-x68.google.com) 56 data bytes
64 bytes from qw-in-x68.google.com: icmp_seq=1 ttl=55 time=232 ms
64 bytes from qw-in-x68.google.com: icmp_seq=2 ttl=55 time=229 ms
64 bytes from qw-in-x68.google.com: icmp_seq=3 ttl=55 time=230 ms
64 bytes from qw-in-x68.google.com: icmp_seq=4 ttl=55 time=231 ms
Tambien recomiendo hacer traceroute y el primer salto que veras es el IPv6 del Cisco.
Ahora bien, del lado del Cisco podemos ver la cantidad de paquetes que han transitado por la interfaz tunel y comprobar el incrementos de paquetes:
#sh int tunne0
Linkstar_PBR#sh int tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Tunel a mi casa
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 210.147.51.107, destination 211.28.235.85
Tunnel protocol/transport IPv6/IP
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:07, output 00:00:06, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
19 packets input, 2736 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
51 packets output, 5540 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
En otra oportunidad indicare como hacer que toda tu red navegue en IPv6 dentro del Tunel.
Suerte y exitos,
Topologia:
PC Linux (2820:26:11::/64) ------ RED IPv4 (ISP) ----- Cisco router (Ipv4 e IPv6) ---- RED IPv6
Comenzaremos configurando el Cisco:
Es necesario crear una interfaz tunnel similar a la siguiente:
interface Tunnel0
description Tunel hacia mi casa
no ip address
ipv6 address 2820:26:10::1/64
ipv6 enable
tunnel source 210.57.51.107
tunnel destination 211.28.235.85
tunnel mode ipv6ip
end
ipv6 route 2820:26:11::/64 Tunnel0
Explicacion:
En la configuracion anterior se aprecia que hay que indicarle la direccion IPv4 fuente, la direccion IPv6 destino y una direccion IPv6 al tunel. El modo del tunel es lo mas importante el cual indica que son paquetes ipv6 en ipv4. Recordemos que Cisco soporta muchos tipos de tunel y recomiendo ser explicito. Adicionalmente el modo del tunel concuerda con el tipo de tunel que vamos a utilizar en Linux (modo sit). Notese que la direccion IPv4 origen del tunel puede ser cualquier IPv4 configurado en el router (una loopback, otra interfaz, etc).
Por ultimo, el comando ipv6 route indica la red que va a manejarse del lado del linux. Muy importante para que exista conectividad y enrutamiento dentro del tunel.
A configurar el linux:
Del lado del Linux es mas facil de lo que uno esperaria. Estos son los comandos utilizados por mi persona:
ifconfig eth0 add 2820:26:11::1/64
ifconfig sit0 tunnel ::210.147.51.107
ifconfig sit1 up
route -A inet6 add ::0/ dev sit1
ping6 2820:26:10::1
Explicacion:
El primer comando le indica la red IPv6 a la interfaz eth0.
El segundo comando indica la interfaz sit (modo ipv6 en ipv4) y el IPv4 donde va a terminar el tunel. El comando route indica la ruta por defecto para que sea enviado por la interfaz sit 1.
Luego de esto, estamos listos para probar la conexion. Primero, vamos a ubicarnos del lado del Linux:
Lo primero es realizar un ping al IPv6 del tunel
[root@localhost ~]# ping6 2800:26:10::1 -c 4
PING 2800:26:10::1(2800:26:10::1) 56 data bytes
64 bytes from 2820:26:10::1: icmp_seq=1 ttl=64 time=153 ms
64 bytes from 2820:26:10::1: icmp_seq=2 ttl=64 time=154 ms
64 bytes from 2820:26:10::1: icmp_seq=3 ttl=64 time=153 ms
64 bytes from 2820:26:10::1: icmp_seq=4 ttl=64 time=152 ms
Luego un ping6 a ipv6.google.com:
[root@localhost ~]# ping6 ipv6.google.com -c 4
PING ipv6.google.com(qw-in-x68.google.com) 56 data bytes
64 bytes from qw-in-x68.google.com: icmp_seq=1 ttl=55 time=232 ms
64 bytes from qw-in-x68.google.com: icmp_seq=2 ttl=55 time=229 ms
64 bytes from qw-in-x68.google.com: icmp_seq=3 ttl=55 time=230 ms
64 bytes from qw-in-x68.google.com: icmp_seq=4 ttl=55 time=231 ms
Tambien recomiendo hacer traceroute y el primer salto que veras es el IPv6 del Cisco.
Ahora bien, del lado del Cisco podemos ver la cantidad de paquetes que han transitado por la interfaz tunel y comprobar el incrementos de paquetes:
#sh int tunne0
Linkstar_PBR#sh int tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Tunel a mi casa
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 210.147.51.107, destination 211.28.235.85
Tunnel protocol/transport IPv6/IP
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:07, output 00:00:06, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
19 packets input, 2736 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
51 packets output, 5540 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
En otra oportunidad indicare como hacer que toda tu red navegue en IPv6 dentro del Tunel.
Suerte y exitos,
martes, 28 de abril de 2009
Ejemplo VPN entre Juniper y Cisco
El siguiente ejemplo muestra la creación de una VPN entre un Firewall Juniper con ScreenOS 5.4 y un Cisco router con el set de Crypto.
La topología es la siguiente:
LAN_lado_Juniper <----> Juniper <---- INTERNET <---> Cisco <--- LAN_lado_Cisco --->
Del lado del Cisco la configuración es la siguiente:
*** BEGIN ***
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key MISECRETO address IP_JUNIPER
crypto map MIVPN 1 ipsec-isakmp
set peer IP_REMOTO
set transform-set MIVPN
match address 140
access-list 140 permit ip LAN_LADO_CISCO 0.0.0.255 LAN_LADO_JUNIPER
crypto ipsec transform-set VPN_to_SW7B esp-3des esp-sha-hmac
interface f0/0
description VPN-SUICHE7B
ip address IP_CISCO 255.255.255.255
crypto map MIVPN
end
*** FIN ***
Aqui podemos ver que el isakmp map utiliza shared secret (clave compartida) para levantar la VPN, MISECRETO es la clave y donde indica IP_JUNIPER hay que colocar el IP del Firewall de la interfaz externa del Juniper.
Luego el Crytp map llamada MIVPN indica el Peer Remoto (nuevamente el IP de la interfaz externa del Juniper, el transform set a utilizar (donde se indica lo que es la fase 2 de la negociación de la VPN) y finalmente el Access-list (ACL con el cual va a hacer match al momento de cifrar y no cifrar los paquetes).
El ACL en realidad define los SA (security association) que se van a intercambiar en la VPN. Es muy importante que utilices un ACL extendido para que puedas definir IPs origen y destino. Es decir, aqui se definen (desde la perspectiva del cisco) cuales son las redes remotas y cuales son las redes locales.
Luego el comando crypto ipsec es en realiad quien define que tipo de cifrado y hash para los datos se va a utilizar. En este caso 3DES y SHA1, sin embargo se puede utilizar DES, MD5, combinaciones y otros.
Finalmente, lo que hay que hacer es aplicar el cryto map a la interfaz por donde va a "transitar" el tráfico en el Cisco, en nuestro caso F0/0
Con lo anterior, ya terminamos con el lado del Cisco...., ahora vamos a Juniper.
Pasos:
1) Crear una interfaz tunnel (tunnel -- interfaces --- new interface) con los siguientes parametros:
* Unnumbered
* Interfaz WAN del Juniper
2) VPN --> Autokey advance --- Gateway
3) New
Debemos dejar la configuración como aparece en la siguiente pantalla:
4) Click en Advance
5) Dejar la configuración como aparece en la siguiente pantalla:
6) VPN --> Autokey advance --- Gateway
7) Click en new
8) Dejar la configuración similar a como aparece en la imagen:
9) Click en advance
10) Dejar la configuración como a aparece en la imagen:
11) Comenzar a pasar tráfico por el tunel (MUY IMPORTANTE)
Luego de esto.., ya debe comenzar a funcionar el tunel sin inconvenientes. La típica prueba en este caso es dejar un ping extendido entre ambos sitios.
Suerte y saludos,
La topología es la siguiente:
LAN_lado_Juniper <----> Juniper <---- INTERNET <---> Cisco <--- LAN_lado_Cisco --->
Del lado del Cisco la configuración es la siguiente:
*** BEGIN ***
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key MISECRETO address IP_JUNIPER
crypto map MIVPN 1 ipsec-isakmp
set peer IP_REMOTO
set transform-set MIVPN
match address 140
access-list 140 permit ip LAN_LADO_CISCO 0.0.0.255 LAN_LADO_JUNIPER
crypto ipsec transform-set VPN_to_SW7B esp-3des esp-sha-hmac
interface f0/0
description VPN-SUICHE7B
ip address IP_CISCO 255.255.255.255
crypto map MIVPN
end
*** FIN ***
Aqui podemos ver que el isakmp map utiliza shared secret (clave compartida) para levantar la VPN, MISECRETO es la clave y donde indica IP_JUNIPER hay que colocar el IP del Firewall de la interfaz externa del Juniper.
Luego el Crytp map llamada MIVPN indica el Peer Remoto (nuevamente el IP de la interfaz externa del Juniper, el transform set a utilizar (donde se indica lo que es la fase 2 de la negociación de la VPN) y finalmente el Access-list (ACL con el cual va a hacer match al momento de cifrar y no cifrar los paquetes).
El ACL en realidad define los SA (security association) que se van a intercambiar en la VPN. Es muy importante que utilices un ACL extendido para que puedas definir IPs origen y destino. Es decir, aqui se definen (desde la perspectiva del cisco) cuales son las redes remotas y cuales son las redes locales.
Luego el comando crypto ipsec es en realiad quien define que tipo de cifrado y hash para los datos se va a utilizar. En este caso 3DES y SHA1, sin embargo se puede utilizar DES, MD5, combinaciones y otros.
Finalmente, lo que hay que hacer es aplicar el cryto map a la interfaz por donde va a "transitar" el tráfico en el Cisco, en nuestro caso F0/0
Con lo anterior, ya terminamos con el lado del Cisco...., ahora vamos a Juniper.
Pasos:
1) Crear una interfaz tunnel (tunnel -- interfaces --- new interface) con los siguientes parametros:
* Unnumbered
* Interfaz WAN del Juniper
2) VPN --> Autokey advance --- Gateway
3) New
Debemos dejar la configuración como aparece en la siguiente pantalla:
4) Click en Advance
5) Dejar la configuración como aparece en la siguiente pantalla:
6) VPN --> Autokey advance --- Gateway
7) Click en new
8) Dejar la configuración similar a como aparece en la imagen:
9) Click en advance
10) Dejar la configuración como a aparece en la imagen:
11) Comenzar a pasar tráfico por el tunel (MUY IMPORTANTE)
Luego de esto.., ya debe comenzar a funcionar el tunel sin inconvenientes. La típica prueba en este caso es dejar un ping extendido entre ambos sitios.
Suerte y saludos,
BGP en IPv6 y Cisco
Configurar BGP sobre IPv6 en Cisco es parecido a IPv4.
En realidad los principios son los mismos de IPv4 tales como:
* Debe existir una ruta en la tabla de enrutamieto para que sea publicada vía BGP
* Hay que crear el peering con el equipo remoto
* Colocar filtros correspondiente tales como filtros entrantes y salientes
Antes de crear la sesión BGP hay que conocer:
* Dirección IPv6 local
* Subred IPv6 a publicar
* Dirección IPv6 remota
* Password (opcional)
Un ejemplo de configuración de BGP sobre IPv6 sería:
router bgp 65501
bgp log-neighbor-changes
neighbor 2820:22:1:1::1 remote-as 1111
neighbor 2820:22:1:1::1 update-source POS3/0
!
address-family ipv6
neighbor 2820:22:3:1::1 activate
network 2820:26::/32
En caso de querer levantar sobre el mismo enlace una sesión BGP en IPv4 es necesario también el siguiente comando:
address-family ipv4
neighbor 2820:22:3:1::1 activate
Comandos utiles para troubleshooting:
1) sh bgp ipv6 unicast (vemos los prefijos ipv6 aprendidos por BGP)
2) sh bgp ipv6 unicast neighbors 2820:22:3:1::1 advertised-routes (prefijos IPv6 que nosotros publicamos al peer)
3) show ipv6 route
Suerte!
En realidad los principios son los mismos de IPv4 tales como:
* Debe existir una ruta en la tabla de enrutamieto para que sea publicada vía BGP
* Hay que crear el peering con el equipo remoto
* Colocar filtros correspondiente tales como filtros entrantes y salientes
Antes de crear la sesión BGP hay que conocer:
* Dirección IPv6 local
* Subred IPv6 a publicar
* Dirección IPv6 remota
* Password (opcional)
Un ejemplo de configuración de BGP sobre IPv6 sería:
router bgp 65501
bgp log-neighbor-changes
neighbor 2820:22:1:1::1 remote-as 1111
neighbor 2820:22:1:1::1 update-source POS3/0
!
address-family ipv6
neighbor 2820:22:3:1::1 activate
network 2820:26::/32
En caso de querer levantar sobre el mismo enlace una sesión BGP en IPv4 es necesario también el siguiente comando:
address-family ipv4
neighbor 2820:22:3:1::1 activate
Comandos utiles para troubleshooting:
1) sh bgp ipv6 unicast (vemos los prefijos ipv6 aprendidos por BGP)
2) sh bgp ipv6 unicast neighbors 2820:22:3:1::1 advertised-routes (prefijos IPv6 que nosotros publicamos al peer)
3) show ipv6 route
Suerte!
jueves, 2 de abril de 2009
Comando oculto en Cisco. Conectarse a VIPs
Manejas routers 7500 o 12000 de Cisco?
Probablemente hayas tenido la necesidad o curiosidad de conectarte directamente a una interfaz VIP del router, aquí puedes revisar CPU, memoria, controladoras directamente, etc. Es casi como un pequeño o mini router dentro del router grande (7500/12000).
El comando es el siguiente:
if-con #nro de slot
por ejemplo
coreNNN#if-con 0
Console or Debug [C]:
Entering CONSOLE for VIP4-80 RM7000 0
Type "^C^C^C" or "if-quit" to end this session
VIP-Slot0>ena
VIP-Slot0#sh proc cpu
CPU utilization for five seconds: 18%/18%; one minute: 6%; five minutes: 8%
ETC, aquí puedo hacer lo que desees. Incluso un reload de la VIP
Suerte!
Probablemente hayas tenido la necesidad o curiosidad de conectarte directamente a una interfaz VIP del router, aquí puedes revisar CPU, memoria, controladoras directamente, etc. Es casi como un pequeño o mini router dentro del router grande (7500/12000).
El comando es el siguiente:
if-con #nro de slot
por ejemplo
coreNNN#if-con 0
Console or Debug [C]:
Entering CONSOLE for VIP4-80 RM7000 0
Type "^C^C^C" or "if-quit" to end this session
VIP-Slot0>ena
VIP-Slot0#sh proc cpu
CPU utilization for five seconds: 18%/18%; one minute: 6%; five minutes: 8%
ETC, aquí puedo hacer lo que desees. Incluso un reload de la VIP
Suerte!
miércoles, 1 de abril de 2009
Comando oculto en Cisco. Telefonía
Muchas veces es complicado hacer troubleshooting de llamadas en Cisco, quizás debes contactar a una persona que se encuentra en una localidad remota para hacer algún tipo pruebas etc.
En fin, si deseas simular una llama en un equipo puedes hacerlo con el siguiente comando:
csim start
Con este comando puedes simular la llamada donde es el peer al que deseas llamar.
Te recomiendo que coloques previamente terminal monitor para hacer un troubleshooting con más detalle
En fin, si deseas simular una llama en un equipo puedes hacerlo con el siguiente comando:
csim start
Con este comando puedes simular la llamada donde
Te recomiendo que coloques previamente terminal monitor para hacer un troubleshooting con más detalle
Redistribuir ruta por default en RIP
En mi red de varios equipos Cisco (Routers y Switches) quería que algunos equipos aprendieran la ruta por default vía RIP. Pensé que redistribuyendo static en RIP era suficiente (donde una ruta estática era una ruta por default). Lamentablemente no funcionó
Si deseas que redistribuir tu ruta por default en rip debes colocar el proceso de RIP el siguiente comando default-information originate. Quedando algo así:
router rip
version 2
network x.0.0.0
default-information originate
no auto-summary
Si deseas que redistribuir tu ruta por default en rip debes colocar el proceso de RIP el siguiente comando default-information originate. Quedando algo así:
router rip
version 2
network x.0.0.0
default-information originate
no auto-summary
Networking Tips
Gracias por entrar en acostanetwork.blogspot.com.
Aquí se publicaran tips semanales en el area de networking
Aquí se publicaran tips semanales en el area de networking
Suscribirse a:
Entradas (Atom)