Verificacion de Alta Disponibilidad en Anillos de Agregacion de ISP

7/23/2019 Verificacion de Alta Disponibilidad en Anillos de Agregacion de ISP

http://slidepdf.com/reader/full/verificacion-de-alta-disponibilidad-en-anillos-de-agregacion-de-isp 1/36

Carrera de Especialización en Tecnologías de Telecomunicaciones

Trabajo Final Integrador

Tema: Plan de Mantenimiento Lógico a Red de Datos

Título: Verificación de Alta Disponibilidad en Anillos de Agregación de

Proveedor de Servicios

Autor: Stephen Rodríguez Ortegón

Año: 2015



Dedicado a las mi hijo Thomas, a mi papá y a Catalina.

Por ser una gran inspiración para mí.




3 | R E S U M E N

Verificación de Alta Disponibilidad en Anillos de Agregación de


RESUMEN

Se presenta el diseño de un Method Of Procedure para la evaluación de Alta Disponibilidad en los

anillos de Agregación basados en MPLS de un Service Provider . Este Protocolo de Actividades permiterealizar, únicamente con acceso a los equipos de Backbone, la revisión y medición de los tiempos de

convergencia de las redundancias en varios niveles: Capa 3 de conectividad con los equipos Provider

Egde, Capa 2 de conectividad entre Customer Egde dentro de una VPLS y a nivel de Hardware de las

controladoras.




4 | C O N T E N I D O Verificación de Alta Disponibilidad en Anillos de Agregación de


TABLA DE CONTENIDO

RESUMEN ................................................................................................................................................ 3

TABLA DE CONTENIDO ............................................................................................................................ 4

INTRODUCCIÓN ....................................................................................................................................... 5

2. MARCO TEÓRICO ............................................................................................................................. 6

2.1. Redes Capa 2 ........................................................................................................................... 6

2.1.1. Redes 802.1Q .................................................................................................................. 6

2.1.2. Redes 802.1AD – Provider Bridges .................................................................................. 7

2.2. Red Privada Virtual o VPN (Virtual Private Network ) .............................................................. 8

2.2.1. L2VPN Punto a Punto ...................................................................................................... 92.2.1.1. L2VPN Martini ........................................................................................................... 10

2.2.1.2. L2VPN Kompella ........................................................................................................ 11

2.2.2. L2VPN Punto a Multipunto ............................................................................................ 12

2.2.2.1. Componentes de una VPLS ........................................................................................ 13

2.2.2.2. Plano de Forwarding ................................................................................................. 14

2.2.2.3. Plano de Control ........................................................................................................ 14

3. DISEÑO DE LA RED DE PRUEBA ..................................................................................................... 19

3.1. Topología de la Red ............................................................................................................... 19

3.1.1. LDP-VPLS entre Nodos U-PE .......................................................................................... 19

3.1.2. BPG-VPLS entre Nodos N-PE ......................................................................................... 20

3.1.3. Interoperación entre BGP-VPLS y LDP-VPLS .................................................................. 22

4. PROTOCOLO DE PRUEBAS ............................................................................................................. 25

4.1. Diseño del Protocolo ............................................................................................................. 25

4.2. Resultados ............................................................................................................................. 26

5. CONCLUSIONES ............................................................................................................................. 28

6. ANEXOS.......................................................................................................................................... 29

6.1. MOP ....................................................................................................................................... 29

6.2. Snapshot Sistema .................................................................................................................. 33

7. LISTA DE FIGURAS .......................................................................................................................... 34

8. BIBLIOGRAFÍA ................................................................................................................................ 35




5 | I N T R O D U C C I Ó N Verificación de Alta Disponibilidad en Anillos de Agregación de


INTRODUCCIÓN

Usualmente los Service Provider requieren ofrecer una disponibilidad de 99.999% y alrededor de

50mseg de tiempo de restauración ante una falla, en mecanismos de protección entre los puntos determinación del servicio final y los nodos de la red [1]. De no cumplir con el Service Level Agreement

se exponen al pago de penalidades, de modo que están obligados a monitorear y comprobar la

redundancia de servicios en la red para asegurar dicho nivel de servicio. Estos requerimientos hacen

necesario el uso de un Protocolo de Actividades para la revisión de Alta Disponibilidad que permita

ejecutar el chequeo, idealmente sin disrupción de servicio.

Los equipos Carrier Class ofrecen redundancia a varios niveles para mantener su Alta Disponibilidad y

por ello los fabricantes usualmente diseñan métodos de chequeo de estas redundancias; los

manuales donde se explica como realizarlo son de dominio publico. Sin embargo, no ofrecen Best

Practices para la revisión de redundancia en anillos.

El área de Soporte del Service Provider debe proponer métodos para hacer el chequeo preventivo de

la disponibilidad de los servicios que corren en la red. Muchas empresas delegan esta

responsabilidad en el Vendor o el Partner que realiza la implementación de la red. Sin importar quien

tome a su cargo esta labor, se espera hacer uso de la menor cantidad de recursos disponibles y por

esta razón se propone realizar un Method Of Procedure que evite herramientas adicionales a la

simple conectividad con los equipos.

En este documento se realiza un plan esquemático de las pruebas que se deben realizar para

comprobación de Alta Disponibilidad en Capa 2 y Capa 3 de una arquitectura de red especifica. Se

presenta un Method of Procedure con el que realizan pruebas de efectividad del procedimiento. Las

pruebas se realizan en un escenario real que permite realizar una estadística de los tiempos de

convergencia de anillo en capa 3, tiempo de convergencia de VPLS en capa 2 y tiempo de

redundancia de placas controladores. Nunca se mencionará el Service Provider en el que se realizan

las pruebas.

En la primera parte del documento se hace un acercamiento teórico a las VPN Capa 2, haciendo

énfasis en VPLS. En el capitulo siguiente se explica la arquitectura de la red de prueba y la

configuración de los anillos de Agregación para los cuales se diseña el protocolo. Posteriormente se

analizan la variables a medir y los puntos que se desean evaluar para la fabricación del protocolo.

Finalmente se presentan los resultados de la ejecución del protocolo y las conclusiones del proyecto.




6 | M A R C O T E Ó R I C O Verificación de Alta Disponibilidad en Anillos de Agregación de


2. MARCO TEÓRICO

2.1.

Redes Capa 2

2.1.1.

