lunes, 30 de julio de 2012

SSH: Configurar acceso SSH router cisco

Esta es una de esas cosas sencillas, pero muy útiles a la hora de configurar un router.

Habilitar SSH en un router lo que permite es que si alguien está esnifando tu red, no consiga usuarios y contraseñas de acceso a equipos de comunicaciones.

Configuración

aaa new-model <----- Para que pida usuario y contraseña
username networkkings password piruleta

line vty 0 4
   transport imput ssh
   login local <----usa los usuarios definidos localmente( si tienes tacacs omitelo)
exit

crypto key generate rsa 1024
<----crea la clave con la que se va a encriptar la conexión.
Si se te olvida el último paso el router no permitirá el acceso por telnet, ya que no será capaz de generar una conexión encriptada.

1024 es una clave normalita, pero permite el uso de ssh 1 y ssh 2, pero si vas a usar ssh2 seguro puedes poner claves RSA mas gorditas.

 Nota mental, si en ese router sustituyes la supervisora porque se fastidie, no vale tan solo con copiarle la configuración, también hay que generar la clave rsa de nuevo, o si la creaste exportable, pues volversela a cargar.

Por último añadir que no todas las IOS permiten SSH :) , por lo que antes de intentar hacer nada es mejor que compruebes el cisco feature navigator, que es una web que permite comprobar que cosas están habilitadas en cada imagen de IOS.

Cisco feature navigator

lunes, 23 de julio de 2012

QinQ: Pasar un trunk a través de una vlan

Q in Q, o dot1q tunneling es una tecnología principalmente destinada a operadores, y como en casi todas las tecnologías de operador, permite sacar mucho mas rendimiento a la tecnología.

¿En que consiste Q in Q?

Q in Q consiste en hacer un tunnel, el cual permite que usando como transporte una única VLAN(Vlan que estará en la red del operador) transportar todas las VLAN de un trunk 802.1q de un cliente. Es simplemente un sistema de VPN de nivel 2 para cliente, que usa como transporte una red de nivel 2 en el lado de operador.

¿Como funciona?

Intentando no hacer un artículo infumable diremos que lo que hace es añadir doble etiquetado de VLAN, osea a parte del etiquetado de 802.1q que usa el cliente, nosotros volvemos a poner nuestro etiquetado de 802.1q, de este modo cuando los paquetes atraviesan la red del operador lo único a lo que se va a hacer caso es al etiquetado 802.1q de operador, y cuando se llega al otro extremo del tunnel se quita ese etiquetado, y se entrega un trunk normal y corriente.






¿Seguridad? 

Tu estás en una red, tu tráfico se encapsula sin prestar atención a lo que hay dentro, es a todos los efectos una VPN de nivel 2.

¿VPLS o Q-in-Q?

VPLS se basa sobre MPLS, el backbone MPLS permite provisionar circuitos de nivel 2 o 3 a nivel nacional, internacional, o lo que abarque el operador. Q-in-Q esta pensado para entornos MAN, en los cuales el operador transporta el tráfico sobre enlaces de nivel 2, no hablamos de MPLS, ni de routing ni nada. Es el ejemplo claro de MetroEthernet. Dicho lo cual, se pueden combinar MPLS y Q-in-Q, pero eso es otra historia.

Ejemplo de configuración:

PE del Site 1:

int gi1/1 <----contra el cliente A en el site 1
switchport access vlan 10 <---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp <----los protocolos son a nivel del tunel, por tanto simplemente hacemos bypass de ellos
l2protocol-tunnel stp
l2protocol-tunnel vtp

int gi1/2 <----contra el cliente B en el site 1
switchport access vlan 20<---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp

int Tengiga 1/1<---interfaz sobre la que transportaremos nuestras vlanes de operador
switchport mode trunk
switchport trunk allowed vlan 10,20<--- vlanes de operador, cada una transporta una VPN de cliente

PE del Site 2:

int gi1/1 <----contra el cliente B en el site 2
switchport access vlan 20 <---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp <----los protocolos son a nivel del tunel, por tanto simplemente hacemos bypass de ellos
l2protocol-tunnel stp
l2protocol-tunnel vtp


int gi1/2 <----contra el cliente A en el site2
switchport access vlan 10<---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp

int Tengiga 1/1<---interfaz sobre la que transportaremos nuestras vlanes de operador

switchport mode trunk
switchport trunk allowed vlan 10,20<--- vlanes de operador, cada una transporta una VPN de cliente


¿Implicaciones de Spanning Tree?

El cliente interactuará entre sus lans como si fuesen switches directamente conectados, a efectos prácticos es como una LAN. Por tanto el cliente con su STP, y el operador con el suyo propio, por supuesto cualquier cambio de STP en el proveedor afecta al cliente en forma de corte.


lunes, 16 de julio de 2012

