Alternativas al Spanning Tree Protocol

ALTERNATIVAS AL SPANNING TREE PROTOCOL 1

Universidad Interamericana

Recinto de Guayama

Topic Paper: Alternativas al Spanning Tree Protocol

CSNS 5131 - Tecnologías de Conmutadores 1

José Andrés Dominicci Albarrán

Número Estudiante E00122717

Profesor: Dr. José R. Colón


Tabla de Contenido

Introducción ............................................................................................................ 3

Spanning Tree Protocol (STP) ................................................................................ 4

Rapid Spanning Tree Protocol (RSTP) ................................................................... 7

Multiple Spanning Tree Protocol (MSTP) .............................................................. 9

Cuando Spanning Tree Protocol (STP) Colapsa una Red Completa .................... 10

Alternativas al Spanning Tree Protocol (STP) ..................................................... 12

Multi-Chassis Link Aggregation Group (MC-LAG) ........................................ 12

Shortest Path Bridging (SPB) ........................................................................... 14

Transparent Interconnection of Lots of Links (TRILL) ....................................... 17

Conclusión ............................................................................................................ 20

Referencias ............................................................................................................ 21


Introducción

Durante el estudio del curso de Introducción a Conmutadores un tema que

siempre me llamó la atención fue el Spanning Tree Protocol (STP) y su importante

función en nuestra red Ethernet para mantenerla redundante y libre de “loops”. A la vez

comencé a notar muchas críticas de autores: como el que solo permite un camino activo

simple entre dos nodos de la red, como los atributos mismos del STP limita la

escalabilidad de la red y la debilidad más grande, el tiempo de convergencia al fallar un

enlace. Esta situación se agudiza más con la falta de compatibilidad del protocolo con las

nuevas tendencias de la nube en el internet.

El avance del mismo protocolo pero con otros nombres como Rapid Spanning

Tree Protocol (RSTP) y el Multiple Spannning Tree Protocol (MSTP) muestra a su vez la

aceptación de la comunidad del algoritmo detrás de éste.

También discutiremos un caso en particular, el del Centro Médico Beth Israel

Deaconess, donde en el 2002 su sistema de red colapso por un problema en el STP.

Veremos que fue lo que ocasionó el fallo y como las mismas limitaciones del STP fueron

el causante.

Este trabajo tiene la intención de mostrar alternativas que pudieran o están siendo

utilizadas tanto, propietarias como estandarizadas. Entre ellas prestaremos particular

atención a Multi Chassis Link Aggregation Group (MC-LAG), Shortest Path Bridging

(SPB) y Transparent Interconnection of Lots of Links (TRILL).


Spanning Tree Protocol (STP)

Spanning Tree Protocol (STP) es un protocolo que corre en la capa 2 del Open

System Interconnection (OSI) en conmutadores. La especificación de este protocolo esta

definida por el IEEE 802.1d y aunque hay diferentes tipos, esta especificación es la más

aceptada y usada. Su propósito principal es asegurar que no se creen “loops” cuando

tenemos enlaces redundantes a nivel físico de nuestra red. Los “loops” son mortales para

el funcionamiento de una red. A continuación mostramos la figura 1 que muestra una red

con enlaces redundantes.

Figura 1: Diagrama Red Tipo “Mesh” (Cisco, 2006)

Los enlaces redundantes en nuestra red son tan importantes como los resguardos

de datos ya que en caso de que un conmutador deje de funcionar estos enlaces

redundantes permiten que continúe la comunicación de los dispositivos en la red. Sin

STP implementado en la red una falla provocaría la creación de un “loop”.


Es importante señalar que cuando se usan diferentes tipos de STP estos requieren

diferentes tiempos de convergencia. Estos diferentes tiempos de convergencia crean un

problema que afectan los estados de bloqueo y adelanto. Por lo tanto se recomienda la

utilización de un mismo tipo de STP cuando se implementa en la red.

La clave en STP es que los conmutadores en la red elijan cual será el “root

bridge” este será el foco principal de la red. Todas las decisiones en la red tales como

