Network Kings: Networking y tecnología en español: CCNP

Mostrando entradas con la etiqueta CCNP. Mostrar todas las entradas

jueves, 11 de septiembre de 2014

Mi topología para todo

Voy a compartir una topología con la que he estado trabajando últimamente. Se trata de una topología genérica de modo en que pueda con ella generar de manera lógica cualquier topología de una manera rápida.

A nivel físico es como más o menos se aprecia en la imagen:

Cuatro Switches unidos entre sí por dos puertos, no he puesto las conexiones cruzadas por no sobrecargar demasiado la topología, pero no es descartable.

Los dos Switches principales tienen un puerto conectado cada uno de ellos contra cada router de la topología, de este modo todos los routers tienen dos conexiones contra la LAN.

Hay 10 routers que están corriendo IOS. De este modo aunque sea una topología relativamente grande, con 10 routers corriendo IOS + 4 switches que llegado el caso también pueden hacer routing nos plantaríamos con 14 equipos con IOS.

Hay dos routers con IOS-XR (R1 y R2), estos equipos los tengo para cuando quiera emular topologías en las que influyan CRS. Están también conectado a la capa de switching de modo que se pueden incluir en cualquier topología con los IOS.

El laboratorio está pensado para trabajar con subinterfaces, pero llegado el caso si usamos interfaces físicas tampoco pasa nada.

Vlans:

Todos los switches tienen definidas un porrón de Vlans que permiten interconectar a los equipos, la nomenclatura de la vlan es XY, siendo X el primer router que conectan, e Y el segundo router que conectan.

Hago un copy paste de la definición de las VLANS en todos los switches.

vlan 12

name R1toR2

vlan 13

name R1toR3

vlan 14

name R1toR4

vlan 15

name R1toR5

vlan 16

name R1toR6

vlan 17

name R1toR7

vlan 18

name R1toR8

vlan 19

name R1toR9

vlan 111

name R1toR11

vlan 112

name R1toR12

vlan 23

name R2toR3

vlan 24

name R2toR4

vlan 25

name R2toR5

vlan 26

name R2toR6

vlan 27

name R2toR7

vlan 28

name R2toR8

vlan 29

name R2toR9

vlan 211

name R2toR11

vlan 212

name R2toR12

vlan 34

name R3toR4

vlan 35

name R3toR5

vlan 36

name R3toR6

vlan 37

name R3toR7

vlan 38

name R3toR8

vlan 39

name R3toR9

vlan 311

name R3toR11

vlan 312

name R3toR12

vlan 45

name R4toR5

vlan 46

name R4toR6

vlan 47

name R4toR7

vlan 48

name R4toR8

vlan 49

name R4toR9

vlan 411

name R4toR11

vlan 412

name R4toR12

vlan 56

name R5toR6

vlan 57

name R5toR7

vlan 58

name R5toR8

vlan 59

name R5toR9

vlan 511

name R5toR11

vlan 512

name R5toR12

vlan 67

name R6toR7

vlan 68

name R6toR8

vlan 69

name R6toR9

vlan 611

name R6toR11

vlan 612

name R6toR12

vlan 78

name R7toR8

vlan 79

name R7toR9

vlan 711

name R7toR11

vlan 712

name R7toR12

vlan 89

name R8toR9

vlan 811

name R8toR11

vlan 812

name R8toR12

vlan 911

name R9toR11

vlan 912

name R9toR12

vlan 666

name R11toR12

vlan 101

name R10toR1

vlan 102

name R10toR2

vlan 103

name R10toR3

vlan 104

name R10toR4

vlan 105

name R10toR5

vlan 106

name R10toR6

vlan 107

name R10toR7

vlan 108

name R10toR8

vlan 109

name R10toR9

vlan 110

name R10toR11

vlan 120

name R10toR12

¿Cómo se configuran los puertos de los switches?

Pues teniendo en cuenta que se supone que voy a usar subinterfaces todos los puertos van en trunk. Los puertos 0/0 a 0/3 son los que interconectan los Switches. El resto van a los routers.

int range ethernet 0/0 - 3

switchport trunk encapsulation dot1q

switchport mode trunk

int range ethernet 1/0 - 3

switchport trunk encapsulation dot1q

switchport mode trunk

duplex full

int range ethernet 2/0 - 3

switchport trunk encapsulation dot1q

switchport mode trunk

duplex full

int range ethernet 3/0 - 3

switchport trunk encapsulation dot1q

switchport mode trunk

duplex full

int range ethernet 4/0 - 3

switchport trunk encapsulation dot1q

switchport mode trunk

duplex full

Ejemplo básico de configuración:

Como se puede ver en el dibujo tenemos tres routers, R1(IOS-XR), R3 y R4. Los tres están hablando ospf, y para interconectarlos vamos a usar subinterfaces.

Configuración de R3:

interface Ethernet0/0

no ip address

!

interface Ethernet0/0.13

encapsulation dot1Q 13

ip address 192.168.13.3 255.255.255.0

!

interface Ethernet0/0.34

encapsulation dot1Q 34

ip address 192.168.34.3 255.255.255.0

router ospf 1