Redes 802.1Q

Ethernet es la tecnología de acceso más difundida actualmente; se estandarizó por primera vez como

IEEE 802.3 [2] y se utiliza para redes de área local o Local Area Networks (LAN). Posteriormente se

introdujeron ampliaciones como IEEE 802.1Q [3] en la que se agrega una etiqueta de Virtual LAN

(VLAN) que permite separar virtualmente hasta 4096 dominios de Broadcast .

Ilustración 1. Formato de trama 802.3 + 802.1Q [1]

El formato de la trama 802.3 presentado en la Ilustración 1 está compuesto por los siguientes

campos:

PRE = Preamble o Preámbulo.

SFD = Start of Frame Delimiter o Delimitador de comienzo de trama.

DA = Destination Address o Dirección Destino.

SA = Source Address o Dirección Origen.

Lenght / Type = Longitud de trama / Tipo de Protocolo Capa 2.

Data(Pad) = Datos (Payload o carga útil).

FCS = Frame Check Secuence o Secuencia de Chequeo de Trama.

Posteriormente con 802.1Q se le agrega una etiqueta dividida en dos partes:

TPID = Tag Protocol ID o Etiqueta Identificadora de Protocolo también conocido como Ethertype. Se

configura como 0x8100 para tramas 802.1Q.

TCI = Tag Control Information o Etiqueta de Información de Control, internamente está compuesta

por los siguientes campos:

Priority = Prioridad, 23 equivalente a 8 prioridades.

CFI = Canonical Format Indicator o Indicador de Formato Canónico que permite identificar el formatode la trama, se usa cero para Ethernet.




7 | M A R C O T E Ó R I C O



VID = VLAN Identifier o VLAN ID, este permite separar los 4096 dominios (12 bits).

Por convención, se hará referencia al prestador de servicios de conectividad como Proveedor de

Servicios de Internet o Internet Service Provider (ISP). Si un Service Provider utilizase únicamente

802.1Q podría ofrecer sólo 4096 servicios Capa 2 en su red y al mismo tiempo no sería posible que elcliente separara su propio tráfico Capa 2 en otros dominios de Broadcast . En tal caso, los clientes

deberían usar 802.3 (Ethernet sin VLAN) como se muestra en la Ilustración 2, porque de lo contrario

no se podrían diferenciar las VLAN del Service Provider .

Ilustración 2. 802.1Q [1]

Otra de las desventajas de esta arquitectura es que todos los Switch del Service Provider deben

aprender las direcciones MAC de todos los clientes, proceso conocido como MAC Learning. Esto

requiere que mantengan grandes bases de datos en sus tablas de Forwarding Capa 2, lo cual puedeafectar notablemente el procesamiento del equipo. De la misma manera, deben realizar Flooding o

Inundación para descubrir las MAC de destinos desconocidos, aumentando la carga de los enlaces de

acceso.

2.1.2.

Redes 802.1AD – Provider Bridges

Para mejorar la escalabilidad de las redes 802.1Q se realiza una nueva ampliación del estándar,

introduciendo IEEE 802.1AD [4] que permite agregar nuevas etiquetas anidadas para posibilitar la

separación de los VLAN de Clientes y las del Proveedor.

Se implementa así una etiqueta para el Cliente que contiene la Customer VLAN y otra para el Service

Provider que contienen la Service VLAN. A esta solución con 2 etiquetas se le conoce como QinQ y se

puede ver en la Ilustración 3:







Ilustración 3. 802.1AD [1]

Esto permite que el cliente pueda separar los dominios de Broadcast en hasta 4096 VLANs y el

Service Provider puede ofrecer igualmente hasta 4096 servicios, siendo aun limitante para las dos

partes. Aunque es una mejora con respecto al estándar anterior, se sigue manteniendo toda la Capa

2 en un mismo plano, y por tanto los Switch siguen manteniendo bases de datos de las MAC de todos

los clientes.

Muchas otras ampliaciones fueron propuestas, tales como el estándar IEEE 802.3AH [5] conocida

como Provider Backbone Bridges (PBB), sin embargo los problemas de escalabilidad siguieron

persistiendo mientras crecían las redes.

Con la introducción de Multiprotocol Label Switching (MPLS) [RFC 3031] [6] como tecnología de

convergencia, se posibilitó el uso de VLAN, QinQ y PBB dentro de la red del cliente; separándolo del

plano Capa 2 del Service Provider . Usualmente se considera MPLS como una tecnología Capa 2.5

porque los equipos realizan una función de conmutación de paquetes similar a la de Capa 2 pero

establecen conectividad en Capa 3.

2.2.

Red Privada Virtual o VPN (Virtual Private Network )

Una VPN [RFC 2764] [7] es una red que conecta dos o más subredes a través de una red pública, por

medio de túneles. Es privada porque no hace parte de la red que la transporta y por tanto el clientela percibe como una conexión local. Una forma esquemática de visualizarlo se presenta en la

Ilustración 4:







Service Provider

Backbone

Sucursal 1

del Cliente

Sucursal 2

del Cliente

Sucursal 3

del Cliente

Ilustración 4. VPN

Existen diferentes tipos de VPN, sin embargo se hará referencia únicamente a VPNs Capa 2 (L2VPN)[RFC 4664] [8]; las cuales son independientes de la capa de red. La interconexión de una VPN Capa 2

puede ser una línea arrendada a un ISP por ejemplo Frame Relay /ATM/TDM o un túnel sobre la red

IP/MPLS del ISP. En general, para las soluciones de L2VPN puede verse la red Backbone del ISP como

la emulación de un gran Switch entre las redes que se desean conectar.

2.2.1. L2VPN Punto a Punto

Una VPN punto a punto en el contexto de una Packet-Switching Network (PSN) se le conoce comoVirtual Leased Line (VLL) o Virtual Private Wire Service (VPW).

En la arquitectura MPLS el equipo que se encuentra en el cliente se le conoce como Customer Egde

(CE), pudiendo referirse a un Router , un Switch o un hub. Así mismo se denomina como Provider

Edge (PE) al equipo que se encuentra entre el CE y el Backbone del ISP. La idea de usar un PE en los

bordes es que la red de Backbone del ISP sea transparente a los CE por medio de un túnel que

atraviesa dicha red, como se puede ver en la Ilustración 5:

Service

Provider

BackboneSucursal 1