MST: Otra evolución de spanning tree(802.1s)


 Este artículo es una introducción a MST, no pretende abarcar todo el contenido de MST, pero sirve como una guia introductoria, con sus comandos básicos, y si gusta, quizá haya mas artículos sobre MST.

Spanning Tree desde que fue dado a luz hace muchos años ha sufrido muchas evoluciones, dichas evoluciones van siempre orientadas a hacer un poco mas llevable un protocolo que desde la perspectiva de diseño siempre ha sido poco flexible.

MST es una de estas evoluciones, en realidad el MST 802.1s es una evolución de rapid spanning tree. MST aborda el hecho de que resulta un malgasto de recursos el tener una instancia de spanning tree, con su root, y su calculo del mejor camino para cada vlan, sobre todo cuando en el 99% de las LAN tienen la misma topología para todas las vlan, o como mucho una topología con un root para las pares, y otra para las impares, de cara al balanceo de carga.

Lo cierto es que cuando hay un cambio de topología porque un trunk se cae, en los spanning tree "tradicionales" se produce una marabunta de bpdu's que inundan la red, calculos independientes por vlan de root, y seamos realistas, es poco práctico.

MST en lo que consiste a grandes rasgos es, en lugar de tener una instancia de spanning tree para todas las vlan como el STP tradicional, ni tampoco tener una instancia de spanning tree para cada vlan, coge el concepto de ambos y lo funde. Una instancia de spanning tree para cada "grupo" de vlans.

En MST se crean instancias, una es la instancia de STP por defecto, que es la instancia 0, o tambien conocida como IST.

Configuración:

spanning-tree mode mst <---- activa MST
spanning-tree mst configuration
name <nombre_de_la_region>
revision <numero> <----al estilo VTP 
instance <numero> vlan <vlans_metidas_en_la_instancia>

La gran putada de MST es que hay que ir configurandolo igual switch por switch, y si la pifias los puertos empezaran a bloquearse porque los switches se veran entre ellos como regiones diferentes, por lo que para muchas redes resulta poco escalable. Para un entorno de operador, o un entorno muy estable quizá si resulta adecuado ya que ahorra recursos, aunque las migraciones a MST suelen ser complicadas.

Añadir ya de paso como nota positiva que VTP versión 3 permite la propagación de la información de MST, lo cual quitaría el principal handicap de MST.

Ejemplo:

Dos switches y alguno mas colgando que tendría la configuración basica de MST, pero nada de prioridades de root.

Switch 1:

spanning-tree mst configuration
 name ARBOL
 revision 1
 instance 1 vlan 17, 39, 45
 instance 2 vlan 24, 56, 100
!
spanning-tree mst 1 priority 24576  <---root para la instancia 1
spanning-tree mst 2 priority 28672  <---backup root instancia 2


Switch 2:

spanning-tree mst configuration
 name ARBOL
 revision 1
 instance 1 vlan 17, 39, 45
 instance 2 vlan 24, 56, 100
!
spanning-tree mst 1 priority 28672<---backup root instancia 1
spanning-tree mst 2 priority 24576<---root para la instancia 2

Output de switch 1:

show spanning-tree

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     aabb.cc00.0700
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     aabb.cc00.0700
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Desg FWD 2000000   128.67   Shr
Et2/3               Desg FWD 2000000   128.68   Shr

         
MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    24577
             Address     aabb.cc00.0700
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
             Address     aabb.cc00.0700
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Desg FWD 2000000   128.67   Shr
Et2/3               Desg FWD 2000000   128.68   Shr

         
MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    24578
             Address     aabb.cc00.0800
             Cost        2000000
             Port        67 (Ethernet2/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    28674  (priority 28672 sys-id-ext 2)
             Address     aabb.cc00.0700
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Root FWD 2000000   128.67   Shr
Et2/3               Altn BLK 2000000   128.68   Shr

Output switch 2

show spanning-tree

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     aabb.cc00.0700
             Cost        0
             Port        67 (Ethernet2/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     aabb.cc00.0800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Root FWD 2000000   128.67   Shr
Et2/3               Altn BLK 2000000   128.68   Shr

         
MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    24577
             Address     aabb.cc00.0700
             Cost        2000000
             Port        67 (Ethernet2/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    28673  (priority 28672 sys-id-ext 1)
             Address     aabb.cc00.0800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Root FWD 2000000   128.67   Shr
Et2/3               Altn BLK 2000000   128.68   Shr

         
MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    24578
             Address     aabb.cc00.0800
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24578  (priority 24576 sys-id-ext 2)
             Address     aabb.cc00.0800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/2               Desg FWD 2000000   128.35   Shr
Et1/3               Desg FWD 2000000   128.36   Shr
Et2/0               Desg FWD 2000000   128.65   Shr
Et2/1               Desg FWD 2000000   128.66   Shr
Et2/2               Desg FWD 2000000   128.67   Shr
Et2/3               Desg FWD 2000000   128.68   Shr
Como se puede ver en lo resaltado en azul, existe una instancia 0, pero sus funciones las contaremos en otro capitulo, mientras tanto disfrutad con ello ;) .

lunes, 9 de julio de 2012

EEM: Embedded Event Manager

Probablemente publique varios artículos sobre EEM, ya que desde mi punto de vista se trata de una tecnología con una flexibilidad acojonante, pero hoy comenzaremos explicando que es.

EEM como su nombre indica es un gestor de eventos embebido dentro del software de los routers y switches, o lo que es lo mismo, un software dentro de IOS, que te permite que si pasa algún evento dentro del router, el propio router cambie su configuración, mande un e-mail de alerta, o muchas otras cosas.

EEM era posiblemente el complemento que le faltaba a TCL para poder tener un sistema de eventos y scripts dentro de tu router, cosa que permite que tu red sea mas sencilla de controlar.


Configurar applets de EEM:


Tirando de wikipedia llegamos a la definición de applet: Un componente de una aplicación que se ejecuta en el contexto de otro programa.  Bien pues nosotros vamos a configurar applets, a los que tendremos que ponerles nombre.

Router(config)#event manager applet <NOMBRE_APPLET>

Después deberemos seleccionar que evento queremos inspeccionar, cada uno de ellos se configura de manera diferente, por lo que pongo un listado de todo lo que se puede monitorizar.

Router(config-applet)#event ?
  application  Application specific event
  cli          CLI event
  counter      Counter event
  interface    Interface event
  ioswdsysmon  IOS WDSysMon event
  none         Manually run policy event
  oir          OIR event
  resource     Resource event
  snmp         SNMP event
  syslog       Syslog event
  timer        Timer event
  track        Tracking object event 


Una vez que hemos seleccionado la el evento que queremos detectar, lo que configuraremos será la acción que llevaremos a cabo en nuestro router en caso de que se produzca el evento. Al igual que antes pongo un listado con las acciones disponibles en EEM, varía según versión, este es el listado de las disponibles en la 12.4T del laboratorio del CCIE.

Router(config-applet)#action <numero_accion> ?
  cli               Execute a CLI command
  cns-event         Send a CNS event
  counter           Modify a counter value
  force-switchover  Force a software switchover
  info              Obtain system specific information
  mail              Send an e-mail
  policy            Run a pre-registered policy
  publish-event     Publish an application specific event
  reload            Reload system
  snmp-trap         Send an SNMP trap
  syslog            Log a syslog message
  track             Read/Set a tracking object

Si os fijais he puesto numero de acción, acciones se pueden ejecutar varias.

Ejemplo:

Ahora voy a poner un ejemplo sencillo de un applet de eem, el cual detecta que alguien introduzca el comando reload, y el router no solo no se reiniciará, sino que además generará una linea en el log.

event manager applet NO_REINICIAR
 event cli pattern "reload" sync no skip yes occurs 1
 action 1.0 syslog msg "¡¡¡OYE TIO LISTO NO INTENTES REINICIARME QUE ME VOY A CABREAR!!!"

sync no: Es para que la política y el comando no se ejecuten al mismo tiempo, en esta ocasión quiero que el applet se ejecute antes(no quiero que me reinicie el router).
skip yes: Es para configurar que quiero que no haga ni caso al comando.
Occurs 1: es para saber cuantas veces tiene que pasar este evento para que se ejecute la accion.


En linea de comandos:

Router#reload
Router#
*Mar  1 00:15:47.455: %HA_EM-6-LOG: NO_REINICIAR: B!B!B!OYE TIO LISTO NO INTENTES REINICIARME QUE ME VOY A CABREAR!!!

En posteriores artículos pondré otros applets bastante mas útiles, hechos por mi, o que he visto en documentaciones y me han parecido muy útiles.


lunes, 2 de julio de 2012

Netflow: Configuración en routers cisco

Netflow es un protocolo desarrollado por Cisco, que permite recoger estadísticas del tráfico de red en routers y switches.

Netflow consiste en un servidor que recoge estadísticas de los dispositivos de red, para servidores hay muchos tipos, de los gratuitos destaca Cacti que corre sobre linux.

En la parte de los equipos de red lo que se configura es un agente de netflow que será el encargado de ir generando las estadísticas a nivel de equipo.



Las estadísticas que recoge mayormente en la versión 5 de netflow son las siguientes:

  • Interfaz de entrada
  • IP origen
  • IP destino
  • Protocolo
  • Puerto de origen
  • Puerto de destino
  • Tipo de servicio

Para configurar el agente de netflow se hace de manera bastante sencilla:

ip flow-export version 5
ip flow-export destination <ip_servidor> <puerto_servidor>

inteface x/x <----de las que queramos recoger estadísticas
ip flow ingress <---trafico de entrada
ip flow egress <--- trafico de salida

Comandos relacionados:

show ip cache verbose flow

http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_01.html