cual puerto bloquear y cual puerto estará en modo de adelanto se hacen desde la

perspectiva del “root bridge”. Si estamos trabajando en un ambiente con solo

conmutadores se le conoce al “root bridge” como “root switch”. Con la utilización de

conmutadores damos paso a la creación de VLANs donde cada VLAN tendrá su propio

“root bridge” ya que operan un dominio de transmisión diferente. Los “roots” de

diferentes VLANs pueden ser configurados para que residan en un solo conmutador o en

varios.

Todos los conmutadores intercambian información que contribuirá a la selección

del “root switch” y para la configuración subsiguiente de la red. Bridge Protocol Data

Units (BPDU) son los que cargan con esta información. Cada conmutador compara los

parámetros en los BPDU que el conmutador a un vecino con los parámetros en el BPDU

que el conmutador recibe de su vecino. En la selección del “root” en STP, mientras

menos mejor. Si el conmutador A anuncia un “root id” que es más bajo que el “root id”

que el conmutador B, la información del conmutador A es mejor. El conmutador B

entonces para de anunciar su “root id” y acepta el del conmutador A. (Cisco, 2006).

La desventaja principal del STP es su tiempo de convergencia que es el tiempo

que toma la red en recuperarse cuando hay un cambio de topología. Para STP este tiempo


fluctúa entre 30 a 50 segundos dependiendo del tamaño de la red y cuan bien se haya

configurado los parámetros del protocolo. Otra desventaja es que retiene en las

direcciones MAC que no se usan mucho después de que haya un cambio en la topología

de la red. Esto puede crear “loops” temporales ya que los “data frames” son enviados a

los puertos equivocados, por la falta de información actualizada en la tabla MAC. Para

finalizar, la centralización de la toma de decisiones de un “root bridge” y la que solo

permite un camino activo simple entre dos nodos de la red, nos lleva a pensar en otras

soluciones más efectivas.


Rapid Spanning Tree Protocol (RSTP)

El STP fue concebido en un época donde el tiempo de convergencia de cerca de

un minuto era aceptable. Con el advenimiento de conmutadores con capacidad de

realizar tareas a nivel de Capa 3 del OSI esa solución (STP) competía con protocolos de

Capa 3 mucho más avanzados y rápidos como el Open Shortest Path First (OSPF) y el

Enhanced Interior Gateway Routing Priotocol (EIGRP) que proveen tiempos de

convergencia en mucho menos tiempo.

El RSTP es un estándar IEEE 802.1w y se podría interpretar como un avance o

evolución del el estándar 802.1d, más que una revolución. El RSTP mantiene

compatibilidad con el STP pero tiene varias diferencias que amilanan algunas las

desventajas del STP, entre estas el tiempo de convergencia. Para lograr más rapidez en

los tiempos el RSTP solo permite conexiones entre conmutadores a “full duplex”. STP y

RSTP también tienen designaciones diferentes de sus puertos, entre ellos y los que le dan

más rapidez de convergencia entre estos: puerto alterno y puerto de resguardo.

Estos dos puertos no están en modo de envío sino que están listos para entrar en

acción al momento que haya una falla en la red. Al esta ser su única función pueden

reaccionar de una forma más rápida para convergir la red y que ésta siga funcionando.

También supera el problema de mantener información de MACs fuera de uso en la tabla

de direcciones MAC, esto lo logra cuando hay un cambio de topología generado por el

conmutador que lo detecta de inmediato y envía la información para que se saque la

dirección de la tabla de direcciones MAC.

Una desventaja que podemos encontrar en el RSTP es cuando ocurre una falla

indirecta. Cuando esto ocurre el tiempo de convergencia puede tomar hasta 50 segundos,


la misma cantidad de tiempo que STP. Pero cabe señalar que RSTP toma un rol activo en

la convergencia y no espera pasivamente por los relojes de tiempo a que expiren antes de

hacer la transición a un “non-edge port” como es el caso de STP.


Multiple Spanning Tree Protocol (MSTP)