del Cliente

Sucursal 2

del Cliente

CECE

PE PE

Túnel Capa 2

Ilustración 5. Virtual Private Wire Service (VPW)

No se puede usar la red del ISP para transportar tráfico Capa 2 de cliente porque el encabezado de la

trama (incluyendo sus MAC Origen y Destino) sería retirado cuando la trama ingresa al Backbone.Para preservar el encabezado de la trama Capa 2 del cliente, el PE de ingreso encapsula toda la trama







en un paquete de capa superior y le agrega su propio encabezado de Capa 2, el cual es retirado alotro extremo en el PE de egreso. Finalmente, el PE de egreso desencapsula la trama para obtener latrama original y se la entrega al CE destino, que la recibe como si se la hubiera enviado directamenteel CE emisor. [9]

Los dos PE deben conocerse entre sí y establecer una sesión dentro del Core. Este modelo crea unaLAN emulada en la que los CE se interconectan como si fuese un Bridge. Por definición las Bridge LANque intenta emular no pierden ni descartan paquetes, de manera que requieren una sesión confiable(orientada a la conexión) y por ello se establece una sesión TCP que mantiene el túnel a través delCore entre los dos equipos [9]. La red Core IP/MPLS interconecta los PE pero no participadirectamente en la funcionalidad de la VPN; simplemente el tráfico es conmutado basado enetiquetas MPLS.

Al túnel entre un par de PE se le conoce como Label Switched Path (LSP). Se usa Label Distribution

Protocol (LDP) [RFC 5036] [10] para establecer estos túneles de forma dinámica. Los LSP son también

denominados como túneles externos o túneles de transporte, porque son creados como parte de la

infraestructura de la solución MPLS. Todos los LSP son unidireccionales. El establecimiento del túnel

LSP se realiza de la siguiente forma:

1. PE1 envía un paquete UDP “Hello” al PE2

2. PE2 responde con un paquete UDP “Hello” al PE1

3. Se establece una conexión TCP

Existen dos tipos principales de L2VPN punto a punto dentro de una red MPLS, Martini y Kompella,nombrados así en honor a sus creadores.

2.2.1.1. L2VPN Martini

La L2VPN Martini [RFC 4447] [11] fue la primera versión propuesta de VPN punto a punto Capa 2

sobre MPLS. Se compone de dos LSP que interconectan los PE y una sesión Targered LDP (T-LDP) que

permite el intercambio de etiquetas entre estos PE, como se puede ver en la Ilustración 6:

Sucursal 1

del Cliente

Sucursal 2

del Cliente

CECE

PE PE

Sesión LDPTarget

Service Provider

Backbone

LSPà

ß LSP

Ilustración 6. L2VPN Martini







Al estandarizarse, la L2VPN Martini pasó a conocerse como Pseudo Wire Emulation Edge-to-Edge

(PWE3) [RFC 3985] [12] o simplemente PW. Un PW consta de dos LSP unidireccionales en direcciones

opuestas, permitiendo que el PW sea bidireccional. Si cualquiera de los LSP se cae, el PW entero se

considera caído [1]. A los PW también se les conoce como túneles internos o túneles de servicio,

porque son conexiones punto a punto que identifican inequívocamente a cada cliente.

En cada PE, se identifica el LSP con una etiqueta externa o de transporte y el PW se identifica con una

etiqueta interna o de servicio a la cual se le refiere como etiqueta de Virtual Circuit (VC), como se


Etiqueta

LSP

Etiqueta

VCTrama Cliente

Ilustración 7. Formato de trama L2VPN

La etiqueta de LSP va cambiando a medida que atraviesa los equipos del Backbone MPLS, mientras

que la etiqueta de VC permanece intacta de un extremo al otro y sólo es utilizada por los PE. Un solo

LSP puede contener múltiples VCs, por ello se usa T-LDP como protocolo de señalización para mapear

cada etiqueta con su respectivo VC.

2.2.1.2. L2VPN Kompella

La L2VPN Kompella [RFC 6624] [13] es una solución de VPN punto a punto sobre MPLS propuestaposteriormente a la de Martini. A nivel de infraestructura también funciona con dos LSP para

interconectar los PE, sin embargo usa las familias extendidas de Border Gateway Protocol (BGP) [RFC

4760] [14] para establecer una sesión MultiProtocol BGP (MP-BGP) [RFC 7432] [15] que permita la

señalización de las etiquetas de VC, como puede verse en la Ilustración 8:

Sesión

MP-BGP

Sucursal 1

del Cliente

Sucursal 2

del Cliente

CECE

PE PE

Service Provider

Backbone

LSPà

ß LSP

Ilustración 8. L2VPN Kompella







El formato de trama usado es el mismo de la Ilustración 7, utilizando la etiqueta externa de LSP para

el transporte y una etiqueta interna de VC para el servicio, pero realizando el mapeo con MP-BGP.

Igualmente equivale a un PW y por tanto, en adelante, se hará referencia como PW Kompella y PW

Martini para diferenciarlos entre si.

2.2.2. L2VPN Punto a Multipunto

Se le conoce como Virtual Private LAN Service (VPLS) y provee interconexión entre múltiples sitiosgeográficamente dispersos, estableciendo túneles Capa 2 entre todos ellos como se muestra en laIlustración 9:

Service Provider

Backbone

Sucursal 1

del Cliente

Sucursal 2

del Cliente

Sucursal 3

del Cliente

CE CE

CE

PE PE

PE

T ú n e l C

a p a 2T ú n e l C a p a 2

Túnel Capa 2

Ilustración 9. Virtual Private LAN Service (VPLS)

Para poder tener un servicio de VPN Multipunto se requiere una malla completa de PW entre los PE

que participan de dicha VPLS. Dado que los PW son bidireccionales, cada túnel Capa 2 está

compuesto por dos LSP en sentidos opuestos.

La trama utilizada tiene el mismo formato de las L2VPN punto a punto, usando una etiqueta externa

que identifica el túnel de transporte y una etiqueta interna que identifica el VC como se puede ver enla Ilustración 10:

Etiqueta

LSP

Etiqueta

VC

MAC

Destino

MAC

OrigenDatos/Payload

Trama Cliente

Ilustración 10. Formato de paquete L2VPN VPLS







Al igual que como se mencionó antes, la etiqueta de LSP va cambiando a medida que atraviesa los