network 192.168.13.3 0.0.0.0 area 0

network 192.168.34.0 0.0.0.255 area 0

Configuración de R4:

interface Ethernet0/1

no ip address

!

interface Ethernet0/1.34

encapsulation dot1Q 34

ip address 192.168.34.4 255.255.255.0

router ospf 1

network 192.168.34.0 0.0.0.255 area 0

Configuración de R1:

cdp

interface GigabitEthernet0/0/0/2

cdp

!

interface GigabitEthernet0/0/0/2.13

ipv4 address 192.168.13.1 255.255.255.0

encapsulation dot1q 13

!

interface GigabitEthernet0/0/0/3

cdp

!

router ospf 1

router-id 192.168.13.1

area 0

interface GigabitEthernet0/0/0/2.13

Como se puede ver en la configuración, la vlan 13 comunica R1 con R3, y la vlan 34 comunica R3 con R4.

Vamos a hacer un ping:

P/0/0/CPU0:R1#sh route

Thu Sep 11 11:05:05.759 SGT

Codes: C - connected, S - static, R - RIP, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

       U - per-user static route, o - ODR, L - local, G - DAGR

       A - access/subscriber, (!) - FRR Backup path

Gateway of last resort is not set

C    192.168.13.0/24 is directly connected, 01:23:58, GigabitEthernet0/0/0/2.13

L    192.168.13.1/32 is directly connected, 01:23:58, GigabitEthernet0/0/0/2.13

O    192.168.34.0/24 [110/11] via 192.168.13.3, 01:19:02, GigabitEthernet0/0/0/2.13

RP/0/0/CPU0:R1#ping 192.168.34.4

Thu Sep 11 11:05:15.711 SGT

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.34.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms

Espero que a alguien más le sirva de ejemplo.

jueves, 25 de julio de 2013

BGP:Algoritmo selección ruta BGP

Uno de los pilares fundamentales para entender bgp es el algoritmo de selección de rutas o prefijos de BGP.

Para la gente acostumbrada a los IGP, BGP puede llegar a ser un poco confuso, este artículo pretende dejar claro como se decide que ruta se introduce en la tabla de rutas por BGP en un router cisco, en los routers de otros fabricantes el proceso va a ser muy similar, salvo por algunos detalles que se es exclusivo de Cisco.

BGP tan solo va a meter una ruta por defecto en la tabla de rutas para un único destino, esta ruta se elegirá comparando una serie de argumentos, que en caso de empate en el primero, se pasará al segundo, tercero, cuarto...etc hasta que se encuentre una ruta a considerar válida.

1. WEIGHT:

La ruta que tenga el mayor peso se instalará en la tabla de routing. Se trata de un atributo específico de Cisco Systems.

Se trata de un atributo que tan solo es representativo en el router, el router no le anuncia a otros routers que peso tienen las rutas, se trata de un mecanismo de control muy sencillo para elegir por donde queremos que el tráfico transite.

Una forma sencilla de configurarlo:

router bgp 200
neighbor 10.10.10.10 remote-as 100
neighbor 10.10.10.10 weight 200

También se pueden usar route-maps para fijar o matchear el weight.

2. LOCAL_PREFERENCE:

La ruta que tenga la mayor local preference se instala en la tabla de routing. Se trata de un atributo que es significativo en el sistema autónomo local, por lo que se anuncia a routers del mismo AS para influirlos, pero no se anuncia a routers de otros AS.

Por defecto el valor de la local preference es 100.

Forma de configurarlo:

router bgp 200
neighbor 10.10.10.10 remote-as 100
bgp default local-preference 200

Tambíen se pueden usar route-maps para fijar o matchear la local preference.

3. Redes originadas por medio de un network o un aggregate-address:

Estas rutas apareceran como internal en los routers, al contrario que las rutas que han sido redistribuidas de otro protocolo de routing...etc.

4. La ruta que pase por menos sistemas autónomos:

Por defecto BGP intenta pasar por el mínimo número de sistemas autónomos, para evitar bucles de routing.
Se puede configurar que a ciertas rutas se les añadan AS en el atributo AS PATH para que el resto de
routers penalicen estas rutas.

router bgp 65001
neighbor 10.1.0.3 remote-as 65100
neighbor 10.1.0.3 route-map prepend out
!
route-map prepend permit 10
set as-path prepend 65001 65001 65001

5. Origen mas bajo:

Esto es simplemente que las rutas cuyo orígen es un IGP o locales, son preferidas a las aprendidas por un EGP, y estas son preferidas ante las rutas con orígen incompleto.

6. Rutas con un campo MED menor:

Por defecto los routers anuncian las rutas con el campo MED a 0, pero cuando son rutas redistribuidas de otro protocolo en BGP se añade la métrica del IGP al atributo MED en la ruta de BGP.
Por supuesto, como todo, se puede cambiar o matchear con route-maps.

Un documento muy bueno para leer con una buena dosis de café encima, que trata esto y muchas otras cosas es:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

lunes, 3 de septiembre de 2012

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#

miércoles, 29 de agosto de 2012

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.

miércoles, 22 de agosto de 2012

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

lunes, 20 de agosto de 2012

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