BGP Communities: Filtrando por una community

En el último artículo vimos como podíamos asignar communities a prefijos de BGP, en este lo que vamos a hacer es filtrar el tráfico en base a la community que traiga asignado. Si le echas un un poco de imaginación se te ocurrirá cuantas cosas puedes hacer con route-maps y communities, de cara a redistribuciones...etc.

Configuración:

router bgp x
neighbor x.x.x.x route-map <nombre_route_map> in
route-map <nombre_route_map> deny 10
 match community <nombre_comunity_list>

route-map <nombre_route_map> permit 20 <---si no lo pones te cepillas también el resto de prefijos :-D

ip community-list standard <nombre_comunity_list> permit <community_a_filtrar>

Ejemplo:

El mismo ejemplo de la otra vez, pero en esta ocasión filtrando en R2.

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 Loopback33
 ip address 33.33.33.33 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
 match ip address 23
 set community 3 33 333
!
route-map COMMOUT permit 20
 set community 2 22 222

access-list 23 permit 33.33.33.33

R2(El que filtra):

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 route-map PRUEBA in

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

ip community-list standard SIN_333 permit 333
!
!
route-map PRUEBA deny 10
 match community SIN_333
!
route-map PRUEBA permit 20

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 8
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: 2 22 222
R2#show ip bgp 33.33.33.33
% Network not in table
R2#

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.

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

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.

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 ;) .

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.

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

DNS: Configurando un router como servido DNS

Una de esas funcionalidades curiosas, se puede configurar un router cisco como servidor DNS, supongo que para alguna pequeña red puede hacer el apaño.

Para explicarlo voy a poner un ejemplo con este blog:

ip dns server
ip host networkkings-es.blogspot.com ns 192.168.1.1 <---la pagina apunta a esa ip
ip host correo.networkkings-es.blogspot.com ns 192.168.1.33 <---el servidor de correo a esa otra
ip dns primary networkkings-es.blogspot.com soa dns1.networkkings-es.blogspot.com admin@networkkings-es.blogspot.com <--- configuramos el router como ns1.network... como dns primario, y la cuenta de correo del administrador admin@net...

Si esta bien configurado debería tener este aspecto:

R2#show ip dns primary
Primary for zone networkkings-es.blogspot.com:
  SOA information:
  Zone primary (MNAME): dns1.networkkings-es.blogspot.com
  Zone contact (RNAME): admin@networkkings-es.blogspot.com
  Refresh (seconds):    21600
  Retry (seconds):      900
  Expire (seconds):     7776000  

Minimum (seconds):    86400

Mi recomendación es utilizar unos dominios bastante mas pequeños, pero solo era un ejemplo.

https://learningnetwork.cisco.com/docs/DOC-6248

GLBP: Balanceo de carga y redundancia de gateway usando ARP

En artículos anteriores vimos HSRP, y VRRP, que ambos permiten alta disponibilidad en gateways. GLBP es un protocolo similar hasta cierto punto a los anteriores, pero GLBP lo que también permite es hacer balanceo de carga, cosa que salvo artimañas de doble gateway no es posible con VRRP y HSRP.

GLBP tampoco es que sea un protocolo con una tecnología especialmente novedosa, realmente lo único que hace es, que uno de los routers llamado AVG(Active Virtual Gateway) se encarga de responder a todas las peticiones de ARP de todo el mundo en esa vlan para la ip virtual, pero responde a cada cliente con la dirección MAC diferente cada vez, que corresponderá a la de los routers que forman parte del grupo de GLBP, lo que se llama AVF(Active Virtual Forwarders).

Pongo un ejemplo que también deja muy claro como se configura:

Router 1 (AVG):

interface Vlan2
 ip address 192.168.1.11 255.255.255.0
 glbp 2 ip 192.168.1.1
 glbp 2 priority 200 <--- es la prioridad del AVG, luego se balancea el tráfico
 glbp 2 preempt
 glbp 2 authentication md5 key-string GoMiNoLa
end

Router 2 (Standby AVG):

interface Vlan2
 ip address 192.168.1.22 255.255.255.0
 glbp 2 ip 192.168.1.1

 glbp 2 priority 100
 glbp 2 preempt
 glbp 2 authentication md5 key-string GoMiNoLa
end

También tiene opciones para elegir como balancear el tráfico, se puede elegir también que algunos equipos reciban mas tráfico que otros...etc.
Para todo esto, le podéis echar un vistazo a este link:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_glbp.html

VRRP: El primo standard de HSRP

En el artículo anterior hablamos de HSRP como protocolo de alta disponibilidad para gateway, en esta ocasión veremos VRRP que es un protocolo bastante parecido, pero es standard y se puede configurar en cualquier router de cualquier fabricante.

La configuración es bastante parecida, por lo que paso directamente a detallar un ejemplo.

Master:

interface Vlan2
 ip address 192.168.1.1 255.255.255.0
 vrrp 1 ip 192.168.1.1
 vrrp 1 priority 200
 vrrp 2 authentication md5 key-string GoMiNoLa