equipos del Backbone MPLS, mientras que la etiqueta de VC permanece intacta de un extremo al

otro y sólo es utilizada por los PE.

Siendo una evolución de los PW Martini y Kompella, se produjo dos documentos separados paraestandarización de VPLS según su señalización: VPLS señalizado con LDP [RFC 4762] [16] y VPLS

señalizado con BGP usando AutoDiscovery [RFC 4761] [17]. En este punto es necesario hacer una

diferenciación en lo que respecta al Plano de Control y Plano de Forwarding. El Plano de Control

refiere al descubrimiento de vecinos y señalización de la instancia VPLS, es el plano en el que se va a

establecer la sesión. El Plano de Forwarding es en el que cursa el tráfico del cliente, por tanto refiere

al transporte [18]. Esto se profundizará mas adelante.

2.2.2.1.

Componentes de una VPLS

El CE se conecta al PE a través del Attachment Circuit (AC), que se asume como una interfaz Ethernet.Los PE deben soportar todas las prestaciones “clásicas” de Ethernet y para ello implementan una

Virtual Switch Interface (VSI) como se puede ver en la Ilustración 11:

Ilustración 11. Componentes VPLS [1]

Dado que las VSI cumplen la función de un Ethernet Bridge, realizan MAC Learning, Flooding y

Forwarding. La funcionalidad del VSI en el PE se lleva a cabo mediante la Forwarding Information

Base (FIB) que almacena las MAC aprendidas para cada instancia VPLS [19].

El establecimiento del PW habilita a los PE para participar del MAC Learning, de tal forma que

cuando el PE recibe una trama con una MAC desconocida, tiene identificado por cual VC se recibió.Todo el trafico se conmuta en base a las MAC y por eso la FIB mapea cada MAC recibida por la VSI







con su respectivo VC. Cuando un PE debe enviar tráfico Broadcast , Multicast o Unknown Unicast

hace Flooding por el VC asociado a la instancia VPLS y todos los PE remotos pertenecientes a dicha

VPLS lo reciben, así que también hacen MAC Learning asociando la MAC recibida a su propia FIB [1],

tal como se puede ver en la Ilustración 12:

Ilustración 12. MAC Learning en VPLS [1]

Se hace uso de Split Horizon para evitar bucles de Forwarding en el Backbone del ISP, esto implica

que nunca se renvían tramas por el mismo VC que se recibió [19].

Un VPLS Identifier (VPLS ID) es intercambiado con las etiquetas, así las etiquetas de PW son asociadasa una instancia VPLS particular. La forma de aplicar el VPLS ID difiere dependiendo de la señalización

que se use.

2.2.2.2.

Plano de Forwarding

Los procedimientos para realizar el Forwarding son básicamente los mismos sin importar la

señalización que se use, puesto que refiere al establecimiento de los LSP entre los PE. Siendo este el

plano de datos de la VPLS en los PE, se cumplen las funciones corrientes de una Ethernet Bridge LAN ,

correspondientes al MAC Learning, Flooding y Aging. [18]

2.2.2.3. Plano de Control

El control tiene dos funciones principales: señalización y AutoDiscovery . El descubrimiento se refiere

al proceso de encontrar todos los PE que participan de la instancia VPLS. El PE puede ser configurado

manualmente con las identidades de los otros PE o puede realizarlo automáticamente usando un

protocolo para el descubrimiento, a lo cual se le denomina AutoDiscovery. Actualmente sólo MP-BGP

soporta esta característica [18].

Después de que ocurre el descubrimiento, se establecen los PW y la señalización permite trasmitircaracterísticas del PW y realizar cambios en caso de necesitarlo.







Plano de Control LDP-VPLS

Si el plano de Control es señalizado con LDP como se indica en la RFC 4762 [16], se establece una

sesión T-LDP entre cada par de equipos, similar al PW Martini, como se muestra en la Ilustración 13:

PE

P

VPLSVPLS

Plano de Control

Plano de Forwarding

MPLS/LDP

PE

Sesión LDP

Target

LDP

Ilustración 13. Plano de Control LDP

El intercambio de etiquetas de PW entre dos PE que pertenecen a una instancia VPLS sólo tiene

significado de manera local para cada pareja [20]. Para distinguir cada VPLS se usa el VC Identifier

(VCID) en todos los PE.

El intercambio de la señalización en una VPLS se lleva a cabo a través del establecimiento de un Full

Mesh de sesiones T-LDP entre los PE. T-LDP solo permite realizar señalización, no AutoDiscovery , por

tanto en cada PE debe configurarse todos los otros PE que pertenecen a la misma instancia VPLS. Con

el crecimiento de la red se dificulta el mantenimiento de la solución, debido a que para agregar o

eliminar un PE en una instancia VPLS de N nodos se requiere configurar (N-1) conexiones en cada PE;

lo que implica que la cantidad de sesiones que deben establecer manualmente es N(N-1)/2, como se








Ilustración 14. Establecimiento de sesiones LDP cuando se agrega un nodo a la VPLS [18]

VPLS Jerárquico (H-VPLS)

Por los problemas de escalabilidad que representa, LDP también define una jerarquía de dos niveles

conocida como Hierarchical VPLS (H-VPLS) para minimizar la cantidad de PW en Full Mesh que deben

ser configurados para usar la solución T-LDP [18].

H-VPLS define nodos User PE (U-PE) que hacen de borde entre el cliente y el Core, mientras que porotro lado están los Network PE (N-PE) que establecen un Full Mesh únicamente en el Core, como se


Ilustración 15. H-VPLS [1]







Este método minimiza la señalización y particiona el proceso de descubrimiento de nodos [1]. Por

redundancia suele conectarse un U-PE a dos N-PE, quedando una arquitectura como se muestra en la

Ilustración 16:

Ilustración 16. Formato de tramas en H-VPLS [1]

Los equipos N-PE del Core establecen un Full Mesh mientras que los de Agregación establecen un PW

Martini con sus dos respectivos N-PE. La etiqueta de LSP cambia a medida que se atraviesa el

Backbone y la etiqueta de VC permanece constante del extremo de un U-PE al otro U-PE.

Plano de Control BGP-VPLS

MP-BGP permite realizar funciones de señalización y AutoDiscovery simultáneamente. Para ello usa

un Route Target (RT) que identifica la instancia VPLS y un Virtual Edge Identifier para distinguir cada