La implementación del Multiple Spanning Protocol (MSTP) esta definida en el

estándar IEEE 802.1s. La convergencia de MSTP cuando hay un cambio de topología es

rápida por que va implementada sobre el Rapid Spanning Tree Protocol (RSTP). MSPT

provee la capacidad de un equilibrio en la carga sin los problemas de escalabilidad que

acompañan al Spanning Tree Protocol (STP). MSTP permite la creación de redes de

Capa 2 más grandes lo cual logra creando dominios o regiones que contienen dispositivos

específicos que operan en la Capa 2.

Una región, similar a la administración de un dominio, es una colección de

VLANs que tienen la misma configuración y son manejados bajo la misma sombrilla del

MSTP. A diferencia de implementaciones propietarias de “spanning trees” por VLAN,

MSTP incluye toda la información del “spanning tree” en un solo formato Bridge

Protocol Data Unit (BPDU). Esto, no solo reduce los números de BPDUs requeridos en

una red para comunicar la información de “spanning tree” para cada VLAN, sino que

también guarda compatibilidad con RSTP y STP.

Una de las ventajas de MSTP es que a pesar de que opera con el concepto de

regiones, al ser compatible con RSTP permite que los conmutadores corriendo RSPT

vean a las diferentes regiones como una sola implementación de RSPT.

Las desventajas son las inherentes al mantener compatibilidad con los protocolos

RSTP y STP. La configuración errónea de parámetros en MSTP podría también los

problemas de convergencia a velocidades no aceptables.


Cuando Spanning Tree Protocol (STP) Colapsa una Red Completa

En noviembre 13 de 2006 mientras un médico del Centro Médico Beth Israel

Deaconess procesaba montañas de datos sobre una investigación que realizaba, recibe la

llamada del Dr. John Halamka, encargado del sistema de redes del hospital. En la mente

de este médico con todos los datos que estaba entrando, él estaba aportando y

contribuyendo a la comunidad científica, cuando de súbito una llamada, la llamada lo

alerta que la cantidad de números y cálculos que entraba amenazaba con la paralización

de miles de records médicos electrónicos y estaba a punto de paralizar la red del hospital

completamente.

De sus labios solo se escucho – “¡Oh Dios!” y literalmente desconecto el sistema

del enchufe de la pared, pero para entonces ya era muy tarde. En algún lugar dentro de la

red de fibras ópticas y cables que conectan sus dos recintos y oficinas satélites los datos

se habían estancado en un “loop” eterno. Los técnicos procedieron a apagar parte de la

red para contener el problema pero eso lo que hizo fue crear una mar de problemas

adicionales. El sistema completo colapso, congelando el envío masivo de información a

través del Centro Médico como organización. El causante del problema el Spanning Tree

Protocol (STP).

La red de la institución estuvo detenida por cuatro días mientras que el personal

técnico y los ingenieros buscaban la causa del problema. Durante muchos años los

ingenieros de redes creían que el STP era la solución perfecta y más segura para

mantener una red redundante y libre de “loops”, a pesar de saber que resultaba en un

sistema más lento.


¿Pero que fue lo que ocurrió, que ocasionó que el STP colapsara el sistema de red

en su totalidad? El problema principal de la institución es que la protección del

“spanning” que utilizó entro a niveles muy profundos, sin tomar en cuenta los patrones de

tráfico y las reglas de convergencia. El número de niveles de protección permitidos por

el STP son 7 y ellos tenían en algunos hasta 10 niveles.

¿Cual es la consecuencia de esto? Lo que hace esto es que los 10 niveles creen un

“loop” tipo cascada cuando un evento lo desencadena. ¿Que puede desencadenar tal

evento? Algo tan simple como un aumento en el flujo de trafico por un nodo en

particular, la degradación de una fibra óptica o un cable dañado. Muchas veces estas

redes son creadas con estos diseños peligrosos por varias razones como: costos,

desconfianza en otras tecnologías emergentes o falta de conocimiento de cómo un “loop”

reacciona en una red de producción.

