BGP Communities: Anunciando prefijos con communities

Este es el primer artículo específico de BGP que tiene este blog pero vamos a empezar con un poquito de nivel, se va a tratar el tema de las communities en BGP.

Una community es un mecanismo muy parecido a un TAG, que se le pone a un prefijo de BGP. Las communities se utilizan sobre todo a nivel ISP, y hay communities conocidas que indican si la ruta debe de ser interna, si es exportable...etc.

Cada operador suele tener un documento de communities, al que el resto de ISP deberá acogerse para hacer traffic engineering, pero eso esa es otra historia. En esta vamos a hacer pruebas con comunidades de prueba.

Configuración:

En el lado que añadimos la community, en el otro con hablar BGP con el que agrega la community nos vale.

router bgp x
neighbor x.x.x.x send-community <----necesario ya que por defecto no se envían
 neighbor 2.2.2.2 route-map <nombre_route_map> out
 

route-map <nombre_route_map>permit 10
 set community <communities_separadas_espacios>

Ejemplo:

R3(Anunciador):

router bgp 6
 no synchronization
 bgp log-neighbor-changes
 network 22.22.22.22 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 send-community
 neighbor 2.2.2.2 route-map COMMOUT out
 no auto-summary
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Loopback22
 ip address 22.22.22.22 255.255.255.255
!
interface FastEthernet0/0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.3 255.255.255.0
ip route 1.1.1.1 255.255.255.255 192.168.2.2
ip route 2.2.2.2 255.255.255.255 192.168.2.2
route-map COMMOUT permit 10
 set community 3 33 333

R2:

router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 5
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 6
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.2 255.255.255.0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.2 255.255.255.0
ip route 1.1.1.1 255.255.255.255 192.168.1.1
ip route 3.3.3.3 255.255.255.255 192.168.2.3

R1:

router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.1 255.255.255.0

Verificación:

R2#show ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  6
    3.3.3.3 from 3.3.3.3 (22.22.22.22)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 3 33 333

R1#show ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  6
    3.3.3.3 from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Si os habéis fijado bien podéis observar que R1 no tiene la community en la ruta, es simplemente porque R2 no anuncia communities a R1 :).


Otro día veremos mas BGP que alguno ya me lo ha reclamado.

TCL: El clasico script de TCL para hacer ping

Un script TCL muy majete para lanzar desde un único router pings secuenciales a una lista de IP. Es considerado un clásico ya que para prepararte el examen del CCIE práctico lo usarás hasta la saciedad para comprobar que el routing funciona correctamente, especialmente después de redistribuciones.

Ejecución:

tclsh <---entramos en TCL

foreach address {
x.x.x.x

x.x.x.x
x.x.x.x
x.x.x.x} { ping $address
}<---se ejecutan los pings

tclquit <--- de lo contrario seguimos en TCL

Un ejemplo con un lab casero:

Rack05R1#tclsh
Rack05R1(tcl)#foreach address {
+>5.5.1.1
+>5.5.2.2
+>5.5.3.3
+>5.5.4.4
+>5.5.5.5
+>5.5.6.6
+>5.5.7.7
+>5.5.8.8
+>5.5.9.9
+>5.5.10.10
+>} { ping $address re 5
+>}

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/32 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/36 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.6.6, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/16 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.9.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/16 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

Rack05R1(tcl)#tclquit
Rack05R1#

Si habéis estado atentos habreis visto que todos respondían excepto el 5.5.6.6 :) .

Moraleja:

Ten preparado tu script de TCL para hacer ping a todo de manera sucesiva, para después de la intervención tan solo hacer un copy paste.

Backup Interfaces: Alta disponibilidad en interfaces punto a punto

Backup interfaces es una feature configurable en las interfaces de los routers cisco, la cual permite establecer que una interfaz va a permanecer en standby hasta que la interfaz principal deje de estar activa.

No se trata de una tecnología de port-channel o algo similar, en esta ocasión estamos hablando de configurar dos interfaces con rangos de ip diferentes, y en caso de que una falle, se utiliza la otra.

Esto era bastante habituál hace años en entornos de operador, en el cual siempre había alguna linea RDSI para hacer el backup en caso de caída. Actuálmente se ve mucho en entornos de altísima criticidad, en los cuales en caso de caída de interfaces utilizas la interfaz secundaria.

El funcionamiento es muy simple, pero ojo, ya que se trata de una funcionalidad que solo resulta eficaz en interfaces punto a punto, si tuviésemos un equipo en medio, que me sigue generando link(como un equipo de transmisión) la interfáz nunca se caería, y por tanto seguiríamos usándola aunque el otro extremo no responda. Para esos casos recomiendo el uso de IP SLA.