PE participante, al cual se hará referencia como Site Identifier.

Una de las ventajas de la señalización MP-BGP es que no es necesario realizar un Full Mesh de PW

entre PE, si a cambio se hace uso de un Router Reflector Capa 2 (L2RR) que se encargue de establecer

las sesiones como se muestra en la Ilustración 17:







PE

P

VPLSVPLS

Plano de Control

Plano de Forwarding

MPLS/LDP

PE

RR_L2VPN

Sesión

MP-BGPSesión

MP-BGP

LDP

Ilustración 17. Plano de Control LDP

De esta forma se implementa intrínsecamente una jerarquía en la que todos los PE realizan un Full

Mesh únicamente contra el L2RR, lo que facilita el mantenimiento y aprovisionamiento, porque al

ingresar un nuevo nodo sólo debe configurarse esta única sesión mientras que los otros PE son

descubiertos con el AutoDiscovery , como se muestra en la Ilustración 18:

Ilustración 18. Establecimiento de sesión contra RR para un PE nuevo en BGP-VPLS [18]

Un PE se comunica con otro a través de paquetes de actualización BGP que contienen el parámetro

Network Layer Reachability Information (NLRI) [16], con suficiente información para que un PE

determine la presencia de una instancia VPLS local en la configuración de otro PE. Así mismo, ante uncambio de topología en un PE, todos los demás PE son informados con los paquetes de actualización.







3. DISEÑO DE LA RED DE PRUEBA

3.1.

Topología de la Red

La red de prueba es del tipo H-VPLS, de manera que define estrictamente las funciones de los nodos

dentro de la Arquitectura, como puede verse en la Ilustración 19:

CORE ACCESOAGREGACIÓNACCESO AGREGACIÓN

U-PE

N-PE

U-PE

CE

CE

RR_L2VPN

U-PE: User Provider Egde

N-PE: Network Provider Egde

AN: Aggregation Node

RR: Router Reflector

CE: Costumer Equipment

PP

VPLS

N-PEN-PE

N-PE

Ilustración 19. Topología de la Red de prueba

Los anillos están compuestos por dos equipos N-PE y un U-PE. Todos los equipos usados en las

pruebas corresponden a Routers Carrier Class MX-960 de tipo Service Provider de Juniper Networks y

las configuraciones que se presentan a continuación corresponden a las recomendaciones e

indicaciones del fabricante expuestas en [18] y [21].

Se hará referencia a cada una de las conexiones entre U-PE y N-PE como troncales.

3.1.1.

LDP-VPLS entre Nodos U-PE

El anillo de Agregación contiene el equipo U-PE, el cual establece el Plano de Forwarding con LDP

como se muestra en la Ilustración 20:







AGREGACIÓN

U-PE

N-PE

Pseudowire

Martini

VPLS

VPLS

VPLS

N-PE

Pseudowire Martini

Ilustración 20. Plano de Forwarding en U-PE

Los nodos de Agregación son los equipos U-PE, que realizan las funciones de MAC Learning y

Flooding. Se usa señalización con LDP para las instancias VPLS, de manera que se establecen

sesiones T-LDP contra cada uno de los dos N-PE del anillo, como puede verse en la Ilustración 21:

AGREGACIÓN

U-PE_AN

N-PE

Sesión T-LDP

VPLS

VPLS

VPLS

Sesión T-LDP

Sesión T-LDP

N-PE

Ilustración 21. Plano de Control en U-PE

3.1.2.

BPG-VPLS entre Nodos N-PE

El Core está compuesto por los equipos N-PE, los cuales en el Plano de Forwarding se encuentran

estableciendo los LSP por medio de LDP, como puede verse en la Ilustración 22:







CORE

N-PE

PP

VPLS

VPLSVPLS

VPLS

MPLS/LDPN-PE

N-PE

N-PE

Pseudowire Kompella

Ilustración 22. Plano de Forwarding en N-PE

Por otro lado, el Plano de Control se realiza con BGP, lo que permite realizar el AutoDiscovery . Las

sesiones entre el L2RR y los PE son del tipo MP-iBGP, por lo que se tiene configurado la familia L2VPN

en los N-PE. No hay conexiones establecidas contra otros N-PE, como puede verse en la Ilustración

23:

CORE

RR_L2VPN

PPMP-BGP

VPLS

VPLS

VPLS

VPLS

MPLS/LDPN-PE

N-PE

N-PE

N-PE

Sesión MP-BGP

Ilustración 23. Plano de Control en N-PE

Cada N-PE tiene configurado un Route Target por instancia VPLS, lo que permite diferenciarlas entre

si. Este RT debe ser el mismo en todos los N-PE que participan de la VPLS. Además, se configura un

parámetro Site Identifier en cada N-PE, que permite identificar al sitio VPLS de forma univoca entre

los PE.

Dentro de cada instancia VPLS se encuentra configurado el atributo Route Distinguisher (RD) que

permite al L2RR identificar la información publicada por cada nodo. Debe ser único e irrepetible paracada N-PE.







3.1.3. Interoperación entre BGP-VPLS y LDP-VPLS

Los nodos N-PE mantienen la Interoperabilidad entre el dominio BGP-VPLS usado en el Core y el

dominio LDP-VPLS usado en los múltiples anillos de Agregación, por ello, a esta topología mixta se le

denomina LDP-BGP Internetworking VPLS [18]. Los dominios pueden verse demarcados en la

Ilustración 24:

CORE ACCESOAGREGACIÓN

U-PE_AN

N-PE

CERR_L2VPN

PP Sesión

MP-BGP

Sesión T-LDP

VPLS

VPLS

VPLS

VPLS

VPLS

MP-BGP

T-LDP

MPLS/LDP

Sesión T-LDP

N-PEN-PE

N-PE

Ilustración 24. Interoperabilidad de VPLS LDP-BGP

Esta solución de Interoperabilidad modifica la regla del Split Horizon debido a que cuando un nodo U-

PE hace Flooding de tráfico Broadcast , Multicast o Unknown Unicast , esta información llega al primer

N-PE, el cual lo reenvía al otro nodo N-PE y este a su vez lo reenvía al mismo nodo U-PE, de manera

que crea un bucle en el anillo de Agregación. Por esta razón se establece una configuración