El STP fue creado para prevenir “loops” accidentales cuando la velocidad

máxima de un nodo en la red era 10 Mbps, todos los puntos de conexión eran “half-

duplex” y los puertos estaban restringidos a 1 o 2. Hoy día las velocidades pueden

alcanzar hasta 10Gbps y decenas de puertos, lo cual puede crear un potencial desastre si

ocurre un “loop” accidental.

Por eso la importancia de comenzar a buscar nuevos métodos y protocolos que se

atemperen a la realidad de las redes actuales, comenzaremos a discutir en las siguientes

secciones algunas alternativas.


Alternativas al Spanning Tree Protocol (STP)

Multi-Chassis Link Aggregation Group (MC-LAG)

Link Aggregation Group (LAG) es un mecanismo utilizado para agrupar

múltiples enlaces Ethernet en un enlace lógico para proveer más ancho de banda y

redundancia de enlaces. (Seifert & Edwards, 2008). Link Aggregation provee agregación

física al enlace de ancho de banda y redundancia pero no provee redundancia a nivel de

nodo.

Multi-Chassis Link Aggregation Group (MC-LAG) es una solución propietaria

que provee ambas redundancias, tanto de enlace como de nodo en nuestra red Ethernet.

La solución MC-LAG es transparente al dispositivo CE1. Desde la perspectiva del

dispositivo CE un LAG con varios links están conectados al proveedor de servicio como

normalmente suelen estar. Solo, que el CE no sabe que estos enlaces que pertenecen al

mismo LAG están conectados a dos enrutadores PE2 en vez de uno. El LAG tendrá

algunos enlaces que estarán activos y otros que estarán en espera (“standby”) (Ver Figura

2). El protocolo MC-LAG comenzará a intercambiar información entre los enrutadores

PE y asignando que puertos estarán activos y que puertos estarán en tiempo de espera.

En caso de que uno de los puertos activos fallará inmediatamente uno de los puertos que

están en espera pasan a modo de activo inmediatamente.

1 Customer Edge – es el enrutador instalado en las facilidades del un cliente a un

proveedor de servicios. 2 Provider Edge – es el enrutador que esta localizado en las facilidades del

proveedor de servicio.


Figura 2 – Ejemplo de sistema configurado para MC-LAG

Algunas de las ventajas del MC-LAG son:

• Transparencia al Cliente – El cliente en ningún momento tiene

conocimiento de lo que esta ocurriendo.

• No requiere de ninguna configuración del lado de los clientes.

• No requiere de STP – STP no es necesario, ya que el protocolo mismo se

encarga de la convergencia y la prevención de “loops”.

• Es ideal para el uso de computación en la nube. (Cisco Systems, 2012)

Una de las desventajas que tiene el MC-LAG es que requiere que los PE a utilizar

sean de la compañía Alcatel-Lucent ya que la tecnología es propietaria de ellos. Aunque

algunos enrutadores Cisco han comenzado a utilizar este protocolo (Cisco Systems,

2012). El CE no es necesario que sea de Alcatel-Lucent.


Shortest Path Bridging (SPB)

Shortest Path Bridging (SPB) es el estándar IEEE 802.1aq y es considerado por la

organización como el próximo paso en la evolución de los protocolos de registros y

“spanning tree” (Ashwood, 2012). SPB permite en una red tipo “mesh” la selección del

camino más corto utilizando el cálculo de múltiples costo de caminos. Esto permite la

creación de topologías de red a nivel de Capa 2 mucho más grandes, con tiempos de

convergencia más rápidos y la utilización inteligente de la topología “mesh”, punto

provisional de membresía lógica, extracción de dirección MAC de dispositivos en

tránsito y replicación “multicast”.

Una de las razones que SPB ha sido estandarizado por el IEEE es para

eventualmente reemplazar a STP como el estándar en prevención de “loops” y

convergencia. (TechTarget, 2011) El protocolo de control para SPB es IS-IS3 con un

pequeño número de TLVs4 y sub-TLVs. Esto hace que pueda trabajar con dos caminos