Configuración(Dentro de la intefaz primaria):

router(config-if)# backup interface <interfaz_de_backup>

Ejemplo:

R1:

interface Ethernet0/0
 ip address 192.168.2.1 255.255.255.0 
interface Serial1/1
 backup interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0

ip route 1.1.1.1 255.255.255.255 192.168.1.2
ip route 1.1.1.1 255.255.255.255 192.168.2.2

R3:

interface Loopback1 
ip address 1.1.1.1 255.255.255.255
interface Ethernet0/0
 ip address 192.168.2.2 255.255.255.0 
interface Serial1/2
 ip address 192.168.1.2 255.255.255.0 
clock rate 56000

Lanzamos un Ping, y tiramos la interfaz primaria.

ping 1.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...............*Mar  1 00:23:53.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to down*Mar  1 00:23:53.211: BACKUP(Serial1/1): event = primary interface went down*Mar  1 00:23:53.215: BACKUP(Serial1/1): changed state to "waiting to backup"*Mar  1 00:23:53.231: BACKUP(Serial1/1): event = timer expired on primary*Mar  1 00:23:53.239: BACKUP(Serial1/1): secondary interface (Ethernet0/0) made active*Mar  1 00:23:53.243: BACKUP(Serial1/1): changed state to "backup mode".*Mar  1 00:23:55.231: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up*Mar  1 00:23:56.231: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*Mar  1 00:23:56.235: BACKUP(Ethernet0/0): event = secondary interface came up!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ahora solo tienes que echarle un poco de imaginación, y montar una RDSI con su dialer/VPN por internet, para alguna conexión punto gorda que tengas :-) .

Spanning Tree: Priority vs cost

En spanning tree, siempre que tengamos dos caminos redundantes para alcanzar a nuestro root bridge podemos elegir que camino queremos utilizar. Para hacer esto spanning tree dispone de dos parámetros que son configurables, pero que funcionan de manera diferente.

• Priority: Priority permite establecer un valor que obligatoriamente tiene que ser múltiplo de 64 y que por defecto es 128, en el cual estableceremos la prioridad del puerto. El puerto con una prioridad menor será el puerto que utilizaremos para alcanzar a root, independientemente del coste que tenga el puerto, la prioridad siempre manda.

Ejemplo:

-Antes-

Rack05SW3(config-if)#do show spanning-tree mst 1
##### MST1    vlans mapped:   11,22,33
Bridge        address aabb.cc00.0900  priority      32769 (32768 sysid 1)
Root          address aabb.cc00.0700  priority      24577 (24576 sysid 1)
            port    Et1/3           cost      2000000              rem hops 19
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Et1/1            Desg FWD 2000000   128.34   Shr
Et1/2            Desg FWD 2000000   128.35   Shr
Et1/3            Root 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

-Después-


 

Rack05SW3(config-if)#spanning-tree mst 1 port-priority 64

Rack05SW3(config-if)#do show spanning-tree mst 1
##### MST1    vlans mapped:   11,22,33
Bridge        address aabb.cc00.0900  priority      32769 (32768 sysid 1)
Root          address aabb.cc00.0700  priority      24577 (24576 sysid 1)
            port    Et1/3           cost      2000000              rem hops 19
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Et1/1            Desg FWD 2000000   128.34   Shr
Et1/2            Desg FWD 2000000   128.35   Shr
Et1/3            Root FWD 2000000    64.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

• Cost:   Cost es la forma natural de coste de spanning tree, el camino con el menor coste para llegar a root es el camino que elegiremos. Podemos configurar el coste también a nivel de puerto, pero en cualquier caso priority siempre se impondrá ante cost.

Ejemplo:

-Antes-

Rack05SW3(config-if)#do show spanning-tree mst 1
##### MST1    vlans mapped:   11,22,33
Bridge        address aabb.cc00.0900  priority      32769 (32768 sysid 1)
Root          address aabb.cc00.0700  priority      24577 (24576 sysid 1)
            port    Et1/3           cost      2000000              rem hops 19
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Et1/1            Desg FWD 2000000   128.34   Shr
Et1/2            Desg FWD 2000000   128.35   Shr
Et1/3            Root 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

-Después-

Rack05SW3(config-if)#spanning-tree mst 1 cost 100

Rack05SW3(config-if)#do show spanning-tree mst 1 
##### MST1    vlans mapped:   11,22,33
Bridge        address aabb.cc00.0900  priority      32769 (32768 sysid 1)
Root          address aabb.cc00.0700  priority      24577 (24576 sysid 1)
            port    Et1/3           cost      100                  rem hops 19
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Et1/1            Desg FWD 2000000   128.34   Shr
Et1/2            Desg FWD 2000000   128.35   Shr
Et1/3            Root FWD 100       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