Active/Stand-By para los PW Martini creados entre el U-PE y los dos N-PE, lo cual es conocido como

Multihoming. La decisión de cual de los dos PW es Activo y cual es Backup la controla BGP [18].

Configuraciones en los N-PE

Las configuraciones expuestas a continuación aplican para cada una de las instancias VPLS a las que

el N-PE pertenece.

Para lograr establecer un PW Activo y otro Backup se comparte el Site Identifier entre los dos N-PE

que cierran el anillo con un U-PE. Se deben definir Site Identifiers en todos los pares de N-PE para

proveer Multihoming en todos los anillos de Agregación, como se puede ver en la Ilustración 25:







N-PE

S

i t e _I D 3

Site _ ID 4

S

i t e _

I D

1

Site_ID 2

S i t e_ I D 5

S i t e _I D 6

N-PE

N-PEN-PE

Ilustración 25. Site Identifiers para Multihoming de H-VPLS

En lo equipos usados se ha configurado cada Site con su respectivo Site ID y especificando la opción

de Multihoming, además de un Site Preference que permite definir manualmente un N-PE como

Primario/Activo y el otro como Backup [21]. Se balancea enviando el tráfico VPLS hacia el VPLS_N-PE

(definido como Primario) y el tráfico IP por el otro segmento del anillo hacia IPv4_N-PE (definido

como Backup) como puede ver en la Ilustración 26:

U-PE_AN

VPLS_N-PE

IPv4_N-PEPseudowire

Principal

VPLS

VPLS

VPLS

Pseudowire

Backup

BGP VPLS

Pseudowire

S i t e _I D 3

Pseudowire Kompella

Pseudowire Martini

Ilustración 26. Multihoming para H-VPLS Internetworking

También se ha necesitado configurar un Mesh-Group con un único VPLS ID donde se pueden agrupar

los nodos U-PE que hacen parte del LDP-VPLS. Si existen varios vecinos LDP en un mismo anillo se ha

configurado Local-Switching para evitar un Full Mesh dentro del anillo [21].







Configuraciones en los U-PE

En cuanto a los nodos U-PE, en la instancia VPLS se ha configurado un VPLS ID que coincide con el

que se encuentra definido en los N-PE con los que se establecen los PW Martini.

Los nodos U-PE reciben las rutas hacia los Router ID de los N-PE (se usan Loopback ) y reciben por LDP

un Label Mapping que permite mapear cada Loopback con una Etiqueta.




25 |D I S E Ñ O D E M O P Verificación de Alta Disponibilidad en Anillos de Agregación de


4. PROTOCOLO DE PRUEBAS

4.1.

Diseño del Protocolo

Una vez cumplido el objetivo de caracterizar la red, detallando su topología y la arquitectura de

servicios, es posible diseñar el Method Of Procedure (MOP) para verificar la Alta Disponibilidad de los

anillos de Agregación y al mismo tiempo hacer una medición de los tiempos de convergencia de la

red.

Este MOP contiene tres pruebas principales que definen el desarrollo de tarea:

1. Medición del tiempo de convergencia ante caída del troncal que ha establecido la sesión

Backup del Multihoming. Para hacer medición se envía un ping extendido a intervalos de

100mseg, desde la interfaz del U-PE conectada al N-PE Backup.

2. Medición del tiempo de conmutación de tráfico VPLS ante caída del nodo N-PE Principal del

Multihoming. Para hacer medición se envía un ping extendido a intervalos de 100mseg,

desde un CE ubicado en el U-PE que se prueba, hasta otro CE ubicado en un U-PE que

pertenezca a la misma VPLS.

3. Medición del tiempo que tarda un Switchover de las placas controladoras. Para determinar el

tiempo se hace revisión del archivo de log de eventos o syslog.

Lo que se intenta evaluar con estas pruebas es:

1. El tiempo que tarda en converger el tráfico por el enlace alternativo, medido en la cantidad

de paquetes perdidos del ping ejecutado durante el corte.

2. La NO afectación del tráfico, determinado en la cantidad de Bandwidth medido en las dos

troncales.

3.

Comportamiento del troncal de Backup, el cual se espera que asuma la carga de su propio

trafico sumado al Bandwidth del troncal principal.

4.

Comportamiento de los protocolos ante el cambio, comparando el estado de las rutas, FIB,

MAC tables, antes, durante y después del corte.5.

Respuesta del Hardware a diversos casos de falla.

El MOP con el detalle de tareas necesarias y secuencia de ejecución se encuentra como un Anexo del

presente trabajo, debido a su extensión.






4.2. Resultados

Después de ejecutar el MOP en equipos localizados en diversos puntos del país, se ha obtenido las

siguientes mediciones de tiempos:

ModeloEquipo

SitioTiempo Convergencia

en Capa 3 (seg)Tiempo Convergencia

en Capa 2 (seg)Tiempo Convergencia de

Placas (seg)

MX960 A 3,5 3,8 38

MX960 B 1,8 8,3 27

MX960 C 3,7 9,9 13

MX960 D 1,9 6,1 11

MX960 E 7,3 12,1 27

MX960 F 5,7 5,5 42

MX960 G 3,6 4,3 16

MX960 H 5,1 11,0 75MX960 I 1,6 5,1 19

MX960 J 5,6 9,4 14

Esto permite realizar un gráfico comparativo de resultados para establecer las capacidades y

limitaciones de la red:

Ilustración 27. Resultados de ejecución del MOP para diferentes sitios

Se puede deducir que el tiempo de reconvergencia del Internal Gateway Protocol (IGP) es en

promedio 4 segundos, mientras que el promedio de reconvergencia de la VPLS es de 7,6 segundos.

Son valores aceptables, sin embargo no responde al valor deseado de 50 mseg. Conviene el análisis

de la posibilidad de implementar Bidirectional Forwarding Detection (BFD) para acelerar el procesode detección de la caída del enlace.

0

10

20

30

40

50

60

70

80

A B C D E F G H I J

S e g u n d o s

Equipo

Resultados de Aplicación de MOP

Tiempo Convergencia en Capa3 (seg)

Tiempo Convergencia en Capa2 (seg)

Tiempo Convergencia de Placas(seg)






A nivel técnico podría pensarse que los sitios “A”, “F” y “H” poseen gran carga de procesamiento y

por ello el traspaso de la placa controladora Backup de Slave a Master durante el Switchover es alto