de datos encapsulados Ethernet, el 802.1aq (Provider Bridges) y 802.1ah (Provider

Backbone Bridges) (Ashwood, 2012).

La base de datos de filtración utilizada es poblada a consecuencia de la topología

computada por IS-IS. SPB tiene múltiples formas de operación dependiendo del tipo de

datos a ser utilizados y el comportamiento deseado. Hay dos modos iniciales de

operación SPBV y SPBM. Con el SPBV múltiples VLANs pueden ser utilizadas para

distribuir la carga en diferentes caminos más cortos a base de sus servicios. Con SPBM

3 Protocolo de enrutamiento diseñado para mover información más eficientemente

en una red. 4 Codificación que consiste de tres campos: tipo, largo y valor.


cada instancia de servicio es delineado por I-SID5s pero los VLANs también pueden ser

utilizadas de la misma forma que SPBV.

SPB está diseñado para hacer frente al problema de “loops” y convergencia

aplicando un protocolo de enrutamiento de Capa 3 en dispositivos de Capa 2. Esto

esencialmente lo que permite es que se haga enrutamiento pero de “data frames” a nivel

de Capa 2. Los proponentes del SPB reclaman que al sacar el STP y liberar más

caminos de Capa 2, las empresas estarán mejores posicionadas para migrar a máquinas

virtuales a través de la red central de datos. A la vez esto provee más ancho de banda

para aplicaciones intensivas de comunicación a tiempo real (ej. video, música).

Es importante resaltar que en el 2011 fue evaluado y aprobado para ser

desplegado dentro del Departamento de Defensa de los Estados Unidos por su facilidad e

integración con “Operations and Management (OA&M) y la interoperabilidad con

protocolos actualmente utilizados. (Clark, 2008).

Algunas de las ventajas de SPB son:

• Estandarización por IEEE

• Virtualización de Servidores

• Facilidad de Despliegue en Centros de Datos

• Utilización en sistemas de nube (“cloud”)

Una de las mayores desventajas que tiene SPB en este momento es la falta de

apoyo de Cisco al protocolo. Cisco actualmente ve con mas futuro el Transparent

Interconnection of Lots of Links (TRILL). Uno de sus principales ejecutivos fue

5 I-SID – Includes Service Instance Identifier


cuestionado sobre el apoyo de Cisco y este contesto: “No tenemos planes de apoyar SPB,

estaremos trabajando con TRILL”. (Kerner, 2011). Uno de los problemas que

particularmente ve Cisco con SPB es el compromiso de IEEE de mantener

compatibilidad con STP, lo cual ante los ojos de Cisco es una limitación a la evolución de

la tecnología al estar amarrado a tecnologías pasadas. (Metzler, 2011).


Transparent Interconnection of Lots of Links (TRILL)

El Transparent Interconnection of Lots of Links (TRILL) es un estándar de

protocolo del Internet Engineering Task Force (IETF). Al igual que SPB, TRILL busca

reemplazar al STP. El Dr. Radia Perlman inventor del SPT, creó TRILL y lo llevó a la

consideración de IEEE para ser revisado e implementado como estándar, pero éstos se

rehusaron, entendiendo que no había la necesidad de introducir enrutamiento IP a nivel

de Capa 2 y muchos menos brincos (hops). (Shamus, 2011).

Perlman le presento la idea a IETF y estos inmediatamente lo autorizaron a crear

un grupo de trabajo para crear el estándar. A medida del crecimiento de Centros de

Datos, virtualización y la nube, IEEE entonces se dio cuenta de la necesidad de buscar

una alternativa a STP, adoptando así el SPB.

TRILL utiliza técnicas de enrutamiento de la Capa 3 para crear una nube amplia

de enlaces que ante los nodos que utilizan IP es una subred IP, utilizando la ventaja de

técnicas IP como rutas más cortas y multi-rutas. (Perlman & Eastlake, 2011). TRILL

ademas brinda apoyo a VLANs, tiene la capacidad de auto-configurarse y transmisión

“multicast” sin la necesidad de otro protocolo.