También hay que tener en cuenta, que por defecto los switches configurarán valores a spanning tree según el tipo de interfaz, ya sea Giga, Ethernet, FastEthernet...etc. Dejo la tabla de referencia que nunca viene mal para tenerlo en cuenta.

Speed	Port Cost	Comment
10 Mbps	100	Ethernet
20 Mbps	56	EtherChannel
30 Mbps	47	EtherChannel
40 Mbps	41	EtherChannel
50 Mbps	35	EtherChannel
54 Mbps	33	802.11 wireless
60 Mbps	30	EtherChannel
70 Mbps	26	EtherChannel
80 Mbps	23	EtherChannel
100 Mbps	19	Fast Ethernet
200 Mbps	12	Fast EtherChannel
300 Mbps	9	Fast EtherChannel
400 Mbps	8	Fast EtherChannel
500 Mbps	7	Fast EtherChannel
600 Mbps	6	Fast EtherChannel
700 Mbps	5	Fast EtherChannel
800 Mbps	5	Fast EtherChannel
1 Gbps	4	Gigabit Ethernet
2 Gbps	3	Gigabit EtherChannel
10 Gbps	2	10G Ethernet
20 Gbps	1	20G EtherChannel
40 Gbps	1	40G EtherChannel

GRE: Tirando un tunel GRE por recursividad

En artículos anteriores hemos visto los túneles GRE, hoy vamos a ver el routing recursivo, una pifia habituál a la hora de trabajar con túneles GRE.

Un tunel GRE permite conectar dos extremos que tienen conectividad y por tanto routing, haciendo que cuando los paquetes atraviesen el tunel parezca que se trata de un único salto, pero en realidad los paquetes del tunel atraviesan una red enruta.

Los túneles se basan en una comunicación TCP entre una IP de origen y una IP de destino.El problema viene cuando hablamos también routing dinámico dentro del tunel, y para alcanzar la ip del otro lado del tunel el camino mas corto es a través del propio tunel.

Esto lo que hace es que para seguir con la comunicación TCP del propio tunel se envíen los paquetes por dentro del tunel, y claro la conexión se cae :-) . Solución, no permitas que las ip que forman el tunel GRE sean alcanzables por routing dentro del tunel GRE.

A continuación pongo un ejemplo, basado en el ejemplo del primer artículo sobre túneles GRE de este mismo blog.

Ejemplo con routing dinámico:

R4:

interface Loopback1
 ip address 4.4.4.4 255.255.255.255
!
interface Loopback2
 ip address 1.2.3.4 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.252
 tunnel source Loopback1
 tunnel destination 6.6.6.6
!
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 half-duplex
!
router eigrp 100
 network 1.2.3.4 0.0.0.0
 network 10.0.0.1 0.0.0.0
 auto-summary
!
router rip
 version 2
 network 4.0.0.0
 network 192.168.1.0!

R5:

interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 half-duplex
!
interface Ethernet0/1
 ip address 192.168.2.1 255.255.255.0
 half-duplex
 router rip
 version 2
 network 192.168.1.0
 network 192.168.2.0

 R6: 

 interface Ethernet0/1
 ip address 192.168.2.2 255.255.255.0
 half-duplex
 interface Loopback1
 ip address 6.6.6.6 255.255.255.255
!
interface Loopback2
 ip address 4.3.2.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.252
 tunnel source Loopback1
 tunnel destination 4.4.4.4

router eigrp 100
 network 4.3.2.1 0.0.0.0
 network 10.0.0.2 0.0.0.0
 no auto-summary
!
router rip
 version 2
 network 6.0.0.0
 network 192.168.2.0

Creando el bucle:

R6:

 router eigrp 100
 network 6.6.6.6 0.0.0.0
Output:
R6(config-router)#network 6.6.6.6 0.0.0.0
R6(config-router)#^Z
R6#do show
*Mar  1 00:23:37.527: %SYS-5-CONFIG_I: Configured from console by console
R6#
*Mar  1 00:23:48.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel1) is down: holding time expired
R6#

Lo que se ve en el otro lado es:

 *Mar  1 00:24:34.223: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 00:24:35.223: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 00:24:35.291: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel1) is down: interface down
R4#

http://networkkings-es.blogspot.com/2012/06/tuneles-gre-la-navaja-suiza-del.html
http://networkkings-es.blogspot.com/2012/06/mgre-tuneles-gre-multipunto.html
http://networkkings-es.blogspot.com/2012/06/mgre-configuracion-de-tuneles-gre.html

RSPAN: SPAN remoto transportando el tráfico sobre una Vlan