Backup:

interface Vlan2
 ip address 192.168.1.22 255.255.255.0
 vrrp 1 ip 192.168.1.1
 vrrp 2 authentication md5 key-string GoMiNoLa

Las principales diferencias a la hora de configurar VRRP son , que la ip virtual debe tenerla uno de los routers configurada, y que automáticamente hace preempt, por lo demás es muy muy parecido, cambia la nomenclatura, pero todo muy parecido.

R1#show vrrp
Vlan2 - Group 1 
  State is Master 
  Virtual IP address is 192.168.1.1
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 255 (cfgd 200)
  Master Router is 192.168.1.1 (local), priority is 255
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.003 sec

HSRP: Alta disponibilidad a nivel de gateway

La primera cosa que no esta en el temario de CCNA, y que debería aprender un estudiante de CCNA para dedicarse a este negocio es HSRP, una de esas cosas básicas que tienes que dominar hasta la saciedad.

HSRP es un protocolo que permite tener una ip virtual a parte de la real, y esa ip virtual la tendrá activa un router en un segmento de red, no es posible que esté activa en ambos. Si el router activo pierde conectividad con el pasivo, el router pasivo inmediatamente pasará a tener activa la dirección ip virtual.

El requisito obviamente es que ambos routers estén en la misma lan, y tengan conectividad entre ellos por esa vlan, porque en caso de no tener conectividad entre ellos por temas de VACL  o similares, los dos se pondrán activos y entonces comenzará la fiesta :-D .

Configuración:

Dentro de una interfaz, ya sea física, vlan o lo que te de la gana:

standby <nºgrupo> ip <ip_virtual>  <---- se pueden configurar varios grupos en la misma vlan por si quieres tener varias icvirtuales
 standby <nºgrupo> priority <prioridad 0-250> <---la mayor prioridad gana
 standby <nºgrupo> preempt <---sirve para que si un router con prioridad mayor se haga automáticamente activo aunque ya haya uno activo, si no esta activo esperaría hasta que el activo deje de responder

 standby <nºgrupo> authentication md5 key-string <PASSWORD>

Resulta conveniente poner password porque si alguien pincha a tu red un equipo con linux y un programa para HSRP sería posible hacer un ataque de Man In The Middle, que por cierto me lo voy a apuntar para otro articulillo mas adelante porque es fácil y divertido de hacer.

Un ejemplo de esto:

Activo:

interface Vlan2
   ip address 192.168.1.11 255.255.255.0
   standby 2 ip 192.168.1.1
   standby 2 priority 200
   standby 2 preempt
   standby 2 authentication md5 key-string GoMiNoLa

Standby:

interface Vlan2
 ip address 192.168.1.22 255.255.255.0
 standby 2 ip 192.168.1.1
 standby 2 preempt
 standby 2 authentication md5 key-string GoMiNoLa

Comprobamos el estado desde el activo:

R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active          Standby         Virtual IP    
Vl2         2   200  P Active   local           192.168.1.22    192.168.1.1  

Nosotros somos los activos, y el stanby es el 192.168.1.22

Ahora vamos a lanzar un ping desde uno de los routers de abajo, y vamos a incomunicar el activo, y pasado unos segundos lo vamos a poner en juego.

R3#ping 192.168.1.1 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<---los dos paquetes fallidos cuando falla el activo
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<---otro paquete fallido cuando vuelve a ponerse activo
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (996/1000), round-trip min/avg/max = 4/16/68 ms

Aquí podemos ver lo que se ve en el servidor cuando tiramos la interfaz y volvemos a levantarla.

R1(config-if)#shut
R1(config-if)#
*Mar  1 03:09:26.791: %HSRP-5-STATECHANGE: Vlan2 Grp 2 state Active -> Init
*Mar  1 03:09:28.799: %LINK-5-CHANGED: Interface Vlan2, changed state to administratively down
*Mar  1 03:09:29.799: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to downno shut
R1(config-if)#
*Mar  1 03:09:38.407: %LINK-3-UPDOWN: Interface Vlan2, changed state to up
*Mar  1 03:09:38.827: %HSRP-5-STATECHANGE: Vlan2 Grp 2 state Listen -> Active
*Mar  1 03:09:39.407: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to up

 Por último hay que añadir, que hay un comando bastante práctico que es el comando track, el cual permite, que si se cae otra interfaz nuestra prioridad de HSRP se decremente, es algo que se hace para cuando se cae un uplink en un switch de distribución, automáticamente el otro se ponga activo.

R1(config-if)#standby 2 track fastEthernet 0/0 120

Este comando lo que haría es que cuando se caiga la interfaz fa0/0 la prioridad de hsrp para este grupo, en esta ip, y en este router, se decremente en 120, que en el caso del ejemplo pasaría a tener 80.

Por último, y muy importante, HSRP es un protocolo propietario de cisco, por tanto para routers de otro fabricante tendrás que usar otro protocolo como VRRP.