Una de las razones por la que TRILL es revolucionario es, que en un centro que

tenga equipo de Capa 2 como los conmutadores, éstos pueden ser convertidos a una nube

TRILL substituyendo un subgrupo de los conmutadores con dispositivos que incorporen

TRILL. Los dispositivos que utilizan el estándar TRILL se le conocen como “Routing

Bridges” o “RBridges”. Según se van remplazando los conmutadores, nada cambia para

los nodos IP que ya están conectados a la nube excepto que la nube se convierte en una

más estable y utiliza el ancho de banda más eficientemente.


Una de las ventajas de TRILL es que permite la facilidad de configuración de una

red Ethernet a la vez que se beneficia de técnicas de enrutamiento provistas en la Capa 3.

También puede coexistir con conmutadores existentes, por lo tanto no es necesario

cambiar todos los conmutadores en la red. Lo que si debemos es entender las

necesidades de la organización que esta actualizando su red y saber cuales son los

conmutadores que se substituirán por RBridges. Usualmente este tipo de decisión es

tomada con los criterios de inversión económica de la organización.

Ahora bien, mientras más conmutadores remplacemos mejor será la utilización

del ancho de banda y más pequeño se va haciendo el STP. Mientras más RBridges se van

instalando STP sigue achicándose hasta desaparecer cuando todos los conmutadores sean

remplazados.

A continuación utilizando la figura 3 explicaremos los conceptos básicos de

TRILL en el manejo de paquete “unicast” donde la localización de destinatario es

conocida.

Figura 3: RBridging


• RBridges corre un protocolo de enrutamiento de estado de enlaces, el cual le da el

conocimiento de todos los RBridges en la red y todos los enlaces entre los

RBridges. Utilizando este protocolo cada RBridge calcula la distancia más corta

de si mismo a cada uno de los otros RBridge y crea un tipo de árbol de

información para entregar el tráfico multidestino.

• Cuando R1 recibe el “frame” Ethernet del nodo S, dirigido al destino Ethernet D,

R1 encapsula el “frame” en un encabezado (header) TRILL, enviando el paquete

a R2, al cual D esta conectado. El encabezado TRILL contiene un campo de

ingreso Rbridge (R1), y un campo de egreso RBridge (R2) y un contador de

brincos.

• Cuando R2 recibe el paquete encapsulado, R2 remueve el encabezado TRILL y

envía el paquete Ethernet a D.

Como se ve el encabezado TRILL y como R1 sabe que R2 es el RBridge de

egreso correcto es a través del protocolo IS-IS (también utilizado en SPB).

Una de las mayores desventajas de TRILL es la inversión en equipo nuevo. Tal

vez en una nueva organización esto no sería un problema, pero en organizaciones con

Centros de Datos con miles de conmutadores puede convertirse en una solución muy

costosa. Aunque si la organización esta comprometida a implementar TRILL tiene la

ventaja que lo puede hacer poco a poco.


Conclusión

STP para efectos prácticos en los nuevos centros de datos donde la

implementación de la nube, virtualización de las redes y la sabia utilización del ancho de

banda son primordiales es un protocolo que está mostrando su edad y llegando al final de

su vida útil a gran escala.

Luego de estudiar detenidamente las referencias adjuntas a esta investigación,

concluyó que eventualmente STP será substituido por SPB o TRILL. Al igual que

muchas tecnologías donde implementaciones similares son adoptadas por bandos,

ejemplo de esto el Blu-Ray y HD-DVD, uno de los dos estándares será el defecto a largo

plazo.

Entiendo que TRILL será el vencedor a final del día por el apoyo que tiene de

mogoles de la industria de redes como lo es Cisco en este caso y el haber sido creado por

el inventor del STP tiene su peso, por el gran servicio que STP ha rendido y sigue

rindiendo a las redes actuales.

Aunque creo que una de las desventajas mayores es, la inversión en cambios de

equipo nuevo, con la recesión mundial las organizaciones de todo tamaño tienen sus

presupuestos muy medidos y fiscalizados. Mientras, SPB funciona prácticamente sin