con respecto al promedio de 28 segundos. Esto podría derivar en una ampliación de la capacidad del

sitio.

También permite tomar decisiones administrativas, en la medida que en sitios como “E” o “H”

sobrepasan los 10 segundos de reconvergencia de VPLS y es posible que deba limitarse el Service

Level Agreement (SLA) para los clientes que se conectan en estas localidades.




28 | C O N C L U S I O N E S Verificación de Alta Disponibilidad en Anillos de Agregación de


5. CONCLUSIONES

Es posible realizar el MOP con únicamente conectividad a los equipos, debido que hay

previstas herramientas del mismo Sistema Operativo para calcular los tiempos deconvergencia. Nótese que los resultados pueden no ser exactos, sin embargo, son una muy

buena aproximación dado que los ping realizados se encuentran en el rango de los mseg.

Los resultados de la ejecución del MOP pueden ayudar a tener una visión general del

comportamiento de la red en los aspectos evaluados, de forma que podría permitir tomar

decisiones que permitan acercarse a los valores esperados.

Se necesita tener un relevamiento específico y detallado de la arquitectura de la red para

diseñar el MOP de forma adecuada, esto quiere decir que los tiempos evaluados sean fieles a

la realidad.

Una de las características mas variables en la ejecución del MOP es la duración del mismo, lo

cual depende de la configuración, el procesamiento, la cantidad de tráfico e incluso de la

experiencia del personal ejecutor, por lo que sólo es posible determinar la extensión de la

tarea después de realizarlo en los equipos mas congestionados.

Es indispensable que el personal ejecutor del MOP cuente con apoyo del Network Operations

Center (NOC) para hacer seguimiento de la tarea, de tal forma que se evite la modificación

del estado una vez terminada la tarea.



METHOD OF PROCEDURE-MOP

6. ANEXOS

6.1. MOP


Aggregation Node




1.

DETALLES DEL PROCEDIMIENTO

1.1. Aspectos Generales

Los aspectos tenidos en cuenta para realizar este documento son:

El tiempo esperado para completar el presente protocolo depende del tamaño de la red. Seestima que pueden ser alrededor de 6 horas.

No hacer cambios durante las 24 anteriores a la aplicación de la tarea.

Realizar durante ventana de menor afectación de tráfico, usualmente en horario nocturno.

Realizar Backup de la configuración como punto de Rollback .

Realizar log durante toda la tarea.

Conlleva un riesgo bajo de afectación en la red.

No existe punto de no retorno. Durante toda la actividad se puede hacer un Rollback a

situación original.

Se tienen dos puntos de comparación: Antes de la Tarea y Después de la Tarea.

Se recomienda tener disponible un esquema/diagrama de la red.

Las VPLS pueden estar clasificadas para tener diferentes N-PE primarios, por simplicidad serealiza asumiendo un solo primario. Si hubiesen diferentes N-PE primarios debe replicarse laprueba con cada uno para las VPLS específicas.

El IGP con el cual se realizan las tareas es OSPF por ser el más común.

Por seguridad se debería realizar con usuario autenticado en servidor AAA y evitar así elusuario root .

Es importante asegurar la estabilidad de la red después de cada corte, para evitar buclesprovocados por el MAC Move en las troncales.

1.2. Topología

CORE ACCESOAGREGACIÓNACCESO AGREGACIÓN

U-PE_AN

N-PE_VPLS

N-PE_IPv4PE

PE

Remote

U-PE_AN

CE

CE

RR_L2VPN

PE: Provider Egde

AN: Aggregation Node

RR: Router Reflector

CE: Costumer Equipment

U-PE_IPv4_Interface

U-PE_VPLS_Interface

N-PE_VPLS_IP

N-PE_IPv4_Interface

N-PE_VPLS_Interface

N-PE_IPv4_IP

Remote

CE_VPLS_test_IP

U-PE_IP

CE_VPLS_test_IPPP

VPLS

Ping




1.3. Abreviaciones

U-PE_AN U-PE Aggregation Node. Nodo sobre el cual se realiza el chequeo, seencuentra en el anillo de Agregación.

U-PE_IP IP Loopback del Nodo de Agregación sobre el cual se realiza elmantenimiento. Puede interpretarse como el “System-ID” con el cual el

equipo realiza adyacencias o peers.

U-PE_VPLS_Interface Interfaz del Nodo de Agregación con la cual se establece la sesiónprimaria LDP-VPLS con el “N-PE_VPLS”.

U-PE_IPv4_Interface Interfaz del Nodo de Agregación con la cual se establece la sesiónBackup LDP-VPLS que con el “N-PE_IPv4”. Cursa tráfico IPv4

principalmente.

CE_VPLS_test_IP IP de prueba en un equipo de cliente que se encuentra en el extremolocal donde se realiza la tarea.

N-PE_VPLS Equipo del Proveedor de Borde que tiene el “site-preference primary ”para el Nodo de Agregación, o sea que establece la sesión primaria LDP-VPLS con el “U-PE_AN”.

N-PE_VPLS_Interface Interfaz del Equipo del Proveedor de Borde por el que cursaúnicamente tráfico Capa 2 con el Nodo de Agregación. Establece lasesión primaria LDP-VPLS con el “U-PE_AN”.

N-PE_VPLS_IP IP Loopback del Equipo del Proveedor de Borde por el que cursa tráficoCapa 2 con Nodo de Agregación.

N-PE_IPv4 Equipo del Proveedor de Borde con el que se cursa principalmentetráfico IPv4. Establece la sesión Backup LDP-VPLS con el “U-PE_AN”.

N-PE_IPv4_Interface Interfaz del Equipo del Proveedor de Borde por el que cursaprincipalmente tráfico IPv4 con Nodo de Agregación.

N-PE_IPv4_IP IP Loopback del Equipo del Proveedor de Borde que cursaprincipalmente tráfico IPv4 con Nodo de Agregación.

Remote_U-PE_AN Nodo de Agregación Remoto con el cual se realiza el test deconectividad para VPLS de prueba.

Remote_CE_VPLS_test_IP IP de prueba en un equipo de cliente que se encuentra en el extremodel Nodo de Agregación Remoto que tenga la misma VPLS. Es el otroextremo de la prueba ping.

VPLS_INSTANCE Cada una de las VPLS configuradas en el Equipo del Proveedor deBorde, establecidas con el Nodo de Agregación.