En el artículo anterior vimos como se podía capturar tráfico en un switch de forma que lo redireccionásemos a otro puerto del mismo switch, de este modo se pueden diagnosticar comportamientos extraños en servidores...etc.

La gran limitación que tiene SPAN es que tanto tráfico a capturar(puertos o VLANS), como puerto en donde vamos a copiar esa información deben estar conectados en el mismo router/switch. Esto sobre todo es un problema para una ubicación remota en la que queremos capturar tráfico, pero no tenemos ningún ordenador que nos pueda hacer un tcpdump, o un wireshark.

Para estas situaciones esta RSPAN, el cual permite que el tráfico de origen sea capturado en un router, pero el puerto en donde se van a volcar la información puede estar en otro equipo distinto. La limitación que tiene esto es que tan solo se puede configurar si existe conectividad de nivel 2 entre el switch que captura el tráfico, y el switch que va a volcar el tráfico.

Configuración(suponiendo que no hay VTP):

SwitchOrigen:

router(config)# vlan <nº>
router(config-vlan)# remote-span
router(config-vlan)# exit
router(config)# monitor session <nºsesion> source <interface/vlan> <the_interfaces_or_vlans> <rx/tx/both>
router(config)# monitor session <nºsesion> destination remote vlan <nº>

Hay que aclarar que los dos primeros comandos son para convertir esa vlan en una vlan de rspan, se deberá configurar en todos los equipos que participen del RSPAN, pero si usamos vtp, con configurarlo en el vtp server nos vale.

 Switch Destino:

router(config)# vlan <nº>
router(config-vlan)# remote-span
router(config-vlan)# exit
router(config)# monitor session <nºsesion> source remote vlan <nº>
router(config)# monitor session <nºsesion> destination interace <interfaz_destino>

Obviamente la vlan que se usa para transportar el span deberá propagarse desde el origen al destino, en caso contrario poca cosa vamos a hacer.

SPAN: Redirigiendo tráfico a una sonda local

Una de esas cosas que en el mundo del networking toca hacer un montón de veces durante la vida es capturar el tráfico que está pasando por un puerto, normalmente suele ser relacionado con una de esas incidencias de difícil diagnóstico, en la cual desde un extremo del "cable" se ve una cosa, y desde el otro se ve otra.

Para todas esas incidencias en las que no esta claro lo que pasa en la red, SPAN, o sus hermanos RSPAN, ERSPAN suele ser la solución.

SPAN permite redireccionar los paquetes que entran/salen/ambos por un puerto/grupo de puertos/vlan/grupo de vlanes a un puerto de destino, el cual debe de tener conectado un analizador de paquetes.

A destacar dentro de los analizadores de paquetes wireshark para windows/mac que es una herramienta de facil manejo, o tcpdump para unix/linux que resulta un poquito mas difícil de utilizar, pero que por el contrario ya viene instalada con la mayoría de los sistemas operativos.

Configurar SPAN es muy sencillo:

router(config)# monitor session <nº> source <interface/vlan> <interfaces_o_vlans_capturadas> <rt/tx/both>
router(config)# monitor session <nº> destination interface <interfaz_o_interfeaces_destino>

<nº> Es el número de session, ojo con esto porque dependiendo del hardware que uses estará limitado a un cierto número de sesiones.
<rx/tx/both> Es para determinar si queremos capturar los paquetes enviados por esa interfaz(tx), los recibidos(rx), o ambos (both).

Con eso ya tienes configurado el reenvío de información al puerto de destino, ahora viene lo divertido, que es leerse la captura que hagas con tu tcpdump/wireshark, cosa que suele ser bastante mas entretenida, y que normalmente llevará consigo una buena taza de café.

Ejemplo:

En el gráfico se aprecia un servidor, que está conectado al puerto fa0/0 del switch, y del cual queremos copiar toda la información que entra y sale, con destino a un portatil que tenemos en el puerto fa0/1.

router(config)#monitor session 1 source interface Fa0/0
router(config)#monitor session 1 destination interface Fa0/1

R1#show monitor session 1
Session 1
---------
Source Ports:
    RX Only:       None
    TX Only:       None
    Both:          Fa0/0
Source VLANs:
    RX Only:       None
    TX Only:       None
    Both:          None
Destination Ports: Fa0/1
Filter VLANs:      None

 Como se puede ver, también admite filtro para VLANS.

Advertencia:

SPAN puede tener efectos en el performance de tu red, por tanto si tienes un switch al 99% de CPU lo normal es que la lies parda :) , además hay que tener en cuenta que el tráfico de origen y el de destino sean razonablemente parecidos, porque por ejemplo intentar hacer pasar 20 Gbps de tráfico a un puerto de 1Gbps suele ser mala idea.