tener que remplazar muchos conmutadores. Otra ventaja que le veo a SPB es la adopción

como estándar e implementación en el Departamento de Defensa de Estados Unidos.

Aunque esto no es concluyente de una inminente adopción. Solo el tiempo, las

necesidades y tendencias de los centros de cómputos tendrán la palabra final.


Referencias

Ashwood-Smith, P., & Fedyk, D. (2012). IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. Recuperado de http://tools.ietf.org/html/rfc6329

Cisco. (2006). Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches. Recuperado October 15, 2012, de http://www.cisco.com/en/US/tech/tk389/tk621/technologies_configuration_example09186a008009467c.shtml

Cisco Systems. (2001). Designing MPLS Extensions for Customer Edge Routers. Cisco Systems.

Cisco Systems. (2004). Cisco Networking Academy Program: CCNA 3 and 4.

Cisco Systems. (2006). Understanding Rapid Spanning Tree Protocol (802.1w) [Spanning Tree Protocol]. Recuperado October 16, 2012, de http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

Cisco Systems. (2012). Distributed Virtual Data Center for Enterprise and Service Provider Cloud [Data Center Interconnect]. Recuperado October 17, 2012, de http://www.cisco.com/en/US/prod/collateral/routers/ps9853/white_paper_c11-694882_ns975_Networking_Solutions_White_Paper.html#wp9000133

Clark, B. Defense Information Systems Agency Memorandum (2008).

Faur, A. (2009). STP/RSTP implementation in LiSA. University “Politehnica” of Bucharest.

Greene, T. (2010). IBM to expand mobile unified Double your bandwidth , Necessity of new IETF. NetworkWorld, 4–7.

Hoffman, E. (2005). All Systems Down — Reprise.

Interop Las Vegas 2013. (2012). Recuperado October 17, 2012, de http://www.interop.com/lasvegas/2012/speaker-list/?speaker=shehzad-merchant

Kerner, S. (2012). Will TRILL or Shortest Path Bridging Win Out? Enterprise Networking Planet. Recuperado October 15, 2012, de http://www.enterprisenetworkingplanet.com/datacenter/will-trill-or-shortest-path-bridging-win-out.html

Metzler, J. (2011). What’s the Best Alternative to the Spanning Tree Protocol  ?, (October 2011).


Metzler, J., & Taylor, S. (2011). What’s the best alternative to Spanning Tree? NetworkWorld. Recuperado October 15, 2012, de http://www.networkworld.com/newsletters/frame/2011/082911wan1.html

Need, T., & Tree, S. (2012). TRILL Deployment Nears.

Palacios, E. (2011). TRILL gana presencia en las redes de los nuevos centros de datos | ECUDATOS. EcuDatos. Recuperado October 15, 2012, de http://www.ecudatos.com/2011/03/trill-gana-presencia-en-las-redes-de-los-nuevos-centros-de-datos/

Perlman, R., & Eastlake, D. (2011). Introduction to TRILL. The Internet Protocol Journal, 14(3), 2–21. doi:10.1158/2159-8290.CD-ITI12-10

Seifert, R., & Edwards, J. (2008). The All-New Switch Book (2nd Editio.). Indianapolis: Wiley Publishing, Inc.

Shamus. (2011). TRILL versus Shortest Path Bridging: Hard feelings? The Network Hub. Recuperado October 18, 2012, de http://itknowledgeexchange.techtarget.com/networkhub/trill-versus-shortest-path-bridging-hard-feelings/

What is shortest path bridging? - Definition de WhatIs.com. (2011).TechTarget. Recuperado October 17, 2012, de http://searchnetworking.techtarget.com/definition/Shortest-path-bridging

Xu, F. (2010). Designing and Implementing IP/MPLS Based Ethernet Layer 2 VPN Services: An Advanced Guide for VPLS and VLL. Indianapolis: Wiley Publishing, Inc.

Alternativas al Spanning Tree Protocol

Documents

Transcript of Alternativas al Spanning Tree Protocol