VPLS_INSTANCE_Interface Interfaz a la que está asociada la determinada VPLS_INSTANCE.

SITE_ID_H-VPLS ID de H-VPLS del Multihoming entre los Equipo de Borde.




CONTENIDO PRIVADO

Solicitar información al autor




57 | F I G U R A S Verificación de Alta Disponibilidad en Anillos de Agregación de


7. LISTA DE FIGURAS

Ilustración 1. Formato de trama 802.3 + 802.1Q [1] ............................................................................... 6

Ilustración 2. 802.1Q [1] .......................................................................................................................... 7Ilustración 3. 802.1AD [1] ........................................................................................................................ 8

Ilustración 4. VPN .................................................................................................................................... 9

Ilustración 5. Virtual Private Wire Service (VPW) .................................................................................... 9

Ilustración 6. L2VPN Martini.................................................................................................................. 10

Ilustración 7. Formato de trama L2VPN ................................................................................................ 11

Ilustración 8. L2VPN Kompella .............................................................................................................. 11

Ilustración 9. Virtual Private LAN Service (VPLS) ................................................................................... 12

Ilustración 10. Formato de paquete L2VPN VPLS .................................................................................. 12

Ilustración 11. Componentes VPLS [1] .................................................................................................. 13

Ilustración 12. MAC Learning en VPLS [1] ............................................................................................. 14Ilustración 13. Plano de Control LDP ..................................................................................................... 15

Ilustración 14. Establecimiento de sesiones LDP cuando se agrega un nodo a la VPLS [18] ................ 16

Ilustración 15. H-VPLS [1] ...................................................................................................................... 16

Ilustración 16. Formato de tramas en H-VPLS [1] ................................................................................. 17

Ilustración 17. Plano de Control LDP ..................................................................................................... 18

Ilustración 18. Establecimiento de sesión contra RR para un PE nuevo en BGP-VPLS [18] .................. 18

Ilustración 19. Topología de la Red de prueba ...................................................................................... 19

Ilustración 20. Plano de Forwarding en U-PE ........................................................................................ 20

Ilustración 21. Plano de Control en U-PE .............................................................................................. 20

Ilustración 22. Plano de Forwarding en N-PE ........................................................................................ 21Ilustración 23. Plano de Control en N-PE .............................................................................................. 21

Ilustración 24. Interoperabilidad de VPLS LDP-BGP .............................................................................. 22

Ilustración 25. Site Identifiers para Multihoming de H-VPLS................................................................. 23

Ilustración 26. Multihoming para H-VPLS Internetworking................................................................... 23

Ilustración 27. Resultados de ejecución del MOP para diferentes sitios .............................................. 26




58 | B I B L I O G R A F Í A Verificación de Alta Disponibilidad en Anillos de Agregación de


8. BIBLIOGRAFÍA

[1] M. Cohen, «Arquitecturas de Redes Ópticas».

[2] IEEE, «802.3,» [En línea]. Available: https://standards.ieee.org/findstds/standard/802.3-

2002.html.

[3] IEEE, «802.1Q,» [En línea]. Available: http://www.ieee802.org/1/pages/802.1Q.html.

[4] IEEE, «802.1AD,» [En línea]. Available: http://www.ieee802.org/1/pages/802.1ad.html.

[5] IEEE, «802.3AH,» [En línea]. Available:

http://www.ieee802.org/21/doctree/2006_Meeting_Docs/2006-11_meeting_docs/802.3ah-

2004.pdf.

[6] IETF, «MPLS,» [En línea]. Available: https://tools.ietf.org/html/rfc3031.

[7] IETF, «VPN,» [En línea]. Available: https://tools.ietf.org/html/rfc2764.

[8] IETF, «L2VPN,» [En línea]. Available: https://tools.ietf.org/html/rfc4664.

[9] I. T. -. N. T. C. LTD, «Virtual network: VLAN, VPN, VPLS,» [En línea]. Available:

http://inetco.com.vn/show.aspx?cat=014&nid=217.

[10] IETF, «LDP Specification,» [En línea]. Available: https://tools.ietf.org/html/rfc5036.

[11] IETF, «Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),» [En

línea]. Available: https://tools.ietf.org/html/rfc4447.

[12] IETF, «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,» [En línea]. Available:

https://tools.ietf.org/html/rfc3985.

[13] IETF, «Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling,» [En línea].

Available: https://tools.ietf.org/html/rfc6624.

[14] IETF, «Multiprotocol Extensions for BGP-4,» [En línea]. Available:

https://tools.ietf.org/html/rfc4760.

[15] IETF, «BGP MPLS-Based Ethernet VPN,» [En línea]. Available: https://tools.ietf.org/html/rfc7432.

[16] Alcatel-Lucent, «LDP VPLS using BGP-Auto Discovery,» [En línea]. Available:

https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0267-

HTML/7X50_Advanced_Configuration_Guide/LDPVPLS-using-BGP-AutoDiscovery.html.

[17] IETF, «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,» [En línea].

Available: https://tools.ietf.org/html/rfc4761.

[18] J. Networks, «LDP-BGP VPLS Interworking,» [En línea]. Available:

http://www.juniper.net/us/en/local/pdf/whitepapers/2000282-en.pdf.




[19] J. D. C. S. K. J. Witters, «Claves para desplegar con éxito el VPLS,» Revista de Telecomunicaciones

de Alcatel.

[20] Alcatel-Lucent, «VPLS Technical Tutorial - Technology White Paper,» 2009.

[21] J. Networks, «Configuring H-VPLS BGP-Based and LDP-Based VPLS Interoperation,» [En línea].

Available: http://www.juniper.net/documentation/en_US/junos14.2/topics/example/h-vpls-

interop.html.

[22] IETF, «Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs),»

[En línea]. Available: https://tools.ietf.org/html/rfc6074.

[23] IETF, «Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling,» [En

línea]. Available: https://tools.ietf.org/html/rfc4762.

[24] J. Networks, «VPLS Multihoming, Improved Convergence Time,» [En línea]. Available:

http://www.juniper.net/documentation/en_US/junos14.2/topics/example/vpls-multihoming-

convergence-example.html.

Verificacion de Alta Disponibilidad en Anillos de Agregacion de ISP

Documents

Transcript of Verificacion de Alta Disponibilidad en Anillos de Agregacion de ISP