Designing Cisco Network Service Architectures

1

Diseño Óptimo del Campus de la Empresa ................................................................................................. 14

Principios de Diseño del Campus Empresarial ......................................................................................... 15

Jerarquía ...................................................................................................................................................................... 15

Capa de acceso .......................................................................................................................................................... 15

Capa de distribución .............................................................................................................................................. 17

Capa núcleo ................................................................................................................................................................ 17

Modelo de capa de dos capas de campus empresarial .......................................................................... 18

Modelo de capa de tres niveles del campus de la empresa ................................................................. 19

Modularidad ............................................................................................................................................................... 20

La Arquitectura Modular del Campus de la Empresa y El Campus Empresarial Modular con

OSPF ............................................................................................................................................................................... 20

Bloque de Acceso-Distribución ......................................................................................................................... 22

Flexibilidad ................................................................................................................................................................. 23

Virtualización de la red del Campus ............................................................................................................... 24

Tecnologías y Técnicas de Virtualización de la Red del Campus ..................................................... 25

Resiliencia ................................................................................................................................................................... 29

Consideraciones de Diseño de Alta Disponibilidad del Campus de la Empresa ....................... 29

Recomendaciones de Diseño de VLANs, Trunking y Agregación de Enlaces ............................. 30

Protocolo de redundancia de primer salto (FHRP) ................................................................................ 35

Opciones y Consideraciones de Diseño de Límites de Capa 2 a Capa 3 ........................................ 38

Diseño EIGRP ............................................................................................................................................................. 45

Descripción del diseño EIGRP escalable....................................................................................................... 46

EIGRP con múltiples sistemas autónomos .................................................................................................. 46

Consultas EIGRP ....................................................................................................................................................... 46

Múltiples controladores del sistema autónomo EIGRP ........................................................................ 47

Arquitecturas multicapa EIGRP ........................................................................................................................ 48

Arquitectura de jerarquía EIGRP de dos capas ......................................................................................... 50

Arquitectura de jerarquía EIGRP de tres capas ........................................................................................ 51

Diseño EIGRP Hub-and-Spoke .......................................................................................................................... 53

Fugas de stub EIGRP .............................................................................................................................................. 58

EIGRP DMVPN Escalado ....................................................................................................................................... 59

Consideraciones de diseño de convergencia rápida EIGRP ................................................................ 60

Detección de reenvío bidireccional (BFD) .................................................................................................. 60

Consideraciones EIGRP sobre el Reinicio Gentil / NSF ......................................................................... 61

Diseño OSPF ............................................................................................................................................................... 63

Consideraciones de diseño de escalabilidad OSPF .................................................................................. 64

Vecinos adyacentes ................................................................................................................................................ 64

Información de enrutamiento en el área y el dominio enrutado ..................................................... 66

Número de enrutadores en un área ............................................................................................................... 68

Número de Áreas por ABR .................................................................................................................................. 69

Consideraciones sobre el diseño del área OSPF ....................................................................................... 70

Jerarquía OSPF .......................................................................................................................................................... 71

Resumen de áreas y dominios ........................................................................................................................... 72

Diseño de malla completa OSPF ....................................................................................................................... 74

Diseño de OSPF Hub-and-Spoke ...................................................................................................................... 75

Colocación de los ABR en el diseño de OSPF Hub-and-Spoke ........................................................... 76

Número de áreas en el diseño de OSPF hub-and-spoke ....................................................................... 78

Tipos de red en el diseño de OSPF hub-and-spoke ................................................................................. 79

Consideraciones de diseño de convergencia y técnicas de optimización OSPF ........................ 79

Detección de eventos ............................................................................................................................................. 80

Propagación de eventos de OSPF ..................................................................................................................... 81

Procesamiento de eventos OSPF ...................................................................................................................... 82

Reducción de la inundación de OSPF ............................................................................................................. 83

Protección de sobrecarga de la base de datos OSPF............................................................................... 83

Diseño de IS-IS .......................................................................................................................................................... 85

Visión general del protocolo .............................................................................................................................. 86

Características de IS-IS ......................................................................................................................................... 87

Enrutamiento IS-IS integrado ............................................................................................................................ 88

Descripción de la arquitectura jerárquica IS-IS ........................................................................................ 89

Tipos de enlaces y enrutadores IS-IS ............................................................................................................. 90

Adyacencias IS-IS ..................................................................................................................................................... 91

IS-IS Versus OSPF .................................................................................................................................................... 93

Similitudes entre IS-IS y OSPF ........................................................................................................................... 93

Características de OSPF e IS-IS ......................................................................................................................... 93

Diseños de área OSPF e IS-IS integrado ........................................................................................................ 95

3

IS-IS Technical Deep Dive .................................................................................................................................... 97

Direccionamiento IS-IS ......................................................................................................................................... 97

Inundaciones de paquetes de estado de enlace IS-IS .......................................................................... 105

Sincronización LSDB de IS-IS .......................................................................................................................... 105

Consideraciones de diseño IS-IS ................................................................................................................... 107

Descripción general de la lógica de enrutamiento IS-IS .................................................................... 107

Fugas de Ruta (Route Leaking) ...................................................................................................................... 108

Enrutamiento simétrico versus asimétrico de IS-IS ............................................................................ 110

Enrutamiento de IS-IS en una red de malla completa ........................................................................ 111

Diseño de enrutamiento plano IS-IS............................................................................................................ 112

Resumen de Rutas IS-IS ..................................................................................................................................... 114

IS-IS integrado para IPv6 .................................................................................................................................. 115

Pensamientos finales sobre el diseño de enrutamiento IS-IS ......................................................... 119

Diseño de BGP ........................................................................................................................................................ 121

Descripción de BGP ............................................................................................................................................. 122

Tipos de hablantes BGP ..................................................................................................................................... 122

Reglas de prevención de bucle y horizonte dividido en BGP .......................................................... 123

Atributos de ruta BGP y Selección del Mejor Camino ......................................................................... 124

Diseño de redes escalables iBGP ................................................................................................................... 126

Limitaciones de escalabilidad de iBGP ....................................................................................................... 126

Diseño de Reflector de Ruta BGP .................................................................................................................. 132

Regla de Horizonte dividido del Reflector de ruta ............................................................................... 132

Opciones y consideraciones de diseño de redundancia del reflector de rutas BGP............. 133

Congruencia de redes físicas y lógicas ....................................................................................................... 138

Posibles problemas de diseño de red del Reflector de Ruta............................................................ 140

Mejorando el diseño de las políticas BGP con las comunidades BGP .......................................... 141

Descripción del atributo de la comunidad BGP ..................................................................................... 141

Comunidades bien conocidas de BGP ......................................................................................................... 142

Lista de la comunidad nombrada BGP ....................................................................................................... 143

Planificación para el uso de comunidades BGP ..................................................................................... 143

Diseño de carga compartida de BGP ........................................................................................................... 144

Single-Homing Versus Multihoming ........................................................................................................... 145

4

Consideraciones de Diseño de Dual-homing y Multihoming .......................................................... 145

Consideraciones de Diseño de IPv6 ............................................................................................................. 154

Consideraciones sobre implementación y diseño de IPv6 ............................................................... 155

Fase de descubrimiento de negocios y redes.......................................................................................... 156

Fase de evaluación ............................................................................................................................................... 156

Fase de planificación y diseño ........................................................................................................................ 157

Fases de implementación y optimización ................................................................................................. 157

Consideraciones para la migración a diseño IPv6 ................................................................................ 158

Adquisición de prefijos IPv6 ........................................................................................................................... 158

Proveedor Independiente Versus Proveedor Asignado .................................................................... 158

Dónde iniciar la migración ............................................................................................................................... 159

Modelos de migración y consideraciones de diseño ........................................................................... 161

Mecanismos de transición IPv6 ..................................................................................................................... 164

Doble pila.................................................................................................................................................................. 166

NAT64 y DNS64 ..................................................................................................................................................... 167

Túneles manuales ................................................................................................................................................. 169

Corredores de túneles ........................................................................................................................................ 170

Despliegue rápido 6............................................................................................................................................. 171

Dual-Stack Lite (DS-Lite) .................................................................................................................................. 173

Localizador / protocolo de separación de ID (LISP) ........................................................................... 174

Pensamientos finales sobre los mecanismos de transición IPv6 .................................................. 178

Desafío en la Transición a IPv6 ...................................................................................................................... 179

Servicios IPv6 ......................................................................................................................................................... 180

Servicios de nombres ......................................................................................................................................... 180

Servicios de Direccionamiento ...................................................................................................................... 181

Servicios de seguridad ....................................................................................................................................... 181

Consideraciones de seguridad de la capa de enlace ............................................................................ 182

Soporte de aplicaciones ..................................................................................................................................... 183

Seguridad del plano de control ...................................................................................................................... 185

Consideraciones de seguridad de doble pila ........................................................................................... 186

Consideraciones sobre la Seguridad de los Túneles ............................................................................ 187

Multihoming ............................................................................................................................................................ 187

5

VPN Gestionada por el Proveedor de Servicios ..................................................................................... 189

Cómo elegir su conexión WAN ....................................................................................................................... 190

VPN de MPLS de capa 3 ..................................................................................................................................... 193

Arquitectura MPLS VPN .................................................................................................................................... 195

Consideraciones sobre el enrutamiento empresarial ......................................................................... 197

Provider Edge (PE) Arquitectura del enrutador ................................................................................... 198

Protocolo de enrutamiento PE-CE ............................................................................................................... 202

Virtual Private Wire Service (VPWS).......................................................................................................... 215

Servicio de LAN Privada Virtual (VPLS) .................................................................................................... 217

VPLS Versus VPWS .............................................................................................................................................. 223

WAN Gestionada por la Empresa.................................................................................................................. 225

Vista general de la VPN Gestionada por la Empresa ........................................................................... 226

Descripción de GRE ............................................................................................................................................. 227

Descripción de Multipoint GRE ...................................................................................................................... 229

Comparación punto a punto y multipunto GRE ..................................................................................... 230

Descripción de IPsec ........................................................................................................................................... 232

IPsec y GRE .............................................................................................................................................................. 234

IPsec y la interfaz de túnel virtual ................................................................................................................ 236

IPsec y VTI dinámico ........................................................................................................................................... 237

Descripción de DMVPN ...................................................................................................................................... 238

DMVPN Fase 1 ........................................................................................................................................................ 242

DMVPN Fase 2 ........................................................................................................................................................ 245

DMVPN Fase 3 ........................................................................................................................................................ 248

DMVPN Fase 1-3 Resumen .............................................................................................................................. 250

DMVPN y redundancia ....................................................................................................................................... 252

Descripción general de VPN SSL ................................................................................................................... 253

Descripción general de FlexVPN ................................................................................................................... 254

Arquitectura de FlexVPN .................................................................................................................................. 255

Capacidades FlexVPN ......................................................................................................................................... 256

Bloques de configuración FlexVPN .............................................................................................................. 257

GETVPN ..................................................................................................................................................................... 258

Diseño de la Resiliencia de la WAN Empresarial .................................................................................. 262

6

Descripción del sitio remoto de WAN ........................................................................................................ 263

Modelos de diseño WAN de la capa 3 de MPLS ...................................................................................... 265

Modelos de diseño de WAN de capa 2 ........................................................................................................ 267

Modelos Comunes de Diseño de WAN VPN ............................................................................................. 269

Modelos de diseño VPN 3G / 4G .................................................................................................................... 272

Sitio remoto usando Internet local .............................................................................................................. 273

LAN del sitio remoto ........................................................................................................................................... 275

NGWAN, SDWAN y IWAN; Descripción general de la solución ...................................................... 279

Diseño independiente del transporte ......................................................................................................... 281

Control de trayectoria inteligente ................................................................................................................ 282

Optimización de aplicaciones ......................................................................................................................... 282

Conectividad segura ............................................................................................................................................ 283

Administración ...................................................................................................................................................... 283

Vista General del Diseño IWAN ..................................................................................................................... 284

Descripción general de Cisco PfR ................................................................................................................. 288

Operaciones de Cisco PfR ................................................................................................................................. 288

Cisco IWAN y PfRv3 ............................................................................................................................................. 290

Consideraciones sobre el diseño y la implementación de Cisco PfRv3 ...................................... 293

Gestión de acceso y WAN empresarial ....................................................................................................... 295

APIC-EM .................................................................................................................................................................... 295

Diseño de APIC-EM .............................................................................................................................................. 297

Diseño de Centro de Datos Empresariales Multicapa ......................................................................... 299

introducción ............................................................................................................................................................ 300

Estudio de caso 1: Centros de datos pequeños (Conexión de servidores a una LAN

empresarial) ........................................................................................................................................................... 300

Estudio de caso 2: arquitectura de red de dos centros de datos ................................................... 303

Estudio de caso 3: Arquitectura de red de tres niveles de centros de datos ........................... 304

Enrutamiento Inter-VLAN del centro de datos ...................................................................................... 305

Modelos de conectividad de conmutador de acceso de Top of rack (ToR) versus End of

rack (EoR) ................................................................................................................................................................ 307

Extensores de tela Cisco (FEX) ...................................................................................................................... 308

Alta disponibilidad del centro de datos ..................................................................................................... 311

Equipos de controladores de interfaces de red ..................................................................................... 314

7

Nuevas Tendencias y Técnicas en el Diseño del Centro de Datos Modernos .......................... 316

La necesidad de una nueva arquitectura de red.................................................................................... 317

Limitaciones de la tecnología de red actual ............................................................................................. 318

Técnicas y arquitecturas modernas de diseño de centros de datos ............................................ 319

Diseño del centro de datos de Spine-Leaf ................................................................................................. 320

Superposiciones de red ..................................................................................................................................... 321

Cisco Fabric Path .................................................................................................................................................. 322

LAN virtual extensible (VXLAN).................................................................................................................... 324

Punto Final del Túnel VXLAN ......................................................................................................................... 325

Descubrimiento de los VTEP Remotos y el Aprendizaje de Direcciones de Inquilinos ...... 327

Optimización del plano de control VXLAN ............................................................................................... 329

Redes definidas por software ......................................................................................................................... 330

Centro de datos de múltiples tenencias ..................................................................................................... 337

Microsegmentación con redes de superposición .................................................................................. 340

Infraestructura Centrada en la Aplicación de Cisco (ACI) ................................................................ 342

Características del ACI ....................................................................................................................................... 343

Cómo el Cisco ACI soluciona las limitaciones de red actuales ........................................................ 344

Componentes de Arquitectura de Cisco ACI ............................................................................................ 345

Cisco Application Policy Infrastructure Controller (APIC)............................................................... 346

Enfoque APIC dentro de la arquitectura ACI ........................................................................................... 348

El Tejido de ACI ..................................................................................................................................................... 349

Superposiciones de virtualización de red ACI ........................................................................................ 352

Principios de diseño de aplicaciones con el modelo de políticas de Cisco ACI ....................... 356

¿Qué es un grupo de puntos finales en Cisco ACI?................................................................................ 360

Políticas de acceso de tela ACI........................................................................................................................ 363

Bloques de construcción de un inquilino en el Cisco ACI ................................................................. 365

Construcción del diseño de aplicaciones con Cisco ACI ..................................................................... 367

Interacción de ACI con conexiones y redes externas de capa 2 ..................................................... 368

Enrutamiento ACI ................................................................................................................................................. 372

Puerta de acceso predeterminada de capa 1 de primer nivel en ACI.......................................... 373

Hojas de la frontera ............................................................................................................................................. 374

Propagación de ruta dentro de la Tela ACI .............................................................................................. 376

8

Conexión de los dominios de la capa ACI a la capa externa 3 ......................................................... 377

Integración y migración a las opciones de conectividad ACI .......................................................... 378

Conexiones en el Centro de Datos ................................................................................................................ 381

Flujos de tráfico del centro de datos ........................................................................................................... 382

Direcciones del flujo de tráfico ...................................................................................................................... 382

Tipos de flujo de tráfico ..................................................................................................................................... 383

La necesidad de ICD ............................................................................................................................................ 386

Movilidad de direcciones IP ............................................................................................................................ 388

Estudio de caso: Dark Fiber DCI .................................................................................................................... 393

Pseudowire DCI ..................................................................................................................................................... 398

Servicio de LAN privada virtual DCI ............................................................................................................ 399

Modelos de implementación DCI de capa 2 gestionados por el cliente ..................................... 400

Implementación de DCI de capa 2 gestionada por el cliente ........................................................... 402

Advertencias de la capa 2 DCI ........................................................................................................................ 404

DCI de virtualización de transporte superpuesto ................................................................................. 405

Overlay Networking DCI ................................................................................................................................... 410

Capa 3 DCI ................................................................................................................................................................ 410

Descripción General de QoS ............................................................................................................................ 413

Visión general de QoS ......................................................................................................................................... 414

IntServ versus DiffServ ...................................................................................................................................... 414

Clasificación y marcado ..................................................................................................................................... 416

Clasificaciones y herramientas de marcado ............................................................................................ 416

Marcado de la capa 2: IEEE 802.1Q / p Clase de servicio ................................................................. 418

Marcado de la capa 3: Tipo de servicio IP ................................................................................................ 419

Marcado de la capa 3: Comportamiento de DSCP por salto ............................................................. 420

Capa 2.5 Marcado: MPLS Experimental Bits ........................................................................................... 425

Mapeo de marcas QoS entre capas OSI ...................................................................................................... 426

Clasificación de la capa 7: NBAR / NBAR2 ............................................................................................... 427

Policers y Shapers ................................................................................................................................................ 428

Algoritmos Token Bucket ................................................................................................................................. 431

Herramientas de Policing: Single-Rate Three-Color Marker ........................................................... 434

Herramientas de politicas: marcador de tres colores de dos velocidades ............................... 435

9

Herramientas de colas ....................................................................................................................................... 437

Anillo tx (TX-ring) ................................................................................................................................................ 439

Colas justas (Fair Queuing) .............................................................................................................................. 440

CBWFQ ....................................................................................................................................................................... 441

Herramientas de Descarte ............................................................................................................................... 444

DSCP basado en WRED ...................................................................................................................................... 444

Principios de Diseño de QoS y Mejores Prácticas ................................................................................. 455

Visión general de QoS ......................................................................................................................................... 456

Principios de diseño de la clasificación y el marcado ......................................................................... 456

Principios de diseño de vigilancia y marcado......................................................................................... 457

Principios de diseño de colas .......................................................................................................................... 458

Principios de diseño del descarte ................................................................................................................. 459

Principios de Diseño de Colas de Comportamiento por salto ......................................................... 460

Modelos de estrategia de QoS......................................................................................................................... 462

Estrategia de QoS de 4 Clases ......................................................................................................................... 462

Estrategia de QoS de 8 Clases ......................................................................................................................... 463

Estrategia de QoS de 12 Clases ...................................................................................................................... 465

Diseño del QoS del Campus, WAN y Data Center .................................................................................. 467

Descripción general de la QoS del campus ............................................................................................... 468

VoIP y Video ............................................................................................................................................................ 469

Buffers y ráfagas ................................................................................................................................................... 469

Límites y Estados de confianza ...................................................................................................................... 470

Modelo de QoS Clasificación / Marcado / Vigilancia ........................................................................... 473

Recomendaciones de Cola / Descarte ........................................................................................................ 474

Diseño de QoS "EtherChannel" de agregación de enlaces ................................................................ 475

Descripción de la QoS de la WAN .................................................................................................................. 476

Consideraciones sobre el rendimiento de la plataforma .................................................................. 477

Consideraciones de Latencia y fluctuación de fase (Jitter) .............................................................. 478

Consideraciones de cola .................................................................................................................................... 479

Consideraciones de modelado ....................................................................................................................... 480

Ejemplo práctico de QoS de la WAN y de la rama ................................................................................. 481

Visión general del QoS del centro de datos .............................................................................................. 482

10

Arquitectura comercial de alto rendimiento .......................................................................................... 482

Gran Arquitectura de Datos ............................................................................................................................. 483

Conjunto de herramientas de puenteo de centros de datos ............................................................ 484

Diseño de QoS para las VPN MPLS ............................................................................................................... 486

La necesidad de QoS en VPN MPLS .............................................................................................................. 487

Administración de la calidad de servicio WAN de la capa 2 privada .......................................... 488

Administración de QoS de VPN MPLS de malla completa ................................................................ 489

Modos de túnel MPLS DiffServ ....................................................................................................................... 490

Modo de tunelización uniforme .................................................................................................................... 493

Modo de túnel de tubería corta ..................................................................................................................... 493

Modo de Túnel de Tubería ............................................................................................................................... 494

Ejemplo de las Funciones de QoS de MPLS VPN.................................................................................... 495

Diseño QoS para las VPN IPsec ...................................................................................................................... 499

La necesidad de QoS en las VPN IPsec ........................................................................................................ 500

Casos de uso de VPN y sus modelos de QoS ............................................................................................ 501

IPsec Refresher ...................................................................................................................................................... 501

Encriptación y clasificación IOS: Orden de operaciones ................................................................... 503

Consideraciones MTU ......................................................................................................................................... 505

Consideraciones de QoS de DMVPN ............................................................................................................ 506

Consideraciones de QoS de VPN GET ......................................................................................................... 508

Diseño IP Multicast de la Empresa ............................................................................................................... 511

¿Cómo funciona la multidifusión IP? ........................................................................................................... 512

Grupo de multidifusión ...................................................................................................................................... 513

Modelo de servicio de multidifusión IP ..................................................................................................... 513

Funciones de una red de multidifusión ..................................................................................................... 515

Protocolos de multidifusión ............................................................................................................................ 516

Reenvío de multidifusión y comprobación RPF .................................................................................... 517

Fundamentos del Protocolo de Multidifusión ........................................................................................ 519

Identificación de árboles de distribución de multidifusión ............................................................. 521

Descripción de PIM-SM...................................................................................................................................... 522

El receptor se une al árbol compartido PIM-SM .................................................................................... 523

Registro en RP ........................................................................................................................................................ 524

11

Conmutación SPT PIM-SM................................................................................................................................ 525

Tabla de enrutamiento de multidifusión .................................................................................................. 529

Conceptos básicos de SSM ................................................................................................................................ 530

Escenario SSM ........................................................................................................................................................ 532

PIM bidireccional .................................................................................................................................................. 533

Modificaciones PIM para la operación bidireccional .......................................................................... 534

Soluciones a la Distribución de Puntos de Encuentro (RP) ............................................................. 537

Descubrimiento de puntos de encuentro ................................................................................................. 538

Ubicación de encuentro ..................................................................................................................................... 539

Auto-RP ..................................................................................................................................................................... 540

PIMv2 BSR................................................................................................................................................................ 544

Punto de encuentro incorporado para IPv6 ............................................................................................ 546

Características de Anycast RP ........................................................................................................................ 548

Ejemplo de Anycast RP ...................................................................................................................................... 548

Visión general del protocolo MSDP ............................................................................................................. 550

Relación de vecino MSDP.................................................................................................................................. 550

Diseño de los Servicios de Seguridad y la Protección a la Infraestructura ............................... 551

Zonificación de seguridad de red .................................................................................................................. 552

Arquitectura modular de red de Cisco ....................................................................................................... 553

Seguridad de próxima generación de Cisco ............................................................................................. 558

Diseño de la protección de la infraestructura ........................................................................................ 559

Acceso al dispositivo de infraestructura ................................................................................................... 560

Infraestructura de enrutamiento .................................................................................................................. 562

Resiliencia y supervivencia del dispositivo ............................................................................................. 563

Aplicación de políticas de red ......................................................................................................................... 564

Infraestructura de conmutación ................................................................................................................... 565

Consideraciones de seguridad SDN ............................................................................................................. 566

Diseño de Soluciones de Firewall e IPS ..................................................................................................... 569

Arquitecturas de Firewall ................................................................................................................................. 570

Firewalls virtualizados ...................................................................................................................................... 572

Estudio de caso 1: Separación de niveles de aplicación .................................................................... 575

Asegurar el tráfico Este-Oeste ........................................................................................................................ 577

12

Estudio de caso 2: implementación de firewalls en un centro de datos .................................... 578

Estudio de caso 3: Alta disponibilidad del Firewall ............................................................................. 580

Arquitecturas IPS.................................................................................................................................................. 585

Estudio de caso 4: Construcción de un diseño de borde de campus seguro (conectividad de

Internet y de extranet) ....................................................................................................................................... 589

Borde del Campus ................................................................................................................................................ 590

Conexión de socios externos ........................................................................................................................... 596

Seguridad en la Multidifusión IP ................................................................................................................... 600

Retos de seguridad de multidifusión .......................................................................................................... 601

Problemas en la red de multidifusión ........................................................................................................ 601

Consideraciones de seguridad de la red de multidifusión................................................................ 602

Seguridad del elemento de red ...................................................................................................................... 603

Seguridad en el Borde de la Red.................................................................................................................... 605

PIM y seguridad de multidifusión interna ................................................................................................ 609

Diseño de Soluciones de Control de Acceso a la Red ........................................................................... 615

Descripción general de IEEE 802.1X ........................................................................................................... 616

Protocolo de autenticación extensible ....................................................................................................... 619

Suplicantes 802.1X............................................................................................................................................... 621

Implementación en fases de IEEE 802.1X ................................................................................................ 622

Cisco TrustSec ........................................................................................................................................................ 623

Servicio de perfiles .............................................................................................................................................. 624

Etiqueta de grupo de seguridad .................................................................................................................... 625

13

Capítulo 1

Diseño Óptimo del

Campus de la Empresa

14

Principios de Diseño del Campus Empresarial

El uso de un conjunto guía de principios fundamentales de ingeniería garantiza que el

diseño del campus proporcione el equilibrio de disponibilidad, seguridad, flexibilidad y

capacidad de gestión necesarios para satisfacer las necesidades empresariales y

tecnológicas actuales y futuras. En esta sección se discuten los principales principios de

diseño que, a su vez, aprovechan un conjunto común de principios de ingeniería y

arquitectura:

Jerarquía.

Modularidad.

Flexibilidad.

Resistencia

JERARQUÍA

Romper el diseño en capas permite que cada capa implemente funciones específicas, lo

que facilita el diseño de la red. Esto también facilita el despliegue y la administración de la

red. Las dos arquitecturas de diseño jerárquico probadas para las redes de campus son los

modelos de capa de tres niveles y de capa de dos niveles.

Capa de acceso

La capa de acceso es la primera capa o borde de la red del campus. Es el lugar donde los

puntos finales (PC, impresoras, cámaras, etc.) se conectan a la parte con cable o

inalámbrica de la red del campus. También es el lugar donde se unen los dispositivos que

amplían la red a un nivel mayor.

La capa de acceso es la primera capa de defensa en la arquitectura de seguridad de la red y

el primer punto de negociación entre los dispositivos finales y la infraestructura de red.

Casi siempre se espera que la capa de acceso proporcione seguridad, calidad de servicio

(QoS) y funciones de límites de políticas de confianza. Como resultado, estas necesidades

de amplio alcance a veces presentan un reto para el arquitecto de la red al momento de

15

determinar cómo generar un diseño que cumpla con una amplia variedad de requisitos.

Este es un elemento clave para habilitar múltiples servicios en el campus (como la

necesidad de varios niveles de movilidad, acceso unificado de voz, video y datos, la

necesidad de un entorno de operaciones rentable y flexible), al mismo tiempo que se

puede proporcionar el equilibrio de seguridad y disponibilidad esperado en entornos de

configuración fija más tradicionales.

Requisitos de servicio

Servicios de

descubrimiento y

configuración

Servicios de Seguridad e

Identidad y Acceso a la

Red

Servicios de

reconocimiento de

aplicaciones

Servicios Inteligentes de

Control de Red

Servicios de

infraestructura física

Características del servicio

802.1AF, CDP, LLDP.

IBNS (802.1X), port security, DHCP snooping, DAI, IPSG,

802.1X, Web-Auth.

Marcado QoS, vigilancia, colas, inspección profunda de

paquetes NBAR, y así sucesivamente

PVST+, Rapid PVST+, EIGRP, OSPF, DTP, PAgP/LACP,

UDLD, FlexLink, Portfast, UplinkFast, BackboneFast,

LoopGuard, BPDUGuard, Port Security, RootGuard

Power over Ethernet (PoE)

16

Capa de distribución

La capa de distribución en el diseño del campus tiene un papel único en que actúa como

un límite de servicios y control entre el acceso y el núcleo. La capa de distribución sirve

para múltiples propósitos:

Actúa como un punto de agregación para todos los nodos de acceso (al realizar las

agregaciones de enlaces físicos y agregación de tráfico hacia la capa núcleo)

Proporcionar servicios de conectividad y políticas para flujos de tráfico dentro de

un solo bloque de distribución de acceso para el tráfico entre nodos de acceso

(flujos de tráfico este-oeste)

Proporcionar el punto de demarcación de agregación, control de políticas y

aislamiento entre el bloque de construcción de distribución del campus y el resto

de la red (flujos de tráfico norte-sur)

Enrutamiento en la capa de distribución, ya que participa en el enrutamiento del

núcleo.

Por lo tanto, las opciones de configuración para las características de la capa de

distribución a menudo están determinadas por los requisitos de la capa de acceso. Las

opciones de configuración para las características en la capa de distribución también están

determinadas por los requisitos de la capa núcleo o por la necesidad de actuar como una

interfaz tanto para la capa de acceso como para la capa núcleo.

Capa núcleo

Proporciona un conjunto limitado de servicios y debe estar diseñado para ser altamente

disponible y operar en un modo de siempre encendido. Los principales objetivos de diseño

para el núcleo del campus se basan en proporcionar el nivel de redundancia adecuado

para permitir una recuperación inmediata del flujo de datos en el caso de que se produzca

un fallo de componente (switch, supervisor, tarjeta de línea o fibra). El núcleo de la red no

debe implementar ningún servicio de políticas complejo, ni debe tener conexiones de

17

puntos finales conectadas directamente. La capa núcleo sirve como agregador para todos

los otros bloques del campus y enlaza el campus con el resto de la red. La capa núcleo

ofrece flexibilidad para el diseño de grandes redes de campus para satisfacer el cableado

físico y los retos geográficos.

En consecuencia, basándose en el tamaño de la red actual (teniendo en cuenta los planes

futuros del negocio), puede elegir uno de los dos modelos de diseño comunes del diseño

del campus empresarial jerárquico: el modelo de capas de dos niveles o el de tres niveles.

Modelo de capa de dos capas de campus empresarial

Redes de campus más pequeñas, como una pequeña ubicación remota del campus, pueden

tener varios departamentos trabajando en varios pisos dentro de un edificio. En estos

entornos, los diseñadores de redes pueden considerar colapsar la función de núcleo en el

switch de capa de distribución para un campus tan pequeño donde puede haber solo un

bloque de distribución sin comprometer los principios básicos del diseño de la red.

Este modelo de diseño ofrece una solución rentable (menos niveles significa menos

dispositivos, específicamente, dispositivos básicos) sin sacrificar la mayoría de los

beneficios del modelo de tres capas en las pequeñas redes de campus. Las funciones de

capa de distribución y capa de núcleo se combinarán en una sola capa/dispositivo, por lo

que el núcleo/dispositivo de distribución colapsado debería ofrecer las siguientes

funciones y capacidades:

Interconexiones de alta capacidad.

La agregación de la capa 2 y un punto de demarcación entre la capa 2 y la capa 3.

18

Políticas de enrutamiento y acceso a la red definidas.

Servicios inteligentes de red como QoS y virtualización de red.

Modelo de capa de tres niveles del campus de la empresa

La implementación del modelo de capa de tres niveles es un modelo de diseño altamente

recomendado y factible para redes de campus de grandes empresas, especialmente si se

espera que la red crezca significativamente con el tiempo. Además, en las redes de campus

de gran escala, cuando la densidad de los controladores WAN, controladores WAAS,

dispositivos de borde de Internet y controladores LAN inalámbricos crece, no es factible y

no se aconseja conectar estos nodos a un solo interruptor de capa de distribución. De esta

forma, se evitan las complejidades de diseño y de operación, así como un único punto de

falla, lo que lo convertirá en un diseño inflexible, no resistente y no escalable.

Por lo tanto, debe considerar una capa de distribución independiente para los servicios

basados en la red. Como resultado, habrá más bloques de distribución a ser

interconectados, y mientrás más bloques de distribución haya en la red, más se tendrá que

considerar un bloque de núcleo separado (capa). Como regla general, cuando tiene tres o

más bloques de distribución, debe considerar una capa/bloque de núcleo distinta para

interconectar estos bloques de distribución, en los que deben interconectarse múltiples

switches de distribución.

19

MODULARIDAD

Los módulos del sistema son los bloques de construcción que se ensamblan en el campus.

La ventaja del enfoque modular se debe en gran medida al aislamiento que puede

proporcionar. Las fallas que ocurren dentro de un módulo pueden aislarse del resto de la

red, proporcionando tanto una detección de problemas más sencilla como una mayor

disponibilidad general del sistema. Además, teniendo en cuenta la modularidad en su

diseño, proporcionará una operación optimizada, ya que los cambios de red,

actualizaciones o la introducción de nuevos servicios se pueden hacer de forma controlada

y escalonada, lo que permite una mayor flexibilidad en el mantenimiento y una operación

menos compleja de la red del campus.

No debería ser necesario rediseñar toda la red cada vez que se añade o se elimina un

módulo. Por lo tanto, introducir la modularidad en el diseño del campus empresarial hace

que la red sea fácil de escalar, comprender y solucionar problemas mediante la promoción

de patrones de tráfico deterministas.

La Arquitectura Modular del Campus de la Empresa y El Campus

Empresarial Modular con OSPF

Normalmente, la arquitectura de red de campus de empresa a gran escala puede tener

múltiples módulos especializados diferentes, también denominados "bloques de

construcción" o "lugares en la red (PIN)".

La introducción de la modularidad en grandes redes de campus con múltiples bloques de

distribución promoverá un diseño de enrutamiento más optimizado para tener un mejor

20

aislamiento de fallas por bloque/módulo y un resumen de ruta más eficiente (suponiendo

que existe un esquema de direccionamiento IP estructurado en el que cada bloque tiene su

propio rango IP).

21

Bloque de Acceso-Distribución

El bloque de acceso - distribución consta de dos de los tres niveles jerárquicos dentro de la

arquitectura de campus multicapa: las capas de acceso y distribución.

Existen tres opciones de diseño comunes y comprobados para configurar el bloque de

acceso - distribución y los protocolos del plano de control asociados (enrutamiento,

Spanning-Tree, etc.): multicapa, switch virtual (switch clustering) y acceso enrutado. A

pesar de que estos diseños utilizan relativamente la misma topología física básica y

estructura de cableado, existen algunas diferencias clave entre cada opción de diseño

(debe tener en cuenta estas diferencias para poder diseñar una arquitectura de red de

campus óptima). Las siguientes son descripciones de cada uno:

Multicapa: Este modelo de diseño se basa principalmente en los diseños

tradicionales de capa 2 que se basan en el protocolo Spanning-Tree (STP) para

evitar bucles de capa 2 y controlar el tráfico de la topología desde una perspectiva

de capa 2 (para la cual el enlace está activo). En general, esta opción de diseño

proporciona la menor flexibilidad y pocas capacidades de convergencia en

comparación con las otras opciones. Normalmente, hay diferentes topologías en

este diseño, como con bucle y sin bucle. Considerando, cualquiera de estas opciones

puede influir en el nivel de flexibilidad del diseño y el tiempo de convergencia. Por

lo tanto, el nivel real de flexibilidad y capacidad de convergencia rápida depende de

la topología utilizada.

Switch virtual (switch clustering): Este modelo ofrece un diseño optimizado,

flexible, resistente y fácil de gestionar para la conectividad acceso-distribución. Con

este modelo, no hay necesidad de confiar en otros protocolos tales como Spanning-

Tree Protocol (STP) y First-Hop Redundancy Protocol (FHRP); además, el concepto

de agregación de enlaces multi-chasis (mLAG) con los switches de distribución

ascendentes agrupados (conmutación virtual) hace que este modelo sea más

flexible cuando se requiere una cobertura de VLAN de Capa 2 entre diferentes

switches de acceso. Además, tener ambos enlaces ascendentes desde el acceso a los

switches de distribución agrupados en estado de reenvío ayuda a maximizar el

ancho de banda disponible para los extremos conectados a los switches de capa de

acceso y optimiza significativamente el tiempo de convergencia después de un

evento de fallo de nodo o enlace.

Acceso enrutado: Se trata de un modelo de conectividad de acceso/distribución

confiable y de convergencia rápida. En las redes de campus empresariales

modernas, el acceso enrutado se utiliza a veces como una configuración alternativa

al modelo de bloque de distribución tradicional, en el que el switch de acceso actúa

como un nodo enrutado de Capa 3 completo (que proporciona conmutación de

Capa 2 y Capa 3) y los enlaces troncales ascendentes de acceso-a-distribución de

capa 2 se reemplazan con enlaces enrutados punto a punto de capa 3. El diseño de

bloque de distribución de acceso enrutado tiene una serie de ventajas sobre el

diseño multicapa que usa enlaces ascendentes capa 2 entre acceso y distribución.

22

Ofrece herramientas comunes de solución de problemas de extremo a extremo

como ping y traceroute, usa un protocolo de control único como EIGRP o OSPF, y

elimina la necesidad de características como HSRP.

FLEXIBILIDAD

El principio de diseño de flexibilidad se refiere a la capacidad de modificar las porciones

de la red, añadir nuevos servicios o aumentar la capacidad sin pasar por una actualización

importante.

23

El diseño jerárquico estructurado proporciona un alto grado de flexibilidad porque

permite cambios escalonados o graduales a cada módulo en la red con bastante

independencia de los demás. Los cambios en el transporte del núcleo se pueden hacer

independientemente de los bloques de distribución. Los cambios en el diseño o capacidad

de la capa de distribución se pueden implementar de forma gradual o incremental.

Como diseñador de redes, debe considerar una serie de áreas clave al diseñar una red de

campus de empresa moderna que puede evolucionar en los próximos años. Las áreas clave

a considerar son las siguientes:

Flexibilidad del plano de control: La capacidad de soportar y permitir la

migración entre múltiples protocolos de enrutamiento, spanning-tree y otros

protocolos de control.

Flexibilidad del plano de reenvío: La capacidad de soportar la introducción y el

uso de IPv6 como requisito paralelo junto con IPv4.

Flexibilidad de grupos de usuarios: La capacidad de virtualizar las capacidades y

servicios de reenvío de red en el tejido del campus para soportar cambios en la

estructura administrativa de la empresa. Esto puede implicar la adquisición, la

asociación o la subcontratación de funciones empresariales.

Flexibilidad en la gestión y el control del tráfico: las comunicaciones unificadas,

los enfoques empresariales colaborativos y los modelos de software continúan

evolucionando, junto con una tendencia hacia un mayor crecimiento de los flujos de

tráfico peer-to-peer. Estos cambios fundamentales requieren diseños de campus

que permiten el despliegue de herramientas de seguridad, monitoreo y solución de

problemas disponibles para dar soporte a estos nuevos patrones de tráfico.

Flexibilidad para soportar los requisitos de aislamiento de multitenencia y

tráfico: La capacidad de soportar estos requisitos es necesaria en las modernas

redes de hoy en día.

VIRTUALIZACIÓN DE LA RED DEL CAMPUS

Admitir la virtualización de red ofrece flexibilidad al diseño. Proporciona diferentes redes

lógicas y se traduce en diferentes grupos de acceso a través de una sola red física,

manteniéndolas lógicamente separadas; Esta es una solución que ha desafiado a los

operadores de red. Uno de los enfoques de virtualización de red tiene como objetivo

permitir que una sola entidad física actúe en múltiples instancias físicas en las que pueda

ser utilizada por diferentes grupos de usuarios.

Desde el punto de vista del diseño, para proporcionar el nivel deseado de flexibilidad y

eficiencia con la virtualización de la red, la solución de diseño debe considerar los

siguientes aspectos:

24

Control de acceso: También se denomina control de bordes, lo que ayuda a

garantizar que los usuarios y dispositivos legítimos sean reconocidos, clasificados y

autorizados a entrar en las partes asignadas de la red. Una de estas tecnologías que

se puede utilizar es IEEE 802.1X, que es el estándar para la autenticación de

puertos.

Aislamiento de ruta: ayuda a asegurar que el usuario o dispositivo justificado se

correlaciona eficazmente con el conjunto seguro y correcto de recursos

disponibles, como lo es la red inquilina relevante (red virtual) en un entorno de

multitenencia.

Borde de servicios: también se denomina virtualización de servicios, lo que ayuda

a garantizar que los servicios adecuados sean accesibles a los conjuntos legítimos

de usuarios y dispositivos (por ejemplo, un centro de datos de multitenencia).

Tecnologías y Técnicas de Virtualización de la Red del Campus

En esta sección se analizan los requisitos tecnológicos fundamentales para lograr la

virtualización de red en una red de campus y las diferentes técnicas que pueden utilizarse

para lograr el aislamiento de rutas de extremo a extremo a través de la red por VN (red

virtual).

Asignación de VLAN

Como se mencionó anteriormente, el primer punto para asignar un usuario o un

dispositivo a una red determinada está en la capa de acceso, que es el primer punto de

entrada a la red del campus. El enfoque más simple y más común aquí es asignar una

VLAN diferente por grupo de usuarios o red virtual en la capa de acceso. En el pasado, el

enfoque típico para la asignación de VLAN sería asignar manualmente un puerto para ser

miembro de una VLAN específica. Otro método que se está volviendo mucho más común

hoy en día es a través de las capacidades de seguridad mejoradas de la Autenticación

Flexible usando 802.1X, Autenticación MAC y Bypass (MAB), o Webauth como medio

alternativo para autenticar primero a un usuario contra un Servidor Radius o un Servidor

de Cumplimiento de Políticas, como el Cisco Identity Services Engine (ISE), para el acceso

25

a la red. Una vez autenticado, el switchport se cambia dinámicamente a la VLAN apropiada

y, opcionalmente, se puede empujar una ACL al switch, imponiendo un acceso específico a

la red.

Enrutamiento y Reenvío virtuales (VRF)

Como el objetivo de cada diseño de red sólida es minimizar el alcance del dominio de

difusión y la exposición a los bucles capa 2, se requiere un método para traducir la VLAN

de Capa 2 a una red virtual de Capa 3 o VPN (Virtual Private Network). Esta VN de Capa 3

debe ser capaz de soportar su propio plano de control único, con su propia estructura de

direccionamiento y tablas de enrutamiento para el reenvío de datos completamente

aislado de cualquier otra VPN de Capa 3 en ese dispositivo y en la red. La tecnología que

permite este tipo de funcionalidad se conoce como la instancia virtual de enrutamiento y

reenvío (VRF).

Por otra parte, basados en el modelo de diseño del campus (multicapa versus acceso

enrutado) utilizado, los VRFs se definen donde las VLAN de capa 2 bordean la red de capa

3. Por lo tanto, si la capa de acceso está conectada a la de agregación a través de la Capa 2,

los VRF se definen en la distribución o los switches de núcleo colapsados que agregan la

capa de acceso. Sin embargo, si la capa de acceso está conectada a la capa 3 (el modelo de

acceso enrutado), los VRF se definen en el propio switch de acceso.

Técnicas de aislamiento de ruta

La instancia VRF en un dispositivo de red es un objeto aislado que debe estar vinculado a

otras instancias del mismo VRF en otros dispositivos a través de la red. Hay varios medios

por los cuales esto se logra. Los siguientes son los métodos más comunes para lograr el

aislamiento de la ruta en la red del campus:

26

Hop-by-hop basado en VRF-Lite: VRF-Lite desplegado en un esquema hop-byhop

en un campus utiliza troncales 802.1Q para interconectar los dispositivos

configurados para VRFs. Una vez que se ha completado la asignación de VLAN a

VRF en el hardware de acceso o de distribución, las interfaces orientadas al núcleo

deben configurarse. Estas interfaces pueden ser configuradas de dos formas

diferentes. La primera aproximación es usar una VLAN y su SVI asociado, que

entonces sería asignado al VRF apropiado. La segunda es usar subinterfaces en la

interfaz de núcleo con cada subinterfaz asignada a la VRF apropiada. Por lo general,

para cada VRF, se debe utilizar un ID de VLAN único para cada enlace físico que

interconecta dispositivos de red porque cada uno se considera un salto enrutado

Hop-by-hop virtual basado en la red virtual (EVN): Hop-by-hop VRF-lite es

manejable para redes con menos números de redes virtuales y menos números de

saltos en una ruta de red virtual. Sin embargo, cuando el número de redes lógicas

(virtuales/inquilinos) aumenta, habrá un alto grado de complejidad operacional

para crear y configurar la interfaz o subinterfaz por VN. EVN ofrece los mismos

beneficios para garantizar la separación del tráfico con operaciones más

simplificadas. En otras palabras, EVN se basa en los conceptos y capacidades VRF-

Lite y proporciona beneficios adicionales, entre los que se incluyen los siguientes:

o EVN ofrece una mejor escalabilidad de extremo a extremo en comparación

con la clásica solución hop-by-hop basada en 802.1Q.

o EVN ofrece una configuración y gestión simplificadas.

o EVN ofrece la capacidad de proporcionar servicios compartidos entre

diferentes grupos lógicos.

27

Con la ruta EVN, puede lograr el aislamiento mediante el uso de una etiqueta única

para cada VN. Esta etiqueta se conoce como etiqueta VNET. Cada VN transporta a

una red virtual el mismo valor de etiqueta asignado por un administrador de red.

Basado en eso, los dispositivos con capacidad para EVN a lo largo de la ruta usarán

estas etiquetas para asegurar el aislamiento del tráfico de extremo a extremo entre

diferentes VNs. Con este enfoque, se elimina la dependencia de las interfaces físicas

o lógicas clásicas (basadas en 802.1Q) para proporcionar separación de tráfico.

Multihop GRE basado en túneles: Si no todos los dispositivos de la ruta soportan

VRF-Lite, el VRF puede ser transportado usando túneles genéricos de encapsulación

de enrutamiento (GRE) para que cada VRF pueda ser asignado a una interfaz de

túnel específica. Dependiendo de la topología, se pueden usar túneles punto a

punto o punto a multipunto. Además, GRE puede agregar un poco de sobrecarga de

procesamiento en los switches (según la plataforma); Por lo tanto, este enfoque no

siempre se recomienda a menos que se utilice como una solución provisional.

28

Basado en MPLS Multihop: Uno de los principales beneficios del despliegue de

una infraestructura MPLS es la capacidad de proporcionar conectividad dinámica

de malla a cualquier red virtual privada (VPN) mediante el uso de Multiprotocol

BGP y el protocolo Label Distribution Protocol (LDP). En este tipo de diseño, se

puede pensar en el núcleo del campus como el enrutador de proveedor (P) y el

nodo de capa de distribución como nodos de borde del proveedor (PE). De hecho,

MPLS no debe ser visto como una solución destinada sólo a WAN. Muchas

organizaciones empresariales han desplegado MPLS con éxito a lo largo de la

distribución y el núcleo de redes de datos, además de centros de datos, WAN e

Internet.

RESILIENCIA

Se refiere a la capacidad de un sistema para permanecer disponible para su uso en

condiciones normales y anormales. Las condiciones normales (también llamadas

interrupciones planificadas) incluyen eventos tales como ventanas de cambio, flujos de

tráfico normales o esperados, y patrones de tráfico. Las condiciones anormales (también

llamadas interrupciones imprevistas) incluyen fallas de hardware o software, cargas

extremas de tráfico, patrones de tráfico inusuales, eventos de denegación de servicio

(DoS), ya sean intencionales o no intencionales, y cualquier otro evento no planeado.

El diseño resiliente no es una característica, ni hay una cosa específica que se deba hacer

para lograrlo. Al igual que con la jerarquía y la modularidad, la resiliencia es un principio

básico que se hace real mediante el uso de muchas características relacionadas y opciones

de diseño.

Consideraciones de Diseño de Alta Disponibilidad del Campus de

la Empresa

En general, los siguientes tres requisitos de resiliencia clave abarcan la mayoría de los

tipos comunes de condiciones de falla; dependiendo del nivel de diseño de LAN, debe

implementarse la opción de resiliencia apropiada al tipo de servicio de rol y de red:

Resiliencia de red: Proporciona redundancia durante fallos de enlaces físicos,

como corte de fibra, transceptores defectuosos, cableado incorrecto, etc. Para

lograr este tipo de resiliencia, siempre debe tener como objetivo tener enlaces

ascendentes redundantes entre dos capas de red en la red del campus.

Resiliencia del dispositivo: Protege la red durante fallas anómalas del nodo

activadas por hardware o software, como fallos de software, un supervisor que no

29

responde, etc. Por ejemplo, considerando el concepto de switch virtual como VSS o

Stackwise, la tecnología ayudará a lograr la elasticidad a nivel de dispositivo.

Resiliencia operativa: Habilita las capacidades de resiliencia al siguiente nivel,

proporcionando una disponibilidad completa de la red incluso durante

interrupciones planificadas de la red utilizando las funciones de actualización de

software en servicio (ISSU).

Recomendaciones de Diseño de VLANs, Trunking y Agregación de

Enlaces

Esta sección ofrece las recomendaciones de mejores prácticas con respecto a VLAN,

trunking y agregación de enlaces para lograr un diseño que admita una red de campus

altamente disponible.

Diseño de VLAN

Un diseño tradicional común de VLANs debe configurarse a través de múltiples switches

de acceso que se conectan al mismo switch de capa de distribución ascendente. Aunque

este modelo de implementación es técnicamente válido, tiene algunas desventajas que, en

última instancia, pueden introducir limitaciones de escalabilidad y estabilidad a la red. Por

ejemplo, cuando utiliza una topología en la que las VLAN se distribuyen a través de varios

switches de capa de acceso, puede introducir enrutamiento asimétrico e inundación

unicast, en el que el tráfico que regresa a través del router HSRP en espera, VRRP

alternativo o GLBP no reenviador puede inundarse a todos los puertos en la VLAN de

destino. Esto puede tener un impacto significativo en el rendimiento y la disponibilidad y

estabilidad del servicio.

Es necesario considerar un diseño en el que las VLAN sean locales a los switches

individuales de la capa de acceso. Este tipo de problema es, por tanto, intrascendente

30

debido a que el tráfico se inunda en una sola interfaz (la única interfaz en la VLAN) en el

HSRP en espera, VRRP, o GLBP no facilitante. El tráfico se inunda la misma interfaz que se

utilizaría normalmente, por lo que el resultado final es el mismo. Además, el switch de

capa de acceso que recibe el tráfico inundado tiene una entrada de tabla CAM para el host

porque está conectado directamente, de modo que el tráfico se conmuta sólo al host

previsto. Como resultado, ninguna estación final adicional se ve afectada por el tráfico

inundado

Cuanto mayor sea el dominio de la capa 2, mayor será el dominio de fallo en la red. Por lo

tanto, siempre debe tratar de evitar que se extiendan las VLAN de Capa 2 a través de los

switches de capa de acceso, a menos que sea necesario para ciertas VLAN para ciertas

aplicaciones.

Trunking

Los protocolos de trunking permiten que los enlaces entre dispositivos de red lleven

múltiples VLAN a través de un solo enlace físico o lógico (EtherChannel).

Actualmente se dispone de dos tipos de troncales:

802.1Q: Implementación estándar del Instituto de Ingenieros Eléctricos y

Electrónicos (IEEE).

Inter-Switch Link (ISL): Cisco desarrolló ISL antes de que se estableciera el

estándar.

Las siguientes son prácticas recomendadas al implementar VLAN múltiples en una sola

interconexión switch-to-switch o troncal:

Implementar VLANs en la interconexión entre capas de acceso y distribución.

31

Utilice el VLAN Trunking Protocol (VTP) en modo transparente para reducir

potenciales errores operacionales. De lo contrario, no se recomienda porque sus

preocupaciones superan sus beneficios.

Establecer el modo troncal a on y la encapsulación de negociar a apagado

(nonegotiate) para una convergencia óptima. Cuando se habilita la negociación de

protocolo dinámico de troncal (DTP) y 802.1Q o ISL, se puede dedicar un tiempo

considerable a la negociación de la configuración de troncales cuando se restaura

un nodo o una interfaz. Mientras esta negociación está ocurriendo, el tráfico se

pierde (vea la Figura 1-20).

Asigne la VLAN nativa a una ID no utilizada o utilice la opción Tagged Native VLAN

para evitar salto de VLAN.

Manualmente podar todas las VLANS excepto las necesarias.

Agregación de enlace

El agrupamiento lógico de múltiples enlaces redundantes en una única entidad lógica se

denomina agregación de enlaces. Existen dos variantes: la implementación de Cisco

EtherChannel que utiliza el protocolo de agregación de puertos (PAgP) como un

mecanismo de control y la implementación basada en estándares IEEE 802.3ad que utiliza

el protocolo de control de agregación de enlaces (LACP) como mecanismo de control.

Normalmente, la agregación de enlaces se utiliza para eliminar las dependencias de un

solo punto de fallo (es decir, vínculo o puerto) de una topología. Por lo tanto, se despliega

comúnmente entre las redes de acceso a la distribución, la distribución a núcleo y las

interconexiones de núcleo a núcleo, donde se requiere mayor disponibilidad y ancho de

banda escalado.

32

Puede crear canales que contengan hasta ocho enlaces paralelos entre switches. También

puede crear estos canales en interfaces que están en diferentes tarjetas de línea física, lo

que proporciona una mayor disponibilidad porque el fallo de una tarjeta de línea única no

causa una pérdida completa de conectividad. En algunos switches de Cisco que admiten

canales apilables como las familias de switches 3750, 2960 o 3800, puede crear un canal

de interconexión donde los miembros del EtherChannel existen en diferentes miembros

de la pila, lo que genera un alto nivel de disponibilidad.

Las siguientes son recomendaciones de prácticas recomendadas que se deben tener en

cuenta al implementar la agregación de vínculos:

Para EtherChannels de Capa 2, Desirable/Desirable es la configuración

recomendada para que PAgP se ejecute en todos los miembros del stack,

asegurándose de que un fallo de enlace individual no resulte en un fallo de STP.

Para EtherChannels de Capa 3, considere una configuración que use On / On. Hay

un equilibrio entre el impacto de alto rendimiento y el rendimiento y las

implicaciones de mantenimiento y operaciones.

Una configuración On/On es más rápida desde una perspectiva de enlace

(restauración) que una alternativa desirable / desirable. Sin embargo, en esta

configuración, PAgP no está monitoreando activamente el estado de los miembros

del paquete, y un paquete configurado incorrectamente no se identifica fácilmente.

Los protocolos de enrutamiento pueden no tener visibilidad en el estado de un

miembro individual de la agrupación. Puede usar LACP y la opción de enlaces

mínimos para apagar la agrupación completa cuando la capacidad disminuya.

Debe desactivar la negociación PAgP si los túneles EtherChannel no son necesarios.

Si no se desactiva la negociación de EtherChannel, el desajuste entre los estados

33

(un lado podría ser deseable y el otro fuera) puede causar hasta 7 segundos de

pérdida durante la negociación del enlace.

Por otro lado, Multichassis EtherChannel (MEC) ofrece la mejor alta disponibilidad,

rendimiento y diseño de convergencia más rápida. En el caso de un fallo de desvinculación

de un miembro MEC hacia un switch de distribución VSS, desde el punto de vista de tráfico

en sentido ascendente, la convergencia está determinada por la detección de fallo de

enlace de dispositivo de acceso. En tal escenario, la convergencia de EtherChannel es de

unos 200 ms, y sólo los flujos en el enlace fallido en ese momento se ven afectados. Del

mismo modo, desde un punto de vista de tráfico en sentido descendente, la convergencia

está determinada por el nodo VSS, y la convergencia de VSS EtherChannel tardará

normalmente unos 200 ms, y sólo afectarán los flujos en el enlace fallido.

34

Protocolo de redundancia de primer salto (FHRP)

En un diseño jerárquico de campus que utiliza un modelo de acceso multicapa, los

switches de distribución son el límite de capa 2 / capa 3 y normalmente proporcionan el

servicio de puerta de enlace predeterminado de capa 3 para el dominio de capa 2

correspondiente. Para mantener la disponibilidad de estas funciones claves, debe

considerar la redundancia FHRP para evitar cualquier interrupción que podría ocurrir si

falla el dispositivo que actúa como puerta de enlace predeterminada.

Cisco ha desarrollado el protocolo HSRP para abordar esta necesidad, y el grupo de

trabajo de ingeniería de Internet (IETF) posteriormente ratificó el protocolo VRRP como el

método basado en estándares para proporcionar redundancia de puerta de enlace

predeterminada .

El protocolo GLBP, por otro lado, protege el tráfico de datos de un enrutador o circuito

fallido, como HSRP y VRRP, al mismo tiempo que permite compartir la carga de paquetes

entre un grupo de routers redundantes.

Cuando se utiliza HSRP o VRRP para proporcionar redundancia de puerta de enlace

predeterminada, los miembros de respaldo de la relación de iguales están inactivos,

esperando que ocurra un evento de error para que ellos tomen el relevo y activamente

envíen tráfico

Antes del desarrollo de GLBP, algunas soluciones utilizaban uplinks más eficientemente.

Por ejemplo, una de las técnicas comunes utilizadas con HSRP es asegurar que los roles de

raíz STP / RSTP se alternan entre pares de nodos de distribución, con las VLAN pares

domiciliadas en un par y las VLAN impares domiciliadas en el alterno. Otra técnica utilizó

grupos HSRP múltiples en una sola interfaz y utilizó DHCP para alternar entre las

múltiples pasarelas predeterminadas. Aunque estas técnicas funcionaron, no eran óptimas

desde una perspectiva de configuración,

mantenimiento o administración.

GLBP ofrece todos los beneficios de HSRP

más el equilibrio de carga de la puerta de

enlace predeterminada para que pueda

utilizar más eficientemente todo el ancho

de banda disponible. Con el GLBP, un

grupo de enrutadores funciona como un

enrutador virtual compartiendo una

dirección IP virtual pero utilizando varias

direcciones MAC virtuales para el

reenvío de tráfico. En consecuencia, el

tráfico de una sola subred común puede

pasar por múltiples puertas de enlace

35

redundantes utilizando una sola dirección IP virtual.

Sin embargo, GLBP conduce al enrutamiento asimétrico porque enviará flujos de tráfico de

salida sobre las rutas ascendentes disponibles, y lo más probable es que el tráfico de

retorno de estos flujos distribuidos vuelva sobre una única ruta de retorno. Este resultado

puede conducir a algunos problemas de diseño si un dispositivo de seguridad con estado,

como un firewall está en la ruta. La solución a este problema es considerar HSRP y alinear

el anuncio de subred a las redes externas para garantizar que el tráfico de retorno vuelve

por el mismo camino (Porque HSRP también, por defecto, conduce a un enrutamiento

asimétrico si el anuncio de enrutamiento no está alineado con el nodo HSRP activo). Como

alternativa, puede utilizar la capacidad de clúster de firewall que ofrece Cisco ASA

firewalls.

Además, debe asegurarse de que el enlace de conmutación entre distribuciones esté

siempre en el estado de bloqueo STP si se implementa como capa 2. También debe

asegurarse de que los enlaces ascendentes de los switches de capa de acceso se

encuentren en un estado de reenvío (por ejemplo, al cambiar el costo de puerto en la

interfaz entre la capa de distribución cambia el puente raíz secundario STP a valor alto)

para permitir que el tráfico fluya hacia arriba en ambos enlaces desde los switches de capa

de acceso a ambas direcciones MAC virtuales GLBP y evite una ruta de dos saltos en la

capa 2 para el tráfico ascendente.

36

Para operaciones FHRP más optimizadas en entornos que dependen de STP, la

preemption es importante para proporcionar una convergencia rápida y confiable. Por

ejemplo, HSRP preemption permitirá HSRP para seguir una topología árbol expandido.

Con el preemption, el par primario de HSRP reasume el papel primario cuando viene

detrás en línea después de un acontecimiento del fallo o del mantenimiento. Sin embargo,

debe tener en cuenta el tiempo de arranque del conmutador y la conectividad con el resto

de la red porque puede formarse una relación de vecino HSRP y la preemption ocurrirá

antes de que el conmutador principal tenga conectividad de Capa 3 con el núcleo. Si esto

sucede, el tráfico probablemente se reducirá hasta que se establezca la conectividad

completa.

Por lo tanto, la mejor práctica recomendada es medir el tiempo de arranque del sistema y

establecer la sentencia de espera anticipada HSRP a un 50 por ciento mayor que este

37

valor. Esto asegura que el nodo de distribución principal del HSRP haya establecido una

conectividad completa a todas las partes de la red antes de que se permita que se

produzca la preemption HSRP.

Optimización de redundancia de puerta de enlace IP con VSS

Dado que el sistema de conmutación virtual (VSS) agrupa dos chasis físicos en sistemas

lógicos únicos, no es necesario implementar un protocolo como HSRP para proporcionar

redundancia de gateway IP para puntos finales. En su lugar, la redundancia del gateway en

la capa de agregación ahora se ofrece con la arquitectura de interconexión con estado

interconectado (SSO) integrada en lugar de crear cualquier configuración de puerta de

enlace virtual. Por lo tanto, VSS elimina la necesidad de implementar FHRP para cada

VLAN, lo que mejora significativamente el rendimiento de la CPU en un diseño de red de

capa 2 a gran escala. También reduce la complejidad operacional y de solución de

problemas con una configuración de red sencilla para implementar redes. Además, VSS

elimina la necesidad de implementar completamente los protocolos FHRP; Como

resultado, ya no necesita ajustar este protocolo para el proceso de recuperación rápida.

Opciones y Consideraciones de Diseño de Límites de Capa 2 a

Capa 3

En esta sección se destaca y se analiza el papel crítico del enlace de interconexión entre los

conmutadores de la capa de distribución para lograr un diseño de capa 2 resiliente. A

continuación, se analiza las diferentes opciones de diseño que pueden utilizarse para

proporcionar el punto de demarcación de capa 2 y capa 3 como parte de la arquitectura de

red de campus jerárquico.

38

Consideraciones sobre el diseño del enlace de distribución a distribución

A veces, los ingenieros de red subestiman la importancia del enlace de interconexión entre

los switches de la capa de distribución en el bloque de distribución de la red de campus

empresarial. Sin embargo, cuando elimina una ruta directa de comunicación para los

switches de capa de distribución, a continuación, dependerá de la capa de acceso para la

conectividad. En un entorno tradicional (basado en STP), esto puede introducir un

comportamiento inesperado en caso de fallo, como el siguiente:

El tráfico se reduce hasta que el HSRP se activa.

El tráfico se pierde hasta que el enlace transita al estado de reenvío, con un tiempo

de hasta 50 segundos.

El tráfico se reduce hasta que el temporizador MaxAge expira y hasta que se

completan los estados de escucha y de aprendizaje.

STP podría causar flujo de tráfico no determinista / ingeniería de carga de enlaces.

Se podría producir una convergencia y una reconvergencia inesperadas de la capa

3.

Interconexión de distribución a distribución con el modelo de acceso

multitier

La eliminación del enlace distribución-distribución puede tener un impacto significativo

en la resiliencia y el rendimiento del diseño de la red del campus. Puede agregar un enlace

de interconexión entre los conmutadores de la capa de distribución de una red de campus

39

basada en el modelo de acceso multicapas discutido anteriormente en este capítulo

(basado en STP) utilizando uno de los dos modelos principales de diseño siguientes:

Modelo con bucle

Modelo sin bucles

El modelo en bucle tiene los siguientes atributos:

Las VLAN pueden extenderse entre los switches de agregación, creando la

topología en bucle.

STP se utiliza para evitar bucles de capa 2.

Las rutas redundantes están disponibles a través de una segunda vía que está en el

estado de bloqueo STP.

Las VLAN pueden equilibrar la carga a través del acceso disponible a los enlaces

ascendentes de la capa de distribución.

Se pueden conseguir dos topologías posibles con este modelo: topologías de

triángulo y bucles cuadrados.

Idealmente, como diseñador de red, debe construir su diseño basado en los requisitos de

las aplicaciones. Por lo tanto, si los requisitos de ciertas aplicaciones críticas requieren que

las VLAN se extiendan a través de varios switches de capa de acceso y el uso de STP sea

una parte integral de su plan de convergencia, considere los siguientes pasos para

asegurarse de que puede obtener lo mejor de esta situación subóptima:

40

Considere PVST + rápido como la versión de STP. Cuando se requiere convergencia

de árbol de expansión, Rapid PVST + es superior a PVST + o 802.1d simple.

Asegúrese de aprovisionar un enlace de Capa 2 entre los dos conmutadores de

distribución con el tamaño correcto de este enlace (por ejemplo, 10/40 Gbps) para

evitar rutas de tráfico inesperadas y eventos de convergencia múltiples.

Si elige equilibrar la carga de las VLAN a través de los enlaces ascendentes,

asegúrese de colocar el primario HSRP y el primario STP en el mismo switch de

capa de distribución. Las raíces HSRP y Rapid PVST + deben ubicarse en los mismos

switches de distribución para minimizar el uso del enlace inter-distribución para el

tránsito.

Debido a que STP desempeña un papel vital en dicha topología, asegúrese de que

habilita la característica mejorada STP para fortalecer la operación STP.

En contraste, el modelo sin bucle tiene los siguientes atributos:

Como se indica a partir de este nombre de modelo de diseño, es libre de bucle. Por

lo tanto, aunque el árbol de expansión está habilitado en tal topología, no habrá

enlaces ascendentes en el estado de bloqueo (todos los puertos están reenviando).

Se pueden conseguir dos topologías posibles con este modelo: las topologías U y U

invertida.

Ofrece una solución más protectora porque habrá menos posibilidades de una

condición de bucle debido a una configuración errónea.

A diferencia del modelo en bucle, en el modelo sin bucle, los límites de capa 2 y

capa 3 varían dependiendo de si se usa la topología U o U invertida.

41

Interconexión de distribución a distribución con el modelo de acceso

enrutado

Cuando está implementando un campus con acceso enrutado, es importante entender

cómo el diseño de enrutamiento del campus encaja en la jerarquía general de

enrutamiento de red y cómo configurar mejor los switches del campus para lograr lo

siguiente:

Convergencia rápida por errores de enlace y / o switch

Recuperación determinista del tráfico

Jerarquía de enrutamiento escalable y manejable

Una de las principales consideraciones de diseño para lograr una convergencia rápida y

una recuperación del tráfico más determinista es la disposición física de los enlaces

enrutados entre los diferentes niveles, específicamente entre los nodos de la capa de

distribución.

42

Aunque la topología básica del campus enrutado es similar al entorno WAN, no es

exactamente la misma. Por lo tanto, debe tener en cuenta las siguientes diferencias entre

los dos entornos al optimizar el diseño de enrutamiento del campus para la convergencia

rápida de enrutamiento:

A diferencia de la WAN, la abundancia de ancho de banda en las redes de campus

permite un ajuste más agresivo del tráfico del plano de control (por ejemplo,

intervalos de paquetes de saludo).

Las redes de campus jerárquicas típicamente tienen cuentas de vecinos más bajas

que la WAN y por lo tanto tienen una carga de plano de control reducida.

Las interconexiones directas de fibra simplifican la detección de fallas de vecinos.

La facilidad y el menor costo de aprovisionar la redundancia en la red del campus

permiten el uso de un diseño redundante óptimo.

La conmutación de hardware de capa 3 asegura recursos de CPU dedicados para el

procesamiento del plano de control.

Interconexión de distribución a distribución con el modelo de conmutador

virtual

El sistema de conmutación virtual funciona de manera diferente en diferentes planos.

Desde un punto de vista de plano de control, los pares de VSS (switches) funcionan en

modo de redundancia en activo/pasivo. El conmutador en modo de redundancia activa

mantendrá el archivo de configuración único para el VSS y lo sincronizará con el

conmutador pasivo, y sólo se podrá acceder a la interfaz de consola del switch activo.

43

Desde una perspectiva de datos y planos de reenvío, tanto los datos como los planos de

reenvío están activos. El supervisor pasivo y todas las tarjetas de línea están activamente

reenviando.

El enlace de interconexión entre los dos miembros del switch virtual se llama enlace de

conmutación virtual (VSL). Este enlace es clave porque además del tráfico de datos

regular, lleva la comunicación de plano de control entre los dos miembros de conmutador

virtuales

Las VSL pueden configurarse con hasta ocho enlaces entre los dos switches a través de

cualquier combinación de tarjetas de línea o puertos de supervisor para proporcionar un

alto nivel de redundancia. Si, por alguna rara razón, todas las conexiones VSL se pierden

entre los miembros de conmutador virtual, dejando a ambos los miembros de conmutador

virtual hacia arriba, el VSS pasará al modo de recuperación de doble activo.

El estado doble activo se detecta rápidamente (en milisegundos) por cualquiera de los tres

siguientes métodos:

Mejora de PAgP utilizada en MEC con switches Cisco de conexión

La configuración de la Detección de Reenvío Bidireccional Capa 3 (BFD) en un

enlace conectado directamente (además de VSL) entre miembros del switch virtual

o a través de un enlace de capa 2 a través de un switch de capa de acceso

La configuración de la Detección Activo Doble de Saludo Rápido Capa 2 en un enlace

directo (además de VSL) entre los miembros de switch virtual

En el modo de recuperación de doble activo, todas las interfaces excepto las interfaces VSL

están en un estado de apagado automático en el miembro del switch virtual anteriormente

activo. El nuevo switch virtual activo continúa transmitiendo tráfico en todos los vínculos.

44

Capítulo 2

Diseño EIGRP

45

DESCRIPCIÓN DEL DISEÑO EIGRP ESCALABLE

EIGRP se puede desplegar sin reestructurar la red (plano). Sin embargo, a medida que

aumenta el tamaño de la red, aumenta el riesgo de inestabilidad o los tiempos de

convergencia son más largos. Para diseñar un EIGRP escalable y estable, debe utilizar una

topología jerárquica estructurada junto con el resumen de ruta, con el propósito de

romper un único dominio de inundación en múltiples dominios y así tener un diseño más

estructurado, manejable y escalable.

Técnicamente, uno de los problemas más importantes de estabilidad y convergencia con

EIGRP es la propagación de consultas (Query). Cuando EIGRP no tiene un sucesor factible,

envía consultas a sus vecinos. Las consultas pueden inundar muchos enrutadores en una

parte de la red y aumentar el tiempo de convergencia. Los puntos de resumen, el

enrutamiento de stubs EIGRP y el filtrado de rutas limitan el alcance de la consulta

(propagación) y minimizan el tiempo de convergencia.

EIGRP CON MÚLTIPLES SISTEMAS AUTÓNOMOS

Algunos diseñadores de redes consideran el uso de múltiples sistemas autónomos EIGRP

(AS), y la redistribución parcial o total entre los dos, como una técnica de escalado. La

racionalidad habitual es reducir el volumen de las consultas EIGRP limitándolas a un solo

sistema EIGRP. Sin embargo, algunos problemas están asociados con este enfoque de

diseño (múltiples ASs EIGRP y distribución entre ellos).

La pregunta aquí es: "¿Este enfoque de diseño (múltiples sistemas autónomos EIGRP y

redistribución entre ellos) ayuda a optimizar la propagación de consultas EIGRP?"?

Consultas EIGRP

46

Considere que este enfoque de diseño (EIGRP con múltiples sistemas autónomos y la

redistribución entre ellos) como un intento de diseño EIGRP de limitación de la consulta,

no es una solución óptima o recomendada en este caso. Para contener consultas, se

recomienda utilizar métodos generales de escalado como resumen, filtrado (listas de

distribución) y stubs EIGRP.

Múltiples controladores del sistema autónomo EIGRP

Considerando EIGRP con múltiples sistemas autónomos y la redistribución entre ellos no

ayuda a limitar el volumen de consultas EIGRP en la topología. Dicho esto, podría haber

varias razones válidas para tener múltiples sistemas autónomos EIGRP, incluyendo lo

siguiente (debe prestarse mucha atención a limitar las consultas EIGRP):

Estrategia de migración después de una fusión o adquisición: Aunque este

escenario de caso de uso no es permanente, varios sistemas autónomos son

apropiados para fusionar dos redes a lo largo del tiempo.

Diferentes grupos gestionan diferentes sistemas autónomos EIGRP: Este

escenario agrega complejidad al diseño de red, pero puede ser utilizado para

diferentes dominios de confianza o control administrativo.

Las organizaciones con redes muy grandes pueden utilizar múltiples

sistemas autónomos EIGRP como una forma de dividir sus redes:

Generalmente, un enfoque de diseño utiliza rutas de resumen en los límites AS para

contener bloques resumibles de prefijos IP en redes muy grandes y para abordar el

problema de la propagación de consultas EIGRP.

47

ARQUITECTURAS MULTICAPA EIGRP

EIGRP no tiene técnicamente "áreas" como OSPF porque la información de topología está

oculta, por diseño, en cada salto. EIGRP ofrece la flexibilidad de ser diseñado con múltiples

capas (capas) en topologías de red jerárquica. Esta flexibilidad es impulsada por el hecho

de que los diseñadores de redes pueden definir tantos niveles como sea necesario. Lo que

define técnicamente un límite de capa o capa en el diseño EIGRP es el lugar donde se

define el resumen o el filtrado de rutas. En otras palabras, en una red EIGRP, la jerarquía

se crea mediante resumen o filtrado. EIGRP no tiene un límite impuesto sobre el número

de niveles de jerarquía, que es una ventaja clave de diseño.

Las zonas son partes topológicamente definidas de la red. Las zonas representan un

dominio de fallo. Enlace y fallos de dispositivos dentro de una zona deben tener poco o

ningún impacto fuera de esa zona específica.

Los puntos de estrangulación representan los lugares donde las zonas están

interconectadas. Los puntos de estrangulación proporcionan un lugar donde agrega

accesibilidad e información de topología. Los puntos de estrangulación son un lugar donde

se aplica el resumen. También son un lugar donde se agregan los flujos de tráfico y se

aplican las políticas de tráfico.

48

Cuando está diseñando una red EIGRP, la pregunta principal es cuántas capas debe tener.

Aunque EIGRP no está limitado con varias capas, los diseños EIGRP típicos implementan

dos o tres capas. La dispersión geográfica de la red tiene un gran efecto sobre el número

de capas. Debe esforzarse por utilizar dos capas para redes pequeñas y contenidas. Utilice

tres capas para redes con mayor alcance.

Las profundidades de topología, es decir, el número máximo de saltos de un borde a otro,

también dictan el número de capas. Normalmente, dividir los grandes dominios enrutados

en otros más pequeños ayuda a proporcionar un diseño de enrutamiento más controlado

y estable.

Al tener un esquema IP estructurado y colocar el punto estrangulador en una capa más

alta, usted es capaz de resumir todas las direcciones subyacentes, creando un punto de

estrangulación eficiente que agrega información de accesibilidad.

¿Es mejor utilizar una jerarquía EIGRP de dos o tres capas? Técnicamente, es más fácil

hacer la ingeniería de tráfico eficiente con un diseño de dos capas. Sin embargo, las

políticas de restricción de recursos prefieren diseños de tres capas. Al final, usted tiene

que decidir sobre un diseño que equilibre la simplicidad, el enrutamiento óptimo y la

separación funcional.

49

Arquitectura de jerarquía EIGRP de dos capas

La arquitectura jerárquica de dos capas se basa principalmente en dos capas primarias o

límites lógicos EIGRP: núcleo y distribución.

En esta arquitectura, la función primaria de la capa núcleo es pasar el tráfico de un área

topológica de la red a otra y realizar conmutación de paquetes de alta velocidad, por lo

que se debe evitar la aplicación de políticas complejas en el núcleo. Además, debe evitar la

accesibilidad y la agregación de topología dentro del propio núcleo. Sin embargo, los

enrutadores principales deben resumir la información de enrutamiento hacia la capa de

agregación para definir un límite lógico del núcleo a la capa de distribución: cuantas

menos rutas se anuncian hacia el borde, mejor. Además, puede implementar políticas de

enrutamiento para controlar cuántas y qué rutas deben aceptarse de las áreas de

50

agregación para proteger el núcleo de ser inundado por rutas innecesarias o

malintencionadas que pueden afectar a toda la red.

La capa de agregación proporciona típicamente puntos de unión de capa de acceso. La

información sobre el borde debe estar oculta del núcleo usando técnicas de resumen y

ocultación de topologías y para definir el límite lógico de la capa de agregación.

Idealmente, las políticas de aceptación y seguridad de tráfico deben definirse en el borde

de la red utilizando las técnicas de filtrado de Capa 2 y Capa 3 para hacer cumplir las

políticas lo más cerca posible de la fuente.

Arquitectura de jerarquía EIGRP de tres capas

La arquitectura de jerarquía de tres capas se basa en el uso de las tres capas clásicas:

acceso, agregación y núcleo. Como en la jerarquía de dos capas, la capa núcleo obtiene el

tráfico de un área topológica de la red a otra. Realiza conmutación de paquetes de alta

velocidad, por lo que debe evitar la aplicación de políticas complejas en el núcleo. Además,

dentro de la capa de núcleo en sí, la accesibilidad y la agregación de topología deben

evitarse.

El resumen de direcciones se produce en puntos de estrangulamiento entre las capas de

agregación y núcleo y entre las capas de distribución y acceso.

Para evitar el tráfico inesperado black-holing o enrutamiento subóptimo en algunos

escenarios de fallo, no resuma dentro de la capa de distribución en sí (entre los routers de

la capa de distribución). Desde un punto de vista de optimización del diseño de

enrutamiento y control, un diseñador de red puede considerar lo siguiente:

51

Implementar políticas de enrutamiento para controlar cuántas rutas y qué rutas se

aceptan desde las áreas de acceso y cuáles de las rutas se pasarán al núcleo.

Agregue tanto tráfico como sea posible en la capa de agregación.

Realice la ingeniería de tráfico dirigiendo el tráfico a los mejores puntos de entrada

centrales, ya sea enviando rutas más específicas (no normalizadas) o utilizando el

filtrado de tráfico.

Normalmente, la capa de acceso proporciona puertos de acceso para usuarios o puntos

finales y esta capa debe usarse para colocar políticas de aceptación y seguridad de tráfico

y para filtrar el tráfico no deseado de Capa 2 y Capa 3. Lo ideal sería que los enrutadores

de la capa de acceso se configuren como stubs EIGRP.

La definición del resumen o del filtrado de rutas en las diferentes capas de la red

minimizará el alcance de la consulta EIGRP, lo que a la larga ofrecerá más estabilidad a la

red EIGRP enrutada después de cualquier evento de fallo de red. En este tipo de

arquitectura, se recomienda que el resumen de ruta se realice hacia arriba y hacia abajo de

las capas, y se debe evitar la agregación de rutas entre los nodos interconectados dentro

de la misma capa.

Una jerarquía más profunda no cambia los conceptos fundamentales de diseño de tres

capas. Utilice la capa de distribución como un punto de bloqueo de las consultas y

proporcione información mínima hacia el núcleo y hacia la capa de acceso.

Además, para ambas arquitecturas discutidas en esta sección (dos niveles y tres niveles),

si el diseñador de red decide agregar una interfaz separada por segmento LAN en la capa

de acceso (ya sea utilizando interfaces físicas o subinterfaces), técnicamente, EIGRP

examinará estos (en cada enlace de la ruta de consulta). Esto conducirá a un tiempo de

convergencia reducido, así como a una mayor complejidad del plano de control. Una

solución sencilla y probada para evitar este problema es considerar el uso del comando

52

"passive-interface" para las interfaces LAN y así evitar la formación de cualquier relación

de vecino sobre estos enlaces, así como para dejar de enviar y recibir actualizaciones de

enrutamiento en ambas direcciones.

DISEÑO EIGRP HUB-AND-SPOKE

Hub and spoke es una de las topologías más comunes utilizadas para interconectar

múltiples sucursales a un único sitio (o dual) o centro de datos a través de un transporte

de red de área extensa (WAN). Por lo general, los spoke (sucursales) se comunican con

otros spoke a través del hub (sede); Comúnmente, esto se debe a que los requisitos de

seguridad se orientan a una aplicación centralizada de las políticas. El hub es, por lo tanto,

un punto de estrangulación ideal donde agregar la accesibilidad y la información de la

topología.

Debido a que el hub es el único punto a través del cual los spoke pueden alcanzar las otras

redes, se anuncia sólo la ruta predeterminada desde el hub a los spoke.

Se recomienda resumir las redes spoke en el concentrador hacia el núcleo; De esta

manera, se minimiza el número de rutas y se crea una capa lógica para limitar la

propagación de consultas EIGRP desde los sitios remotos hasta el núcleo para lograr un

diseño de enrutamiento más estable. Además, al construir topología con enlaces punto a

punto, considere la posibilidad de utilizar subredes /31 para que los vínculos conserven el

espacio de direcciones. Coloque direcciones a los enlaces con un rango fuera del espacio

53

de la dirección que está disponible en el spoke para permitir el resumen simple. Si esta

acción no es posible, considere el uso de listas de distribución para filtrar las subredes de

enlace de ser anunciadas en el núcleo de la red.

Diseñar EIGRP sobre una topología hub-and-spoke tiene algunas preocupaciones y

limitaciones de diseño que se deben tener en cuenta para producir un diseño EIGRP fiable

y escalable.

Retos de resumen

Aunque el resumen de rutas de EIGRP ofrece un diseño de enrutamiento más escalable y

estable, en algunos escenarios introducirá alguna limitación al diseño que se deben tener

en cuenta para evitar producir un diseño no fiable que no cumpla con los requisitos de la

aplicación y del negocio. Los típicos desafíos presentados en el resumen de rutas son:

Enrutamiento de agujeros negros

Enrutamiento subóptimo

Las siguientes secciones analizan cada uno de estos desafíos junto con las posibles

técnicas de mitigación.

Agujeros negros de resumen de rutas:

En una red hub-and-spoke redundante típica, cada uno de los spoke tiene vínculos a dos

routers hub, con un resumen de ruta hacia el núcleo de red. Este diseño normalmente

tiene un alto potencial para los agujeros negros de rutas.

54

Para superar esta limitación de diseño y evitar el potencial de agujero negro de la ruta, es

necesario interconectar los dos enrutadores hubs. Si lo hace, ayudará a dirigir el tráfico a

través del enlace interurbano para alcanzar el hub que tiene una conexión de trabajo con

el spoke.

Sin embargo, debe tener cuidado de no habilitar el resumen sobre la interconexión entre

los enrutadores hub. La razón es que, técnicamente, la ruta de descarte de la ruta de

resumen EIGRP se instala con una distancia administrativa (AD) de 5. Si uno de los

enrutadores hub recibe un anuncio de red resumido de la misma longitud de prefijo desde

el otro enrutador concentrador, ruta de descarte siempre tendrá prioridad antes de la ruta

recibida, debido a su menor AD, y eliminará el beneficio del enlace interhub añadido.

Resumen de rutas y enrutamiento subóptimo

Idealmente, para lograr un diseño de enrutamiento estable y escalable, cuando el diseño

de la red requiere algo más que una ruta predeterminada que se anuncia desde el hub a

los spoke, debe resumir las rutas que anuncia desde el hub hacia los spoke lo máximo

posible. Sin embargo, en los escenarios de hub dual y otros escenarios hub-and-spoke

complejos, esta situación puede conducir a un enrutamiento subóptimo en el que el tráfico

tomará una ruta más larga (indirecta).

Con EIGRP, se optimiza este diseño mediante la fuga de rutas más específicas a través de

un resumen, lo que le permite resumir todas las redes centrales en los routers hub,

mientras que ocurre la fuga de rutas más específicas a través del resumen.

55

Optimización de la escalabilidad de EIGRP Hub-and-Spoke

Técnicamente, la escalabilidad del EIGRP en topologías de hub-and-spoke depende de

varios factores, incluyendo los siguientes:

Cuando los spoke están conectados al hub a través de múltiples interfaces, el

procesador es el factor limitante principal.

Con la topología punto a multipunto sobre una sola interfaz, el factor limitante

primario es la congestión de la cola. EIGRP tiene una limitación teórica de 4000

pares por interfaz, cuando están en el mismo prefijo.

EIGRP se utiliza en entornos de producción, donde más de 800 vecinos EIGRP se ven

desde un punto. Las topologías con más de 1400 vecinos EIGRP se han ejecutado con éxito

en el laboratorio. Sin embargo, estos números sólo se pueden lograr con un diseño

cuidadoso.

Para lograr un diseño EIGRP escalable que sea capaz de soportar un gran número de

spokes sin sacrificar la estabilidad de la red y su capacidad para converger rápidamente,

debe considerar un stub EIGRP en los sitios de spoke.

Los stubs son imprescindibles en una topología EIGRP hub-and-spoke si desea lograr un

diseño resistente, escalable y confiable. Con la función de enrutamiento de stubs EIGRP, los

enrutadores (normalmente los spoke) configurados como stub enviarán un paquete

especial de información de iguales a todos los dispositivos vecinos para reportar su estado

como un enrutador stub. A su vez, cualquier vecino EIGRP que reciba un paquete que lo

informa del estado de stub no consultará al dispositivo stub para ninguna ruta, y un

56

enrutador que tenga un par stub no consultará a ese par. Por lo tanto, el dispositivo de

derivación dependerá del enrutador concentrador para enviar actualizaciones apropiadas

a todos los otros spoke. Además, cuando se configura un stub EIGRP en los enrutadores

spoke, no serán utilizados como enrutadores de tránsito por los otros enrutadores spoke o

el concentrador.

Además, la consideración clave de escalabilidad en este diseño es la agregación de rutas. El

ancho de banda y la memoria se pueden conservar resumiendo los anuncios a los spoke.

Anuncie, la ruta predeterminada o un grupo cuidadosamente seleccionado de redes

resumidas. Sin embargo, si el enrutamiento de EIGRP en los spoke no está habilitado,

incluso luego de que las rutas que se envían desde el enrutador de concentrador a los

radios han sido filtradas o resumidas, todavía hay un potencial de inestabilidad de la red o

para un tiempo de convergencia más lento después de un evento de fallo de red.

La característica de enrutamiento de stubs EIGRP permite a un operador de red evitar que

las consultas se envíen al dispositivo remoto (limitación del alcance de la consulta). Como

resultado, la red será más estable, capaz de convergir más rápido y escalar a un gran

número de spoke. De hecho, si los spoke no están configurados como stubs, no será capaz

de construir una red fiable de más de 100 vecinos EIGRP que convergan rápidamente. La

línea azul con pendiente pronunciada muestra la velocidad a la que el tiempo de

convergencia de conmutación por error aumenta a medida que los vecinos EIGRP se

añaden a un solo enrutador concentrador.

57

Fugas de stub EIGRP

Examinemos un escenario en el que dos sitios remotos (spoke) están interconectados

directamente entre sí (enlace de puerta trasera) y cada sitio tiene una ubicación única en

el mismo sitio de concentrador, pero está conectado a un enrutador concentrador

diferente. Con este diseño, ambos enrutadores spoke se configuran como enrutadores de

código abierto, y anuncian las redes conectadas y de resumen, pero no anuncian las rutas

que aprenden de sus vecinos según el comportamiento típico del anuncio de la ruta stub.

58

EIGRP DMVPN Escalado

Aunque EIGRP ofrece un diseño de red escalable a través de la VPN dinámica multipunto

(DMVPN), la escalabilidad real sobre redes DMVPN depende de varios factores: topología,

número de pares, número de prefijos anunciados y fase DMVPN.

El comportamiento EIGRP varía dependiendo de la fase DMVPN utilizada. Las fases más

nuevas producen tiempos de convergencia más bajos cuando se utiliza la misma topología

EIGRP. DMVPN Fase 3 no sólo ofrece el enrutamiento óptimo sino también los tiempos de

convergencia EIGRP más rápidos.

Los despliegues de producción muestran que un máximo práctico de los pares de EIGRP

en una red de la fase 2 de DMVPN es alrededor de 600. Este número no diferencia para

despliegues de un solo eje y de doble eje. Después de ese número, los tiempos de

convergencia comienzan a aumentar significativamente. La ampliación de la red DMVPN

más allá de ese número requiere típicamente múltiples hubs, cada uno de los cuales tiene

hasta 600 spokes.

El aumento en el número de prefijos anunciados aumenta linealmente los tiempos de

convergencia. Los tiempos de convergencia pueden ser fácilmente cubiertos mediante el

uso de resumen, especialmente en las redes de DMVPN Fase 3.

59

CONSIDERACIONES DE DISEÑO DE CONVERGENCIA RÁPIDA

EIGRP

Aunque EIGRP fue diseñado para lograr la convergencia en milisegundos, el factor clave

para esta capacidad de convergencia rápida es la presencia de un sucesor factible. Cuando

no existe un sucesor factible, EIGRP utiliza consultas a pares EIGRP y tiene que esperar

respuestas, y estas consultas normalmente ralentizarán el tiempo de convergencia en

general.

Para lograr la rápida convergencia, es necesario diseñar correctamente su red, teniendo

en cuenta las diferentes consideraciones de diseño. Por ejemplo, el resumen de rutas

ayuda a limitar el alcance de las consultas EIGRP, lo que acelerará indirectamente el

tiempo de convergencia. La agregación de rutas también reduce el número de entradas en

la tabla de enrutamiento, lo que acelera varias operaciones de la CPU. El efecto de la

operación de la CPU sobre la convergencia es mucho menos significativo que la presencia

o ausencia de un sucesor factible.

Tener rutas múltiples en la tabla de enrutamiento (costo igual o de costo desigual) ofrece

tiempos de convergencia más rápidos porque una ruta existente ya está disponible en la

tabla de enrutamiento si una de ellas falla.

Además, desde el punto de vista del diseño, es difícil establecer un límite exacto en el

número de vecinos EIGRP que un enrutador puede soportar, ya que este enfoque depende

del uso adecuado del resumen, el filtrado de rutas y el enrutamiento stub. Una red

correctamente diseñada con 500 pares puede converger rápidamente, mientras que una

red EIGRP mal diseñada con 20 pares puede experimentar severa inestabilidad de

enrutamiento.

Además, uno de los elementos clave para lograr una red de convergencia rápida es su

capacidad para detectar el fallo y reportarlo al protocolo de enrutamiento de una manera

rápida y manejable.

Detección de reenvío bidireccional (BFD)

BFD puede proporcionar tiempos de detección de fallos rápidos para todos los tipos de

medios, encapsulaciones, topologías y protocolos de enrutamiento. En el mejor de los

casos, puede proporcionar detección rápida de fallos en ~ 50 milisegundos. BFD verifica la

conectividad entre dos sistemas. Los paquetes de control de BFD siempre se envían como

paquetes unicast al par BFD. La implementación BFD de Cisco encapsula paquetes de

control BFD en paquetes UDP (User Datagram Protocol), usando el puerto de destino

3784. EIGRP informa al proceso BFD de la dirección IP del vecino que necesita supervisar.

BFD no descubre sus pares dinámicamente. Se basa en los protocolos de enrutamiento

60

configurados para indicarle qué direcciones IP utilizar y qué relaciones de pares se

formarán.

BFD forma un paquete de control BFD en cada enrutador. Estos paquetes se envían con un

mínimo de intervalos de un segundo hasta que se establece una sesión BFD. Después de

que el enrutador remoto reciba un paquete de control BFD durante la fase de iniciación de

sesión, copia el valor del campo My Discriminator en su propio campo Your Discriminator

y establece el bit H (I Hear You) para cualquier paquete de control BFD posterior que

transmita. Cuando ambos sistemas ven sus propios Discriminadores en los paquetes de

control de cada uno, se establece la sesión. Ambos sistemas continúan enviando en (al

menos) intervalos de un segundo hasta que vean a los Discriminadores apropiados en los

paquetes de control de BFD de cada uno.

Cuando se establece la sesión BFD, los temporizadores BFD se negocian. Estos

temporizadores se pueden renegociar en cualquier momento durante la sesión sin causar

un restablecimiento de sesión. Los temporizadores BFD se pueden negociar

asincrónicamente. Un par puede enviar paquetes de control BFD a intervalos de 50 ms en

una dirección mientras que el otro par está enviando sus paquetes de control BFD cada

150 ms en la otra dirección.

Siempre y cuando cada par BFD reciba un paquete de control BFD dentro del período de

detección de temporizador, la sesión BFD permanece en marcha, y cualquier protocolo de

enrutamiento que está asociado con BFD mantiene sus adyacencias. Si un par BFD no

recibe un paquete de control dentro del intervalo de detección, informará a cualquier

protocolo de enrutamiento de esa sesión BFD acerca del fallo. Depende del protocolo de

enrutamiento se determinará la respuesta apropiada a esa información.

En un modo BFD llamado eco BFD, el dispositivo local envía paquetes de eco desde el

motor de reenvío al vecino BFD remoto. El vecino BFD reenvía el paquete de eco a lo largo

del mismo camino para realizar la detección; El vecino BFD no participa en el reenvío real

de los paquetes de eco.

CONSIDERACIONES EIGRP SOBRE EL REINICIO GENTIL / NSF

Cuando se reinicia un dispositivo de red, todos los usuarios de enrutamiento asociados

con ese dispositivo detectan que el dispositivo ha fallado y que se eliminan las rutas de ese

interlocutor. La sesión se restablece cuando el dispositivo completa el reinicio. Esta

transición resulta en la eliminación y reinserción de rutas, que podrían extenderse a

través de múltiples dominios de enrutamiento.

Los sistemas de procesador dual que soportan la conmutación con estado (SSO: stateful

switchover) o la actualización de software en servicio (ISSU: in-service software upgrade)

pueden continuar enviando tráfico mientras se reinicia el plano de control en el segundo

procesador. En este caso, la eliminación de la ruta y la inserción causada por el

61

enrutamiento de los reinicios del protocolo ya no son necesarias porque crean

inestabilidades de enrutamiento innecesarias, que son perjudiciales para el rendimiento

general de la red. El reinicio agraciado (GR: graceful restart), también conocido como

reenvío sin interrupción (NSF: non stop forwarding), suprime los cambios de

enrutamiento en pares a los dispositivos SSO activados durante los eventos de

conmutación del procesador (SSO o ISSU), reduciendo la inestabilidad de la red y el

tiempo de inactividad.

A diferencia del enfoque de convergencia de enrutamiento típico que apunta a enrutar el

tráfico alrededor del fallo, el GR permite el reenvío de paquetes de datos para continuar a

lo largo de rutas conocidas (a través del mismo enrutador con el fallo del procesador de

ruta) mientras se está restaurando la información de protocolo de enrutamiento, tras la

conmutación del procesador.

Cuando GR se utiliza, los dispositivos de red pares se informan a través de extensiones de

protocolo antes del evento de la capacidad SSO de los enrutadores para realizar un

reinicio agraciado. El dispositivo par debe tener la capacidad de entender esta mensajería.

Cuando se produce una conmutación, el interlocutor continuará reenviando la

conmutación sobre el enrutador según lo indicado por el proceso GR para cada protocolo

en particular, aunque en la mayoría de los casos la relación de pares necesita ser

reconstruida. Esencialmente, el enrutador par le dará a la conmutación un período de

"gracia" para restablecer la relación de vecino, mientras continúa reenviando a las rutas

de ese par.

62

Capítulo 3

Diseño OSPF

63

CONSIDERACIONES DE DISEÑO DE ESCALABILIDAD OSPF

La utilización de los recursos de hardware de un enrutador -su memoria y CPU- y su ancho

de banda de interfaz son los principales factores que influyen en la escalabilidad de OSPF.

La carga de trabajo que OSPF impone a un enrutador depende de varios factores:

Número de prefijos: El número de prefijos que lleva OSPF es sin duda el factor

más importante en la determinación de la estabilidad OSPF y su escalabilidad.

Estabilidad de conexiones: OSPF ve conexiones inestables como enlaces de

aleteo. Estos enlaces de aleteo introducen recálculo en el proceso de enrutamiento

y, por tanto, las inestabilidades.

Número de vecinos adyacentes para cualquier enrutador: OSPF inunda con

todos los cambios de estado del enlace a todos los enrutadores de un área. Los

enrutadores con muchos vecinos tienen más trabajo que hacer cuando se producen

cambios de estado de enlace.

Número de enrutadores adyacentes en un área: OSPF utiliza un algoritmo

intensivo de CPU. El número de cálculos que deben realizarse dados n paquetes de

estado de enlace es proporcional a n log n. Como resultado, cuanto mayor y más

inestable es el área, mayor es la probabilidad de problemas de rendimiento

asociados con el recálculo del protocolo de enrutamiento.

Número de áreas que cualquier enrutador puede soportar: Un enrutador debe

ejecutar el algoritmo de estado de enlace para cada cambio de estado de enlace que

se produce para cada área en la que reside el enrutador. Cada enrutador de borde

de área (ABR) normalmente pertenece al menos a dos áreas, la backbone y una

zona adyacente.

Desde una perspectiva de diseño, la primera y más importante decisión al desarrollar un

diseño de red OSPF, o evaluar uno existente, es determinar qué enrutadores y enlaces

deben incluirse en el área de backbone y qué enrutadores y enlaces deben incluirse en

cada área adyacente (No backbone).

Vecinos adyacentes

En OSPF, la adyacencia es el siguiente paso después del proceso de descubrir vecinos. Los

enrutadores adyacentes son enrutadores que van más allá del simple intercambio de

saludo y continúan en el proceso de intercambio de bases de datos. En cada segmento

multiacceso, para minimizar la cantidad de intercambio de información en un segmento

en particular, OSPF elige a un enrutador para ser un enrutador designado (DR) y un

64

enrutador para ser un enrutador designado de respaldo (BDR). El BDR se elige como un

mecanismo de respaldo en caso de que el DR se caiga. La idea detrás de esto es que los

enrutadores tienen un punto central de contacto para el intercambio de información. En

lugar de que cada enrutador intercambie actualizaciones con cada otro enrutador del

segmento, cada enrutador intercambia información con DR y BDR. El DR y el BDR

transmiten la información a todos los demás (el BDR comienza a retransmitir información

cuando el DR está desactivado).

Desde el punto de vista del diseño, la escalabilidad OSPF está influenciada por el número

de vecinos adyacentes. Los enrutadores vecinos están conectados al mismo segmento, o

cada enrutador utiliza su propio segmento de conexión. Normalmente, cada segmento

tiene un DR y BDR que construyen adyacencias con todos los demás enrutadores.

Cada adyacencia OSPF representa a otro enrutador, cuyos recursos se gastan para

soportar estas actividades:

Intercambiando saludos.

Sincronización de bases de datos de estado - enlace (LSDB).

Inundación confiable de los cambios de los anuncios de estado de enlaces OSPF

(LSA).

Anuncio del LSA de enrutador y de red.

Por lo tanto, considerar el diseño jerárquico y la distribución de carga (difusión de las

conexiones de sucursales a varios enrutadores hub) puede ayudar a reducir el número de

adyacencias OSPF. La volatilidad, la cantidad de cambios y la otra carga de trabajo deben

considerarse al determinar cuántos pares un enrutador concentrador central puede

soportar en una topología de hub-and-spoke. Cuando esté probando un futuro entorno de

producción, tenga en cuenta las peores situaciones: reinicios simultáneos en todos los

pares o conexiones de aleteo.

65

Información de enrutamiento en el área y el dominio enrutado

La cantidad de información de enrutamiento que existe dentro de un área OSPF o un único

dominio de enrutamiento tiene un impacto directo en la carga de trabajo del enrutador.

Este problema se puede observar cuando un enrutador necesita converger después de un

fallo de nodo o vínculo y un gran número de rutas deben procesarse.

Por lo tanto, el número de enrutadores y enlaces a enrutadores adyacentes en un área

determinan cuánta información hay en la base de datos LSA o cuánta información de

enrutamiento hay en el área. El tipo de área y la cantidad de resumen también son factores

que influyen en la cantidad de información de enrutamiento. El número de áreas y tipos de

áreas que son compatibles con cada enrutador también influyen en la cantidad de

información de enrutamiento en un dominio.

Diversas técnicas y herramientas están disponibles para reducir esta información. Las

áreas de stub y totally stubby importan menos información sobre destinos fuera del

dominio de enrutamiento o del área que las áreas normales. Por lo tanto, el uso de stub y

áreas totally stubby reduce aún más la carga de trabajo en un enrutador OSPF.

Técnicamente, las áreas stubby de OSPF suprimen la información de enrutamiento

externo, mientras que las áreas totally stubby suprimen la información de enrutamiento

externo e interarea. Por otro lado, las áreas not-so-stubby (NSSA) y totally NSSA utilizan el

mismo concepto de "stub y totally stubby" excepto que ambos permiten que la

información de enrutamiento externo sea inyectada en el área como LSA Tipo-7. Para

mantener la accesibilidad total de estas áreas, la información suprimida se reemplaza por

la ruta por defecto IPv4 (0.0.0.0/0) o la ruta por defecto IPv6 (:: / 0), dependiendo de la

versión de IP utilizada.

66

Las rutas y los costos interarea son anunciados en un área por cada ABR. Como se

mencionó anteriormente, las áreas totally stubby mantienen no sólo las rutas externas,

sino también la información interarea de haber sido inundado en y dentro de un área.

Además, se recomienda excluir los prefijos IP de redes conectadas (IPs de enlaces de

transporte de tránsito) de LSA en redes OSPF grandes. Esto es importante porque estos

IPs limitan el número de prefijos IP que se transportan en los OSPF LSA para acelerar la

convergencia OSPF.

En el software IOS de Cisco, el argumento prefix-supression ayuda a simplificar el

filtrado de estos prefijos IP, evitando que OSPF anuncie todos los prefijos IP de las

interfaces conectadas, excepto los prefijos asociados con loopbacks, direcciones IP

secundarias e interfaces pasivas. Los diseños de redes requieren que éstos permanezcan

accesibles.

Otra técnica para reducir el número de prefijos que se intercambian entre las áreas es el

filtrado interárea utilizando listas de prefijos. Puede utilizar este método en lugar de áreas

totally stubby si se necesita información de enrutamiento específica para algunos prefijos,

pero no para otros. Este enfoque, sin embargo, puede aumentar la complejidad de

mantener un gran número de listas de prefijos en las grandes redes.

Por otro lado, los enrutadores ABR y ASBR en OSPF proporcionan una lista de destinos y

costos externos de tipo vector-distancia. Cuanto más prefijos externos y más ASBRs hay,

mayor es la carga de trabajo para el LSA tipo 5 o 7. Las áreas stub evitan que toda esta

información sea inundada dentro de un área. Del mismo modo, cuanto más ABRs existen

entre dos áreas, más LSAs OSPF de resumen se generan a cada área.

67

La conclusión es que el tamaño de la superficie y el diseño de la disposición, los tipos de

área, los tipos de rutas, el número de ABRs / ASBRs, la redistribución y el resumen afectan

el tamaño de la base de datos LSA en cualquier área. Por lo tanto, utilice este consejo

general para lograr un diseño OSPF simple de manejar y fácil de escalar:

Manténgalo sencillo (por ejemplo, evite múltiples puntos de redistribución, un gran

número de listas de prefijos y políticas de enrutamiento).

Manténgalo corto (o manténgalo totally stubby, especialmente para sitios

remotos).

Limite el número de routers ABR / ASBR al mínimo por área.

Manténgalo resumido (utilizando una estructura, el esquema de direccionamiento

IP es clave para lograr un diseño de resumen de ruta óptimo).

Número de enrutadores en un área

La cantidad de información en el LSA aumenta su tamaño. Por lo tanto, en general, es una

buena práctica de diseño mantener los LSA del enrutador OSPF bajo el tamaño máximo de

unidad de transmisión IP (MTU). Cuando se supera la MTU, el resultado es la

fragmentación de IP, un problema que es, en las mejores circunstancias, una forma menos

eficiente de transmitir información que también requiere un procesamiento adicional del

enrutador. Un gran número de LSAs de router también implica que hay muchas interfaces

68

(y tal vez vecinos); Es una indicación indirecta de que el área puede haber llegado a ser

demasiado grande.

El enfoque para conseguir sólo un diseño escalable no es suficiente, ya que la estabilidad y

la redundancia son los criterios más importantes para el backbone y otras áreas de la red.

Normalmente, mantener el tamaño del backbone razonable conduce a una mayor

estabilidad.

Si la calidad del enlace es alta y el número de rutas es pequeño, se puede aumentar el

número de enrutadores.

Prácticamente, debido a varios factores de complejidad, es difícil especificar un número

máximo de enrutadores por área. Un área 0 bien diseñada, con el hardware más reciente

de Cisco, no debe tener más de unos 300 enrutadores.

Número de Áreas por ABR

Cada ABR mantiene una copia de un LSDB para cada área que éste sirve. En otras palabras,

si un enrutador está conectado a diez áreas, por ejemplo, tiene que mantener una lista de

diez LSDBs diferentes. Dicho esto, diferentes factores pueden influir en el número de áreas

por ABR, tales como el tipo de área (normal, stub, NSSA), recursos de energía del

hardware ABR (CPU, memoria), número de rutas por área, y el número de rutas externas

por área.

Por lo tanto, se recomienda comúnmente tratar de evitar la sobrecarga de un ABR y en su

lugar difundir las áreas sobre varios enrutadores (anteriormente, se recomendó tener

69

hasta tres áreas por ABR). Sin embargo, los diseños prácticos requieren sólo unos cuantos

enrutadores para servir como ABRs de múltiples áreas, y estos enrutadores pueden

actualizarse al hardware más reciente para soportar 50 y más áreas por ABR. Por lo tanto,

con los enrutadores de próxima generación de hoy, con gran capacidad de memoria y altas

capacidades de procesamiento de la CPU, colocar un ABR en decenas de áreas

simultáneamente ya no es un problema, especialmente si las topologías de área son

simples. En algunos casos, se puede tolerar un menor rendimiento. Por esta razón, no se

puede recomendar un número específico de áreas por ABR. Vigile cuidadosamente sus

ABRs y agregue ABRs adicionales para distribuir la carga si es necesario.

CONSIDERACIONES SOBRE EL DISEÑO DEL ÁREA OSPF

Idealmente, la topología de la red y el direccionamiento deben diseñarse teniendo en

cuenta la división por áreas. Aunque el protocolo EIGRP tolera topologías de red más

arbitrarias, OSPF requiere una jerarquía más limpia con una topología de backbone y de

área más clara.

Además, en las grandes redes, los límites geográficos y funcionales deben ser

considerados al determinar la ubicación del área OSPF, ya que esto influirá en el límite de

inundación de la información.

Un diseño escalable y estable de OSPF tiene como objetivo minimizar la cantidad de

información de enrutamiento que se anuncia dentro y fuera de las áreas, teniendo en

cuenta que cualquier cosa en el LSDB debe propagarse a todos los enrutadores dentro de

una sola área. En particular, los cambios deben propagarse, consumiendo ancho de banda

y CPU para enlaces y enrutadores dentro del área. Cambios rápidos o de aleteo requiere el

mayor esfuerzo porque los enrutadores tienen que propagar repetidamente los cambios.

Por lo tanto, considerar áreas stub, áreas totally stubby y rutas de resumen ayuda a reducir

70

el tamaño del LSDB e imponer una red OSPF más estable aislando el área de propagación

de cambios externos.

La redundancia es importante en el backbone para evitar un área de backbone

particionada cuando falla un enlace. Los backbones buenos se diseñan de modo que

ningún fallo único del acoplamiento pueda causar una partición, que puede conducir a la

comunicación quebrada entre las áreas o a un enrutamiento subóptimo.

Desde un punto de vista de enrutamiento óptimo, los diseñadores de redes deben tener en

cuenta lo siguiente al diseñar áreas OSPF:

Las áreas totally stubby sólo reciben una ruta predeterminada del ABR; Por lo

tanto, el área no puede distinguir un ABR de otro, en términos de la mejor ruta a

destinos fuera de la zona, ya que no tendrá visibilidad a las rutas más específicas.

Esto conduce a enrutamiento subóptimo en algunos escenarios. A menos que los

ABR estén geográficamente muy separados, en general no debería importar.

De manera similar, debido a que las áreas stub no tienen visibilidad a rutas

externas, esto puede conducir a un enrutamiento subóptimo para llegar a redes

externas, ya que el área stub no puede distinguir entre ABRs para destinos externos

al dominio OSPF (rutas redistribuidas). A menos que los ABR estén

geográficamente muy separados, en general no debería importar.

Jerarquía OSPF

La arquitectura más típicamente utilizada en las grandes redes empresariales es la

arquitectura jerárquica de tres capas que consiste en las capas de núcleo, distribución y

acceso. La naturaleza del protocolo OSPF, sin embargo, permite sólo dos niveles de

jerarquía: el backbone, o área 0, y todas las demás áreas que están conectadas al backbone

a través de ABR. Dicho esto, todavía puede usar OSPF en las redes jerárquicas con tres

capas con algunos desafíos alrededor de los límites óptimos de enrutamiento y resumen.

Por lo tanto, casi siempre, OSPF se adapta naturalmente mejor cuando hay un área

backbone 0 y las áreas fuera del backbone con un enrutador, o varios, interconectando las

otras áreas al área 0. Si usted debe tener tres niveles de jerarquía para una red grande,

siempre que sea posible, debería considerar el uso del protocolo BGP como un protocolo

de enrutamiento básico para interconectar diferentes dominios de enrutamiento OSPF

para lograr un diseño más flexible y escalable para redes empresariales de gran escala.

Una pregunta difícil en el diseño de OSPF es donde poner los ABRs. ¿Deben colocarse en el

núcleo o en la capa de distribución? El consejo general del diseño es separar la

complejidad de la complejidad, y poner partes complejas de la red en áreas separadas. Una

parte de la red puede considerarse compleja cuando cuenta con una considerable

71

información de enrutamiento, como una malla completa, un hub-and-spoke grande o una

topología altamente redundante, como un campus redundante o un centro de datos.

Para mantener un OSPF fiable y escalable, debe considerar el resumen de ruta de red

cuando sea posible. Típicamente, los ABRs proporcionan oportunidades para soportar el

resumen de rutas o crear áreas stub o totally stubby. Sin embargo, para lograr un resumen

óptimo de rutas efectivas, se requiere un esquema estructurado de direccionamiento IP

para alinearse con el diseño del área. Una de las formas más sencillas de asignar

direcciones en OSPF es asignar un número de red independiente para cada área.

Resumen de áreas y dominios

En OSPF, el resumen se apoya dentro y fuera de las áreas en el ABR o ASBR, y hay

diferentes maneras de resumir las rutas en OSPF. Sin embargo, el requisito fundamental

para lograr un resumen eficaz de la ruta es tener un esquema de direccionamiento IP

estructurado.

72

Para minimizar la información de la ruta que se inserta en el área, considere las siguientes

líneas de guía al planificar su intercomunicación OSPF:

Configure el esquema de direccionamiento de red para que el rango de subredes

asignados dentro de un área sea contiguo.

Cree un espacio de direcciones que divida fácilmente las áreas a medida que crece

la red. Si es posible, asigne subredes de acuerdo con los límites de octetos simples.

Planee con anticipación la adición de nuevos enrutadores al entorno OSPF.

Asegúrese de que los nuevos enrutadores se insertan correctamente como

enrutadores de área, backbone o frontera.

Los siguientes son algunos de los métodos para resumir las rutas y de otra manera reducir

el tamaño de LSDB y las inundaciones en OSPF:

Rangos de área según los RFC de OSPF.

Filtrado de área.

Filtrado de direcciones de resumen.

Origen predeterminado.

Filtrado de rutas NSSA.

73

DISEÑO DE MALLA COMPLETA OSPF

Las topologías de malla total y parcial se implementan típicamente en redes que

demandan alto rendimiento y enrutamiento óptimo, como las redes centrales. Sin

embargo, las redes de malla completa son costosas y complejas debido a que

experimentan un crecimiento cuadrático de enlaces de interconexión a medida que añade

enrutadores y, por lo tanto, plantea un desafío de escala específico para OSPF. Puede

calcular el número de interconexiones requeridas siguiendo esta fórmula, donde n

enrutadores requieren ((n) (n - 1)) / 2 interconexiones.

Desde el punto de vista de control del plano, la inundación de información de

enrutamiento a través de una topología de malla completa es la principal preocupación.

Técnicamente, cada enrutador recibe al menos una copia de nueva información de cada

vecino. La preocupación con este comportamiento es que, en un dominio de red de malla

completa o incluso dominios de OSPF de malla parcial, una cantidad significativa de

inundación de información de enrutamiento puede afectar el rendimiento general de la

red y el tiempo de convergencia. Por lo tanto, si alguna de estas topologías se utiliza, debe

implementar técnicas para reducir la cantidad de información de enrutamiento.

El sistema intermedio a sistema intermedio (IS-IS) proporciona un mecanismo simple

para contrarrestar la inundación de malla completa, llamada grupos de malla. OSPF utiliza

una técnica similar a los grupos de malla en el concepto, reduciendo la inundación en una

red de malla completa mediante la configuración manual del filtro de base de datos

utilizando la lógica que se enumera aquí:

74

Elija un subconjunto de dos o más enrutadores en una red de malla que inundará

los LSA a todos los demás enrutadores.

Configure todos los otros enrutadores para filtrar su LSA para todos excepto el

subconjunto seleccionado de enrutadores.

Como resultado, los routers de inundación elegidos se comportan de manera similar a la

forma en que se comporta un DR en una LAN compartida. Esto eventualmente ayuda a

reducir la cantidad de inundación de información de enrutamiento con la red de malla o

de malla parcial. Además, es importante considerar al menos dos enrutadores para

realizar la inundación "con un comportamiento similar a DR" para evitar un solo punto de

fallo en este tipo de escenario.

Además, los diseñadores de redes también pueden considerar el mecanismo de reducción

de inundaciones OSPF (RFC 4136) en redes de malla completa para eliminar la

actualización periódica de LSAs sin cambios, lo que conduce a un diseño de malla OSPF

más estable y escalable.

DISEÑO DE OSPF HUB-AND-SPOKE

Aunque OSPF sobre hub-and-spoke es uno de los diseños de WAN más implementados,

tiene varias limitaciones técnicas que usted, como diseñador de red, debe estar consciente

y evitar para ser capaz de proporcionar un diseño confiable y escalable. Por ejemplo,

cuando se utiliza OSPF como plano de control sobre la topología de hub-and-spoke,

cualquier cambio en un sitio spoke se transmite a través del enlace al hub y luego se

replica a cada uno de los otros sitios spoke (si se utiliza una sola área entre el hub y los

spoke). Otro ejemplo común, uno que causa cambios frecuentes en períodos pequeños de

75

tiempo, es un aleteo de un enlace que podría ser debido a un problema físico. Como

resultado, en grandes redes, estos cambios frecuentes pueden colocar una gran carga en el

enrutador concentrador, así como en los spoke, cuando la inundación se propaga a otros

spoke.

Una de las principales técnicas de mitigación de los problemas anteriores es reducir la

cantidad de información de enrutamiento que se va a inundar. Por lo tanto, siempre se

recomienda, en la topología hub-and-spoke, colocar los spoke en un área stub para

minimizar la cantidad de información dentro del área. De hecho, se debe apuntar a

configurar las áreas como stubby, siempre que sea posible. Es por eso que las áreas totally

stubby se consideran aún mejor en este caso. Sin embargo, si un sitio spoke necesita

redistribuir rutas en OSPF, debe convertirlo en un NSSA o NSSA total para minimizar el

número de información de enrutamiento.

Además, limitar el número de spoke por área reduce la inundación en el concentrador. Sin

embargo, tenga en cuenta que las áreas más pequeñas permiten menos resumen en el

backbone. Además, cada spoke puede requerir una subinterfaz separada en el enrutador

concentrador.

Colocación de los ABR en el diseño de OSPF Hub-and-Spoke

Comúnmente, las topologías hub-and-spoke se despliegan en escenarios en los que

múltiples sitios remotos están conectados a una Sede Central o una Sede Regional. Aunque

ambas topologías son hub-and-spoke, la profundidad de la topología y el esquema de

direccionamiento IP pueden influir en la colocación de los límites del área ABR u OSPF.

Desde el punto de vista del diseño OSPF, el área del backbone es extremadamente

importante. Por lo tanto, siempre se recomienda diseñar el área 0 para que sea lo más

pequeño y estable posible. Teniendo esto en cuenta, los diseñadores de redes deben

76

detener cualquier inestabilidad de la WAN (como los cambios de enrutamiento debido al

aleteo de enlace WAN) que afectan a la estabilidad del núcleo de la red. Para lograr esto en

OSPF, normalmente necesita usar un enrutador concentrador como ABR entre el área

central 0 y una o varias áreas spoke. Con este diseño, es posible que necesite emplear un

enrutador concentrador de alto calibre, que puede servir como ABR para múltiples áreas.

Con este enfoque de diseño, el concentrador ABR, junto con el resumen de rutas, puede

proporcionar topología e información de enrutamiento ocultos entre el backbone (área 0)

y el área WAN, lo que en última instancia ofrecerá un diseño más estable y escalable.

Además, puede extender el área 0 hasta los enrutadores spoke, en los que los radios ahora

sirven como ABR entre la WAN hub-and-spoke y sus LANs de sucursal. Con este enfoque

de diseño, reduce la presión sobre el enrutador concentrador. Sin embargo, la advertencia

es que todos los enlaces WAN ahora son parte del área backbone. Como resultado,

cualquier aleteo de enlace WAN produce muchas actualizaciones de enrutamiento, lo que

puede desestabilizar el núcleo. Este diseño es viable para topologías con un núcleo

pequeño con enlaces WAN fiables, o una red pequeña en general, con un pequeño número

de spoke. Además, este modelo de diseño puede utilizarse en algunas topologías de

múltiples hub-and-spoke, en las que el área backbone puede extenderse al nivel del

primer spoke; Cada nivel actúa entonces como un concentrador para los routers de

segundo nivel del spoke.

77

Número de áreas en el diseño de OSPF hub-and-spoke

El diseño de OSPF con múltiples áreas, junto con el resumen en cada frontera del área,

ayuda a optimizar el diseño y hacerlo más estable y escalable. Por lo tanto, en una

topología hub-and-spoke, cuando el número de sitios remotos sube, es necesario

comenzar a romper la red en varias áreas OSPF. Sin embargo, el número de enrutadores

por área depende de un par de factores. Cuanto mayor sea el tamaño de la red hub-andspoke,

más áreas de OSPF serán requeridas para optimizar el diseño de los dominios de

inundación.

78

Además, mantener cada spoke en un área separada contendrá cambios de enrutamiento

de sucursal y aleteo de enlace WAN, no sólo del núcleo, sino también de las otras

sucursales. Sin embargo, este enfoque aumenta el número de áreas en el hub ABR, lo que

significa aumentos en el número de LSDBs que el ABR necesita mantener. Esta solución

podría no ser un gran problema si el enrutador concentrador está utilizando un enrutador

de próxima generación con capacidades de recursos de hardware (memoria, CPU).

Tipos de red en el diseño de OSPF hub-and-spoke

Tipo de red Ventajas Desventajas

Subred IP simple.

Menos rutas de host en

la tabla de

enrutamiento.

BDR.

Interfaz única en el

concentrador tratada

como una red OSPF o

una red multiacceso de

no difusión (NBMA)

Interfaz única en el

concentrador tratada

como una red OSPF

punto a multipunto

Interfaz punto a punto

individual en el

concentrador para cada

spoke

Subred IP simple

Menos configuración

por spoke

Puede aprovechar la

señalización de

extremo a extremo

para el estado

descendente

Intervalos más cortos

de temporizadores de

saludo y muerto.

Configuración manual de

cada spoke, con la prioridad

OSPF correcta para DR y

No se pueden alcanzar

entre los spoke, o la

configuración de capa 2 de

uso intensivo de labor.

Rutas de host adicionales

insertadas en la tabla de

enrutamiento

Intervalos más largos de los

temporizadores de saludo y

muerto.

Espacio de direcciones IP

perdido

Más rutas en la tabla de

enrutamiento

Gastos generales de la

subinterfaz

CONSIDERACIONES DE DISEÑO DE CONVERGENCIA Y

TÉCNICAS DE OPTIMIZACIÓN OSPF

Prácticamente, lo que debe determinar el tiempo de convergencia son los requisitos de

aplicación, en particular las aplicaciones de misión crítica que tienen un impacto directo

en las funciones empresariales. Sin embargo, es común que, en algunas redes, el tiempo de

reacción por defecto del protocolo de enrutamiento no sea lo suficientemente rápido para

cumplir con los requisitos de la aplicación. Por lo tanto, una buena comprensión de lo que

influye en la convergencia OSPF le ayudará a mejorarlo.

79

La convergencia de red es el tiempo que se necesita para que la red responda a los

eventos. Es el tiempo que tarda el tráfico en ser reencaminado en una ruta alternativa

cuando un nodo o enlace falla o en una ruta más óptima cuando aparece un nuevo enlace o

nodo. El tráfico no es redirigido hasta que las "estructuras de datos" del plano de datos,

tales como la base de información de reenvío (FIB) y las tablas de adyacencia de todos los

dispositivos, se han ajustado para reflejar el nuevo estado de la red. Para que esto suceda,

todos los dispositivos de red deben pasar por los siguientes pasos:

1. Detectar el evento: Se debe detectar la pérdida o la adición de un enlace o vecino.

Puede realizarse mediante una combinación de mecanismos de detección de Capa

1, Capa 2 y Capa 3, como detección de portador (temporizadores de retardo de

portador), temporizadores de protocolo de enrutamiento y BFD.

2. Propagar el evento: Los mecanismos de actualización del protocolo de

enrutamiento se utilizan para reenviar la información sobre el cambio de topología

de un vecino a otro.

3. Procesar el evento: La información debe introducirse en las estructuras de datos

de protocolo de enrutamiento adecuadas y el algoritmo de enrutamiento debe

invocarse para calcular las mejores rutas actualizadas para la nueva topología.

4. Actualizar estructuras de datos de reenvío: Los resultados de los cálculos de

algoritmos de enrutamiento deben introducirse en las estructuras de datos de

reenvío de paquetes del plano de datos

En este punto, la red ha convergido. El primer paso depende del tipo de fallo y de la

combinación de los protocolos de Capa 1, Capa 2 y Capa 3 que se implementan. Los pasos

segundo y tercero son más específicos de OSPF, y el ajuste de los parámetros asociados

puede mejorar en gran medida los tiempos de convergencia OSPF. El cuarto paso no es

específico del protocolo de enrutamiento, sino que depende de la plataforma de hardware

y los mecanismos que están involucrados en la programación de las estructuras de datos

de plano de datos.

Detección de eventos

En entornos en los que los enrutadores que ejecutan OSPF necesitan detectar cambios

rápidos en la red, deben confiar en protocolos externos como BFD para lograr la detección

de fallos de menos de un segundo, sin afectar a OSPF ni al rendimiento de la red.

BFD es una tecnología que utiliza saludos de enlace de capa 2 rápidos para detectar

enlaces fallidos o unidireccionales y permite la detección de eventos secundarios. El

impacto de la CPU de BFD es menor que el impacto de la CPU del protocolo de

enrutamiento fast hellos porque parte del procesamiento se desplaza al plano de datos en

lugar del plano de control. En plataformas no distribuidas, las pruebas de Cisco han

80

demostrado un menor incremento del CPU del 2 por ciento sobre la línea de base al

soportar 100 sesiones simultáneas BFD.

BFD es un protocolo independiente, y es necesario vincularlo al protocolo de

enrutamiento seleccionado. Puede configurar el soporte BFD para OSPF ya sea

globalmente bajo la configuración del protocolo de enrutamiento o por interfaz específica.

Propagación de eventos de OSPF

Los cambios de topología OSPF se anuncian con inundaciones LSA. El retardo de

propagación de OSPF es igual a la suma del retardo de generación de LSA, el retardo de

llegada de LSA y el retardo de procesamiento de LSA.

Las especificaciones OSPF originales requerían que la generación de LSAs similares, con ID

de enlace de estado, tipo e ID de router de origen, pero posiblemente contenido

actualizado, se retrasara por un intervalo fijo. Este intervalo predeterminado es 1

segundo. Para optimizar este comportamiento, Cisco implementó un algoritmo de backoff

exponencial para calcular dinámicamente el retraso, antes de generar LSAs similares.

Los temporizadores de retroceso inicial son bajos, lo que permite una convergencia más

rápida. Si se generan eventos sucesivos para el mismo LSA, los temporizadores de

retroceso aumentan. Tres temporizadores configurables controlan el retardo:

Start-interval: Define el retardo inicial para generar un LSA. Este temporizador

puede ajustarse a un valor muy bajo, tal como 1 ms o incluso 0 ms. Ajustar este

temporizador a un valor bajo ayuda a mejorar la convergencia porque los LSA

iniciales para nuevos eventos se generan lo más rápidamente posible. El valor

predeterminado es 0 ms.

Hold-interval: Define el tiempo mínimo que transcurre antes de inundar una

instancia actualizada de un LSA. Este es un valor incremental. Inicialmente, el

"tiempo de espera" entre LSAs sucesivos se establece para ser igual a este valor

configurado. Cada vez que se genera una nueva versión de un LSA, el tiempo de

espera entre LSAs se duplica, hasta que se alcanza el valor de intervalo máximo,

momento en el que se utiliza ese valor hasta que la red se estabilice. El valor

predeterminado es 5000 ms.

Max-interval: Define el tiempo máximo que puede transcurrir antes de inundar

una instancia actualizada de un LSA. Una vez que el algoritmo de backoff

exponencial alcanza este valor, deja de aumentar el tiempo de retención y en su

lugar utiliza el temporizador de intervalo máximo como un intervalo fijo entre los

LSA recién generados. El valor predeterminado es 5000 ms.

La determinación de los valores óptimos depende de la red. Una sintonización de los

temporizadores demasiado agresiva podría dar lugar a una carga excesiva de la CPU

81

durante la reconvergencia de red, especialmente cuando la red es inestable durante un

período. Baje los valores gradualmente de sus valores predeterminados y observe el

comportamiento del enrutador para determinar cuáles son los valores óptimos para su

red.

Cuando ajusta los temporizadores de regulación de LSA OSPF, también puede necesitar

ajustar el temporizador de llegada LSA. Cualquier LSA que se reciba a una frecuencia

mayor que el valor de este temporizador se descartará. Para evitar que los enrutadores

descarten LSAs válidos, debe asegurarse de que el temporizador de llegada LSA está

configurado para ser inferior o igual al temporizador de intervalo de espera. De lo

contrario, a un vecino se le permitiría enviar un LSA actualizado antes de que este

enrutador estuviera dispuesto a aceptarlo.

Procesamiento de eventos OSPF

Después de que un enrutador recibe un LSA actualizado, necesita programar su SPF para

procesar la actualización. Debido a que un cambio de topología a menudo afecta a varios

enrutadores, es prudente esperar algún tiempo para que los LSA más actualizados lleguen

y luego ejecutar el SPF sólo después de que este período de espera haya terminado. Esta

acción permite al SPF procesar múltiples actualizaciones en una sola ejecución. Sin

embargo, si el cambio de topología es causado por un fallo repetitivo, como un enlace de

aleteo debido a conectores defectuosos, el SPF con frecuencia ejecuta una carga

innecesaria en el enrutador. Por lo tanto, si un enrutador continúa recibiendo LSAs

actualizados, el retraso antes de la próxima ejecución SPF debería crecer progresivamente

para amortiguar el impacto negativo del aleteo en la red.

Los temporizadores que están involucrados en el estrangulamiento de SPF de OSPF son

similares a los temporizadores de regulación de LSA. Los tres temporizadores

sintonizables

82

SPF-Start: Este es el retardo inicial para programar un cálculo SFP después de un

cambio.

SPF-Hold: Es el tiempo mínimo de espera entre dos cálculos SPF consecutivos.

Similar al temporizador LSA-Hold, este temporizador se utiliza como un valor

incremental en un algoritmo de backoff exponencial.

SPF-Max-Wait: Es el tiempo de espera máximo entre dos cálculos SPF

consecutivos.

De forma predeterminada, los enrutadores de Cisco programarán una ejecución de SPF 5

segundos después de recibir un LSA actualizado y, si un LSA actualizado llega después de

que este SPF se ejecute, el retardo posterior crece hasta 10 segundos.

Reducción de la inundación de OSPF

La característica de reducción de inundación OSPF funciona reduciendo la actualización

innecesaria y la inundación de información ya conocida e inalterada. Como se define en el

RFC 4136, una interfaz que se configura con la reducción de inundación anuncia LSAs con

el conjunto de bits DoNotAge. Como resultado, los LSA no necesitan actualizarse a menos

que se detecte un cambio de red. El mayor impacto se logra en las topologías de malla

completa, donde se reduce el mayor número de LSAs regeneradas.

Puede configurar la reducción de inundación de OSPF sólo por interfaz, pero asegúrese de

que solo habilita la reducción de inundación de OSPF en entornos estables. Una

actualización periódica de LSAs permite que el mecanismo OSPF se recupere de bugs y

glitches, lo que garantiza la robustez del protocolo.

Protección de sobrecarga de la base de datos OSPF

La característica de protección de sobrecarga de la base de datos de estado de enlace OSPF

le permite limitar el número de LSA no generados automáticamente y proteger el proceso

OSPF. Los LSA excesivos generados por otros enrutadores en el dominio OSPF pueden

drenar sustancialmente los recursos de CPU y memoria del enrutador.

Cuando otros enrutadores OSPF en la red han sido mal configurados, pueden generar un

alto volumen de LSA, por ejemplo, para redistribuir un gran número de prefijos. Este

mecanismo de protección impide que los enrutadores reciban muchos LSAs y por lo tanto

experimenten escasez de CPU y memoria.

Cuando la característica protección de sobrecarga de la base de datos de estado de enlace

OSPF está habilitada, el enrutador mantiene un recuento del número de LSA que recibe.

83

Cuando alcanza el número de umbral configurado de LSA, registra un mensaje de error.

Cuando excede el número máximo configurado de LSA, el enrutador envía una

notificación. Si el recuento de LSA recibidos sigue siendo superior al máximo configurado

después de un minuto, el proceso OSPF anula todas las adyacencias y borra la base de

datos OSPF.

En este estado de ignorar, todos los paquetes OSPF recibidos en cualquier interfaz que

pertenecen a este proceso OSPF se ignoran y no se generan paquetes OSPF en ninguna de

estas interfaces. El proceso OSPF permanece en este estado durante el tiempo configurado

por la palabra clave ignoretime del comando max-lsa. Cada vez que el proceso OSPF pasa

a un estado de ignorar, incrementa un contador. Si este contador supera el número de

cuenta, como se configuró en la palabra clave ignore-count, el proceso OSPF permanece

permanentemente en el mismo estado de ignorar, y se requiere intervención manual para

sacar al proceso OSPF fuera de dicho estado. El contador de estado de ignorar se

restablece a cero cuando el proceso OSPF permanece en el estado normal de

funcionamiento durante el tiempo especificado por la palabra clave reset-time.

84

Capítulo 4

Diseño de IS-IS

85

VISIÓN GENERAL DEL PROTOCOLO

IS-IS fue desarrollado originalmente para enrutar en redes de protocolo de red sin

conexión ISO (CLNP); Sin embargo, desde entonces se ha creado una versión que admite

redes CLNP e IP. Esta versión se conoce generalmente como IS-IS integrado o dual.

Las especificaciones ISO se refieren a enrutadores como sistemas intermedios. Por lo

tanto, IS-IS es un protocolo que permite a los enrutadores comunicarse con otros

enrutadores. El conjunto OSI utiliza CLNS para proporcionar la entrega de datos sin

conexión y el protocolo Capa 3 real es CLNP. Además, IS-IS utiliza direcciones de servicio

de red sin conexión (CLNS) para identificar los enrutadores y crear la base de datos de

estado de enlace (LSDB). Las direcciones CLNS, que se conocen como puntos de acceso a

servicios de red (NSAP), se componen de tres componentes:

Un prefijo de identificador de área (ID de área).

Un identificador de sistema (sysID).

Un selector N.

El selector N se refiere al usuario del servicio de red, tal como un protocolo de transporte.

Tiene una interpretación similar a la del número de puerto de aplicación que se utiliza en

el Protocolo de Control de Transmisión IP (TCP).

Además, el mecanismo de tipo, longitud y valor (TLV) hace que el protocolo IS-IS sea

flexible y fácil de extender. Las cadenas TLV, que se llaman tuplas, están presentes en

todas las actualizaciones IS-IS. IS-IS hoy soporta IPv6; puede crecer fácilmente para

soportar cualquier otro protocolo porque extender IS-IS consiste simplemente en crear

nuevos TLVs. Por lo tanto, la introducción de nuevas características para el protocolo es

fácil y más flexible con el uso de los TLV.

Los sistemas intermedios se comunican entre sí utilizando directamente la capa 2 del

modelo OSI. Esto significa que no hay necesidad técnica para IP o cualquier otro protocolo

de capa superior. La interconexión con la capa de enlace de datos (capa 2) implica

principalmente operaciones para detectar, formar y mantener adyacencias de

enrutamiento con enrutadores vecinos sobre varios tipos de medios o enlaces de red de

interconexión. Esto también hace IS-IS relativamente más seguro que otros protocolos de

enrutamiento que se ejecutan a través de IP.

El protocolo de red ISO Connectionless se especifica para la transferencia de datos entre

dos categorías principales de dispositivos de red:

Sistemas finales: estaciones de trabajo o hosts de red con capacidad limitada de

enrutamiento.

Sistemas intermedios: dispositivos de red, como enrutadores, con extensas

capacidades de envío de paquetes. La palabra intermedio se refiere a las

86

capacidades de los enrutadores como dispositivos intermedios de reenvío o de

retransmisión.

Características de IS-IS

Al igual que OSPF, IS-IS también es un protocolo de estado de enlace que usa el algoritmo

de Dijkstra, en el que cada enrutador tiene información de topología para su área. IS-IS es

parte de la suite de protocolos estándar OSI y se utilizó originalmente con CLNS. Cada

enrutador se identifica utilizando una dirección NSAP única, que es parte del protocolo

CLNS. IS-IS sigue utilizando CLNS para mantener adyacencias y generar árboles SPF, pero

la versión integrada de IS-IS puede utilizarse para otros protocolos, como IP, y también

puede tener extensiones para Multiprotocol Label Switching Traffic Engineering (MPLS

TE).

Desde un punto de vista de diseño de alto nivel, IS-IS funciona de forma similar a OSPF. IS-

IS permite dividir el dominio de enrutamiento en áreas. Normalmente, los enrutadores IS-

IS establecen adyacencias usando un protocolo "Hello" e intercambian información de

estado de enlace, utilizando paquetes de estado de enlace (LSP) en un área para construir

el LSDB. Cada enrutador entonces ejecuta el algoritmo de la ruta más corta de Dijkstra

(SPF) contra su LSDB para escoger los mejores caminos. Una cantidad mínima de

información se comunica entre las áreas, reduciendo así la carga en los enrutadores que

soportan el protocolo. El enrutamiento IS-IS tiene lugar en dos niveles dentro de un

sistema autónomo enrutado (AS): Nivel 1 y Nivel 2. Estos niveles en IS-IS son similares a

las áreas OSPF en concepto (cada uno tiene su propio dominio de inundación enrutado y

ofrece la capacidad de ocultar información de topología y accesibilidad en el límite de área

/ nivel).

La especificación IS-IS original define cuatro tipos diferentes de métricas. El costo, la

métrica predeterminada, es compatible con todos los enrutadores. Retraso, gasto y error

son métricas opcionales. La métrica de retardo mide el retardo de tránsito, la métrica de

gasto mide el costo monetario de la utilización del enlace y la métrica de error mide la

probabilidad de error residual asociada con un enlace.

La implementación de Cisco utiliza sólo la métrica de coste. Si se implementaran las

métricas opcionales, existiría una base de datos de estado de enlace para cada métrica y

SPF se ejecutaría para cada base de datos de estado de enlace.

La métrica de estilo amplio debe utilizarse para redes de proveedores de servicios grandes

y de alta velocidad (métrica de enlace de 24 bits, métrica de ruta de 32 bits). El costo del

enlace es 10 y puede modificarse para reflejar el costo deseado. La métrica de estilo

estrecho puede acomodar sólo 64 valores métricos, lo cual es típicamente insuficiente en

87

las redes modernas y puede que ni siquiera sea compatible con extensiones IS-IS, como las

de Cisco MPLS TE.

El Software Cisco soluciona este problema con el soporte de la métrica de enlace de 24

bits, la métrica de ruta de 32 bits (la denominada "métrica amplia"). Por lo tanto, se

recomienda implementar IS-IS en la red IP con métricas amplias (especialmente en redes

grandes y de alta calidad) para permitir granularidad más fina y para soportar futuras

aplicaciones, como el etiquetado de rutas, la filtración de rutas y la ingeniería de tráfico.

Enrutamiento IS-IS integrado

IS-IS integrado, o IS-IS dual, es una implementación del protocolo IS-IS para enrutar

múltiples protocolos de red; IS-IS Integrado para IP y CLNS se especifican en RFC 1195 e

ISO 10589.

La IS-IS integrada etiqueta las rutas CLNP con información sobre redes IP. Como una

alternativa a OSPF, IS-IS integrada combina ISO CLNS y enrutamiento IP en un protocolo.

IS-IS integrada se puede utilizar para el enrutamiento IP, el enrutamiento CLNS o una

combinación de los dos. IS-IS integrada utiliza sus propias unidades de datos de paquetes

(PDU), incluyendo la información de accesibilidad IP, para transportar información entre

enrutadores. La información IS-IS no se transporta dentro de un protocolo de capa de red,

sino que se transporta directamente dentro de las tramas de la capa de enlace de datos.

Esta independencia del protocolo hace IS-IS fácilmente extensible; También hay una

versión de IS-IS integrada que admite IPv6, como se describe en el RFC 5308. Debido a que

IS-IS utiliza direcciones CLNS para identificar los enrutadores y para construir el LSDB,

una comprensión de las direcciones CLNS es necesaria para configurar y solucionar

problemas de IS- IS, incluso cuando se utiliza sólo para enrutar IP.

Las siguientes opciones de implementación para dominios IS-IS están especificadas por

RFC 1195:

Dominio IP puro: enruta sólo el tráfico IP pero admite el reenvío y procesamiento

de paquetes OSI que se requieren para la operación IS-IS.

Dominio ISO puro: lleva sólo el tráfico ISO, incluida la comunicación necesaria

para la operación IS-IS.

Un dominio dual: enruta tráfico IP y OSI CLNP simultáneamente.

También es posible diseñar un dominio dual para que algunas áreas sólo enruten IP,

mientras que otras sólo enruten CLNP, y otras enruten IP y CLNP. El objetivo es lograr una

información de enrutamiento consistente dentro de un área al tener bases de datos de

estado de enlace de Nivel 1 idénticas en todos los enrutadores de esa zona.

88

DESCRIPCIÓN DE LA ARQUITECTURA JERÁRQUICA IS-IS

IS-IS, como un protocolo de enrutamiento de estado de enlace, tiene soporte integrado

para el diseño de redes lógicas estructuradas. Sin embargo, el diseño y los términos

utilizados en IS-IS son ligeramente diferentes de lo que están en OSPF. Las siguientes son

las principales condiciones de red IS-IS que colectivamente pueden construir una

arquitectura jerárquica:

Un área es un grupo de redes contiguas y hosts conectados que se especifica como

un área por un gestor o administrador de red.

Un dominio es una colección de áreas conectadas. Los dominios de enrutamiento

proporcionan conectividad completa a todos los sistemas finales dentro de ellos. En

otras palabras, un dominio de enrutamiento IS-IS es una red en la que todos los

enrutadores ejecutan el protocolo de enrutamiento IS-IS integrado para admitir el

intercambio intradominio de información de enrutamiento.

El enrutamiento de nivel 1 es el enrutamiento dentro de un área. Un enrutador de

nivel 1 sólo conoce la topología de su área y puede tener vecinos de Nivel 1 o Nivel

1 / Nivel 2 sólo en su propia área. Tiene una base de datos de estado de enlace de

nivel 1 con toda la información para el enrutamiento intra-área. Utiliza el

enrutador L1 / L2 más cercano en su propia área para enviar paquetes fuera del

área.

El enrutamiento de nivel 2 es el enrutamiento entre diferentes áreas. Un enrutador

de nivel 2 (L2 o L1 / L2) puede tener vecinos L2 en la misma o en diferentes áreas,

y tiene una base de datos de estado de enlace de nivel 2 con toda la información

89

para el enrutamiento interarea. El enrutador también puede servir como un

sistema L1 / L2, en cuyo caso tiene bases de datos de enlace L1 y L2.

El backbone IS-IS es una cadena contigua de enrutadores compatibles con L2 (L2 o

L1 / L2) que contienen la información para el enrutamiento interarea completo. El

backbone abarcará múltiples áreas con enrutadores miembros en cada área. El

backbone no debe ser interrumpido; Por lo tanto, usted tiene que diseñar su red

con enlaces redundantes L2 en mente. Esto hará al backbone más resistente a las

fallas en los enlaces o enrutadores a lo largo del camino.

A diferencia de OSPF, en IS-IS todas las áreas no tienen que conectarse a un área común

del backbone.

Tipos de enlaces y enrutadores IS-IS

IS-IS se puede dividir en múltiples áreas y niveles en los que se necesitan diferentes tipos

de enrutadores y enlaces para formar y mantener las adyacencias y la comunicación IS-IS.

Los siguientes son los tipos de enrutador IS-IS que debe considerar en un diseño IS-IS de

varios niveles (jerárquico):

Enrutador de nivel 1: Este enrutador conoce la topología sólo de su área y tiene

vecinos de Nivel 1 o Nivel 1 / Nivel 2 en esta área. Tiene una base de datos de

estado de enlace de nivel 1 con toda la información para el enrutamiento intraárea.

Utiliza el enrutador Nivel 1 / Nivel 2 más cercano en su propia área para

enviar paquetes fuera del área.

Enrutador de nivel 2: Este enrutador puede tener vecinos en la misma o en áreas

diferentes, y tiene una base de datos de estado de enlace de nivel 2 con toda la

información para el enrutamiento entre líneas. Los enrutadores de nivel 2 conocen

90

otras áreas, pero no tienen información de Nivel 1 de su área. Si el tráfico en un

área es IP solamente, todos los enrutadores pueden configurarse como Nivel 2.

Enrutador Nivel 1 / Nivel 2: Este enrutador puede tener vecinos en cualquier

área. Cuenta con dos bases de datos de estado de enlace: una base de datos de

estado de enlace de nivel 1 para el enrutamiento intra-área y una base de datos de

estado de enlace de nivel 2 para el enrutamiento interarea. Un enrutador Nivel 1 /

Nivel 2 ejecuta dos SPF y puede requerir más memoria y poder de procesamiento.

Los tipos de enlaces IS-IS juegan un papel clave para formar adyacencias vecinas, teniendo

en cuenta el tipo de enrutador que se va a interconectar y el diseño del área IS-IS. Todos

estos factores entran en juego al determinar si una adyacencia IS-IS puede ser formada o

no, como se resume aquí:

Las adyacencias de nivel 1 sólo se pueden formar entre enrutadores en la misma

área. No es posible tener una adyacencia L1 entre enrutadores en diferentes áreas.

Sólo se pueden formar adyacencias de nivel 2 entre enrutadores en diferentes

áreas. La adyacencia de nivel 2 también se puede formar entre enrutadores en la

misma área si ambos son compatibles con L2 (por configuración).

Ambas adyacencias de nivel 1 y 2 entre un par de enrutadores pueden formarse

sólo si existen dentro de la misma área.

Adyacencias IS-IS

La formación exitosa de una adyacencia IS-IS entre dos nodos es un requisito previo para

el intercambio de información de enrutamiento IS-IS. Esto sucede usando LSPs y paquetes

de números de secuencia (SNP).

En IS-IS, para que dos enrutadores se conviertan en vecinos y construyan una adyacencia

entre ellos, deben cumplirse los siguientes parámetros (acordados):

Nivel 1: Dos enrutadores que comparten un segmento de red común deben tener

sus interfaces configuradas para estar en la misma área para poder establecer una

adyacencia de nivel 1.

Nivel 2: Si dos enrutadores comparten un segmento de red común y pertenecen a

áreas diferentes, deben configurarse como Nivel 2 si necesitan convertirse en

vecinos.

Autenticación: IS-IS permite la configuración de una contraseña para un enlace

especificado, para un área o para todo un dominio. Para que una adyacencia se

forme, las contraseñas deben coincidir.

91

Para las topologías LAN, un ejemplo es

Los enrutadores de una zona aceptan unidades de datos de paquete (PDU) saludo

IIH (Intermediate to Intermediate System Hello) de nivel 1 únicamente desde su

propia área y, por lo tanto, establecen adyacencias de nivel 1 únicamente con

enrutadores de nivel 1 de su misma área.

Los enrutadores de una segunda área aceptan de manera similar las PDU IIH de

nivel 1 sólo desde su propia área.

Los enrutadores de Nivel 2 (o el proceso de Nivel 2 dentro de cualquier enrutador

de Nivel 1-2) aceptan sólo PDU de Nivel 2 IIH y establecen únicamente adyacencias

de Nivel 2.

Para topologías punto-a-punto, las PDU IIH son comunes para L1 y L2; Sin embargo,

dentro del mismo paquete de saludo, el nivel real (L1, L2 o L1 / L2) se anuncia de la

siguiente manera:

Enrutadores de nivel 1 en la misma área intercambian PDU IIH que especifican

Nivel 1 y establecen una adyacencia de Nivel 1.

Los enrutadores de Nivel 2 intercambian PDUs IIH que especifican el Nivel 2 y

establecen una adyacencia de Nivel 2.

Dos enrutadores de nivel 1-2 en la misma área establecen adyacencias de nivel 1 y

nivel 2 y mantienen estas adyacencias con una PDH IIH común que especifica la

información de nivel 1 y nivel 2.

Dos enrutadores Nivel 1 que están conectados físicamente, pero que no están en la

misma área, pueden intercambiar IIHs, pero no establecen adyacencia porque las

direcciones de área no coinciden.

92

IS-IS VERSUS OSPF

Esta sección resalta y explica las similitudes y diferencias entre IS-IS y OSPF para

simplificar el trabajo de los diseñadores de redes cuando tienen que seleccionar un

protocolo de enrutamiento de estado de enlace.

Similitudes entre IS-IS y OSPF

En general, ambos protocolos de enrutamiento tienen las siguientes características:

Son protocolos de enrutamiento interior de estado de enlace de estándar abierto.

Soportan VLSM.

Utilizan mecanismos similares, como LSAs / LSPs, temporizadores de

envejecimiento de estado de enlace y sincronización LSDB, para mantener la salud

del LSDB.

Utilizan el algoritmo SPF de Dijkstra, con procesos similares de actualización,

decisión e inundación.

Ambos usan el concepto de áreas.

A pesar de que IS-IS es comúnmente desplegado en las redes de proveedores de

servicios, son igualmente exitosos en la empresa pequeña y en los más grandes y

más exigentes despliegues (redes de proveedores de servicios).

Soportan MPLS-TE.

Son escalables y convergen rápidamente después de los cambios de red.

Características de OSPF e IS-IS

OSPF se basa en LSA para enviar actualizaciones; Sin embargo, produce muchos LSA

pequeños. En contraste, las actualizaciones IS-IS están agrupadas por el enrutador y se

envían como un LSP. Por lo tanto, a medida que aumenta la complejidad de la red, el

número de actualizaciones IS-IS no es un problema. Sin embargo, cada paquete de

actualización debe estar enrutado y el enrutamiento toma los recursos de red, por lo que

más paquetes representan un mayor impacto en la red.

93

Debido a que IS-IS utiliza significativamente menos LSP, más enrutadores, por lo menos

1000, pueden residir en una sola área, por lo que IS-IS es más escalable que OSPF. Dicho

esto, en una red típica de medios de comunicación, una con enrutadores modernos, OSPF e

IS-IS son opciones perfectamente válidas. Como cuestión de practicidad, las redes

empresariales con áreas estructuradas / diseño de nivel, es muy raro que se necesita un

número extremadamente grande de enrutadores en una sola área. Además, OSPF se

ejecuta a través de IP, mientras que IS-IS se ejecuta a través de CLNS, que puede dar

preferencia a OSPF en los diseños donde se necesita ejecutar a través de IP, como sobre un

túnel GRE o mGRE. Además, a diferencia de OSPF, IS-IS no tiene concepto de redes NBMA,

que pueden ser requeridas por algunas WAN heredadas, como Frame Relay.

Además, IS-IS es también más eficiente que OSPF en el uso de recursos de la CPU y en la

forma en que procesa las actualizaciones de enrutamiento. No sólo hay menos LSPs para

procesar (LSAs, en terminología OSPF), sino que también el mecanismo por el cual IS-IS

instala y retira prefijos es menos intensivo. IS-IS utiliza direcciones de título de entidad de

red (NET), que ya están resumidas. Prácticamente, en redes de grado empresarial con

enrutadores de próxima generación que tienen altas capacidades de hardware, este punto

no es una gran preocupación.

Tanto OSPF como IS-IS son protocolos de estado de enlace, por lo que proporcionan

convergencia rápida. El tiempo de convergencia depende de varios factores, como los

temporizadores, el número de nodos y el tipo de enrutador. Basándose en los

temporizadores predeterminados, IS-IS detecta un error más rápido que OSPF; por lo

tanto, la convergencia ocurre más rápidamente. Si hay muchos enrutadores y adyacencias

94

vecinas, el tiempo de convergencia también puede depender de la potencia de

procesamiento del enrutador. IS-IS requiere menos CPU que OSPF.

A diferencia de IS-IS, en los paquetes OSPF, las nuevas características no son fáciles de

implementar; requieren la creación de un nuevo LSA. El esquema de descripción de OSPF

es difícil de extender, debido a problemas de compatibilidad y porque fue desarrollado

exclusivamente para IPv4. Por el contrario, IS-IS es fácil de extender a través del

mecanismo TLV. Las cadenas TLV, que se llaman tuplas, codifican todas las actualizaciones

IS-IS. IS-IS puede crecer fácilmente para cubrir IPV6, o cualquier otro protocolo, porque

extender IS-IS consiste simplemente en crear TLVs nuevos.

Una empresa puede elegir OSPF sobre IS-IS porque OSPF está más optimizado y porque

fue diseñado exclusivamente como un protocolo de enrutamiento IP. Por ejemplo, OSPF

define diferentes tipos de área (normal, stub y NSSA). Además, la métrica OSPF

predeterminada es más flexible, ya que está relacionada con el ancho de banda de la

interfaz, mientras que IS-IS tiene una métrica predeterminada de diez en todas las

interfaces.

Desde los puntos de vista de implementación y operación, si una empresa considera a

OSPF como el protocolo de enrutamiento principal, normalmente requiere equipos de red

que soportan OSPF, junto con ingenieros de red familiarizados con la teoría y operación de

OSPF. Es relativamente fácil encontrar equipo y personal para soportar una

infraestructura OSPF. Además, la documentación OSPF está mucho más disponible que la

documentación para IS-IS.

Diseños de área OSPF e IS-IS integrado

Esta sección se centra en las diferencias entre el OSPF y el diseño del área de IS-IS

integrado.

Diseño de Área OSPF

Con OSPF, el diseño de la red está limitado por el hecho de que OSPF se basa en un

backbone central, el área 0, con todas las otras áreas unidas físicamente al área 0. El borde

entre las áreas está dentro de los ABR; cada enlace está en una sola área. Cuando se utiliza

este tipo de modelo jerárquico, es necesaria una estructura de direccionamiento IP

coherente para permitir un resumen efectivo de la ruta hacia el backbone. Esto reduce la

cantidad de información que se transporta en el backbone y se anuncia a través de la red.

95

Diseño de Área IS-IS Integrado

A diferencia de OSPF, IS-IS tiene una jerarquía de enrutadores Nivel 1 y Nivel 2 o Nivel 1-2

y las fronteras de área se encuentran en los enlaces. La capacidad de IS-IS para soportar la

superposición entre el nivel 1 y el nivel 2 en el ABR ofrece un enfoque más flexible para

ampliar el backbone, así como facilitar el logro de un enrutamiento más óptimo en las

redes complejas. Puede extender la columna vertebral simplemente añadiendo más

enrutadores Nivel 2 y Nivel 1-2, un proceso menos complejo que con OSPF.

96

IS-IS TECHNICAL DEEP DIVE

Esta sección abarca varios aspectos técnicos del protocolo IS-IS, incluidos

Direccionamiento IS-IS

Paquetes IS-IS y flujo de datos

Tipos de red IS-IS y funcionamiento

Inundación LSP IS-IS y sincronización LSDB

Direccionamiento IS-IS

IS-IS LSP utiliza direcciones NSAP para identificar al enrutador y construir la tabla de

topología y el árbol de enrutamiento IS-IS subyacente; Por lo tanto, IS-IS requiere

direcciones NSAP para funcionar correctamente, incluso si se utiliza sólo para enrutar IP.

Las direcciones NSAP contienen lo siguiente:

Dirección OSI del dispositivo

Enlace con el proceso de capa superior

La dirección NSAP es equivalente a la combinación de la dirección IP y el protocolo de

capa superior en un encabezado IP. Las direcciones NSAP tienen un tamaño mínimo de 8

bytes y un tamaño máximo de 20 bytes. Los bits de mayor orden identifican la estructura

inter área, y los bits de orden inferior identifican sistemas únicos dentro de un área. Hay

varios formatos de dirección NSAP.

La implementación de Integrated IS-IS de Cisco divide la dirección NSAP en tres campos:

la dirección de área, la ID de sistema y NSEL NSEL.

El enrutamiento Cisco CLNS utiliza direccionamiento que cumple con el estándar

ISO10589. Las direcciones ISO NSAP consisten en estos elementos:

La autoridad y el identificador de formato AFI y el identificador de dominio inicial

IDI constituyen la parte de dominio inicial IDP de la dirección NSAP. El IDP

corresponde aproximadamente a una red principal clasificadora de IP:

o El byte AFI especifica el formato de la dirección y la autoridad asignada a

esa dirección.

o Las direcciones que comienzan con el valor AFI de 49 son direcciones

privadas, análogas a la RFC 1918 para direcciones IP IS-IS a estas

direcciones; sin embargo, este grupo de direcciones no debe ser anunciado a

97

otras redes CLNS porque son direcciones ad hoc. Otras empresas que

utilizan el valor de 49 pueden haber creado diferentes esquemas de

numeración que, cuando se usan juntos, podrían crear confusión.

o El IDI identifica un subdominio bajo el AFI

La parte específica del dominio contribuye al enrutamiento dentro de un dominio

de enrutamiento IS-IS. El DSP está compuesto por el DSP HO-DSP de alto orden, el

ID del sistema y el NSEL.

o El HO-DSP subdivide el dominio en áreas. El HO-DSP es aproximadamente el

equivalente OSI de una subred en IP.

o El ID del sistema identifica un dispositivo OSI individual. En OSI, un

dispositivo tiene una dirección, al igual que en DECnet, mientras que en IP,

cada interfaz tiene una dirección.

o El NSEL (selector NSAP) identifica un proceso en el dispositivo y

corresponde aproximadamente a un puerto o socket en IP. El NSEL no se

utiliza en las decisiones de enrutamiento.

El formato NSAP más simple, utilizado por la mayoría de las empresas que ejecutan IS-IS

como IGP, se compone de lo siguiente:

Dirección de área: Debe tener al menos 1 byte, dividido en dos partes:

o El AFI, establecido en 49, que significa que el AFI se administra localmente, y

por lo tanto, las direcciones individuales pueden ser asignados por la

empresa.

o El ID de área, los octetos de la dirección de área, sigue al AFI.

ID del sistema: ID de sistema de 6 bytes.

NSEL: NSEL siempre se debe establecer en 0 para un enrutador. NET es una

dirección NSAP con un NSEL de 0.

La dirección de área identifica únicamente el área de enrutamiento, y el ID del sistema

identifica cada nodo. La primera parte de un NSAP es la dirección de área, y está asociada

con el proceso de enrutamiento IS-IS. A diferencia de OSPF, un enrutador IS-IS puede ser

un miembro de una sola área. Todos los enrutadores en un área deben utilizar la misma

dirección de área, que la define. La dirección de área se usa en el enrutamiento de nivel 2

(interárea).

98

El identificador del sistema NSAP de 6 bytes debe ser único dentro de un área. Es habitual

utilizar una dirección MAC del enrutador o, para IS-IS integrado, codificar una dirección IP

en el ID del sistema. Todos los identificadores de sistema en un dominio deben ser de igual

longitud y únicos. Cisco hace cumplir esta directiva OSI fijando la longitud del ID del

sistema en 6 bytes.

Al diseñar el direccionamiento IS-IS, debe tener en cuenta lo siguiente:

Todos los enrutadores dentro de un área deben usar la misma dirección de área.

La dirección de área se utiliza en el enrutamiento de nivel 1 y 2.

El ID del sistema identifica el sistema intermedio.

El ID del sistema para enrutadores L1 debe ser único dentro de un área.

El ID del sistema para enrutadores L2 debe ser único dentro de todo el dominio.

Normalmente se utiliza un ID de sistema exclusivo de dominio.

Paquetes IS-IS

Los primeros ocho octetos de todas las PDU IS-IS son campos de encabezado que son

comunes a todos los tipos de PDU. La información TLV se almacena al final de la PDU. Los

diferentes tipos de PDU tienen un conjunto de códigos TLV definidos. Cualquier código

TLV que un enrutador no reconozca debe ser ignorado y pasado sin cambios.

Las PDU IS-IS se encapsulan directamente en una trama de enlace de datos OSI. IS-IS

define cuatro tipos generales de PDU, y cada tipo puede ser Nivel 1 o Nivel 2:

IS-IS Hello IIH: Permite que los sistemas intermedios detecten los vecinos IS-IS y

formen adyacencias. Hay dos tipos de IIH:

o LAN IIH: Los enrutadores envían paquetes LAN IIH por separado para

adyacencias nivel 1 y nivel 2.

99

o Punto-a-punto IIH: Los enrutadores envían un solo paquete para L1, L2, o

L1 / L2, dependiendo de la naturaleza de la adyacencia.

PDU LSP: Se utiliza para distribuir información de estado de enlace.

Número de secuencia parcial PDU PSNP: Se utiliza para reconocer y solicitar

piezas faltantes de información de estado de enlace.

Número de secuencia completo PDU CSNP: Se utiliza para describir la lista

completa de LSPs en el LSDB de un enrutador. Los CSNP se utilizan para informar a

otros enrutadores de LSP que pueden estar obsoletos o que faltan en su propia

base de datos. Esto garantiza que todos los enrutadores tengan la misma

información y estén sincronizados. Los paquetes son similares a un paquete de

descripción de base de datos OSPF.

La siguiente información se incluye en las PDU IIH:

Si la PDU es punto a punto (WAN) o LAN.

ID de origen o el ID del sistema del enrutador de envío.

Tiempo de espera, o el período de tiempo para esperar a escuchar un "saludo"

antes de declarar al vecino muerto. Similar al intervalo OSPF, el valor

predeterminado es tres veces el intervalo hello, pero puede cambiarse con el

comando IS-IS hello-multiplier.

Tipo de circuito que indica si la interfaz de la que se envió la PDU es Nivel 1, Nivel 2

o Nivel 1 / Nivel 2.

Longitud de PDU.

ID de circuito local en la interfaz de envío (en PDU de punto a punto).

LAN ID, que es el identificador de sistema del Sistema Intermedio Designado (DIS)

más el ID de pseudonodo (ID de circuito) para diferenciar los ID de LAN en el

mismo DIS.

Prioridad. Más alto es mejor; Se utiliza en la elección DIS.

Flujo de datos de la Información IS-IS

El flujo de información dentro de la función de enrutamiento IS-IS consiste en cuatro

procesos junto con las bases de información de enrutamiento y reenvío. El RIB basado en

información de enrutamiento consiste en la base de datos de estado de enlace y la base de

información de reenvío FIB quecontiene la base de datos de reenvío. Aquí es donde Cisco

Express Forwarding (CEF) juega un papel vital para acelerar el cambio de un paquete. Los

cuatro procesos del diagrama de flujo de datos IS-IS son:

Recepción.

Actualización.

Decisión.

Reenvio.

100

El proceso de recepción es el punto de entrada para todos los datos, incluidos los datos de

usuario, los informes de errores, la información de enrutamiento y los paquetes de

control. Transmite los datos de usuario y los informes de errores al proceso de reenvio y

pasa la información de enrutamiento y los paquetes de control (hellos, LSPs y paquetes de

números de secuencia) al proceso de actualización.

El proceso de actualización genera información de vínculo local que inunda los

enrutadores adyacentes. Además, el proceso de actualización recibe, procesa y envía la

información de enlace que se recibe de los enrutadores adyacentes. Este proceso gestiona

las bases de datos de estado de enlace Nivel 1 y Nivel 2 e inunda los LSPs Nivel 1 y Nivel 2

en un área.

El proceso de decisión ejecuta un algoritmo SPF en la base de datos de estado de enlace y

crea la base de datos de reenvío. Calcula la información del salto siguiente y calcula

conjuntos de rutas de coste igual, creando un conjunto de adyacencia que se utiliza para el

equilibrio de carga. En un enrutador Cisco, IS-IS admite el equilibrio de carga por encima y

hasta seis rutas de coste igual.

El proceso de reenvio recibe su entrada del proceso de recepción y utiliza la base de datos

de reenvío para reenviar paquetes de datos hacia su destino. También redirecciona el uso

compartido de cargas y genera informes de errores.

Tipos de redes IS-IS

En general, los enlaces físicos se pueden colocar en estos dos grupos:

Broadcast: subredes multiacceso que soportan el direccionamiento de un grupo de

sistemas conectados.

Punto a punto: Enlaces permanentes o establecidos dinámicamente.

En contraste, IS-IS soporta dos representaciones de medios para sus estados de enlace:

Broadcast para LANs y enlaces WAN multipunto.

101

Punto a punto para todos los demás medios.

Además, es importante que los diseñadores de redes sean conscientes de que IS-IS no

tiene concepto de redes NBMA. Por lo tanto, se recomienda utilizar un enlace punto a

punto, como subinterfaces punto a punto, en redes NBMA, cuando sea posible, como un

enfoque alternativo.

Características Broadcast Punto a punto

Uso LAN, WAN de malla completa PPP, HDLC, WAN de

malla parcial

Temporizador de 3.3 segundos para DIS, 10 segundos 10 segundos

saludo

para lo demás

Adyacencias n*(n – 1)/2 n-1

Usa DIS Sí No

LSP e IIH Enviado como multicast Enviado como unicast

Tipo de IIH IIH Nivel 1, IIH Nivel 2 IIH punto a punto

Operaciones del protocolo IS-IS

Las adyacencias se forman y se basan en la dirección de área que se comunica en el IIH

entrante y el tipo de enrutador (Nivel 1 o Nivel 2). Los enrutadores de nivel 1 aceptan PDU

de IIH nivel 1 de su propia área y establecen adyacencias con otros enrutadores en su

propia área. Los enrutadores de nivel 2 aceptan sólo las PDU de IIH nivel 2 y establecen

únicamente adyacencias de nivel 2.

En medios multiacceso de difusión (LAN), se elige un Sistema Intermedio Designado (DIS)

y conduce la inundación sobre el medio. El DIS es análogo al enrutador designado en

Protocolo OSPF. El algoritmo de Dijkstra requiere un enrutador virtual (un pseudonodo),

que es representado por el DIS, para construir un grafo dirigido para medios de difusión.

El DIS es responsable de dos tareas principales:

Crear y actualizar el pseudonodo LSP

Inundación de LSPs a través de la LAN

102

Para que los nodos IS-IS seleccionen un DIS, debe satisfacer los siguientes criterios de

selección:

La prioridad más alta; El valor de prioridad es configurable.

El SNPA de punto de acoplamiento de subred más alto; En LANs, el SNPA es la

dirección MAC. El SNPA para una interfaz WAN es el identificador de circuito

virtual.

Las interfaces de un enrutador Cisco tienen la prioridad predeterminada de nivel 1 y nivel

2 en 64. Puede configurar la prioridad de 0 a 127. El nivel 1 DIS y el nivel 2 DIS en una LAN

pueden o no ser el mismo enrutador porque una interfaz puede tener diferentes

prioridades de Nivel 1 y Nivel 2.

No se garantiza que un enrutador seleccionado siga siendo el DIS. Cualquier sistema

intermedio adyacente con mayor prioridad asume automáticamente el papel de DIS. Este

comportamiento se llama preventivo. Debido a que el LSDB IS-IS se sincroniza

frecuentemente en una LAN, dar prioridad a otro sistema intermedio sobre el DIS no es un

problema significativo. IS-IS no utiliza una DIS de respaldo, y los enrutadores en una LAN

establecer adyacencias tanto con el DIS y como con los demás enrutadores.

LSPs e IIHs Nivel 1 y Nivel 2

La naturaleza de dos niveles de IS-IS requiere tipos separados de LSPs: Nivel 1 y Nivel 2.

La siguiente lista explica estos tipos:

LSP Nivel 1 y Nivel 2: IS-IS utiliza una jerarquía de área de dos niveles. La

información de estado de enlace para estos dos niveles se distribuye por separado,

103

En una LAN:

lo que resulta en LSP de nivel 1 y LSP de nivel 2. Cada sistema intermedio origina

sus propios LSPs (uno para el Nivel 1 y otro para el Nivel 2).

o Un enrutador (el DIS) envía información LSP en nombre de la LAN.

o El DIS representa un pseudonodo.

o El DIS envía el LSP de nivel 1 o 2 para el pseudonodo.

o El nivel 1 DIS y el nivel 2 DIS en una LAN puede o no ser el mismo enrutador

porque una interfaz puede tener diferentes prioridades nivel 1 y 2.

o Los LSP en los enlaces punto a punto se envían como unicast, mientras que

en los medios de difusión (LAN) los LSP se envían como multicast.

Nivel 1 y Nivel 2 IIH: Los IIHs se usan para establecer y mantener la vecindad entre

sistemas intermedios. El intervalo de saludo predeterminado es de cada 10

segundos; Sin embargo, el temporizador de intervalo de saludo es ajustable.

En una LAN, se envían periódica y separadamente IIHs de nivel 1 y de nivel 2 como

multicasts a direcciones MAC de ulticast:

Todos L1 ISs-01-80-C2-00-00-14-La dirección multicast "Todos los sistemas

intermedios de nivel 1"

Todos L2 ISs-01-80-C2-00-00-15-La dirección multicast "Todos los sistemas

intermedios de nivel 2"

Además, hay dos direcciones MAC adicionales que están en uso por IS-IS:

Todos los sistemas intermedios-09-00-2B-00-00-05-La dirección de multicast

"Todos los sistemas intermedios" utilizada por ISO 9542

All End Systems-09-00-2B-00-00-04-La dirección multicast "Todos los sistemas

finales" utilizada por ISO 9542

El intervalo de saludo predeterminado para el DIS es tres veces más rápido (es decir, tres

veces menor) que el intervalo de los otros enrutadores para que los fallos de DIS puedan

detectarse rápidamente.

Un vecino es declarado muerto si los saludos no son recibidos dentro del tiempo de

espera. El tiempo de espera se calcula como el producto del multiplicador hello y el tiempo

de hello. El tiempo predeterminado es 10 segundos, y el multiplicador por defecto es tres;

Por lo tanto, el tiempo de espera predeterminado es de 30 segundos.

A diferencia de las interfaces LAN con niveles IIHs independientes de Nivel 1 y 2, los

enlaces punto a punto tienen un formato IIH punto a punto común que especifica si el

saludo se relaciona con Nivel 1 o Nivel 2 o ambos. Los saludos de punto a punto se envían

a la dirección de unidifusión del enrutador conectado; Por lo tanto, es relativamente más

eficiente en relación con otros enlaces WAN.

104

Inundaciones de paquetes de estado de enlace IS-IS

Como protocolo de enrutamiento de estado de enlace, IS-IS normalmente necesita

actualizar la información de topología y propagar la actualización / cambio a otros vecinos

IS-IS. Para lograr esto, un sistema intermedio origina sus propios LSPs (uno para el Nivel 1

y otro para el Nivel 2). Estos LSPs se identifican por el ID del sistema origen y un número

de fragmento LSP que empieza en 0. Si un LSP excede al MTU, el LSP se fragmenta en

varios LSPs, numerados 1, 2, 3 y así sucesivamente.

Sin embargo, no cada LSP inundado es considerado por IS-IS, porque cuando un sistema

intermedio recibe un LSP, examina la suma de comprobación y descarta cualquier LSP no

válido, inundándolos con una edad de vida vencida. Si el LSP es válido y más reciente que

el que está actualmente en el LSDB, se conserva, reconoce y se le da una vida útil de 1200

segundos. La edad se decrementa cada segundo hasta que alcanza 0, momento en el que se

considera que el LSP ha expirado. Cuando el LSP ha expirado, se mantiene durante 60

segundos adicionales antes de que se inunde como LSP caducado.

Sincronización LSDB de IS-IS

Hay dos tipos de paquetes de números de secuencia (SNPs): PDU de número de secuencia

completo (CSNP) y PDU de número de secuencia parcial (PSNP). El uso de SNPs difiere

entre punto a punto y medios de difusión. CSNPs y PSNPs comparten el mismo formato; Es

decir, cada uno lleva información resumida de LSP. Sin embargo, la principal diferencia

105

técnica es que CSNPs contienen resúmenes de todos los LSPs en el LSDB "SNP completo",

mientras que PSNPs contienen sólo un subconjunto de entradas LSP "SNP parcial".

CSNPs y PSNPs separados se utilizan para adyacencias de nivel 1 y nivel 2. Los

enrutadores IS-IS adyacentes intercambian CSNPs para comparar su LSDB. En las

subredes de difusión, sólo el DIS transmite CSNP. Todos los vecinos adyacentes comparan

los resúmenes de LSP que se reciben en el CSNP con los contenidos de sus LSDB locales

para determinar si sus LSDB están sincronizados (en otras palabras, si tienen las mismas

copias de LSP que otros enrutadores para los niveles apropiados y el área de

Enrutamiento).

Los CSNPs son multicast periodicos (cada 10 segundos) enviados por el DIS en una LAN

para garantizar la precisión LSDB. Si hay demasiados LSPs para incluir en un CSNP, los

LSPs se envían en rangos. El encabezado CSNP indica el ID LSP inicial y final en el

intervalo. Si todos los LSPs encajan en el CSNP, el rango se establece en los valores

predeterminados.

Los enrutadores IS-IS adyacentes usan PSNP para reconocer la recepción de LSPs y para

solicitar la transmisión de los LSPs perdidos o nuevos. En las redes punto a punto, los

CSNP se envían solo una vez, cuando el enlace llega para sincronizar los LSDB. Después de

eso, LSPs se envían para describir los cambios de topología, y se reconocen con un PSNP.

106

CONSIDERACIONES DE DISEÑO IS-IS

En esta sección se describen varias consideraciones de diseño de enrutamiento IS-IS sobre

las siguientes topologías:

Hub-and-spoke sobre NBMA

Malla completa

Plano

Jerárquico

Descripción general de la lógica de enrutamiento IS-IS

El enrutamiento dentro de un área (L1) implica la recolección de identificadores de

sistema y adyacencias para todos los enrutadores en un área y el uso del algoritmo de

Dijkstra para calcular las mejores rutas entre los dispositivos. Los enrutadores de nivel 1

sólo son conscientes de la topología de área local. Pasan el tráfico que se destina para

viajar fuera del área al enrutador más cercano del nivel 1-2.

El enrutamiento entre áreas se basa en la dirección del área. Los enrutadores de nivel 2 en

diferentes áreas intercambian información de direcciones de área y utilizan el algoritmo

de Dijkstra para calcular los mejores caminos entre áreas. Pasan el tráfico entre las áreas

al enrutador más cercano del nivel 1-2 en el área de destino.

Los paquetes ESH e ISH se utilizan para que los enrutadores (sistemas intermedios) y los

sistemas finales se detecten entre sí. Cuando se requiere que un host envíe un paquete a

107

otro host, el paquete pasa a uno de los enrutadores de una red que está directamente

conectada al host. Si el host de destino está en la misma área, el enrutador busca el ID del

sistema de destino y reenvía el paquete adecuadamente a lo largo de la mejor ruta.

Si la dirección de destino es un host en otra área, el enrutador de Nivel 1 envía el paquete

al enrutador de nivel 1-2 más cercano. El reenvío a través de los enrutadores de Nivel 2

continúa hasta que el paquete alcanza un enrutador Nivel 2 (o Nivel 1-2) en el área de

destino. Dentro del área de destino, los enrutadores reenvían el paquete a lo largo de la

mejor ruta hasta que se llega al host de destino.

En el mundo IP, al ejecutar IS-IS integrado, la información IP se incluye en los LSPs. La

accesibilidad IP se comporta en IS-IS como si fuera información del sistema final (ES). Es

importante señalar que la información IP no toma parte en el cálculo del árbol SPF; es

simplemente información sobre las conexiones de la hoja con el árbol. Por lo tanto, la

actualización de la accesibilidad IP es sólo un cálculo de ruta parcial (PRC).

Las rutas IP se generan mediante el cálculo parcial y se colocan en la tabla de

enrutamiento IP. Las rutas pueden ser aceptadas en la tabla de enrutamiento o

rechazadas, basadas en las reglas generales de los procesos de enrutamiento, la distancia

administrativa de línea o la máscara de red. Cuando las rutas lleguen a la tabla de

enrutamiento, se mostrarán como rutas de Nivel 1 o Nivel 2, según corresponda.

Basándose en la lógica descrita, IS-IS se considera generalmente "hasta cierto punto" más

estable y escalable que OSPF; la razón es que la separación de la accesibilidad IP de la

arquitectura de red IS-IS de núcleo da a IS-IS integrado es mejor estabilidad y

escalabilidad que OSPF. Específicamente, OSPFv2 envía LSAs para subredes IP

individuales. Si una subred IP falla, el LSA se inunda a través de la red y, en todas las

circunstancias, todos los enrutadores deben ejecutar un cálculo SPF completo. Por el

contrario, OSPFv3 ha añadido nuevos tipos de LSA (Tipo 8 y Tipo 9) que muestran un

comportamiento similar al de IS-IS, donde la información de accesibilidad no se lleva en el

enrutadores LSA.

En comparación, en una red IS-IS integrada, el árbol SPF se construye a partir de

información CLNS. Si una subred IP falla en IS-IS integrado, el LSP se inunda como en

OSPF. Sin embargo, si la subred fallida es una subred IP de hoja (es decir, la pérdida de la

subred no ha afectado a la arquitectura CLNS subyacente), el árbol SPF no se afecta y, por

lo tanto, sólo ocurre un cálculo parcial, lo que tiene un impacto significativamente menor

en los recursos del enrutador.

Fugas de Ruta (Route Leaking)

Los enrutadores de Nivel 1 dentro de un área IS-IS, de forma predeterminada, no

transportan información de enrutamiento ajeno al área a la que pertenecen. Por lo tanto,

108

los enrutadores de nivel 1, para salir del área y alcanzar cualquier prefijo fuera del área

local, usan una ruta predeterminada inyectada por los enrutadores de frontera L1 / L2.

Aunque esta configuración es deseable por razones de escalabilidad, interfiere con el

enrutamiento BGP y MPLS y MPLS-VPN, donde todas las direcciones BGP de próximo salto

deben estar presentes en la tabla de enrutamiento local.

Además, el enrutamiento asimétrico puede causar un uso subóptimo de los recursos de

red, ya que el tráfico utiliza diferentes rutas desde la fuente hasta el destino y viceversa.

Esta situación hace que la solución de los problemas potenciales relacionados con la red

sea más difícil. También puede afectar algunas aplicaciones sensibles al retardo, como

VoIP.

IS-IS admite una característica que se denomina fuga de ruta (route leaking), en la cual las

rutas seleccionadas de Nivel 2 pueden ser anunciadas por un enrutador Nivel 1 / Nivel 2

en el Nivel 1. Estas rutas están marcadas especialmente para que no se vuelvan a publicar

en el Nivel 2 por otro enrutador Nivel 1 / Nivel 2.

Con más detalles sobre rutas interarea, un enrutador de nivel 1 es capaz de hacer una

mejor elección sobre qué enrutador de nivel 1-2 debe recibir el paquete. Las fugas de ruta

se llaman rutas interárea en la tabla de enrutamiento y en la base de datos IS-IS. Al ver la

tabla de enrutamiento, todas las rutas fugadas están marcadas con una designación "ia".

Para implementar la filtración de ruta en los enrutadores L1 / L2, un bit ascendente /

descendente en el TLV indica si se ha filtrado la ruta que se identifica en el TLV. Si el bit

ascendente / descendente está en 0, la ruta se originó dentro de esa área de Nivel 1. Si el

bit ascendente / descendente está en 1, la ruta ha sido redistribuida en el área desde el

nivel 2. El bit ascendente / descendente se utiliza para evitar bucles de enrutamiento; un

enrutador de Nivel 1-2 no vuelve a anunciar, en el Nivel 2, las rutas de Nivel 1 que tengan

109

el bit ascendente / descendente establecido en el 1. Para que una ruta se fugue, ya debe

estar presente en la tabla de enrutamiento como una ruta Nivel 2.

La fuga de rutas debe ser planificada y desplegada cuidadosamente para evitar una

situación en la cual cualquier cambio de topología en un área hace necesario recalcular

múltiples rutas en todas las otras áreas.

Enrutamiento simétrico versus asimétrico de IS-IS

El enrutamiento asimétrico (donde los paquetes toman caminos diferentes, en direcciones

diferentes) no es perjudicial para la red. Sin embargo, este tipo de enrutamiento puede

dificultar la resolución de problemas y, a veces, es un síntoma de un diseño subóptimo que

110

puede afectar el rendimiento de una aplicación y la calidad de la experiencia de los

usuarios.

Enrutamiento de IS-IS en una red de malla completa

111

Una gran malla completa NBMA puede resultar en posibles problemas de rendimiento y

escalabilidad. Las inundaciones excesivas en estos entornos pueden limitarse agrupando

subinterfaces en grupos de malla. Los grupos de malla están diseñados para optimizar la

inundación a través de redes de una malla grande incluyendo grandes nubes NBMA con

muchas conexiones punto a punto. La idea básica detrás de los grupos de malla es que

cada miembro del grupo de malla no vuelva a inundar con los LSPs, que son recibidos de

otro miembro del grupo, a otros miembros del mismo grupo porque ya habrían recibido

copias. Sin embargo, los LSP que se reciben de enrutadores no miembros se inundan a

todos los miembros del grupo de malla, y otros no miembros adyacentes.

Desde el punto de vista del diseño, las redes de malla completa son las más costosas y

complejas de mantener y escalar. Topologías de malla completa son más comúnmente

utilizadas en las redes empresariales para interconectar un pequeño número de

enrutadores principales.

Además, en las redes NBMA, como una nube ATM en la que todos los enrutadores están

completamente acoplados con circuitos virtuales, la red completa permite que la nube sea

modelada como enlace de difusión y configurada como tal para trabajar con IS-IS. El

problema con este modelo es que la nube de ATM de malla completa no tiene las

capacidades completas de difusión de una tecnología de difusión multipunto, como

Ethernet. Cuando cualquiera de los circuitos virtuales (VCs) falla, se pierde la conectividad

any-to-any, rompiendo el modelo de inundación.

Diseño de enrutamiento plano IS-IS

Un diseño plano IS-IS elimina la capacidad de reducir la cantidad de información de

enrutamiento en una sola área o nivel, así como evita la posibilidad de ocultar la

información de topología. Esto puede conducir a un nivel reducido de escalabilidad y

estabilidad en las redes a gran escala. Sin embargo, una red IS-IS, pequeña y sencilla,

puede inicialmente desplegarse como una sola área (red no jerárquica). Incluso entonces,

112

es muy probable que desee determinar de antemano cuando será necesario migrar a una

topología jerárquica. Pasar a un modelo jerárquico depende de muchos factores como, por

ejemplo, el número de enrutadores, la dispersión geográfica de la red, los tipos de enlaces,

la estabilidad del enlace, etc.

Al pasar a una topología jerárquica con múltiples áreas, puede contener la inundación de

LSPs dentro del área. Esta situación no le impide configurar algunas áreas como L2 sólo en

ciertos diseños, lo que puede ahorrarle la potencia de procesamiento de la CPU, si es

necesario.

Debido a que tener una sola área derrota el propósito de tener un enrutamiento de dos

niveles, puede desplegar su red como una red sólo L1 o sólo L2. La forma recomendada de

desplegar estas redes es desplegar una red de sólo L2 desde el principio, lo que facilita la

adición de áreas futuras y garantiza la conectividad de la red troncal desde el principio.

Aunque técnicamente puede iniciar su diseño con enrutadores L1-L2, dándoles la

capacidad de escalar la red en el futuro sin un rediseño mayor, todos los enrutadores

llevarán a cabo dos bases de datos de las que no se aprovechará, ya que sólo pondrán una

carga innecesaria adicional en los enrutadores.

En enrutadores Cisco, el comportamiento es tal que tanto el enrutamiento nivel 1 como el

nivel 2 están habilitados de forma predeterminada. Si desea hacer su red L1 solamente o

L2 solamente, la configuración adicional es necesaria en el enrutador.

Diseño IS-IS jerárquico

Al igual que OSPF, IS-IS soporta naturalmente dos capas de redes jerárquicas. Sin

embargo, los diseñadores de redes todavía pueden usarlo en redes con una jerarquía de

tres capas. Además, como IS-IS soporta la capacidad de superposición entre los dominios

de inundación IS-IS (niveles), ofrece un diseño más flexible con respecto al enrutamiento

óptimo en comparación con OSPF en red con múltiples niveles.

113

Resumen de Rutas IS-IS

El principal objetivo del resumen de rutas es reducir el número de prefijos IP anunciados

entre dominios de enrutamiento. Un dominio de enrutamiento podría ser un área OSPF o

un nivel IS-IS. En otras palabras, el resumen de ruta permite ocultar una información de

topología más detallada y establece un límite para contener cualquier cambio de red. De

esta manera, los diseñadores de redes pueden lograr un diseño de enrutamiento más

escalable, estable y de convergencia rápida porque reduce técnicamente el número de

enrutadores que se ven afectados por cualquier cambio de topología. Esto ayuda a reducir

la carga de procesamiento y el tiempo de convergencia de red después de cualquier evento

de fallo.

Sin embargo, uno de los factores principales que determina qué tan bien un IGP escala es

el diseño de direccionamiento que se planifica en la arquitectura de red. Un esquema de

direccionamiento incorrecto desde la perspectiva de resumen, que se utiliza en el diseño

de su red y en las primeras fases de la implementación, podría causar problemas de escala

más adelante. Como resultado, la red puede encontrar dificultades para escalar más y los

dispositivos pueden terminar utilizando más recursos de hardware (procesamiento de

CPU, memoria) de lo necesario.

114

Para IP, puede resumir sólo las rutas IS-IS nativas en el Nivel 2 de la base de datos de Nivel

1. No es posible resumir las rutas internas IS-IS en el Nivel 1, aunque es posible resumir

rutas externas (redistribuidas) en el Nivel 1.

Los conceptos clave para el resumen de rutas IP en IS-IS son los siguientes:

Las rutas internas se pueden redistribuir y resumir desde el Nivel 1 hasta el Nivel

2. El resumen debe configurarse en el enrutador Nivel 1 / Nivel 2, que inyecta las

rutas Nivel 1 en el Nivel 2.

Si se está utilizando el resumen, todos los enrutadores Nivel 1 / Nivel 2 en un área

deben resumirse en el backbone. Si uno de ellos está anunciando rutas más

específicas, todo el tráfico del backbone será enviado hacia este enrutador debido

al enrutamiento de coincidencia más larga.

Las rutas internas no se pueden resumir en el Nivel 1 porque esta acción no está

permitida por el protocolo.

Es posible resumir rutas externas (redistribuidas) en el nivel 1.

Además, también puede resumirse en la otra dirección, en la capa de distribución desde el

núcleo, hacia abajo, hacia la capa de acceso. Normalmente, los dispositivos de acceso que

se conectan a una capa de distribución (o directamente al núcleo) sólo requieren una ruta

predeterminada. En otros escenarios, como el homing dual, puede ser necesario tomar las

medidas apropiadas para evitar cualquier potencial de selección de trayectoria subóptima.

En este ejemplo, puede ver que prácticamente todos los prefijos de núcleo se resumen en

un anuncio, que es la ruta predeterminada. Esto se muestra como un prefijo de todos los

0s (0.0.0.0/0). Esto ayuda a reducir la carga en los nodos de acceso (LSDB más pequeños)

y también facilita que el tiempo de convergencia de red sea más rápido.

IS-IS integrado para IPv6

115

Cisco ha añadido soporte multitopológico a IS-IS para aumentar la flexibilidad en la

implementación de IS-IS en un entorno de doble pila. Dos TLV se agregan en IS-IS para

soporte IPv6. Estos dos TLV se utilizan para describir la accesibilidad IPv6 y las

direcciones de interfaz IPv6:

Alcance IPv6 TLV (0xEC o 236):

o Describe la accesibilidad de la red (prefijo de enrutamiento, métrica,

opciones).

o Equivalente a TLVs de accesibilidad interna y externa IPv4 (tipo código 128

y 130).

Dirección de interfaz IPv6 TLV (0xE8 o 232):

o Equivalente a la dirección de interfaz IPv4 TLV (código de tipo 132).

o Para hola PDUs, que debe contener la dirección local de enlace.

o Para LSPs, que debe contener únicamente la dirección local no vinculada.

El TLV compatible con el protocolo (código de tipo 129) muestra los NLPID soportados.

Todos los enrutadores IS-IS con IPv6 activado anuncian un valor NLPID de 0x8E (142). El

NLPID de IPv4 es 0xCC (204).

La Multitopología en IS-IS proporciona cierta flexibilidad cuando se está realizando la

transición a IPv6. Se mantiene una topología independiente para las redes IPv4 e IPv6;

Porque algunos enlaces pueden no ser capaces de llevar IPv6, IS-IS específicamente

mantiene un seguimiento de esos enlaces, minimizando la posibilidad de que el tráfico sea

"black-holed".

Una sola topología en IS-IS, donde hay una instancia SPF para IPv4 e IPv6, también sigue

siendo una posibilidad que es aún más fácil de administrar, pero la red debe ser

homogénea. Los mismos enlaces deben transmitir IPv4 e IPv6 simultáneamente.

Restricciones de IS-IS de una sola topología

Al migrar de un entorno IPv4 a un entorno de doble pila, una discrepancia en los

protocolos soportados causaría fallas en las adyacencias. El sistema intermedio realiza

comprobaciones de coherencia en los paquetes de saludo y rechazará los paquetes de

saludo que no tengan el mismo conjunto de familias de direcciones configuradas. Por

ejemplo, un enrutador que ejecuta IS-IS para IPv4 e IPv6 no forma una adyacencia con un

enrutador que ejecute IS-IS para IPv4 o IPv6 solamente. Por lo tanto, para facilitar una

actualización continua, el ingeniero debería considerar inhabilitar las comprobaciones de

consistencia durante la actualización para mantener las adyacencias activas incluso en un

entorno heterogéneo.

116

La supresión de la verificación de adyacencia en los enlaces intra-área (enlaces de capa 1)

se realiza principalmente durante la transición de las redes IS-IS de una sola topología

(IPv4) a multitopología (IPv4 e IPv6). Imagine que un proveedor de servicios está

integrando IPv6 en una red y no es práctico apagar todo el enrutador del proveedor

configurado para una actualización coordinada. Sin deshabilitar la comprobación de

adyacencia, ya que los enrutadores estaban habilitados para IPv6 y IS-IS para IPv6, las

adyacencias caerían con los enrutadores IPv4 y el enrutamiento IPv4 se vería gravemente

afectado. Con la supresión de comprobación constante, IPv6 se puede subir sin afectar la

accesibilidad IPv4.

Como en cualquier diseño de red IS-IS, los enrutadores de nivel 2 (backbone) deben ser

contiguos. Las verificaciones de adyacencia IPv6 no se realizan en los enlaces de nivel 2.

Multitopología IS-IS para IPv6

117

El soporte multitopológico para IPv6 permite a IS-IS mantener un conjunto de topologías

independientes dentro de una única área o dominio. Este modo elimina la restricción de

que todas las interfaces en las que está configurado IS-IS deben admitir el conjunto

idéntico de familias de direcciones de red. También elimina la restricción de que todos los

enrutadores del área IS-IS (para el enrutamiento de nivel 1) o del dominio (para el

enrutamiento de nivel 2) deben admitir el mismo conjunto de familias de direcciones de la

capa de red. Además, con este enfoque de diseño, se realiza un SPF separado para cada

topología configurada. Por lo tanto, es suficiente que la conectividad exista entre un

subconjunto de los enrutadores en el área o el dominio para que una familia de

direcciones de red dada pueda ser enrutada.

Cuando se utiliza soporte multitopológico para IPv6, utilice la métrica amplia porque los

TLV que se utilizan para anunciar información IPv6 en LSP se definen para utilizar

únicamente métricas amplias.

Todos los enrutadores en el área o dominio deben utilizar el mismo tipo de soporte IPv6,

ya sea una sola topología o multitopología. Un enrutador que está operando en modo

multitopología no reconocerá la capacidad del enrutador de modo de una sola topología

para dar soporte al tráfico IPv6, lo que conducirá a los agujeros de enrutamiento en la

topología IPv6. Para pasar del soporte de una sola topología al soporte multitopológico

más flexible, puede implementar un modo de transición multitopológica. En los escenarios

de migración en los que es necesario trasladar el diseño de mono a multitopológico, debe

considerar el modo de transición de multitopología. El modo de transición de

multitopológia permite que una red que esté operando en modo de soporte IPv6 IS-IS de

una sola topología continúe trabajando mientras se actualizan los enrutadores para incluir

la compatibilidad con IPv6 IS-IS multitopológica. En modo de transición, ambos tipos de

TLV (topología única y multitopologíca) se envían en LSP para todas las direcciones IPv6

118

configuradas, pero el enrutador sigue funcionando en modo de una sola topología.

Después de que todos los enrutadores del área o del dominio se hayan actualizado para

soportar IPv6 multitopológica y estén operando en modo de transición, el modo de

transición se puede eliminar de las configuraciones del enrutador.

PENSAMIENTOS FINALES SOBRE EL DISEÑO DE

ENRUTAMIENTO IS-IS

IS-IS no admite directamente el tipo de redes NBMA; Por lo tanto, debe considerar el uso

de un modelo de red broadcast o punto a punto cuando se trata de redes NBMA, como

frame relay o ATM, dependiendo de las características de la red, como la escala de la red,

el ancho de banda disponible, las aplicaciones transferidas, la WAN, y cómo cada tipo de

red puede afectar cualquiera de estos elementos.

Además, es técnicamente válido considerar la construcción de redes IS-IS planas (no

jerárquicas) o un diseño jerárquico. Sin embargo, desde el punto de vista del diseño, la

decisión de diseño ideal debe ser impulsada por diferentes variables técnicas y no

técnicas, tales como la dirección de la empresa y los planes futuros (tales como planes de

expansión) para determinar el tamaño objetivo de la red. Cuando hablamos de un diseño

plano de IS-IS, el diseño involucra sólo un área, por lo que no es necesario un

enrutamiento de dos niveles. Esta es la arquitectura más sencilla que facilita el diseño de

otros protocolos de red y aplicaciones como MPLS-TE y MPLS-VPN en entornos de red

MPLS. Sin embargo, no escala tan bien como el diseño jerárquico. Por esta razón, siempre

es beneficioso diseñar su red con la jerarquía en mente.

En el diseño IS-IS jerárquico, hay múltiples áreas a considerar, así como el

posicionamiento del backbone dentro de la red para pegar las múltiples áreas juntas. Por

lo tanto, el uso de enrutamiento de nivel 2 es crucial en las redes jerárquicas dentro del

backbone. Además, el resumen de rutas hacia el núcleo (backbone) es muy importante en

el diseño de una red IS-IS jerárquica estable y escalable; Por lo tanto, idealmente, se

requiere un diseño muy cuidadoso y estructurado del esquema de direccionamiento IP

dentro de las áreas y globalmente a través de todo el dominio de enrutamiento. Con este

enfoque, el resumen de rutas ofrecerá la capacidad de ocultar las inestabilidades dentro

de una región problemática (área / nivel) del resto de la red.

Aunque la fuga de rutas ayuda a evitar algunos problemas de enrutamiento subóptimos y

a superar las complejidades de solución de problemas, idealmente, los requisitos de las

aplicaciones deberían conducir si se requiere o no un direccionamiento óptimo. Esto, a su

vez, conduce la decisión si usted necesita considerar el enrutamiento que fuga o no.

119

Además, de la sección anterior, usted sabe que considerar la multitopología IS-IS elimina

las restricciones y limitaciones que puede enfrentar al usar la topología única IS-IS. Por lo

tanto, se recomienda considerar IS-IS multitopología si hay alguna necesidad actual o

futura de usar IPv6.

Por lo tanto, cuando está diseñando un enrutamiento IS-IS y construyendo la red desde

cero, es muy importante tener en cuenta los puntos clave de diseño mencionados

anteriormente. La razón es que, después de que la red se ha puesto en funcionamiento,

puede ser difícil hacer grandes cambios, y que podría verse obligado a hacer concesiones y

soluciones. Tales concesiones hacen su red innecesariamente más compleja como

resultado.

120

Capítulo 5

Diseño de BGP

121

DESCRIPCIÓN DE BGP

BGP, como se define en los RFCs 1163 y 1267, es un protocolo de puerta de enlace externa

(EGP). Le permite configurar un sistema de enrutamiento interdominio que garantiza

automáticamente el intercambio de información de enrutamiento sin bucle entre sistemas

autónomos.

Cualquier ruta BGP típica consiste de lo siguiente:

Un número de red

Una lista de sistemas autónomos por los que ha pasado la información (llamada

ruta del sistema autónomo)

Una lista de otros atributos de ruta

Como cualquier protocolo de enrutamiento dinámico, el objetivo principal de BGP es

intercambiar información de accesibilidad de red con otros sistemas BGP. A diferencia de

los IGP, BGP también pasa información sobre la lista de rutas de sistema autónomo de

cada ruta; por ello, es denominado protocolo de vector de trayecto (path-vector).

BGP puede utilizar la lista de sistemas autónomos asociados a cada ruta para construir

una gráfica de conectividad de sistema autónomo desde la cual se pueden podar los bucles

de enrutamiento y determinar qué decisiones de política a nivel de sistema autónomo

pueden ser impuestas.

Una dirección de enrutador de salto siguiente se utiliza en el atributo NEXT_HOP,

independientemente del sistema autónomo de ese enrutador. El software Cisco IOS calcula

automáticamente el valor de este atributo.

Dos enrutadores que forman una conexión TCP para intercambiar información de

enrutamiento BGP se denominan en términos BGP como pares o vecinos.

Los vecinos BGP intercambian información de enrutamiento completa cuando se establece

por primera vez la conexión TCP entre vecinos. Cuando se detectan cambios en la tabla de

enrutamiento, los enrutadores BGP envían únicamente a sus vecinos las rutas que han

cambiado. Además, de forma predeterminada, cada hablante BGP sólo anuncia la ruta

óptima a una red de destino desde su punto de vista.

Tipos de hablantes BGP

Como un protocolo de enrutamiento intra e interdominio, BGP puede ofrecer flexibilidad a

diferentes sistemas autónomos interconectados (AS).

122

Para poder enviar la información a AS externos, debe haber una garantía de la

accesibilidad de estas redes. Para garantizar la accesibilidad de la red, BGP utiliza un tipo

diferente de hablante y de sesión BGP:

BGP Interno (iBGP) asociación entre enrutadores dentro de un AS

BGP Externo (EBGP) asociación entre enrutadores en el borde de los sistemas

autónomos adyacentes.

Cuando BGP se ejecuta entre enrutadores que pertenecen a dos AS diferentes, esto se

llama EBGP. Cuando BGP se ejecuta entre enrutadores en el mismo AS, esto se llama iBGP.

En las redes BGP a gran escala, con un gran número de hablantes iBGP, tener una malla

completa de sesiones iBGP entre los hablantes BGP introduce varias preocupaciones y

limitaciones de diseño, como escalabilidad de la red, flexibilidad operativa y simplicidad.

Reglas de prevención de bucle y horizonte dividido en BGP

En el enrutamiento interior, el anuncio de rutas con horizonte dividido es un método para

evitar bucles de enrutamiento en protocolos vector de distancia al prohibir que un

enrutador anuncie una ruta de regreso a la interfaz desde la que se aprendió. En BGP, el

horizonte dividido se aplica de una manera ligeramente diferente, con el uso de

mecanismos adicionales. BGP tiene dos formas de hablantes, EBGP e IBGP, y cada uno

utiliza diferentes mecanismos para evitar bucles de enrutamiento. EBGP se basa en el

camino AS para evitar bucles.

En contraste, técnicamente no hay manera de saber si una ruta que se anuncia a través de

varios hablantes IBGP es un bucle. Debido a que los pares de IBGP están en el mismo AS,

no añaden nada al camino AS; Por lo tanto, no se debe volver a anunciar las rutas que se

aprenden a través de IBGP a otros compañeros de IBGP.

123

En IBGP, la regla de horizonte dividido obliga a que las actualizaciones recibidas en las

sesiones EBGP se reenvíen en todas las sesiones IBGP y EBGP, mientras que las

actualizaciones que se reciben en una sesión IBGP deben ser enviadas solamente en todas

las sesiones EBGP.

Atributos de ruta BGP y Selección del Mejor Camino

Las rutas aprendidas a través de BGP tienen propiedades asociadas que se utilizan para

determinar la mejor ruta a un destino cuando existen múltiples rutas de acceso. Estas

propiedades se denominan atributos de ruta BGP. En general, los atributos de ruta BGP

tienen tres categorías:

Obligatorio bien conocido: Se deben adjuntar tres atributos obligatorios bien

conocidos específicos a cada mensaje de actualización: Next-hop, AS-PATH y

Origen.

124

Conocido discrecional: Estos atributos pueden ser presentados, pero no son

obligatorios; Incluyen preferencia local BGP y Atomic aggregate. En otras palabras,

BGP considera estos atributos sólo cuando se requiere su función.

Opcional: Cuando un hablante BGP recibe una actualización BGP con atributos

opcionales, el hablante BGP verificará si puede reconocer el atributo opcional

adjunto. Si lo hace, el hablante BGP maneja ese atributo en consecuencia. Sin

embargo, si el hablante BGP no es capaz de identificar el atributo adjunto, mira en

el bit transitivo en el atributo. Los atributos de ruta de acceso opcional BGP se

pueden categorizar en dos tipos basados en este bit:

o Transitivo: este tipo de hablante BGP propaga este atributo opcional

incluso si no reconoce el atributo. Lo hace porque el atributo podría ser útil

para otros hablantes BGP a lo largo del camino, como los valores de la

comunidad BGP.

o No transitivo: Si el tipo de hablante BGP no puede reconocer el atributo

opcional, no lo propagará, por ejemplo, el discriminador BGP de salida

múltiple. Además, los atributos BGP Originator ID y Cluster-List utilizados

para evitar el bucle en el diseño de la reflexión de enrutamiento BGP se

consideran atributos no transitivos opcionales; Estos atributos se tratan

más adelante en este capítulo.

Cómo BGP selecciona los caminos

Desde el punto de vista de iBGP, un router que ejecute IOS Cisco, no selecciona ni utiliza

una ruta iBGP a menos que se cumplan las siguientes dos condiciones:

1. El enrutador tiene una ruta disponible para el siguiente salto.

2. El enrutador ha recibido sincronización a través de un IGP (a menos que se haya

desactivado la sincronización IGP, que está desactivada de forma predeterminada

en las nuevas versiones de software de Cisco).

En general, BGP basa su proceso de decisión en los valores de los atributos. Cuando se

enfrentan a múltiples rutas al mismo destino, BGP elige la mejor ruta para encaminar el

tráfico hacia el destino. El siguiente proceso resume cómo BGP elige la mejor ruta.

1. Si el siguiente salto es inaccesible, no lo considera. Esta decisión es la razón por la

que es importante tener una ruta IGP para el próximo salto.

2. Si la ruta es interna, la sincronización está habilitada y la ruta no está en el IGP, no

considera la ruta.

3. Prefiere la trayectoria con el peso (weight) más grande (el peso es un parámetro

propio de Cisco).

4. Si las rutas tienen el mismo peso, prefieren la ruta con la mayor preferencia local.

5. Si las rutas tienen la misma preferencia local, prefiere la ruta que fue originada por

el enrutador local.

125

6. Si la preferencia local es la misma o si el enrutador local no ha originado ninguna

ruta, prefiere la ruta con la ruta del sistema autónomo (AS path) más corta.

7. Si la longitud del trayecto del sistema autónomo es la misma, preferir la ruta con el

código de origen más bajo (IGP <EGP <INCOMPLETE).

8. Si los códigos de origen son los mismos, prefieren la ruta con el atributo métrico

MED más bajo. Esta comparación se realiza sólo si el sistema autónomo vecino es el

mismo para todas las rutas consideradas, a menos que el comando de

configuración router bgp always-compare-med esté habilitado.

9. Prefiere la ruta externa BGP (eBGP) sobre la ruta iBGP. Todos los caminos de

confederación son considerados caminos internos.

10. Prefiere la ruta que se puede alcanzar a través del vecino IGP más cercano (la

métrica IGP más baja). El enrutador preferirá el camino interno más corto dentro

del sistema autónomo para alcanzar el destino (el camino más corto al salto

siguiente de BGP).

11. Si las siguientes condiciones son todas verdaderas, inserte la ruta para este camino

en la tabla de enrutamiento IP:

a. Tanto la mejor ruta como esta ruta son externas.

b. Tanto la mejor ruta como esta ruta son del mismo sistema autónomo vecino.

c. El comando de configuración del enrutador maximum-paths está habilitado.

12. Si multipath no está habilitado, prefiera la ruta con el valor de dirección IP más

bajo para el ID de enrutador BGP. El ID de enrutador suele ser la dirección IP más

alta en el enrutador o en la dirección loopback (virtual), pero puede ser específica

de la implementación. La mejor práctica es configurar manualmente la ID del

enrutador.

DISEÑO DE REDES ESCALABLES IBGP

Limitaciones de escalabilidad de iBGP

BGP puede proporcionar una interconexión controlada entre múltiples dominios de

enrutamiento que pueden ejecutar diferentes IGP y también puede soportar MPLS VPN.

Por diseño, IBGP requiere una malla completa de pares BGP para funcionar.

El comportamiento típico del protocolo BGP es que los hablantes IBGP no vuelvan a

anunciar rutas que se aprenden a través de compañeros IBGP a otros compañeros IBGP.

Esto es para evitar que la información circule entre los enrutadores hablantes de IBGP en

un ciclo o bucle de información de enrutamiento. Por lo tanto, una malla completa de

126

sesiones IBGP entre enrutadores es necesaria para propagar toda la información de

enrutamiento a todos los pares IBGP en un AS BGP.

La principal preocupación con el enfoque de sesiones de asociaciones IBGP de malla

completa es que la malla completa puede llegar a ser inmanejable, debido a la gran

sobrecarga administrativa de mantener muchas sesiones y políticas BGP. Por lo tanto, este

enfoque no escala a medida que la red crece.

En general, para n pares en una malla completa de IBGP, cada enrutador tendría (n - 1)

pares. Hay n * (n - 1) / 2 asociaciones en total, lo que significa que cada par necesitaría la

CPU, la memoria y el ancho de banda para administrar las actualizaciones y el estado de

los pares para todos los demás enrutadores. Es por eso que este diseño "plano y no

estructurado" de malla completa no es rentable para escalar a redes grandes.

Por ejemplo, un enrutador con un BGP AS que contiene 50 enrutadores requiere (50 * (50

- 1)) / 2 = 1225 sesiones IBGP. Imagine el número de sesiones (y la configuración de

enrutador asociada) que se requeriría para un AS único que contenga 1000 routers.

BGP tiene los siguientes enfoques primarios para escalar IBGP y para superar las

deficiencias de IBGP diseño de malla completa:

Los reflectores de ruta BGP (RR)

Confederaciones BGP

Soluciones de Escalabilidad IBGP

Aunque la confederación de BGP es más comúnmente utilizada en tipos de redes de

proveedores de servicios a gran escala (tales como proveedores de servicios globales y

redes de proveedores de servicios bajo diferentes autoridades administrativas), también

es una solución válida para redes empresariales de gran escala. Sin embargo, BGP Route

Reflector (RR) ofrece una solución más flexible y simplificada a las redes de grado

empresarial para superar las limitaciones de las redes IBGP.

Reflectores de ruta BGP

El comportamiento natural de IBGP es que un enrutador regular de IBGP no está

autorizado a volver a anunciar ninguna ruta IBGP que aprenda de sus compañeros IBGP.

Cuando se introduce un tipo especial de nodo IBGP, esta regla puede ser relajada; y se

denomina reflector de ruta.

El reflector de la ruta BGP (RR) es un hablante IBGP que refleja o vuelve a anunciar rutas

que se aprenden de los compañeros de IBGP a algunos de sus otros compañeros IBGP

modificando la clásica regla de horizonte dividido. En otras palabras, el BGP RR facilita a

un enrutador en particular (hablante IBGP) que envíe las actualizaciones IBGP entrantes a

127

una sesión IBGP saliente bajo ciertas condiciones. Este comportamiento hace que el

enrutador RR sea el punto focal para sesiones IBGP y actualice dentro de un AS BGP. Por lo

tanto, se denomina reflector de ruta. Esto, a su vez, ayuda a escalar las redes BGP para

manejar pares y sesiones IBGP a gran escala sin añadir complejidad a la capacidad de

administración y flexibilidad de la red.

En general, la reflexión de la ruta es un proceso en un enrutador reflector de ruta. Implica

re- publicar las rutas recibidas de un vecino específico a otros. Desde una vista de punto

de diseño, para implementar correctamente reflectores de ruta en su red BGP, debe

seleccionar los mejores candidatos para el rol (en términos de ubicación y recursos de

hardware) para habilitar la funcionalidad de reflector de ruta. La configuración del

reflector de ruta se realiza en el propio reflector de ruta para identificar qué

interlocutores IBGP son clientes de reflectores de rutas. Por lo tanto, cuanto más

centralizado esté el BGP RR, mejor será el diseño, tal como el camino óptimo anunciado

desde el BGP RR a sus clientes. Después de introducir los reflectores de ruta, el número de

asociaciones en una red con decenas de enrutadores disminuye significativamente.

Desde el punto de vista de la configuración, la implementación de reflectores de ruta es

bastante simple y se puede realizar de forma incremental. Además de definir los

reflectores de ruta como pares, no se necesita una configuración especial en los propios

clientes. Cada enrutador cliente debe configurarse como un cliente en el reflector de ruta o

en varios reflectores de ruta. Los pares innecesarios pueden entonces ser quitados de la

configuración en el enrutador cliente. Cada hablante IBGP puede tener una mezcla de

sesiones directas de IBGP con otros compañeros y sesiones de IBGP con los RR de BGP. En

general, sin embargo, un cliente del reflector de la ruta bien diseñado, idealmente debe

mirar solamente con los reflectores de la ruta. Ese es el caso a menos que exista un

requisito especial que obligue a agregar un número limitado de sesiones directas de IBGP

entre hablantes de IBGP, como para evitar una ruta subóptima anunciada por un RR de

BGP.

128

Además, es importante que los diseñadores de redes entiendan las diferentes

terminologías y funciones en un entorno BGP diseñado con reflectores de ruta. En general,

se utilizan tres hablantes IBGP diferentes en este entorno: RR, cliente RR y cliente no RR

Un cliente reflector de ruta es un par de un nodo reflector de ruta. Puede enviar y recibir

rutas reflejadas desde los enrutadores reflectores. Para definir un interlocutor IBGP como

un cliente reflector de ruta en un reflector, el interlocutor debe ser específicamente

designado como cliente mediante una opción de configuración especial de BGP.

Por otro lado, un cliente no RR (también conocido como no cliente) es una definición de

asociación regular en un reflector de ruta, con un par que no está configurado

específicamente como un cliente reflector de ruta. Debido a que se trata de una sesión de

asociación normal de IBGP, cada reflector de ruta debe seguir siendo completamente

IBGP-mallado con los no clientes para mantener la accesibilidad IP completa. Los noclientes

son hablantes normales de IBGP; Por lo tanto, una sesión de asociación IBGP de

malla completa entre ellos es necesaria para mantener la total accesibilidad.

Si los reflectores de ruta pueden ser clientes RR o no clientes a los otros reflectores de ruta

en la red BGP depende de la topología y los requisitos de diseño.

Como resultado, los reflectores de ruta reducen significativamente el acoplamiento dentro

de los conglomerados. Sin embargo, todos los enlaces de malla fuera del cluster deben

mantenerse en el reflector de ruta para que los clientes reflectores de rutas reciban

información IP de los hablantes IBGP fuera del cluster a través de las terminologías y

funciones de reflector de ruta.

129

Confederaciones BGP

La otra manera posible de escalar su red BGP es introducir confederaciones de BGP. Las

confederaciones de BGP (descritas en IETF RFC 5065) dividen un sistema BGP autónomo

grande en múltiples sistemas autónomos más pequeños dentro del AS original. Con este

enfoque, los pequeños sistemas autónomos intercambian actualizaciones BGP entre ellos

utilizando una sesión especial de EBGP, comúnmente denominada sesiones EBGP

intraconfederación. Sin embargo, la AS externa o contenedora (conocida como la

confederación AS) es todo lo que es visible para el mundo exterior (sistemas autónomos

asociados).

Para que BGP evite posibles bucles dentro de un AS, las confederaciones de BGP insertan

información, usando la ruta BGP AS, en rutas BGP en las que los hablantes IBGP dentro de

un sistema subautónomo puedan reconocer el camino BGP AS completo. Este

reconocimiento incluye los números de AS del sistema subautónomo, por lo que ignora

cualquier ruta que tenga el número de sistema subautónomo local (basado en el típico

mecanismo de prevención de bucle del horizonte dividido IBGP).

Con este enfoque, las confederaciones BGP limitan el requisito de malla completa para

estar dentro de un sub-AS en lugar de entre todos los hablantes BGP a través de la red.

Esto reduce el número total de sesiones IBGP necesarias entre los hablantes BGP dentro

de un AS BGP. Además, en redes BGP muy grandes, puede introducir el concepto de

130

reflectores de ruta dentro de cada sub-AS para escalar aún más el diseño y simplificar su

manejabilidad dentro de cada sub-AS.

Normalmente, las confederaciones BGP se utilizan cuando se necesita particionar su red

en función de requisitos estructurales o geográficos. Además, debido a las consideraciones

de BGP, cada sub-AS puede ejecutar un IGP completamente diferente, esto es adecuado

para grandes entornos BGP bajo diferentes autoridades administrativas. La razón es que

cada sub-AS puede tener sus propias políticas de enrutamiento e IGP sin afectar las

sesiones de asociaciones BGP externas con otros sistemas autónomos.

Otro escenario común de la utilización de las confederaciones BGP es durante las fusiones

de las empresas, cuando hay una necesidad de fusionar dos redes BGP. Este enfoque

ofrece una migración más fácil que el uso de los RR BGP que usan la numeración AS

privada en una red consolidada. La confederación recién creada puede tener un número

AS común público al comunicarse con el resto de Internet.

BGP Confederaciones Versus BGP Reflectores de Ruta

Desde el punto de vista del diseño de la red, la pregunta típica que alguien puede hacer es:

"¿Qué enfoque de diseño es mejor para escalar una red BGP?" Para responder a esta

pregunta, usted, como diseñador de red, primero debe identificar los siguientes factores

no técnicos:

¿Cuál es la red de destino? ¿Es una empresa o proveedor de servicios? Esto le

ayudará a entender el entorno objetivo; Por ejemplo, BGP RR suele ser un buen

ajuste para las redes empresariales, pero no siempre.

¿Cuál es la actual estructura del IGP de la red? ¿Es un dominio IGP único o múltiples

dominios IGP? Si hay varios dominios IGP, BGP puede ser un buen ajuste si el IGP

no puede ser reestructurado.

¿Quién administra la red? ¿Está bajo una sola autoridad administrativa o múltiple?

La confederación BGP facilita el mantenimiento de dominios sub-BGP individuales

"AS por dominio" bajo una ASN BGP global.

¿Cuál es el impacto en el negocio de cualquier tiempo de inactividad? ¿Es aceptable

o no? Por ejemplo, la migración de una red completa de malla completa IBGP a las

confederaciones BGP puede introducir cierto tiempo de inactividad en ciertas

partes de la red durante el proceso de migración.

En general, los reflectores de ruta son más fáciles de migrar y relativamente fáciles de

usar, mientras que las confederaciones son más flexibles sobre el IGP y la política.

Confederación

Reflector de Ruta

Prevención de bucles Conjunto de AS confederaciones ID del originador o del

clúster

Separar un solo AS Sistemas Subautónomos Clusters

Redundancia Múltiples conexiones entre El cliente se conecta a

131

sistemas subautónomos

varios reflectores

Conexiones externas En cualquier lugar de la red En cualquier lugar de la

red

Jerarquía multinivel

Reflectores dentro de sistemas Clusters jerárquicos

subautónomos

Puede introducir enrutamiento No

Si

subóptimo a otros peering AS

Control de política

A lo largo de fronteras exteriores y

entre sistemas subautónomos.

A lo largo de la frontera

exterior

Migración

Muy difícil (imposible en algunas

situaciones)

Moderadamente fácil

DISEÑO DE REFLECTOR DE RUTA BGP

Regla de Horizonte dividido del Reflector de ruta

Las reglas de horizonte dividido se relajan en el escenario de diseño del reflector de ruta.

Con estas reglas modificadas, el reflector de ruta toma la comunicación de los clientes

reflectores de ruta, pasando a través de todos los mensajes que normalmente

transmitirían directamente, a través de una sesión. La ruta se envía de acuerdo con las

siguientes reglas:

Si un reflector de ruta recibe una ruta desde un punto EBGP:

o Envía la ruta a todos los clientes y no clientes.

Si un reflector de ruta recibe una ruta de un cliente:

o Refleja la ruta a todos los clientes y no clientes y a todos los compañeros de

EBGP.

o La ruta también se refleja de nuevo al remitente (y luego se descarta en el

remitente).

Si un reflector de ruta recibe una ruta de un no cliente:

o Refleja la ruta a todos los clientes, pero no a los no clientes.

o Los no clientes son hechos puré completamente.

o Envía la ruta a todos los compañeros EBGP.

Actualización de entrada desde

Par EBGP

Par IBGP no cliente

Par IBGP cliente

Se reenvía a

Todos los compañeros (IBGP y EBGP)

Pares EBGP y clientes IBGP

Todos los compañeros (incluyendo el remitente)

132

Además, según el comportamiento típico de BGP, la ruta que debe reflejarse debe ser la

mejor ruta a un destino específico en la tabla BGP del reflector de ruta. Si se recibe una

ruta idéntica en el reflector de ruta de dos o más clientes diferentes, en circunstancias

normales, sólo uno se refleja a otros pares. Una de las desventajas de este comportamiento

en un entorno BGP RR es que puede introducir enrutamiento subóptimo y romper los

requisitos de carga de equilibrio de carga / compartición sobre múltiples rutas.

Opciones y consideraciones de diseño de redundancia del

reflector de rutas BGP

En un entorno BGP diseñado con reflectores de ruta BGP, los clientes pueden tener

cualquier número de pares EBGP, pero normalmente tienen sesiones IBGP sólo con su

reflector de ruta disponible dentro de la BGP AS. Como resultado, si el reflector de ruta

único falla, sus clientes ya no pueden enviar actualizaciones BGP ni recibirlas del resto de

los pares dentro del BGP AS. Por lo tanto, el reflector de ruta se considera como un único

punto de fallo en el diseño y, típicamente, para evitar este único punto de fallo, es

necesario introducir un reflector de ruta redundante a la red.

Para lograr un diseño redundante confiable de RR, los enrutadores RR redundantes deben

estar soportados por enlaces red físicos y sesiones redundantes BGP. Esto permite a los

clientes BGP RR establecer sesiones BGP con reflectores de rutas múltiples utilizando las

rutas físicas redundantes disponibles.

En este tipo de diseño (redundante), típicamente ambos reflectores de ruta reciben la

misma actualización IBGP de sus clientes, y ambos reflejan la actualización al resto de los

clientes. Además, ambos reflectores de ruta reciben actualizaciones de malla completa y

reflejan esas actualizaciones a sus clientes. Como resultado, cada cliente recibe dos copias

133

de todas las rutas. En determinadas circunstancias, especialmente cuando se usan peso en

las sesiones de IBGP para influir en la selección de rutas BGP, la reflexión incorrecta de la

ruta puede resultar en un bucle de enrutamiento IBGP imposible de detectar. Por lo tanto,

son necesarios atributos BGP adicionales para evitar estos bucles de enrutamiento. En

consecuencia, el concepto de clústeres se introdujo para evitar bucles de enrutamiento

IBGP al utilizar reflectores de ruta en la red.

Clusters reflectores de ruta

Los clústeres de reflectores de ruta evitan bucles de enrutamiento IBGP en diseños de

reflectores de rutas redundantes. Por lo tanto, usted, como el diseñador de la red, necesita

identificar correctamente qué reflectores de ruta y sus clientes formarán un cluster;

entonces puede asignar al clúster un número de ID de clúster que sea único dentro del AS

BGP. En las redes a gran escala, un AS BGP se puede dividir en múltiples grupos de

reflectores de rutas.

Con este enfoque de diseño, los clientes examinarán a todos los reflectores de ruta dentro

del clúster para obtener redundancia. Por otro lado, los reflectores de ruta de diferentes

clusters necesitan estar completamente entrelazados entre sí para mantener la

accesibilidad completa de extremo a extremo en toda la red. Sin embargo, en algunas

grandes redes BGP, un reflector de ruta BGP puede definirse como un cliente de otro

reflector de ruta. Este diseño jerárquico se considera una excepción para soportar redes

muy grandes con clústeres de reflectores de rutas múltiples.

Identificador del clúster reflector de ruta

134

Técnicamente, en BGP, el número de ID del clúster puede configurarse explícitamente en

los reflectores de ruta o, si no está explícitamente configurado, el ID del enrutador del

enrutador se utiliza como ID de clúster. Los clientes, por otro lado, no deben configurarse

con esta información.

Existen dos enfoques de diseño para asignar el ID de clúster. Un enfoque asigna el mismo

ID de clúster a todos los reflectores de ruta de un clúster. Con este enfoque, el clúster se

denomina clúster redundante. Debido a que el identificador de clúster es idéntico entre los

reflectores de ruta en este enfoque, las rutas que se intercambian entre los reflectores de

ruta se descartan debido a la entrada de la lista de clústeres, ahorrando así recursos. Sin

embargo, puede conducir a pérdida de rutas y enrutamiento subóptimo en casos de

esquina en los que ciertas clases de BGP disminuyen debido a un fallo de enlace físico,

configuración errónea o error de software.

El otro enfoque de diseño es asignar un ID de clúster idéntico a cada reflector de ruta. Esto

también se conoce como superposición de clusters. Con este enfoque de diseño, los

clientes todavía se conectan a dos reflectores de ruta para redundancia, pero desde esta

perspectiva cada reflector de ruta representa un clúster independiente. Para que los

reflectores de ruta eviten bucles de información de enrutamiento, cada reflector de ruta

agrega la ID del enrutador del reflector a la lista de rutas de la agrupación que refleja entre

los hablantes IBGP. Además, para optimizar aún más la selección de rutas BGP para

acomodar este tipo de topología, se modifica el proceso de selección de ruta BGP para que

incluya los criterios de la longitud de la lista de clústeres. Esto significa que las rutas, con

una lista de clúster más corta, son preferidas a las que tienen una lista más larga.

Mecanismos de prevención de bucles

135

En una red BGP con reflectores de rutas múltiples, para evitar bucles de información,

puede utilizar los siguientes atributos BGP no transitorios opcionales:

BGP Originator-ID

BGP Cluster-List

El atributo BGP Originator-ID ayuda a evitar bucles de información de enrutamiento en un

escenario en el que una ruta se refleja en el reflector de ruta hacia otros clientes. El

reflector de ruta establece el atributo Originator-ID de la ruta al ID del enrutador de

origen. (El ID de router de origen es un hablante IBGP que inyecta una ruta en el AS BGP a

través de una sesión EBGP o utilizando un argumento en el comando network BGP).

Como resultado, cualquier enrutador que reciba una ruta con su propio ID de enrutador

en el atributo Originator-ID ignora silenciosamente esa ruta.

El atributo Cluster-List, por otro lado, ofrece un mecanismo de prevención de bucle

cuando varios reflectores de ruta reflejan la ruta en un escenario donde puede haber

muchas capas de reflectores de ruta en la red. Cluster-List es una lista secuencial de

clústeres IDs, que prepone los router IDs (o ID de clúster si está configurado) de los

reflectores de ruta que han reflejado la ruta a lo largo del camino. Podría considerar el

camino de reflexión que ha pasado la ruta. Si un reflector de ruta encuentra su ID de

enrutador en la lista de clústeres, descarta la ruta como un bucle posible.

Por lo tanto, para acomodar estos atributos con la selección de ruta BGP típica, se

modifican las reglas de selección de ruta BGP para seleccionar la mejor ruta en escenarios

en los que un enrutador podría recibir rutas reflejadas y no reflejadas o varias rutas

reflejadas, como se resume a continuación:

136

Los parámetros tradicionales de selección de ruta BGP, tales como peso,

preferencia local, origen, y MED, se comparan primero.

Si estos parámetros son iguales, las rutas que se reciben de los vecinos EBGP son

preferidas sobre las rutas que se reciben de los vecinos IBGP.

Cuando un enrutador recibe dos rutas IBGP, las rutas no reflejadas (rutas sin

atributo ID de origen) son preferidas a las rutas reflejadas.

Las rutas reflejadas con listas de clúster más cortas son preferibles a las rutas con

listas de clústeres más largas. Si los criterios adicionales de selección orientados a

la ruta y el reflector no dan lugar a una decisión, se considerará el resto de los

criterios tradicionales de selección de ruta BGP.

Desde el punto de vista del diseño, la introducción de la regla de selección de ruta

modificada hace posible el uso de reflectores de ruta sin establecer identificaciones de

clúster explícitas. En este escenario, el atributo Cluster-List se basa únicamente en

identificadores de enrutador de reflectores de ruta. Esta acción añade más resiliencia a la

red a expensas de unos recursos de enrutador más altos.

Técnicamente, cuando se refleja una ruta, el reflector de ruta añade su Cluster ID al

atributo Cluster-List. Como ya se mencionó en este capítulo, el valor ID de clúster de un

reflector de ruta se puede derivar de uno de los siguientes:

BGP Cluster ID: si está configurado explícitamente

BGP Router ID: si la ID de clúster no está configurada explícitamente

137

Congruencia de redes físicas y lógicas

En algunos escenarios, los enrutadores de cliente tienen sesiones de IBGP duales a dos

reflectores de ruta; sin embargo, existe realmente una conexión física única a un

enrutador reflector de ruta única. Por lo tanto, estos enrutadores forman un clúster no

redundante. A pesar de que el cliente tiene dos sesiones IBGP a dos reflectores de ruta, el

enrutador que se designa como el reflector de ruta (físicamente conectado) en el clúster

ya es un único punto de fallo en este diseño físico porque un fallo de este enrutador evita

138

que los clientes en el clúster lleguen al resto de la red. Por lo tanto, no hay ningún

beneficio real de introducir otro reflector de ruta.

Aunque la forma preferida de diseñar la red del reflector de la ruta es usando un cluster

redundante, este acercamiento confía en la redundancia física subyacente de la red.

Idealmente, cuando se están considerando múltiples clusters, los reflectores de ruta deben

estar totalmente engranados, a menos que exista un diseño jerárquico del reflector de la

ruta.

Una red BGP puede diseñarse para utilizar reflectores de rutas dedicados que no

participan realmente en el procesamiento de paquetes de datos de usuario, pero sólo se

ocupan de las tareas de distribución de rutas. Sin embargo, en un entorno no MPLS, este

enfoque puede conducir a un enrutamiento subóptimo a las redes externas.

Diseño Jerárquico del Reflector de Ruta

Considerando un enfoque de diseño jerárquico de reflector de ruta, construir clústeres de

reflectores de rutas en jerarquías puede ayudar a reducir el número de sesiones de malla

completa en redes grandes con un gran número de reflectores de ruta. Con jerarquías, un

enrutador que sirve como reflector de rutas en un clúster puede actuar como un cliente en

otro clúster.

En otras palabras, un enrutador que se despliega para ser un reflector de ruta todavía

tiene sesiones IBGP ordinarias que forman parte de la malla completa. Si estas sesiones se

reducen en número y sólo quedan unas pocas, y las restantes alcanzan un segundo nivel

de reflectores de ruta, se crea una jerarquía de reflectores de ruta. Por lo tanto, con este

enfoque, cuando se genera un primer nivel de clústeres, la malla completa restante es

menor que cuando todos los enrutadores pertenecían a una sola malla. Además, este

enfoque ofrece la flexibilidad al introducir niveles múltiples de jerarquías. Por ejemplo, si

la malla total restante sigue siendo grande en términos de número de enrutadores

reflectores y sesiones de IBGP, puede crear un nivel adicional de reflectores de ruta para

partir una malla grande en más pequeñas.

Como se estableció anteriormente, el atributo Cluster-List juega un papel importante en

una red de BGP de reflector de rutas jerárquica como mecanismo clave de prevención de

bucle.

En este escenario, cuando un cliente en el nivel más bajo recibe una actualización EBGP,

1. Reenviará la actualización en todas las sesiones IBGP configuradas a un reflector de

ruta.

2. El reflector de ruta (primer nivel) reconoce las actualizaciones BGP que se reciben

de los clientes configurados y reenvía estas actualizaciones a todos los demás

clientes y no clientes que usan sesiones normales de IBGP.

139

3. La actualización entonces se envía a través de una sesión IBGP al reflector de ruta

de segundo nivel.

4. A continuación, el reflector de ruta de segundo nivel reconoce que la actualización

se recibió de un cliente y lo remite a todos los demás clientes, y en la malla

completa a otros RR (s) y no clientes.

Con este enfoque, los diseñadores de redes pueden simplificar y superar la complejidad de

malla entre los hablantes BGP y el RR al partir un dominio de malla grande en otros más

pequeños. Aunque la red se puede dividir en cualquier número de nivel / niveles, siempre

se recomienda que lo mantenga simple y apunte a dos o tres niveles de jerarquías como

máximo. Esto es suficiente para optimizar redes BGP muy grandes. Sin embargo, el diseño

jerárquico de RR puede conducir a un enrutamiento subóptimo y un tiempo de

convergencia más largo, así como a ocultar caminos adicionales cuando hay más de un

camino entre dos clientes de punto final RR. En redes de gran escala que utilizan algunas

características avanzadas de BGP como BGP AD-PATH o BGP Diverse Paths, puede

optimizar este comportamiento.

Posibles problemas de diseño de red del Reflector de Ruta

Esta sección proporciona una lista resumida de algunas consideraciones de diseño en

entornos BGP con reflectores de ruta para evitar problemas potenciales o imprevistos,

especialmente si los diseñadores de red se desvían de las reglas y recomendaciones de

diseño de red de reflector de ruta.

140

Si los reflectores de ruta no están conectados con sesiones IBGP en una malla completa,

algunos clústeres no tendrán todas las rutas y romperán el requisito de alcance completo

de extremo a extremo.

En entornos BGP grandes con múltiples puntos de salida EBGP, la introducción de RR en la

red puede conducir a un enrutamiento subóptimo. Por lo tanto, colocar el RR lo más cerca

posible del punto de salida deseado ayuda a optimizar este comportamiento.

Alternativamente, las características avanzadas como BGP ADD-PATH pueden ser

consideradas con una planificación cuidadosa.

Si un cliente tiene sesiones IBGP con algunos reflectores de ruta en un clúster, pero no con

todos ellos, el cliente puede perder algunas rutas BGP.

Si un cliente tiene sesiones IBGP para reflectores de ruta pertenecientes a clústeres

diferentes, el cliente enviará la actualización BGP desde el cliente a la red completa con

ID´s de clústeres diferentes en el atributo Cluster-List. Cuando la actualización de BGP

entra en la malla, llegará al otro reflector de ruta, el cual, innecesariamente, aceptará la

ruta como válida y la reenviará a su cluster. Esta situación, a su vez, provoca la duplicación

innecesaria de las actualizaciones a los clientes. Sin embargo, este enfoque ofrece un

diseño resiliente de RR.

Si un cliente tiene sesiones IBGP con otros clientes del mismo clúster, dichos clientes

recibirán duplicaciones innecesarias de actualizaciones.

La modificación de los atributos de ruta en los reflectores de ruta antes de reflejar las

rutas puede conducir a enrutamiento subóptimo o incluso redes potencialmente rotas.

MEJORANDO EL DISEÑO DE LAS POLÍTICAS BGP CON LAS

COMUNIDADES BGP

Las comunidades de BGP están diseñadas para dar a los operadores de red la flexibilidad

de aplicar políticas complejas a un gran número de rutas junto con mecanismos

integrados de RPL (routing policy language) o mapas de rutas. Esta sección discute la

estructura y alguna posible aplicación de las comunidades BGP; también explora formas

de implementar políticas reutilizables con el uso de cadenas de comunidad de BGP.

Descripción del atributo de la comunidad BGP

141

Una comunidad es un atributo BGP que se puede agregar a cualquier prefijo. Las

comunidades son atributos opcionales transitivos, lo que significa que las

implementaciones BGP no tienen que reconocer el atributo para pasarlo a otro AS.

Estas comunidades BGP pueden aplicarse a cualquier ruta BGP utilizando un mapa de ruta.

Este se comunica con otros enrutadores a través de la red para realizar cualquier acción

basada en la etiqueta (comunidad) que se adjunta a la ruta. Además, técnicamente es

posible que más de una comunidad de BGP esté conectada a una única ruta. Sin embargo,

los enrutadores, de forma predeterminada, eliminan las comunidades en las

actualizaciones de BGP salientes. Por lo tanto, si las comunidades BGP necesitan ser

compartidas con otros hablantes BGP, este comportamiento predeterminado debe ser

ajustado. (En Cisco IOS, puede utilizar el argumento send-community por vecino BGP para

habilitar el envío de atributos de comunidad al vecino BGP).

Las comunidades BGP proporcionan un mecanismo para reducir la complejidad de

configuración de BGP en un enrutador que controla la distribución de información de

enrutamiento. Puede ser leído como un valor de 32 bits o dividido en dos porciones. Los

dos primeros bytes representan un ASN al que está destinada la comunidad, y los dos

últimos bytes son un valor con un significado predeterminado.

El valor del atributo de la comunidad es, en esencia, un entero plano de 32 bits que puede

aplicarse a cualquier conjunto de prefijos. Se puede expresar en decimal, hexadecimal u

ordenando dos valores decimales de 16 bits que se delimitan con dos puntos. La notación

hexadecimal es común en los estándares, mientras que los formatos decimal y de dos

partes son comunes en las configuraciones del enrutador. La mayoría del software de

enrutador moderno muestra comunidades como ASN: VALUE, que es también el formato

más fácil de leer por humanos.

Los rangos de la comunidad son los siguientes:

Los rangos de 1: 0 a 65534: 65535 están destinados al uso gratuito de los

administradores de red; Sin embargo, no hay significado inherente a ellos.

Los rangos de 0: 0 a 0: 65535 y 65535: 0 a 65535: 65535 están reservados.

Las comunidades conocidas pertenecen al grupo de rangos reservados y, a diferencia de

las comunidades definidas por el usuario, tienen un significado específico.

Comunidades bien conocidas de BGP

IETF RFC 1997 y RFC 3765 definieron un conjunto estándar de valores comunitarios bien

conocidos que ayudan a los enrutadores en un entorno BGP para realizar una acción

específica predefinida cuando reciben una ruta marcada con una comunidad predefinida.

La acción que realiza cualquier enrutador se basa en ese entorno de comunidad:

142

No-advertise: Esta comunidad instruye a un enrutador que habla BGP que no

envíe el prefijo etiquetado a ningún otro vecino, incluyendo otros enrutadores IBGP

No-export: si un enrutador recibe una actualización que lleva esta comunidad, no

la propaga a ningún vecino externo, excepto a los vecinos externos

intraconfederación. El atributo no-export es el atributo de comunidad predefinido

más ampliamente utilizado.

No-export-subconfed: Esta comunidad tiene un significado similar a la no-export,

pero mantiene una ruta dentro del AS local (o miembro AS dentro de la

confederación). La ruta no se envía a vecinos externos BGP o a vecinos externos

intraconfederation. Esta comunidad también se conoce como la comunidad localas.

No-peer: Esta comunidad se utiliza en situaciones en las que se requiere control de

ingeniería de tráfico sobre un prefijo más específico, pero para restringir su

propagación sólo a proveedores de tránsito y no a pares. La comunidad no tiene un

buen apoyo de los principales proveedores y puede requerir implementación

manual.

Los dispositivos Cisco también reconocen a la comunidad de Internet, que no es una

comunidad bien conocida basada en estándares con un valor predefinido de 0: 0. En el IOS

Cisco, la palabra clave de Internet se utiliza para coincidir con cualquier comunidad en las

listas de la comunidad. En otras palabras, es una declaración “catchall” al final de una lista

de la comunidad. Estas comunidades estándar permiten a los diseñadores y operadores de

redes lograr requisitos complejos de políticas BGP de una manera flexible y fácil de

manejar a través de sistemas autónomos BGP únicos y diferentes.

Lista de la comunidad nombrada BGP

La característica de las listas de comunidades de BGP (Cisco IOS / IOS XE / IOS XR)

introduce un nuevo tipo de lista de comunidad, la lista de comunidades con nombre. Una

lista de comunidades con nombre se puede configurar con expresiones regulares y con

listas de comunidades numeradas. La función de listas comunitarias nombradas BGP

permite al operador de red asignar nombres significativos a las listas de la comunidad.

Todas las reglas de las comunidades numeradas se aplican a las listas de comunidades con

nombre excepto que no hay ninguna limitación en el número de atributos de la comunidad

que se pueden configurar para una lista de comunidades con nombre. Aunque las listas de

comunidades estándar y expandidas (Cisco IOS / IOS XE) tienen una limitación de 100

grupos de comunidades que se pueden configurar dentro de cada tipo de lista, una lista de

comunidades con nombre no tiene esta limitación.

Planificación para el uso de comunidades BGP

143

Para planificar eficazmente, primero debe definir la directiva administrativa de

enrutamiento. Por ejemplo, debe identificar qué filtro, en qué punto y cómo modificar los

atributos de ruta para influir en los flujos de tráfico para que se adapten a los requisitos de

su empresa. Uno de los factores decisivos comunes en la creación de una directiva de

enrutamiento y una sección de ruta es el coste y la fiabilidad del tráfico de enrutamiento

sobre los enlaces WAN disponibles. Idealmente, esta decisión debe hacerse durante la fase

de planificación.

Después, usted tiene que diseñar el esquema de la comunidad para las metas individuales

de la política. Cuando se define su política y se establece y documenta un esquema de

comunidad, implemente el sistema de comunidad configurando mapas de rutas en sus

dispositivos. Este paso incluye etiquetar rutas y actuar sobre las etiquetas, dependiendo

de la posición del enrutador en la red y la dirección de la política. La política de salida

difiere de la directiva de entrada para un grupo de iguales o un grupo de pares.

La lista de la comunidad es una herramienta importante y flexible a su disposición para

agrupar las comunidades, que se utiliza en el proceso general para identificar y filtrar

rutas por sus atributos comunes.

También, en esta etapa, usted debe planear el diseño del esquema de las comunidades de

BGP y debe hacer el esfuerzo de documentar los valores y el significado de sus

comunidades en tanto detalle como sea posible. Debido a que los cambios posteriores

podrían resultar difíciles después de que la red esté en producción, la etapa de

planificación es vital para el diseño óptimo y efectivo de comunidades y políticas BGP. Por

ejemplo, la comunidad 65000: 12345, si está marcada en el punto de origen, puede ser

usada para señalar al resto de la red BGP que esta ruta es del área 1 y ciudades 23 y 45

para algún significado especial en el que se basará el Política de filtrado.

Si es necesario, puede asignar varios valores de comunidad a una sola ruta, lo cual es una

capacidad flexible porque aparecerá como una serie de comunidades conectadas a una

ruta. Luego, dependiendo de la política BGP definida, BGP puede considerar que una,

algunas o todas las etiquetas de la comunidad sean procesadas en puntos de peering.

DISEÑO DE CARGA COMPARTIDA DE BGP

A veces las empresas necesitan optimizar el retorno de la inversión de los enlaces que

poseen mediante la utilización de todos ellos en lugar de utilizar un enlace y dejar el otro

enlace pasivo (en espera, en frío). Para lograr esto, se necesita un mecanismo para

distribuir los flujos de tráfico a través de los caminos disponibles. Esto también se conoce

como balanceo de carga. El balanceo de carga permite que un enrutador distribuya el

144

tráfico saliente y entrante entre múltiples rutas. Las rutas se derivan de forma estática o

con protocolos dinámicos. De forma predeterminada, BGP selecciona sólo una única mejor

ruta y no realiza el balanceo de carga. Esta sección explica cómo realizar el reparto de

carga en diferentes escenarios con el uso de BGP.

Single-Homing Versus Multihoming

Estrictamente hablando, multihoming es la conexión de su red BGP a cualquier red externa

por múltiples enlaces. Dependiendo del número de ISP, los requisitos de redundancia y el

volumen de tráfico, puede haber una red BGP que sea de singlehomed o multihomed a

redes externas.

Normalmente, las redes singlehomed no proporcionan ninguna redundancia a nivel de ISP.

El espacio de direcciones puede ser del ámbito asignado o independiente del proveedor.

No hace ninguna diferencia porque el BGP local AS tiene solamente un punto de la salida al

Internet.

Por el contrario, las redes multihomed proporcionan configuraciones completamente

redundantes, si se utilizan enrutadores locales redundantes. Con esta configuración, se

pueden establecer dos modelos de conectividad a las redes externas / proveedores de ISP:

ISP único: con este modelo, el ISP externo puede representar un solo punto de fallo

si hay algún problema dentro de la red ISP. El espacio de direcciones puede ser

asignado por el proveedor o independiente del proveedor; No hace ninguna

diferencia porque el BGP local AS tiene solamente un AS de salida al Internet.

Dos o más ISP: con este modelo, su red BGP de empresa se conectará a, al menos,

dos ISP. Por lo tanto, el uso de un proveedor independiente del bloque de

direcciones IP es una necesidad. Además, este modelo ofrece un mayor nivel de

redundancia.

La redundancia es la razón más notable para el multihoming. Con una sola conexión, una

conexión a Internet significa que la red depende de:

Enrutador local (configuración, software, hardware)

Enlaces WAN (fallo físico, falla del portador)

ISP (configuración, software, hardware)

Consideraciones de Diseño de Dual-homing y Multihoming

145

Para proporcionar un diseño orientado a las empresas que tenga en cuenta sus

necesidades y las aplicaciones; el diseño de su red multihomed, según las políticas, debe

derivarse de los requisitos para sus flujos de tráfico.

El uso de cada herramienta es diferente para diferentes escenarios y, como se aprenderá

más adelante en esta sección, la manera de hacerlo es mediante la implementación de

diferentes políticas BGP. Usted puede hacer un montón de ajustes finos para acercarse a la

meta de balanceo de carga deseada, pero el control total sobre el reparto de la carga de

tráfico es difícil de lograr debido al tamaño y la imprevisibilidad de los flujos.

Cuando se conecta a varios puntos de salida de su AS y se asocia con varios ISP, existe el

peligro de que, por mala configuración, anuncie las rutas que se reciben de un ISP al otro

ISP. Su AS puede convertirse en un área de tránsito para el tráfico de Internet de otras

redes, lo que puede costar dinero y recursos. Puede evitar esta situación al anunciar sólo

el espacio de direcciones asignado a todos los ISP adyacentes (también puede anunciar

sólo su AS local y filtrar los otros AS con el filtro BGP AS-path).

Single-homed, enlaces múltiples

Este escenario muestra cómo lograr el reparto de carga cuando hay varios enlaces de igual

costo. En este escenario, los enlaces se terminan en un enrutador del AS local (red

corporativa) y en otro enrutador en un AS remoto (ISP) en un entorno BGP single-homed.

En este escenario, se requiere un IGP (o dos rutas estáticas cada una con la misma

distancia administrativa y apuntando a un enlace diferente para alcanzar al nodo remoto

en una IP de Loopback) entre los hablantes EBGP sobre los dos enlaces. La razón es que el

reparto de carga en este escenario se implementa en el nivel de IGP, donde puede haber

múltiples rutas de igual coste entre las interfaces Loopback EBGP, que sirven como

siguiente salto para las rutas BGP. Sin embargo, debido a que la interfaz de bucle de

retorno no forma parte de un enlace entre los enrutadores, la búsqueda de rutas

recursivas se ejecuta en los enrutadores para encaminar el tráfico a través de los enlaces.

El enrutador puede utilizar varias vías de igual coste para cada paquete o cada base de

datos, dependiendo de las configuraciones de hardware y software del enrutador. Si

decide considerar el equilibrio de carga por paquetes, asegúrese de que esta técnica no

afecta a las aplicaciones que se ejecutan a través de los enlaces, ya que puede dar lugar a

algunos paquetes fuera de orden. Y cuando los paquetes llegan fuera de servicio, el

146

enrutador receptor necesita almacenarlos en memoria y volver a montarlos de nuevo, lo

que introduce un retraso adicional.

Existen varios beneficios para el ECMP del IGP:

La topología física subyacente no afecta a la sesión EBGP, lo que significa que sólo

un enlace debe estar activo y que BGP funcionará según lo previsto.

Los enlaces pueden servir dinámicamente como respaldo mutuo, e IGP se

encargará de la convergencia.

Hay un aumento de ancho de banda entre los erutadores EBGP para el tráfico de

datos del usuario con cada ruta adicional.

Aunque las rutas estáticas se pueden utilizar en este escenario en lugar de IGP, si IGP no se

utiliza y se opta por el enrutamiento estático entre loopback, en ciertas situaciones, esta

acción puede conducir a la pérdida de tráfico porque no hay intercambio de rutas

dinámicas y, más aún un vecino adyacente IGP con estado. Una ruta estática existirá en la

tabla de enrutamiento y el enrutador enrutará el tráfico si la interfaz física a la que apunta

la ruta está arriba. Dicho esto, este comportamiento se puede optimizar si la ruta estática

se combina con Cisco IP SLA para asegurar que cuando el nodo remoto no es accesible

sobre un enlace dado (incluso si el enlace está físicamente arriba), se eliminará la ruta

estática desde la tabla de enrutamiento.

Dual-Homed a un ISP que usa un solo router de borde local

Este escenario muestra cómo lograr el balanceo de carga cuando existen varios enlaces

entre un AS remoto y un AS local. Estos enlaces terminan en un enrutador en la AS local

(red corporativa) y en varios enrutadores en el AS remoto (ISP) en un entorno BGP de un

solo hogar. En este escenario, hay dos sesiones EBGP entre la red corporativa y el ISP; cada

sesión se establece sobre una interfaz física separada.

Además, este escenario de caso de uso demuestra la capacidad de lograr la distribución de

carga (ECMP) en el nivel BGP mediante el uso de la función multipath BGP. De forma

predeterminada, BGP elige una mejor ruta entre las posibles rutas de igual coste que se

aprenden de una AS. Sin embargo, puede cambiar el número máximo de rutas paralelas de

coste igual que se permiten.

Para realizar este cambio, incluya el comando maximum-paths paths bajo la

configuración BGP con un número entre 1 y 6 para el argumento paths.

147

La red corporativa puede controlar completamente el tráfico de salida hacia el AS del ISP,

pero el tráfico entrante no puede controlarse completamente sin la cooperación del ISP.

Para el balanceo de cargas de salida, puede utilizar la función de trayectos múltiples BGP

en el lado del enrutador corporativo, que realiza el balanceo de carga del tráfico basado en

ECMP. En caso de que obtenga demasiados prefijos y el enrutador no pueda manejar

muchas rutas, puede ajustar el uso compartido de carga con preferencias locales o

atributos de peso estableciéndolos para los prefijos que llegan. De esta manera, puede

influir en ese tráfico para un prefijo que saldrá a través del enlace deseado. Si un

enrutador obtiene dos prefijos para el mismo destino, el que tenga mayor peso o, si el peso

no está establecido, un mayor valor de preferencia local ganará.

Dual-Homed a un ISP usando routers de borde múltiple

Este escenario muestra cómo lograr el balanceo de carga cuando hay varias conexiones al

mismo ISP a través de varios enrutadores locales, donde las dos sesiones ISP EBGP se

terminan en dos routers locales diferentes. Además, en este escenario, se requiere una

sesión IBGP entre los enrutadores locales para habilitar el intercambio de rutas BGP entre

ellos.

El equilibrio de carga para un destino específico (como una dirección IP de host) sobre los

dos enlaces externos normalmente no es posible porque BGP elige la mejor ruta entre las

redes que se aprenden de EBGP e IBGP. El compartimiento de carga entre las múltiples

rutas de acceso a AS 456 es la siguiente mejor opción. Con este tipo de carga compartida,

el tráfico a redes específicas, que se basa en políticas predefinidas, viaja a través de ambos

enlaces. Además, cada enlace actúa como una copia de seguridad para el otro enlace en

caso de que un enlace falla.

148

Además, este escenario todavía no establece requisitos estrictos sobre el tipo de espacio

de direccionamiento que utiliza la red corporativa. Permite el uso de rangos de

direcciones PA o PI.

Puede lograr el reparto de carga para la dirección de ingreso en este ejemplo, dividiendo

el intervalo de direcciones de red corporativa o cambiando la ruta AS o el atributo MED al

finalizar las actualizaciones de enrutamiento.

Por otro lado, el intercambio de carga de tráfico de salida se puede realizar de dos

maneras: en el borde (BGP) ajustando el atributo de preferencia local de BGP o

internamente confiando en FHRP o IGP para distribuir los flujos de tráfico a los

enrutadores de borde.

Mediante la manipulación de BGP en los enrutadores de borde, se establece la preferencia

local a los prefijos a medida que llegan, puede lograr aproximadamente 50-50 por ciento

de distribución de tráfico de envío a través de los dos enlaces. Los prefijos que tienen

mayor preferencia local en el enrutador de borde corporativo superior tendrán una

preferencia local menor en el enrutador inferior y viceversa.

El balanceo de carga de tráfico también se puede hacer internamente, antes de que llegue

a los enrutadores de borde. Puede distribuir el tráfico de salida utilizando un FHRP dentro

del AS corporativo, que entonces cargaría el tráfico de equilibrio a los enrutadores de

borde en aproximadamente el mismo porcentaje. Una vez que el tráfico golpea cualquiera

de los enrutadores BGP de borde, se encamina a través del enlace al ISP, por lo que es una

cuestión de cómo FHRP distribuirá la carga para obtener las relaciones de carga

compartida deseadas. Ejemplos de FHRP son HSRP y GLBP. El reparto de la carga usando

IGP ECMP se puede lograr redistribuyendo 0/0 de BGP en IGP. Entonces, la red interna

tendrá dos rutas predeterminadas de costo igual hacia los enrutadores de borde BGP. Sin

embargo, en ambos enfoques, los diseñadores de redes deben planear y diseñar

cuidadosamente políticas BGP para evitar el enrutamiento asimétrico si va a afectar la

comunicación de las aplicaciones que se ejecutan a través de la red, como la Voz sobre IP

(VoIP).

Multihoming con dos ISP usando un único enrutador de borde local

Debido a que este modelo de diseño se basa en la conexión a dos proveedores de servicios

de Internet externos diferentes, el equilibrio de carga de tráfico a un destino no es una

opción en un entorno multihomed, por lo que de nuevo sólo se puede compartir la carga.

La razón técnica detrás de ello es que BGP selecciona sólo una única mejor ruta a un

destino entre las rutas BGP que se aprenden de los diferentes ASN. La idea es establecer

una mejor métrica para ciertas rutas que se aprenden de ISP1 y una mejor métrica para

otras rutas que se aprenden de ISP2.

Para lograr el nivel deseado de flexibilidad en el diseño de la ingeniería de tráfico en este

modelo de diseño (multihoming), usted, como diseñador de red, debería considerar el uso

149

del espacio de direcciones IP PI porque este espacio de direcciones permite a la empresa

anunciar a ambos ISP.

Desde el punto de vista del diseño, este modelo requiere una cuidadosa consideración del

diseño. Por ejemplo, para evitar que la red empresarial sea un AS / ruta de tránsito para

los dos ISP externos (por ejemplo, ISP1 e ISP2), se recomienda que solo se anuncie su

espacio de direcciones PI a los ISP a los que está directamente conectado. Si, por error,

anuncia rutas que se reciben de ISP1 a ISP2, y la política de ISP2 no es lo suficientemente

restrictiva, su AS comenzará a participar en el intercambio de tráfico de Internet

(convertido en un AS de tránsito).

Para lograr el reparto de carga para la dirección de ingreso, puede considerar dividir el

espacio de direcciones y anunciar diferentes bloques a los ISP. El agregado siempre se

anuncia a ambos ISP como una mejor práctica porque sirve como un mecanismo de

respaldo si sucede el fallo de cualquiera de los ISP. Si el espacio de direcciones asignado es

pequeño (/ 24 o menor), lo mejor que puede hacer es usar la configuración activa / pasiva

añadiendo varias veces la ruta AS con su ASN. De esta manera, obtiene redundancia, pero

sin compartir la carga.

150

Para evitar que su red se convierta en un AS de tránsito, asegúrese de anunciar sólo su

propio espacio de direcciones PI a ambos ISP mediante el filtrado de rutas de salida, el

filtrado BGP AS-PATH o una combinación de ambos.

Por otro lado, el reparto de carga para el tráfico de salida cuando dos ISPs son multihomed

es posible si se configura la preferencia local de los valores más altos para las rutas

preferidas procedentes de los enlaces preferidos. En este caso, si está recibiendo la tabla

completa de enrutamiento de Internet de ambos compañeros en su enrutador corporativo,

el ajuste fino del tráfico de egreso puede realizarse empíricamente. Por lo tanto, la

distribución de destinos por enlace (ISP) se puede modificar hasta que se alcancen las

relaciones de tráfico deseadas, por una especie de método de prueba y error. Hay muchos

métodos de dividir los prefijos. Por ejemplo, puede dividirse por la mitad en función del

primer octeto, y también puede dividirlos por principios pares e impares, y así

sucesivamente.

Si está recibiendo una ruta predeterminada y un conjunto limitado de prefijos de los ISP,

el uso compartido de la carga, aunque todavía sea posible, no será tan preciso.

Multihoming con dos ISP usando varios routers de borde local

Este modelo de diseño ofrece la solución más resistente porque está estructurado por dos

enrutadores locales que miran a dos ISP diferentes. Por lo tanto, habrá redundancia en los

siguientes elementos:

Enrutadores de borde local

Sesiones BGP

Enlaces externos físicos

ISP (proveedores diferentes)

Sin embargo, este modelo también tiene el costo más alto; Por lo tanto, es de uso común

por las grandes empresas en sus sitios críticos e importantes, como el centro de datos en

el borde de Internet, que necesitan un alto nivel de disponibilidad de servicios.

151

Cada enrutador local de borde está asociado con un enrutador en un AS / SP diferente, y

hay una sesión IBGP entre los routers locales. De hecho, esta sesión de IBGP ayuda a

garantizar que ambos enrutadores siempre estén totalmente integrados en caso de que

falle un enlace ISP o una sesión EBGP.

Sin embargo, como se mencionó en la sección anterior, se sabe que una de las limitaciones

de diseño de este modelo es que el equilibrio de carga a un destino no es posible en un

entorno multihomed con dos ISP. BGP selecciona sólo la mejor ruta de acceso a un destino

entre las rutas BGP que se aprenden de AS diferentes, lo que hace que el equilibrio de

carga sea casi imposible, incluso con funciones avanzadas BGP como bgp multipath-relax.

Sin embargo, el reparto de la carga es posible en tales redes BGP. Con base en políticas

predeterminadas, el flujo de tráfico se controla con diferentes atributos BGP.

Al igual que con todas las implementaciones multihomed que utilizan varios ISP, se

requiere el espacio de direcciones PI.

De forma similar al escenario de multihoming con un enrutador local, en este escenario, de

nuevo, el reparto de carga para el tráfico de entrada es posible dividiendo el espacio de

direcciones y anunciando diferentes bloques a los ISP. El agregado siempre se anuncia

como una mejor práctica, ya que sirve como un mecanismo de respaldo si hay un fallo de

enlace. La principal diferencia en este modelo es que la sesión IBGP entre los routers

locales de borde se utiliza para asegurar la mejor convergencia en casos de fallos de enlace

o enrutador, lo que hace que sea una configuración muy disponible en comparación con

otros escenarios discutidos en esta sección hasta el momento

Si el espacio de direcciones asignado a usted es pequeño (/ 24 o menor), lo mejor que

puede hacer es una configuración activa / pasiva, prefijando la ruta AS varias veces con su

ASN. Por lo tanto, logra redundancia sin compartir la carga. Aunque MED puede ser

considerado como un atributo BGP para influir en la selección de ruta BGP, prácticamente

152

no es una opción útil o viable aquí como una herramienta para compartir cargas, ya que se

trata de dos ISP distintos.

Sin embargo, el compartimiento de carga en la dirección de salida de este escenario es

similar al que tiene dos enrutadores con el mismo ISP. Los enrutadores locales necesitan

una forma de seleccionar un enlace adecuado para un destino. La meta se logra

estableciendo selectivamente la preferencia local a las rutas a medida que llegan. Cuando

no hay fallas en la red, los flujos de tráfico en este escenario siguen las rutas de "flecha

punteada" para llegar a la red en el rango 1-128. Esto también es aplicable al tráfico que se

envía a otro enrutador de borde. Por ejemplo, si en el enrutador inferior se recibe tráfico

desde el interior de un destino que es interior, en el rango 1-128, este tráfico se encamina

al enrutador superior (a través de la sesión IBGP entre los enrutadores de borde) y es

enviado a través del enlace superior al ISP1. En el caso de que el enlace superior o un

enrutador o ISP1 falle, el tráfico que está destinado a 1-128 es enviado a ISP2.

Si no está usando BGP y las preferencias locales para distribuir el tráfico de egreso, puede

considerar equilibrar el tráfico internamente hacia los enrutadores de borde, de la misma

manera que ya se discutió en un escenario en esta sección, utilizando FHRP o

redistribuyendo la ruta predeterminada en IGP. En este caso, los enrutadires de borde

deben tener una política simple que envía todo lo que reciben a través del enlace a sus ISP

respectivos. Esta política es, en muchos casos, la que se obtiene por defecto en BGP debido

al mecanismo de selección de ruta. Si no es así, puede conseguir fácilmente una política de

este tipo en los enrutadores de borde corporativo mediante el establecimiento de un valor

de peso alto para cualquier ruta que se recibe de la sesión directa EBGP con el ISP versus

el menor peso predeterminado de rutas que se reciben de IBGP (Conectado al otro ISP).

153

Capítulo 6

Consideraciones de

Diseño de IPv6

154

CONSIDERACIONES SOBRE IMPLEMENTACIÓN Y DISEÑO DE

IPV6

Aunque muchas organizaciones consideran que es suficiente ofrecer sus servicios con su

asignación IPv4, en este momento la próxima generación de Internet no parece posible sin

la adopción de IPv6.

Además, los grandes proveedores de contenido ya ofrecen su contenido en ambas pilas de

protocolos. Los proveedores de servicios han adoptado IPv6 para su red de transporte, y

los proveedores de aplicaciones grandes introdujeron el soporte IPv6 con una sólida hoja

de ruta hacia el futuro. Por lo tanto, la migración o la transición a IPv6 no es una opción en

las redes modernas, se está convirtiendo en algo inevitable. Dicho esto, cómo y cuándo

elige migrar varía y depende de muchos factores y variables (técnicas y no técnicas). Esta

sección se centra en la estrategia de migración o transición, junto con los diferentes

enfoques técnicos que puede utilizar para migrar a una red habilitada para IPv6.

El enfoque para implementar IPv6 está integrado por las siguientes fases:

Descubrimiento

Evaluación

Planificación y diseño

Implementación

Optimización de la red

155

Fase de descubrimiento de negocios y redes

En esta fase, los diseñadores de red necesitan identificar las metas y los impulsores del

negocio hacia la habilitación de IPv6 que se puede utilizar para justificar el caso. Durante

esta fase, es necesario tener en cuenta los siguientes factores:

Duración del proyecto

Cumplimiento de las Políticas de Gobierno

Distribución geográfica de los sitios con respecto a la disponibilidad de direcciones

IP

A menudo, las únicas empresas que son capaces de proporcionar un caso de negocio para

el despliegue de IPv6 son los proveedores de servicios, que dependen del creciente

crecimiento de los clientes. Cuando las empresas no son capaces de proporcionar

suficiente infraestructura a su base de clientes, esta incapacidad representa un golpe

directo a su flujo de ingresos.

Una empresa también puede buscar la expansión en aquellas regiones donde la asignación

de IPV4 se ha agotado por completo y los clientes o socios sólo tienen asignación de IPv6

para comunicarse con la sede u otras sucursales. Además, algunas organizaciones

construyen un front-end IPv6 para sus clientes, porque si un dispositivo de usuario final

es IPv6 y no puede acceder a la página web de la empresa, la empresa verá esto como

potencial pérdida de clientes e ingresos.

Fase de evaluación

Cualquier proyecto de diseño que carezca de una evaluación exhaustiva de la

infraestructura existente entraña un alto riesgo durante el proyecto. Dado que los

proveedores de hardware y sistema operativo ya han implementado la compatibilidad con

IPV6, suele haber una ruta de migración sencilla para la que solo se requiere una

actualización de software. Debe reemplazar por completo el equipo que no admite el

conjunto de funciones requeridos y no es capaz de procesar IPv6 en hardware con una

plataforma más nueva.

La migración de aplicaciones representa el mayor desafío en una migración IPv6. Los

proveedores de aplicaciones reconocidos proporcionan una ruta de migración; sin

embargo, las aplicaciones internas o personalizadas pueden suponer un desafío o forzar a

156

la empresa a adquirir una nueva solución, ya que la adaptación puede consumir

demasiados recursos.

Fase de planificación y diseño

La decisión sobre qué despliegue elegir influye grandemente en la fase de planificación y

diseño. Tanto los modelos de despliegue dual como híbridos tienen puntos fuertes y

débiles que deben estar en línea con los requisitos de negocio que se definen en la fase de

descubrimiento.

Aunque el modelo de doble pila puede ser la única estrategia a largo plazo y ofrece

transparencia al usuario final, introduce una mayor complejidad y una gran cantidad de

recursos al implementar

Los modelos híbridos utilizan métodos de túnel y traducción para la implementación

rápida de IPv6 en componentes de red seleccionados o durante la migración a IPv6. El

resultado de la fase de diseño debe incluir un diseño detallado y de bajo nivel que cubra el

direccionamiento, LAN, WAN, seguridad y otras áreas relevantes. En particular, la

seguridad requiere una consideración crucial porque la habilitación de una nueva pila de

protocolos abre posibles riesgos en la red.

Fases de implementación y optimización

Idealmente, siempre debe tener como objetivo inicialmente implementar IPv6 en un

programa piloto limitado o en un entorno de laboratorio que cubra un conjunto completo

de dispositivos, servicios y aplicaciones de red (cualquier cosa incluida en su entorno de

producción). Este enfoque le ayuda a establecer una base desde la cual probar la nueva

pila de protocolos y recopilar la experiencia operacional antes del despliegue a gran

escala. Además, si los requisitos del negocio incluyen las geografías, el programa piloto

debe incluir validación y pruebas del diseño para cada geografía.

Además, debe intentar establecer un proceso de retroalimentación eficaz que permita a

los usuarios informarle sobre problemas críticos para que pueda solucionar y optimizar la

solución. En comparación con otras fases, la fase de optimización de la red es un proceso

continuo. El análisis de métricas operativas y la experiencia del usuario pueden ayudarle a

establecer una lista de mejoras que necesita en el entorno de producción.

157

CONSIDERACIONES PARA LA MIGRACIÓN A DISEÑO IPV6

En esta sección se analizan los aspectos técnicos y los enfoques de diseño que los

diseñadores de redes o arquitectos deben tener en cuenta al migrar una red a IPv6

Adquisición de prefijos IPv6

El primer paso, y uno de los más fáciles, es adquirir un prefijo IPv6. Como diseñador de

red, dependiendo de los requisitos del negocio y de la disponibilidad de IPv6, puede elegir

entre prefijos independientes del proveedor (PI) y asignados por el proveedor (PA).

Para recibir un prefijo PI, debe enviar una solicitud al registro regional. Con base en la

aplicación, se asigna un prefijo mayor o menor. Para PI, los registros regionales asignan el

prefijo / 48 de forma predeterminada.

Si no se requiere un espacio de direcciones PI, el proveedor de servicios puede asignar un

prefijo PA para ubicaciones o sucursales remotas. Si el proveedor de servicios local no

ofrece IPv6 nativo, puede adquirir un prefijo que un corredor de túnel asigna para acceder

a la red IPv6.

Las siguientes son las diferentes asignaciones típicas de prefijo IPv6:

/ 40 prefijo: Está destinado a la mayor de las empresas. Este prefijo ofrece la

capacidad de abarcar miles de VLAN y soportar cientos de sucursales en una región

geográfica.

/ 48 prefijo: Es la asignación predeterminada para las grandes empresas.

/ 56 prefix: Ofrece hasta 256 VLAN. Este prefijo es apropiado para medianas y

pequeñas empresas. El prefijo / 56 también se asigna a menudo para servicios al

consumidor.

Proveedor Independiente Versus Proveedor Asignado

Antes de considerar si una asignación PI o PA es lo mejor para su diseño, es necesario

comprender la diferencia entre ellos desde punto de vista del proveedor de servicios.

Cuando el proveedor de servicios ofrece conectividad IPv6 nativa, asigna un prefijo desde

su propio segmento / 32. En este caso, el proveedor de servicios puede anunciar sólo un

158

prefijo grande a otros proveedores sentido norte, haciendo que la tabla global de

enrutamiento de Internet sea más eficiente y optimizada.

Sin embargo, al planificar una conectividad WAN o de Internet multihomed, recibirá varios

prefijos diferentes de los segmentos de distintos proveedores de servicios. A su vez, estos

prefijos IPv6 múltiples en su LAN se propagarán a los hosts, haciendo que la

autoconfiguración trabaje con múltiples prefijos. Dicho esto, esto puede llevar a

problemas de alta disponibilidad y multihoming cuando uno de los prefijos no está

disponible (puede considerar ocultar la información de accesibilidad, es decir, "agregación

de rutas"). Por lo tanto, como diseñador, usted necesita evaluar y decidir sobre la base de

los requisitos y prioridades.

La asignación PI se acepta como la principal solución multihoming. Es similar a las

soluciones IPv4 multihomed, y ofrece alta resiliencia si falla uno de los proveedores de

servicios. La asignación de direcciones IP se puede obtener del registrador regional, y la

asignación puede aumentarse si presenta un caso de negocio viable. El principal

inconveniente del direccionamiento PI es que los proveedores de servicios tienen que

anunciar una serie de prefijos PI además de los suyos. El aumento del número de prefijos

anunciados aumenta la tabla de enrutamiento global fuera de proporción.

Direccionamiento IPv6 PI versus PA

Proveedor Independiente (PI)

Proveedor asignado (PA)

PI es asignado por los registros de Internet.

PA es asignado por el proveedor de servicios.

Permanece asignado siempre y cuando el

usuario cumpla los criterios de asignación.

Es independiente del proveedor de servicios.

Hay preocupaciones acerca de la explosión

de la tabla de enrutamiento (igual que en

IPv4).

PI resuelve el multihoming y el balanceo de

carga del tráfico.

Algunos operadores de red pueden decidir no

asignar la asignación porque el prefijo no

puede agregarse.

En situaciones de multihoming, los hosts pueden tener

múltiples prefijos.

Los problemas multihoming tradicionales tienen que

ser resueltos mediante el uso de soluciones

alternativas o la evolución del protocolo.

El proveedor de servicios agrega todas las direcciones

de PA que asignó.

Requiere la renumeración al cambiar de proveedor de

servicios.

PA es eficaz para pequeñas sucursales con opciones

de conectividad limitadas.

Dónde iniciar la migración

159

Al abordar una migración o una transición a IPv6, primero debe pensar en dónde iniciar la

migración. Puede definir varios puntos posibles de partida, basado en el caso comercial de

la compañía.

WAN

Borde de Internet (por ejemplo, servicios Web y DMZ)

Centro de datos LAN

Una empresa puede decidir migrar toda la infraestructura. Sin embargo, debido a la

complejidad, puede sugerir comenzar con islas más pequeñas o infraestructura no crítica

para el negocio.

Los clientes a menudo eligen la WAN como el primer punto de contacto porque ofrece una

victoria rápida y requiere la menor cantidad de modificación de componentes. Si DMZ se

migra a continuación, es posible que ya sea capaz de tener una presencia IPV6 en Internet.

Desde el punto de vista del diseño, el proceso de migración de la WAN para que esté

habilitado para IPv6 incluye:

Adquirir un prefijo

Evaluación de los routers WAN

(Opcional) Actualización de los enrutadores WAN

Configuración de doble pila y peering en los routers WAN

160

Otras áreas de red pueden requerir más recursos para migrar a IPv6. Por lo tanto, la parte

de la red que más a menudo se deja como la última pieza del proyecto es la LAN, ya que

puede introducir un riesgo significativo para la continuación del negocio y muchos de sus

servicios. Esto lo convierte en el área de proyecto más exigente de cualquier proyecto de

migración IPv6.

Modelos de migración y consideraciones de diseño

En las siguientes secciones, se describen algunos enfoques posibles de migración que

usted, como diseñador de red, puede considerar al migrar la red empresarial a IPv6.

Isla IPv6

Un enfoque de migración comúnmente utilizado es la creación de islas IPv6. Las islas IPv6

pueden representar segmentos de red más pequeños dentro de la red empresarial que se

comunican entre sí sobre la infraestructura IPv4 existente.

Como se puede ver, la conexión de islas IPv6 requiere la introducción de un mecanismo de

tunelización que pueda llevar los paquetes IPv6. Si el número de islas IPv6 es pequeño, se

prefieren los mecanismos manuales de tunelización en la conexión de islas IPv6 porque

son fáciles de configurar y no hay necesidad de un despliegue a gran escala de túneles.

La creación de islas IPv6 tiene varios beneficios. Los más importantes son probar los

servicios esenciales y reunir la experiencia operacional. Cuando se toma la decisión de un

despliegue a gran escala, ya ha enfrentado y resuelto la mayoría de los problemas técnicos.

Esto reduce el riesgo de migración.

161

IPv6 WAN

A menudo, los sitios de las sedes corporativas incluyen múltiples conexiones hacia los

proveedores de servicios WAN para garantizar alta disponibilidad y multihoming. Con

IPv6, puede elegir entre varias opciones de diseño posibles con el fin de garantizar una

conectividad WAN multihoming. Para determinar qué opción es mejor o más factible a su

diseño, debe tener en cuenta las capacidades de su proveedor de servicio local, así como el

tipo de asignación de prefijo IP elegido. Los siguientes son los principales enfoques

utilizados para lograr la conectividad WAN multihomed con IPv6:

Enfoque asignado por el proveedor: Como ya se ha comentado, con este enfoque

cada proveedor de servicios asigna una red IP PA a la empresa. La preocupación

con este enfoque es que la distribución del prefijo de cada SP a todos los segmentos

de red generará varias direcciones IPv6 en los hosts. Esto puede causar problemas

en algunos escenarios. Por lo tanto, como diseñador de red, debe preguntarse cómo

reaccionarán sus aplicaciones y servicios una vez que el prefijo original no esté

disponible debido a un fallo. Aunque existen diferentes opciones de diseño posibles

para manejar fallas de enlace, ninguna de ellas puede ofrecer un diseño confiable

como el enfoque de diseño PI (la mejor práctica).

Enfoque independiente del proveedor: Con este enfoque de diseño, los routers

WAN anuncian el mismo prefijo PI a través de BGP a pares ascendentes que ofrecen

una solución multihoming válida y confiable. De esta manera, los SPs ahora llevan

su propio prefijo / 32 y todos los prefijos PI / 48 de los clientes. Sin embargo,

cuando se anuncian los prefijos PI de cada cliente, aumenta el tamaño de la tabla de

162

enrutamiento global. Además, la asignación de direcciones PI implica algunos

costos adicionales dependiendo de la política de registro regional.

Enfoque de intermediario de túnel: Una de las limitaciones comunes de diseño es

que cuando IPv6 forma parte de su estrategia comercial pero los proveedores de

servicios locales no ofrecen conectividad nativa, entonces puede implementar su propia

solución de tunelización para superponer la comunicación IPv6 a través de los enlaces

WAN / MAN, o puede comunicarse con un “corredores” (bróker) de túneles para solicitar

asistencia. Los corredores de túneles son, de hecho, proveedores de servicios que

ofrecen acceso a Internet IPv6 a través de túneles IPv4 manuales. Estos túneles se

encuentran en diferentes lugares geográficos. Un agente de túnel puede ofrecer métodos

de conectividad tanto PA o PI. Diseñar el acceso WAN de la sucursal es una tarea más

sencilla.

163

Debido a que las sucursales no siempre están destinadas a conectar con dos ISP, los

requisitos para un prefijo PI no son dominantes. Los métodos de acceso están a menudo

sujetos a la disponibilidad IPv6 del proveedor de servicios local que ofrece conectividad a

la sucursal.

En general, las siguientes son las opciones comunes de conectividad de la sucursal:

IPv6 nativo: El proveedor de servicios local ofrece un prefijo PA con el que la

sucursal se comunica con la sede.

IPv6 no nativo: La LAN de sucursal utiliza una subred asignada por la sede. La LAN

de la sucursal configura manualmente un túnel IPv4 a la sede central sin ofrecer

una ruptura local.

o

La sucursal LAN utiliza una subred PA asignada por un corredor de túneles. La sucursal

LAN se comunica con la sede a través del corredor.

Mecanismos de transición IPv6

Aunque puede seleccionar entre una serie de posibles mecanismos de transición, no puede

aplicar todos los mecanismos de transición a un determinado diseño de red. Por lo tanto,

se recomienda que elija los mecanismos que se alinean estrechamente con la estrategia de

despliegue de IPv6, teniendo en cuenta las limitaciones de diseño, como el conocimiento

del personal de TI o las funciones soportadas en las plataformas de hardware y software

en uso.

164

Además, muchos de los mecanismos de transición han sido obsoletos o no se han

implementado con frecuencia, como son los mecanismos de túnel semiautomático

(ISATAP, 6to4, Teredo, A + P, 464XLAT, 6over4, 4º, NAT-PT). De hecho, estas tecnologías

pueden plantear riesgos de seguridad significativos basados en cómo establecen túneles.

Desde el punto de vista del diseño de la red, cada mecanismo de aproximación o transición

tiene sus características, beneficios y limitaciones. Por lo tanto, la comprensión de estos

parámetros es vital debido a que esta comprensión facilita la selección de la estrategia

más aplicable para su situación. Como diseñador de red o arquitecto, debe tener en cuenta

que la economía puede ser considerablemente diferente dependiendo del enfoque de

diseño seleccionado, y estos enfoques no son iguales en costo, complejidad o capacidades

funcionales. Entender las opciones disponibles y decidir, en función de sus necesidades

particulares, le ayudará a seleccionar la opción y la estrategia de transición a largo plazo

más apropiada.

Las principales opciones disponibles de migración pueden dividirse en tres categorías:

Red de doble pila

Túnel

Traducción

165

Cada categoría puede incluir diferentes enfoques. Por ejemplo, el túnel se puede lograr

utilizando diferentes tecnologías de túneles, y cada una de estas tiene sus propias

características.

El modelo de despliegue de doble pila no siempre es factible debido a la complejidad, el

tiempo o los recursos. Debes tener en cuenta estos factores al considerar un mecanismo

de transición para facilitar la comunicación IPv6 a través de la red. Por lo tanto, este

capítulo, además de la pila dual, también discute brevemente los diferentes mecanismos

comunes de transición IPv6, centrándose en el escenario de uso adecuado de cada

mecanismo.

Doble pila

Como principal impulsor de una estrategia a largo plazo para la adopción de IPv6, las

empresas se enfrentan a considerar la pila dual en un momento u otro. La implementación

de pilas en hosts, dispositivos de red, servicios y aplicaciones es una tarea difícil porque

cada capa introduce nuevos desafíos.

Aunque la implementación puede ser compleja, la lógica detrás del despliegue es bastante

simple. Crear una red lógicamente independiente mediante el uso de los recursos

existentes. Ambos protocolos funcionan de forma totalmente independiente y ofrecen al

operador la capacidad de controlar cada uno de ellos sin afectar al otro. Esta

independencia permite al operador diseñar la nueva red sin consideraciones legadas, así

como implementar las mejores prácticas y funcionalidades del nuevo protocolo. La

implementación de la pila dual es transparente para los hosts.

La fase de evaluación del proyecto IPv6 es un requisito esencial para un modelo de

despliegue de doble pila, ya que cada red, dispositivo, servicio y aplicación requieren

soporte. La complejidad de la red se incrementa, y el costo y la asignación de recursos en

la implementación de doble pila son extremadamente altos en comparación con un

modelo de implementación híbrido.

La complejidad de la implementación puede conducir a varios escollos, lo que puede

ralentizar o detener completamente la implementación de doble pila. Tienes que

considerar todos los posibles escollos en la fase de evaluación para mitigar el riesgo de

fracaso.

Los peligros más comunes son los siguientes:

Los dispositivos con configuración fija pueden causar limitaciones de recursos. Un

dispositivo como un switch puede tener una cantidad fija de memoria o de

memoria TCAM. Cuando se comparte entre ambos protocolos, estos recursos

166

pueden ser significativamente más bajos para cada protocolo. Debido a que este

tipo de dispositivo no se puede actualizar, se tiene que cambiar el dispositivo.

Los dispositivos no pueden controlar los requisitos de rendimiento para el tráfico

IPv6. Un requisito esencial es que todos los hosts, dispositivos de red y aplicaciones

manejen los requisitos de implementación para el tráfico IPv6. Si el dispositivo es

capaz de manejar IPv6 pero no alcanza la capacidad de procesamiento requerida,

necesita ser actualizado o reemplazado.

La paridad de características de los dispositivos de seguridad normalmente no es

igual a IPv4. Su fase de evaluación debe incorporar la capacidad de imitar su

política de seguridad IPv4 a IPv6.

Sin los mecanismos de seguridad adecuados, usted abre su red a ataques externos.

Las aplicaciones heredadas o personalizadas no se pueden portar o no existe

ninguna solución alternativa. Tienes que reescribir la aplicación para que sea

independiente del protocolo porque la aplicación actual no es capaz de soportar

IPv6.

Los dispositivos host no tienen o tienen soporte limitado de IPv6. Los dispositivos

de bajo costo tienen capacidades de software limitadas que requieren actualización

o reemplazo.

Tabla 6-2 Pros y contras de la pila dual

Pros

No hay encapsulación, lo que ayuda a evitar el

aumento de la sobrecarga de paquetes.

Este modelo reduce la complejidad operacional

evitando o minimizando la necesidad de cualquier

tecnología de superposición para transportar

paquetes IPv6.

Los servicios IPv4 e IPv6 se ofrecen en paralelo y las

redes están lógicamente separadas.

El diseño de redes IPv6 puede incorporar las mejores

prácticas y las nuevas soluciones tecnológicas, ya

que no se carga con el diseño de legado.

Ofrece transparencia al usuario final.

Contras

La pila dual aumenta la complejidad del plano

de control.

Requiere soporte IPv6 completo de todos los

dispositivos.

Hay un alto costo y esfuerzo de

implementación.

Los recursos del dispositivo están divididos; Por

lo tanto, se requieren mayores capacidades de

hardware, como la memoria y la CPU.

Los clientes prefieren la ruta IPv6.

NAT64 y DNS64

167

Address Family Translation (AFT), o simplemente "traducción", facilita la comunicación

entre los hosts y redes sólo IPv6 e IPv4 (ya sea en un tránsito, un acceso o una red de

borde) mediante la realización de traducción del encabezado y las direcciones entre las

dos familias de direcciones.

La AFT no es una estrategia de apoyo a largo plazo, es una estrategia de coexistencia a

mediano plazo que puede utilizarse para facilitar un programa a largo plazo de transición

IPv6 tanto por parte de las empresas como de los ISP.

Uno de los escenarios comunes de habilitar IPV6 es que alguna organización puede

requerir una introducción inmediata de hosts sólo IPv6, en los que necesitará un

mecanismo de traducción que permita a sus hosts comunicarse con los nodos sólo IPv4.

Los escenarios siguientes son los más comunes que requieren NAT64:

Una red sólo IPv6 quiere acceder de forma transparente a contenido IPv4 e IPv6

existente.

Los servidores de una red sólo IPv6 quieren servir de forma transparente a los

usuarios de IPv4 e IPv6.

Los servidores de una red existente de IPv4 sólo desean atender a los usuarios IPv6

de Internet.

Tanto una red IPv4 como una red IPv6 están dentro de la misma organización y

requieren la posibilidad de acceder entre ellas.

Un escenario como un host IPv4 que desea acceder a un servidor sólo IPv6 también es

técnicamente y teóricamente posible, pero es improbable porque la mayoría de los

proveedores de contenido prefieren adoptar una estrategia de doble pila en lugar de una

estrategia sólo para IPv6.

NAT64, en cooperación con DNS64, es una opción viable para un escenario en el que un

host sólo IPv6 requiere acceso a un servidor sólo IPv4.

168

Este escenario sigue esta secuencia:

1. El host envía una solicitud DNS para el registro AAAA del servidor IPv4 al DNS64.

2. El DNS64 reenvía la consulta al DNS autorizado.

3. El DNS autorizado no responde con un registro AAAA porque no existe.

4. El nodo DNS64 envía una consulta A al DNS autoritativo solicitando la dirección

IPv4 del servidor de destino.

5. El servidor autoritario responde con el registro A adecuado.

6. El DNS64 transforma el registro A recibido en un registro AAAA que incluye la

dirección de destino IPv4 y responde a la petición inicial del host para un registro

AAAA.

7. El anfitrión no diferencia el registro AAAA recibido e inicia una sesión.

8. Debido a que la dirección IPv6 de destino no existe, debe ser encaminada a un

dispositivo NAT64. Un prefijo IPv6 específico necesita ser designado y siempre

enrutado al dispositivo NAT64.

9. El NAT64 establece la sesión IPv6 con el host y al mismo tiempo inicia la sesión

IPv4 con el servidor de destino.

10. El NAT64 enlaza ambas sesiones y reenvía el tráfico del host al servidor.

Túneles manuales

En algunos casos, es posible que necesite conectar varias islas IPv6 o sucursales

dislocadas en un período de tiempo reducido, a través de una red de transporte sólo IPv4.

En este caso, los túneles manuales se consideran una opción viable y ofrecen una solución

169

suficientemente simplificada y escalable para este tipo de escenarios. Las técnicas de túnel

implican el transporte a través de la encapsulación de un protocolo dentro de otro

protocolo (en nuestro caso, IPv6 tunneling encapsula paquetes IPv6 dentro de los

paquetes IPv4). Hay varios tipos de tunelización IP que puede utilizar para este propósito:

Encapsulación genérica de enrutamiento (GRE): este tipo de encapsulación admite

el tráfico de multidifusión, ofreciendo la capacidad de utilizar protocolos de

enrutamiento e implementar la multidifusión. Sin embargo, la sobrecarga

introducida es significativa, y puede ser difícil de inspeccionar con dispositivos de

seguridad.

IP-in-IP (IPIP): Se trata de un simple encapsulado IPv6 dentro de una cabecera

IPv4. Ofrece una sobrecarga menor en comparación con GRE, pero no soporta el

transporte de tráfico multicast. Las mismas limitaciones con respecto a la

inspección de seguridad se aplican como para el GRE.

Aunque los túneles manuales son fáciles de implementar, algunos no escalan a muchos

túneles (específicamente el modelo de túnel punto a punto). Por lo tanto, debe considerar

esta limitación al decidir sobre el método de implementación. Ningún método incluye

mecanismos de seguridad, y el tráfico puede ser interceptado e inspeccionado por un

tercero. Sin embargo, el cifrado de tráfico, autenticación e integridad se puede lograr

mediante IPsec. Considerar un modelo de túnel multipunto GRE (mGRE), como la VPN

multipunto dinámica (DMVPN) puede ofrecer una solución de superposición escalable

para enviar por túnel el tráfico IPv6 a través de una red IPv4.

Corredores de túneles

Los intermediarios de túneles se refieren a aquellos proveedores de servicios que ofrecen

la capacidad de conectarse al Internet IPv6 sin la conectividad IPv6 nativa original que

ofrecería el proveedor de servicios local. Un método de tunelización se utiliza para crear

un túnel IPv4 hacia el agente de túnel, que des-encapsula el tráfico, y lo envía al Internet

IPv6.

170

Además, los corredores de túneles pueden ofrecer varias ubicaciones geográficas para los

puntos finales del túnel, por lo que puede elegir el más cercano disponible para introducir

el menor retardo posible. Además, el corredor de túneles puede proporcionar su propia

asignación de direcciones PA o puede ofrecer peering avanzado BGP y publicidad del

espacio de direcciones PI asignado al cliente.

Despliegue rápido 6

Despliegue rápido 6 (o 6RD, descrito en RFC 5969) es un mecanismo de tunelización sin

estado que evolucionó desde el mecanismo de túnel 6 a 4. Ofrece conectar hosts con doble

pila con servidores IPv6 sobre una infraestructura IPv4. También aborda ciertas áreas

problemáticas, especialmente la limitación de uso de direccionamiento de túneles de 6 a 4.

6RD se desarrolló principalmente para permitir a los proveedores de servicios una

velocidad de despliegue rápida en la que los consumidores pueden pasar rápidamente a

un entorno de doble apilamiento sin necesidad de migrar toda la infraestructura de

transporte.

La solución 6RD consta de dos elementos de red:

Enrutador capaz de 6RD: Este enrutador de doble pila tiene la capacidad de

descubrir dinámicamente todas las direcciones utilizando el equipo de premisa del

cliente (CPE), donde el enrutador de retransmisión puede definirse de forma

estática o mediante una opción DHCP. El tráfico entre enrutadores con capacidad

6RD se enruta directamente y no tiene que pasar por ningún elemento de red

adicional. Es posible que tenga que actualizar o cambiar el dispositivo CPE para dar

soporte a las capacidades 6RD.

Retransmisor de frontera 6RD: Este elemento de frontera sin estado está

diseñado para desencapsular el tráfico tunelizado entrante y enviarlo a la red IPv6

de destino. Debido a que la operación es sin estado, puede implementar varios

171

elementos de retransmisión de frontera en su red para ganar resilencia. La

dirección de retransmisión de frontera se implementa a menudo como una

dirección Anycast que permite que el protocolo de enrutamiento compense el

equilibrio de carga y la alta disponibilidad.

El enrutador CE se encuentra en el borde de la infraestructura de acceso IPv4 del

proveedor de servicios y proporciona conectividad IPv6 a la red de este usuario final. El

tráfico IPv6 nativo que proviene del host del usuario final es encapsulado en IPv6 por el

enrutador CE y tunelizado al enrutador de retransmisión de borde o directamente a los

otros enrutadores de CE en el mismo dominio 6RD. Por el contrario, el tráfico 6RD

encapsulado recibido desde Internet a través del enrutador de retransmisión de frontera,

y el tráfico 6RD de otros routers CE, se descapsula y se envía a los nodos de usuario final.

Como resultado, desde el punto de vista del diseño, 6RD ofrece los siguientes beneficios:

6RD permite el aprovisionamiento rápido de IPv6 sobre el núcleo de sólo IPv4 sin

forzar la re-arquitectura al servicio existente.

6RD se puede introducir y desplegar de forma incremental.

El tráfico IPv6 sigue automáticamente el enrutamiento IPv4.

6RD ofrece un menor gasto de capital (CapEx) y protección de la inversión

(impacto limitado en la infraestructura existente).

Como una mejora en comparación con el túnel de 6 a 4, que obliga al uso del prefijo 2002 ::

/ 16, 6RD permite a un operador implementar su propio prefijo al asignar las direcciones

a la red. Debido a que 6RD fue desarrollado para ser utilizado en entornos de proveedores

de servicios, el prefijo 6RD se asigna como los primeros 32 bits. Los segundos 32 bits se

utilizan para encapsular la dirección IPv4 de destino o la dirección de retransmisión de

frontera que el CPE utilizará para fines de retransmisión

172

El tamaño del prefijo 6RD y la dirección IPv4 de destino pueden variar, por lo que puede

asignar 48 bits al prefijo 6RD y 16 bits a la dirección IPv4 de destino. Sin embargo, en esta

situación, los primeros 16 bits del destino IPv4 deben estar predefinidos.

Dual-Stack Lite (DS-Lite)

Dual-Stack Lite (o DS-Lite, descrito en RFC 6333) permite el aprovisionamiento de un

entorno de doble apilamiento en los hosts y facilita la conectividad de hosts de pila doble a

servidores IPv4 que requieren acceso a través de una infraestructura IPv6. En otras

palabras, la red de tránsito en este escenario se basa nativamente en IPv6, y el cliente está

obligado a implementar la compatibilidad con IPv4.

173

En este enfoque, el CPE juega un papel vital porque es un dispositivo de doble apilado y

permite:

El tráfico IPv6 se transportará de forma nativa.

El tráfico IPv4 se colocará en un túnel y se entregará al LSN o al CGN (carrier grade

NAT) para su traducción. Entonces, el paquete IPv6 se desencapsula, restaurando

el paquete IPv4 original. El NAT se realiza en el paquete IPv4 y se enruta al IPv4

Internet. El CGN identifica de forma única los flujos de tráfico registrando la

dirección IPv6 pública de CPE, la dirección IPv4 privada y el número de puerto TCP

o UDP como una sesión.

Nota LSN o CGN simplemente es una función NAT realizada a gran escala en el lado del

proveedor de servicios en lugar del lado cliente.

Localizador / protocolo de separación de ID (LISP)

La arquitectura de enrutamiento y direccionamiento de Internet actual, normalmente

utilizada, se basa principalmente en un único espacio de numeración -la dirección IP- para

expresar simultáneamente dos funciones principales sobre un dispositivo:

Identidad del dispositivo

Cómo se conecta el dispositivo a la red

El Locator / ID Separation Protocol (LISP), por otro lado, crea un nuevo paradigma

dividiendo la identidad de dispositivo que se conoce como un identificador de punto final

(EID) y su ubicación, conocida como localizador de enrutamiento (RLOC), en dos

diferentes espacios de numeración. La división de las funciones EID y RLOC genera varios

beneficios:

Multihoming simplificado y rentable

Ingeniería de tráfico de entrada más avanzada y capacidades óptimas de

enrutamiento

Movilidad de dirección IP y de host

La simplificación de la transición IPv6, incluyendo el despliegue incremental de

IPv6 utilizando la infraestructura IPv4 existente El uso de LISP como mecanismo de

transición IPv6, en particular, facilita el logro de:

o Multihoming IPv6

o Conexión de islas IPv6

Dispositivos de Borde de Sitio LISP

174

El nodo de borde del sitio LISP proporciona las siguientes funciones:

Enrutador de túnel de Ingreso (ITR): ITR se implementa como un dispositivo CE.

Recibe paquetes de interfaces que dan hacia el sitio y encapsula los paquetes

dirigidos hacia sitios remotos de LISP o envía nativamente los paquetes a sitios que

no son de LISP.

Enrutador de túnel de salida (ETR): ETR se despliega como un dispositivo CE.

Recibe paquetes en las interfaces orientadas al núcleo y desencapsula los paquetes

LISP o entrega nativamente paquetes no LISP a EIDs locales en el sitio.

Es común que los dispositivos de borde del sitio LISP (como los dispositivos CE)

implementen funciones ITR y ETR. En este caso, el dispositivo se denomina xTR. Sin

embargo, la especificación LISP no requiere que el dispositivo realice las funciones ITR y

ETR.

Para ambos dispositivos, el espacio de nombres EID se utiliza dentro de los sitios para las

direcciones de los sitios finales de hosts y enrutadores. Los EID entran en los registros

DNS. En general, el espacio de nombres EID no está enrutado en la infraestructura

subyacente. El espacio de nombres RLOC, por otro lado, se utiliza en el núcleo. Los RLOC

se utilizan como direcciones de infraestructura para enrutadores LISP y enrutadores ISP, y

se enrutan globalmente en la infraestructura subyacente. Los hosts no saben acerca de los

RLOC, y los RLOC no saben acerca de los hosts.

Dispositivos de Infraestructura LISP

Los siguientes son los nodos/funciones claves de la infraestructura LISP que debe tener en

cuenta en su diseño:

Map-Server (MS): La MS se despliega como un componente de Infraestructura

LISP. Configura la política del sitio LISP para los ETR LISP que se registran en él.

Esto incluye los prefijos EID, para los cuales los ETR de registro son autorizados, y

una autenticación que debe coincidir con la configurada también en el ETR. Los

Servidores de mapas reciben paquetes de control de registro de mapas de los ETR.

Cuando la MS se configura con una interfaz de servicio a la ALT LISP, inyecta

agregados para los prefijos EID para los ETR registrados en la ALT. La MS también

recibe paquetes de control de solicitud de mapa desde la ALT, que luego encapsula

en el ETR registrado que es autoritario para el prefijo EID que se está consultando.

Map-Resolver (MR): El MR se despliega como un dispositivo de infraestructura

LISP. Recibe las solicitudes de mapa encapsuladas por ITR y, cuando se configura

175

con una interfaz de servicio con la ALT de LISP, envía las solicitudes de mapa a la

ALT. Los equipos que resuelven mapas también envían respuestas de mapa

negativas a los ITRs en respuesta a consultas para direcciones que no son de LISP.

Router de túnel de proxy (PxTR): El ITR de proxy proporciona conectividad

entre sitios no LISP y sitios LISP. La funcionalidad Proxy ITR es un caso especial de

la funcionalidad ITR por la que el enrutador atrae paquetes nativos de sitios que no

son LISP (por ejemplo, Internet) destinados a sitios LISP y los encapsula y reenvía

al sitio LISP de destino. Un enrutador de túnel de proxy se sitúa idealmente en el

camino entre sitios LISP y no LISP. El PxTR puede poseer y ser controlado por la

empresa, o esta función puede ser proporcionada por el proveedor de servicios.

Como se discutió anteriormente, LISP no es una característica, ni fue inventado como un

mecanismo de transición IPv6 como la mayoría de las otras opciones enumeradas en la

sección anterior. Más bien, LISP es una nueva arquitectura de enrutamiento diseñada para

un propósito mucho más amplio. Debido a que está diseñado para alojar de forma

transparente varias familias de direcciones, el uso de LISP en soluciones de transición

IPv6 es muy natural.

El escenario más común en el que se utiliza LISP es el caso de uso de la transición IPv6 en

el que una empresa desea migrar gradualmente a IPv6 o adquirir experiencia básica con

IPv6, pero no tiene necesidades urgentes que ameriten un gasto de capital significativo

(CapEx) Gastos (OpEx) o cambios en la infraestructura existente. El enfoque típico

utilizado para lograr este objetivo es crear varias islas IPv6 a través de la red empresarial

176

(una en la sede, o en la sede y otra en los sitios remotos seleccionados). Entonces LISP se

puede introducir aquí para interconectar estas islas IPv6 juntos rápida y fácilmente sobre

la red IPv4 existente sin la necesidad de ningún cambio en la red subyacente. Esto resulta

en una solución rentable para este escenario. La aplicación de LISP en este escenario junto

con las siguientes funciones LISP requeridas:

El enrutador LISP HQ (RTR-A) se configurará para proporcionar servicios de

mapeado LISP y servicios de encapsulación LISP. Por lo tanto, este enrutador se

configurará como un equipo que resuelve Mapa / Servidor de Mapa (MR / MS) y

como un Enrutador de Túnel de Ingreso / Enrutador de Túnel de Salida (xTR) al

mismo tiempo.

Los enrutadores LISP de Spoke-1 y Spoke-2 (RTR-B y RTR-C) sólo se configuran

como LISP xTRs.

Además, uno de los otros escenarios para los que LISP puede utilizarse para proporcionar

servicio de transporte IPv6 se produce cuando una empresa o proveedor de contenido

necesita proporcionar acceso de usuarios de Internet IPv6 (usuarios / sitios no LISP) a

servicios o contenidos alojados en IPv6 Conectividad de Internet IPv4 existente. El

proveedor de servicios en este escenario ofrece funciones PxTR y anuncia rutas IPv6

empresariales hacia el Internet IPv6. Mientras tanto, la empresa sólo necesita desplegar

xTRs en su centro de datos. Con este enfoque, la empresa puede obtener rápidamente la

presencia de IPv6 sin tener conectividad directa IPv6.

177

PENSAMIENTOS FINALES SOBRE LOS MECANISMOS DE

TRANSICIÓN IPV6

Después de discutir los diferentes mecanismos de transición de IPv6, podemos hacer la

siguiente pregunta: ¿Qué mecanismo debemos considerar como una mejor práctica? La

respuesta simple a esta pregunta depende de varios factores, incluyendo las respuestas a

las siguientes preguntas:

¿Cuál es el entorno objetivo? Proveedor de servicios, proveedor de contenido, red

empresarial, etc.? Además, la respuesta a esta pregunta podría ayudarle a entender

la escala de la red.

¿Cuál es la meta de negocio final con respecto a IPv6? Migrar la red para que esté

totalmente, "de extremo a extremo", habilitada para IPv6 en el futuro, habilitar

parcialmente IPv6 para ejecutar determinados servicios solamente, etc.

¿Existen restricciones de diseño no técnicas? Por ejemplo, un marco de tiempo

limitado para habilitar IPv6, un presupuesto limitado para actualizar los

comentarios de la red para que estén preparados para IPv6, etc.

¿Existen limitaciones de diseño técnico? Por ejemplo, algunas aplicaciones pueden

no funcionar con NAT, pueden tener soporte limitado para ciertas tecnologías de

tunelización, es posible que IPv6 no esté soportado en ciertos dispositivos

centrales, los dispositivos de seguridad en la ruta no admitan IPv6, etc.

¿Hay consideraciones operacionales? Por ejemplo, los conocimientos y la

experiencia del personal de operación pueden preferir desplegar determinada

tecnología sobre otros para simplificar la capacidad de administración de la

solución en el futuro para ellos. Una vez que se hayan identificado las respuestas a

estas preguntas (idealmente durante la fase de planificación), el trabajo para usted,

como diseñador de la red, será más fácil de seleccionar el mecanismo de transición

IPv6 más adecuado y deberá tener en cuenta tanto el estado actual como el futuro.

178

Capítulo 7

Desafío en la Transición

a IPv6

179

SERVICIOS IPV6

Después de una cuidadosa evaluación de los dispositivos de red, tendrá que diseñar una

estrategia de despliegue. Se recomienda crear una lista de servicios que se migrarán en el

piloto o prueba de concepto (PoC). La planificación y realización cuidadosas de pruebas

ayudarán a establecer una base de servicios verificados que puede extender fácilmente a

toda la red de producción.

En esta sección se describen brevemente las consideraciones relativas a los siguientes

servicios:

Servicios de nombres

Servicios de direccionamiento

Servicios de seguridad

Servicios de nombres

Uno de los primeros servicios que es instrumental en cualquier implementación de IPv6 es

el Sistema de Nombres de Dominio (DNS). Para resolver correctamente nombres a

direcciones, la infraestructura de DNS debe contener los siguientes registros de recursos,

rellenados de forma manual o dinámica:

Registros de direcciones

Registros de recursos para las direcciones IPv4

Registros de recursos Quad A (AAAA) para las direcciones IPv6

Registros de recursos de puntero (PTR), que son necesarios para las direcciones IP

de los dispositivos que se pueden alcanzar a través del protocolo IPv4 / 6

Registros PTR en el dominio IN-ADDR.ARPA para las direcciones IPv4

Registros PTR en el dominio IP6.ARPA para las direcciones IPv6

Recomendaciones de implementación

Para aprovechar la resolución de DNS y correlacionar entre los servicios IPv4 e IPv6, debe

tener en cuenta lo siguiente:

180

Implemente el transporte de DNS en IPv4 como primer paso, lo que le permitirá

solucionar fácilmente cualquier problema y obtener experiencia operacional.

También le permitirá una configuración más fácil de los hosts, ya que no requieren

una dirección DNS en IPv6.

En una etapa posterior, implementar el transporte IPv6 de registros AAAA.

Implementar DNS dinámico para los hosts.

Las direcciones IPv6 que se autoconfiguran y tener un factor de aleatoriedad plantea un

problema para cualquier configuración de DNS, que necesita mantener un seguimiento

tanto del mapa hacia adelante (nombre a la dirección IP) y posiblemente el mapa inverso

(dirección IP a nombre).

Servicios de Direccionamiento

Dos mecanismos primarios están en uso para la asignación de direcciones:

DHCPv6: Protocolo de configuración de host dinámico versión 6 DHCPv6 es similar

en operación a DHCP; Permite el paso de opciones DHCP junto con la dirección

IPv6 DNS (Domain Name System), Protocolo de transferencia de archivos triviales

(TFTP), Network Time Protocol (NTP), etc.

Autoconfiguración de la dirección sin estado (SLAAC): SLAAC utiliza un

mensaje de autoridad de registro (RA) IPv6 que pasa el prefijo de red a los hosts,

que luego autoconfigura la dirección IPv6. Sin embargo, es extremadamente

limitado para pasar información opcional a los hosts. SLAAC implementa un

mecanismo para pasar información DNS a los hosts a través del servidor DNS

recursivo RDNSS; Sin embargo, DNS es la única información que puede transmitir.

Recomendaciones de implementación

En comparación con SLAAC, DHCPv6 es el método preferido de implementación porque

permite una mayor flexibilidad al manejar información adicional que necesita ser pasada a

los hosts.

Servicios de seguridad

181

Cuando está implementando IPv6, está abriendo una red completamente nueva que puede

ser explotada. Debe planear y preparar una directiva de seguridad que imite su política de

seguridad IPv4 existente antes de implementar IPv6 en producción.

El reto al que se puede enfrentar es que muchos vendedores no pueden ofrecer una

paridad de características completas; por lo tanto, se requiere una evaluación detallada

antes del despliegue. El proveedor le proporcionará una hoja de ruta IPv6 que puede

utilizar para planificar el despliegue de firewalls, dispositivos de inspección y

concentradores VPN remotos. A continuación, debe validar estos mapas de ruta y las

soluciones sugeridas en contra de la hoja de ruta (objetivo previsto) de la red empresarial

que está diseñando, junto con la directiva de seguridad de la empresa y cómo puede

integrarse entre ellos.

Por ejemplo, la red privada virtual (SLL VPN) de Secure Sockets Layer es el método

preferido para permitir a los usuarios remotos acceder a los servicios IPv6, ya sea de

forma nativa o vía túneles IPv6 a través de una VPN SSL IPv4. En algunos escenarios, la

directiva de empresa puede dictar que, dentro de la red interna de la empresa, no debe

haber encapsulación de tráfico / tunneled. Al tener esto en cuenta, deberá asegurarse de

que el tráfico tunelizado de VPN se debe descapsular y enviar de forma nativa antes de

entrar en la red interna.

CONSIDERACIONES DE SEGURIDAD DE LA CAPA DE ENLACE

Las recomendaciones comunes en IPv4 incluyen limitar o filtrar mensajes de ICMP

(Internet Control Message Protocol). Debido a que ICMP es un informe de errores o

protocolo de diagnóstico, puede muy bien ser filtrado o deshabilitado. Sin embargo,

ICMPv6 se ha convertido en el principal elemento de construcción de IPv6, y filtrar el

protocolo completo es casi imposible si desea tener una red IPv6 completamente

funcional. Estas funcionalidades en la capa de enlace no deben ser filtradas:

Descubrimiento del vecino (ND)

Autoridad de registro (RA)

Dedicación de direcciones duplicadas (DAD)

Redirecciones

Usted puede asegurar la capa de enlace a través de los mecanismos existentes que han

sido portados de IPv4 o mediante la implementación de nuevos. Por ejemplo, el acceso

generado criptográficamente (CGA) se utiliza para autenticar al propietario de una

dirección IPv6 real mediante el uso de PKI. El descubrimiento seguro de vecinos (SeND) se

desarrolló como un mecanismo de seguridad para proteger los mensajes ND y proteger

contra lo siguiente:

182

Invocación de vecinos / suposición de anuncios

Error de detección de no asequibilidad de vecinos

Detección de direcciones duplicadas: ataque DoS

Solicitud de Router y ataques de publicidad

Repetición de ataques

Ataques DoS de Descubrimiento de Vecino

Proteger las funciones de DHCPv6 con los mismos principios que en IPv4, donde los

dispositivos de capa 2 filtran los paquetes DHCPv6 basados en las interfaces que no están

conectadas al servidor DHCPv6 y limitan cualquier servidor DHCPv6 deshonesto para

asignar prefijos no autorizados a hosts (DHCP Snooping).

Por otro lado, ND puede ser vulnerable a los ataques DoS en los que un enrutador se ve

obligado a realizar la resolución de direcciones para muchas direcciones no asignadas. Por

lo tanto, debe filtrar direcciones no utilizadas a través de ACL y sintonizar el proceso de

Protocolo de detección de vecinos (NDP) cuando sea posible. Además, RA spoofing es un

vector de ataque bien conocido para los ataques de hombre en el medio (MITM). RA-Guard

resuelve el problema de los RAs deshonestos en los que los segmentos de red están

diseñados en torno a dispositivos de conmutación que son capaces de identificar RAs

inválidas y bloquearlas.

Soporte de aplicaciones

Al final de cada proyecto de migración IPv6, se enfrentará a la tarea más difícil: la

migración de aplicaciones críticas para el negocio. Cada negocio requiere un conjunto de

aplicaciones comunes que soporten el proceso general de negocio y un conjunto de

aplicaciones personalizadas pertinentes al área del negocio.

Las aplicaciones comunes son desarrolladas por vendedores de software notables. Las

aplicaciones tienen soporte IPv6 integrado o tienen una hoja de ruta comprometida para

el futuro desarrollo y soporte del protocolo.

Las aplicaciones personalizadas incluyen software que fue contratado y diseñado para

un proceso de negocio específico. Estas aplicaciones pueden ser críticas para el proceso

empresarial y no pueden ser intercambiadas por una aplicación más común o bien

conocida. A menudo, las aplicaciones personalizadas se construyen en casa debido a los

conocimientos internos y la experiencia que no se encuentra en el mercado. Evaluar una

aplicación personalizada es una tarea seria que incluye

Análisis de la aplicación (recopilación de archivos de captura y comunicación)

Independencia del protocolo (análisis de código)

183

Análisis de la documentación

Como resultado del análisis, puede encontrar que la aplicación sólo requiere una

modificación menor o una reescritura completa. Dependiendo del resultado, puede decidir

emplear una solución si la adaptación podría consumir demasiados recursos.

Adaptación de la Aplicación

Después de una evaluación cuidadosa de una aplicación personalizada, obtendrá

información sobre el nivel de adaptación requerido. La adaptación de la aplicación

requiere acceso al código fuente de la aplicación. Es posible que se enfrente a una

situación en la que la empresa propietaria del código ya no funciona. En ese caso, tendrá

que comisionar una reescritura completa de la aplicación o implementar una solución.

Cuando encuentre que una aplicación personalizada necesita adaptación, puede estimar el

esfuerzo de modificación mediante la categorización del proceso de adaptación en lo

siguiente:

Código independiente del protocolo: en la mayoría de las aplicaciones, las partes

de los códigos se ocupan principalmente de la lógica y el procesamiento

algorítmico sin llamar a ninguna llamada de sistema o API para llevar a cabo su

trabajo. Cuando la aplicación sólo incluye construcciones de lenguaje, puede ser

fácilmente portada o adoptada para la operación de IPv6.

Adaptación de la API: El código puede ser portado simplemente sustituyendo la

API y las estructuras de datos que usan las aplicaciones IPv4 para establecer una

sesión.

Modificación de las llamadas del sistema: esta categoría implica parte del código

que requiere la modificación de las llamadas de red, que pueden afectar a otras

partes del código y dependen de las estructuras de datos del sistema para

funcionar.

Modificación de la lógica del programa: Determinadas partes del código también

afectan a la lógica de la aplicación. Este código es más difícil de migrar y no se

puede transferir automáticamente.

Es probable que el código independiente del protocolo y la adaptación de la API sean

portados de forma fácil o incluso automatizada. Sin embargo, la modificación de las

llamadas del sistema y la modificación de la lógica del programa requieren un análisis

detallado y una reescritura del código para ser adoptado con éxito.

Solución Alternativa en las Aplicaciones

184

Si se enfrenta a una aplicación que no puede ser portada o que requiere demasiados

recursos para adaptarse, puede elegir una solución que aún puede permitirle utilizar sus

aplicaciones personalizadas. Por ejemplo, para que un servidor IPv4 en su DMZ esté

disponible para un cliente IPv6, puede utilizar NAT64 para fines de traducción. También

puede configurar asignaciones de direcciones estáticas y configure las direcciones DNS

AAAA y AA, DNS64 no es necesario. La configuración es adecuada para situaciones en las

que no se implementan equilibradores de carga.

Resumiendo, para entornos de centro de datos y balanceo de carga, puede usar el SLB64

para la traducción de IPv6 a IPv4. Puede configurar reglas automáticas o manuales. El caso

de uso es para el equilibrio de carga de una sesión TCP.

Además, "proxy" le permite mantener sus servidores en IPv4 y usar un servidor proxy

para manejar cualquier petición IPv6 (HTTP) a los servidores que aún no han sido

migrados. Muchas más implementaciones de servidor proxy también pueden funcionar

como servidores de almacenamiento en caché y ofrecer una implementación rápida de

servicios IPv6.

Seguridad del plano de control

Cuando implementa protocolos de plano de control, la tarea principal, junto a la

funcionalidad de implementación, consiste en implementar políticas de seguridad

asociadas con el plano de control. La autenticación vecina ya se ha implementado en la

mayoría de los protocolos de enrutamiento que soportan IPv6 y asegurará su intercambio

de información entre pares:

Protocolo de puerta de enlace de frontera (BGP)

Sistema Intermedio a Sistema Intermedio (IS-IS)

Protocolo de enrutamiento de puerta interior mejorada (EIGRP)

Abrir la ruta más corta primero (OSPF)

Protocolo de información de enrutamiento versión 2 (RIPv2)

El filtrado de rutas es otra herramienta de importación para proteger la infraestructura de

enrutamiento. La mayoría de los protocolos de enrutamiento permiten la configuración de

filtros de ruta que evitan que rutas específicas se propaguen a través de la red. En

términos de seguridad, estos filtros son útiles porque ayudan a garantizar que sólo se

anuncian las redes legítimas:

3ffe :: / 16: prefijo de 6Bone

2001: db8 :: / 32: prefijo de documentación

fe00 :: / 9: Enlace local y prefijo local local

185

En IPv4, comúnmente ICMP fue referido como una herramienta de diagnóstico que podría

introducir riesgos de seguridad; por lo tanto, se anima a muchos administradores de

sistema a filtrar el protocolo en los dispositivos de red. En IPv6, tiene que excluir

selectivamente ICMPv6 funcionalidad ya que se entrelaza profundamente en la nueva pila.

Neighbor Discovery y Router Anuncios son mensajes ICMPv6. También se le recomienda

que permita que los mensajes de error ICMPv6 en su enrutador WAN indiquen problemas

de conectividad como problemas de MTU y Destino inaccesible.

La mayoría de los protocolos ya se han adoptado para IPv6. El uso de SSH, Telnet o SNMP

puede permitirle utilizar la conectividad IPv6. Sin embargo, debido a la falta de paridad de

características en muchas soluciones de NMS, se recomienda mantener toda la gestión de

dispositivos críticos de negocio en IPv4 debido a que está demostrado y estable. A medida

que avanza el desarrollo del software de gestión, puede habilitarlo en una base más

pequeña de dispositivos para validarla antes de implementarla a escala completa en la red

de producción.

Consideraciones de seguridad de doble pila

La implementación de doble pila puede proporcionar varios beneficios, ya que incluye una

red lógicamente separada que se puede controlar sin afectar a la red IPv4 existente. Sin

embargo, debe tener en cuenta algunas consideraciones serias al contemplar pila dual:

Asegurarse de que la política de seguridad IPv6 esté a la par con la política de

seguridad IPv4 existente garantizará que no haya dejado ninguna abertura en su

red recién creada para ser explotada. Cuando se enfrenta con una falta de

características o un defecto de software que puede socavar su seguridad, debe

considerar si este defecto puede imponer graves riesgos de seguridad y, en última

instancia, detener el despliegue. La seguridad total de su red de doble apilamiento

es la cantidad de la red menos segura.

La pila dual carece de servicios de traducción como NAT para ocultar la presencia

de hosts en su LAN. Cada host ahora posee al menos una dirección IPv6

globalmente única a la que se puede acceder. La seguridad del host será más

importante ya que los hackers pueden intentar implementar vectores de ataque

directamente en los hosts cuando se conoce la dirección IPv6. La seguridad del host

debe incluir

Firewall personal

Prevención de intrusiones de host

Aunque los sistemas operativos de los hosts prefieren la pila IPv6 para la comunicación

saliente, es prudente que deshabilite la pila en los hosts antes del despliegue en

186

producción. Además, tenga en cuenta que una pila IPv6 habilitada puede causar tiempos

de espera excesivos debido a mecanismos de fallback en situaciones en las que se rompe la

conectividad de extremo a extremo IPv6.

Nota: Tenga en cuenta que, si deshabilita IPv6 en Windows Vista, Windows Server 2008 o

versiones posteriores, es posible que algunos componentes no funcionen porque Windows

fue diseñado específicamente con IPv6 presente.

Consideraciones sobre la Seguridad de los Túneles

Si no es capaz de implementar una pila dual debido al alto costo o la complejidad, lo más

probable es implementar túneles para interconectar las islas IPv6 con el resto de la

Internet IPv6. Existen varios métodos de tunelización, como se describió anteriormente,

pero la mayoría de ellos no incluyen ningún mecanismo de seguridad. Sin estos

mecanismos de seguridad, pueden ser fácilmente interceptados o el contenido de los

paquetes falsificados. Si la confidencialidad, la integridad y la autenticación son requisitos

previos, debe utilizar IPsec debajo del método de túnel preferido en lo posible.

Además, tenga en cuenta que el uso de mecanismos de creación de túneles puede

introducir un riesgo de seguridad en la forma en que operan o eluden las políticas de

seguridad existentes. Por ejemplo, Teredo probablemente estará habilitado por defecto y

será encapsulado dentro del puerto UDP 3544, que puede pasar la mayoría de los

dispositivos de seguridad si no está prohibido explícitamente. Además, un túnel se

construye de forma semiautomática a un punto final de tunelización de terceros, que

puede inspeccionar el tráfico o el contenido burlado.

Multihoming

Al igual que con la solución IPv4, múltiples negocios en todo el mundo requieren una

solución multihoming para ofrecer continuidad al proceso de negocio. Debido a que el

acceso a Internet fiable está disponible, el diseño de la WAN es bien conocido en IPv4. La

solución es una combinación de espacio de direcciones PI anunciado a través de BGP a un

proveedor en el nivel superior. Esta solución resuelve la mayoría de los problemas de alta

disponibilidad y es elegante de implementar para el cliente empresarial.

El mismo diseño es la mejor solución también en IPv6. Sin embargo, incluye sus

desventajas:

187

Explosión de la tabla BGP global

Falta de resumen

Solicitud y tarifa para PI en RIR

Ha habido intentos de resolver el problema del multihoming con dos o más asignaciones

de PA mediante el uso de una solución basada en el protocolo. Teóricamente parecía ser

compatible con los requisitos del cliente, pero introdujo más problemas. La solución de

protocolo más prometedora es LISP. Su diseño de protocolo lo hace muy natural para ser

utilizado con IPv6.

También se han propuesto resolver el multihoming con dos asignaciones de PA a través

del diseño alternativo de los enrutadores WAN; sin embargo, ninguna de estas soluciones

compite completamente con PI + BGP en la disponibilidad de la red, el equilibrio de carga

y la configuración del host. Puede utilizar enrutamiento basado en directivas, dividir su

subred en regiones o asignar segmentos de subred a sus hosts, pero puede encontrar

casos de uso en los que dichos diseños se enfrentarán a problemas.

188

Capítulo 8

VPN Gestionada por el

Proveedor de Servicios

189

Puede conectar sitios remotos a su sitio principal de múltiples maneras. Puede crear su

propia infraestructura, alquilar una solución de red privada virtual (VPN) del proveedor

de servicios o configurar su propia solución VPN a través de Internet. Este capítulo se

centra en las soluciones WAN (VPN) gestionadas por el proveedor de servicios (SP).

Cuando utiliza una solución VPN administrada, conecta sus dispositivos de red de borde a

la red de área extensa (WAN) del proveedor de servicios. El proveedor de servicios a su

vez se encarga del enrutamiento y el envío de tráfico a través de la WAN, lo que significa

que el proveedor de servicios es responsable de transferir paquetes de un sitio a otro. Los

proveedores de servicios construyen redes utilizando diferentes tecnologías subyacentes,

siendo las más populares Multiprotocol Label Switching (MPLS). Con el modelo MPLS VPN

de capa 3, las empresas pueden descargar su enrutamiento de la red WAN utilizando una

oferta de servicios IP privada de un proveedor de servicios. A diferencia de las redes de

superposición heredadas (tales como ATM o Frame Relay), las MPLS VPN requieren que la

empresa trabaje con el proveedor de servicios en el nivel de nivel 3 de IP. En este caso, la

red SP está implicada en el enrutamiento de Capa 3 de los paquetes IP entregados por la

empresa. Además, los proveedores de servicios modernos pueden ofrecer servicios de

WAN de nivel 2 emulados que mantienen el mismo modelo WAN de capa 2 heredado con

características optimizadas y un ancho de banda significativamente mayor, comúnmente

denominado MPLS de capa 2 VPN.

CÓMO ELEGIR SU CONEXIÓN WAN

Cuando se trata de elegir una tecnología WAN y un proveedor de servicios, debe

considerar las necesidades de su negocio. No hay una la mejor opción para cada

organización. La mejor opción es el proveedor o los proveedores que mejor responden a

sus necesidades organizativas y que ofrecen el servicio más transparente.

Como diseñador de redes, siempre debe evaluar las diferentes soluciones WAN en función

de los diferentes requisitos de diseño, que normalmente son una combinación de

requisitos técnicos y no técnicos. En otras palabras, hay algunos puntos de decisión

importantes cuando se elige la conexión WAN. Estos puntos de decisión pueden incluir la

disponibilidad de servicios, junto con aspectos financieros y técnicos.

Cuando diseñe su WAN, primero debe identificar la continuidad del negocio y los

requisitos de disponibilidad de las aplicaciones (específicamente las aplicaciones de

negocio de misión crítica). A continuación, debe comprobar la disponibilidad del servicio

VPN ofrecido. Una de las preocupaciones comunes con respecto a los servicios VPN

proporcionados por SP es que no todos los servicios están siempre disponibles en todos

los sitios del cliente. Por ejemplo, en las principales ciudades, normalmente los

proveedores de servicios ofrecen un alto nivel de redundancia, mientras que, en lugares

190

remotos, esta capacidad puede limitarse a ciertos proveedores, si los hay. Por lo tanto,

podría verse obligado a combinar varios servicios. Si tiene diferentes opciones, hay un par

de puntos de decisión importantes para elegir su conexión WAN.

Aunque el aspecto financiero no es un punto técnico, es muy importante tener en cuenta al

elegir su conexión WAN. Esto es cierto especialmente si el costo es uno de los principales

factores que influyen en el negocio para considerar una tecnología o si se asigna un

presupuesto limitado para el proyecto WAN. Por lo tanto, debe comparar el costo del

servicio, el costo del equipo y el costo operacional y asegurarse de que el costo de la

solución y proveedor de WAN seleccionado sea justificable para el negocio. Un aspecto

importante a tener en cuenta con la VPN de capa 3 es si el proveedor de servicios será

capaz de mantener su actual dirección IP de cliente (CE) porque el reenvío de todos sus

dispositivos CE puede ser una tarea complicada. Dicho esto, con la VPN de Capa 3, los

clientes empresariales no necesitan preocuparse por el rediseño o la configuración del

enrutamiento de la red WAN. En cambio, puede ser más complicado cambiar el proveedor

cuando elige una VPN de capa 2 porque el enrutamiento está bajo su control y todo el

rediseño y configuración será responsabilidad del cliente.

De hecho, varios aspectos técnicos pueden influir en su decisión cuando elija su conexión

WAN, incluyendo lo siguiente:

Convergencia: Con las VPN de Capa 3, el enrutamiento está bajo control de

proveedor de servicios, que también incluye el tiempo de convergencia. Cuando

elige una solución VPN de Capa 2, usted es responsable del enrutamiento. Sin

embargo, en ambos escenarios, el proveedor gestiona y controla la infraestructura

subyacente. En caso de fallo de enlace o nodo dentro de la nube MPLS del

proveedor, el proveedor de servicios será responsable de redirigir el tráfico a

través de una ruta / componente redundante. Como resultado, esto afectará el

tiempo de convergencia. Dependiendo del tiempo que el proveedor de servicios

necesita para recuperarse de un fallo, podría ser tan rápido como 50 milisegundos,

o podría tardar horas o días en caso de un fallo importante enlace de fibra sin

redundancia eficiente.

Escalabilidad: cuando elige una VPN de Capa 2, enfrentará problemas de

escalabilidad con las topologías de malla completa, en las que los protocolos de

enrutamiento pueden fallar debido a que tienen muchos vecinos y adyacencias. Con

una solución VPN de capa 3, cada dispositivo CE tiene una adyacencia sólo con el

dispositivo de borde de proveedor (PE) del próximo salto y, por lo tanto, es mucho

más escalable.

Calidad de servicio (QoS): Casi siempre, las conexiones WAN tienen ancho de

banda limitado. Por lo tanto, a menudo necesita QoS para priorizar el tráfico en

tiempo real. Los proveedores de servicios a menudo ofrecen QoS para su tráfico,

pero esta solución suele conducir a mayores costos. Además, el costo y el número

de clases ofrecido (clase de servicio, o CoS) varían entre los diferentes proveedores

de servicios.

191

Acuerdo de nivel de servicio (SLA) e informes: Algunos proveedores pueden

ofrecer algún tipo de SLA para sus servicios. Este SLA debe ser revisado para lograr

un nivel de servicio mínimo que esté de acuerdo con el contrato. Aunque los

detalles de un SLA pueden variar, en general debe cumplir con los requisitos

específicos y las necesidades de aplicación de red del cliente. Se pueden negociar

los siguientes productos de rendimiento de la red:

o Ancho de banda

o Latencias

o Fluctuación (jitter)

o Descarga de paquetes

o Disponibilidad de la red

o Reporte de SLA

Tráfico soportado: A menudo, puede que tenga que transferir tráfico como

multicast. Algunos proveedores de servicios admiten multicast, mientras que otros

no. Por ejemplo, es posible que necesite VPN de Capa 2 para permitir el

intercambio de mensajes de enrutamiento. En general, con una VPN de capa 3 VPN,

puede depender de las capacidades y soporte de enrutamiento y reenvío; En

contraste, con una VPN de Capa 2, tiene la flexibilidad de habilitar capacidades

como multicast o IPv6 según sea necesario. La razón es que usted (la empresa) está

desplegando y controlando el enrutamiento mientras que el proveedor de servicios

en una VPN de Capa 2 sólo proporciona el reenvío de tramas de Capa 2.

Tamaño MTU: Es importante reducir la fragmentación al mínimo. Por lo tanto,

necesita conocer el tamaño MTU para establecer los valores MTU apropiados en su

red. Además, es posible que tenga que reenviar marcos jumbo en escenarios en los

que envíe algunos paquetes encapsulados / tunelizados. Por lo tanto, el tamaño

MTU también es un aspecto técnico importante a considerar.

Cobertura de acceso y tipo de medio: Es fundamental comprender la cobertura

de acceso físico que cada proveedor de servicios puede proporcionar, ya que

algunos proveedores de servicios pueden no poder conectar alguna ubicación

remota como parte de su red. Cuando evalúa una oferta de servicio MPLS VPN por

un proveedor de servicios, debe comprender la cobertura de acceso de PE y

considerar en qué ciudades alrededor del mundo se encuentran los enrutadores PE

que se utilizan para las conexiones físicas del cliente. En algunos casos, los

proveedores tienen socios que proporcionan acceso local. Es importante

considerar las ubicaciones en las que estos socios ofrecen los enrutadores PE y

asegurarse de que esta cobertura satisfaga las necesidades de su organización.

Además, el tipo de medios de acceso es otro aspecto que debe tener en cuenta. Por

ejemplo, con una VPN de capa 3, normalmente puede tener opciones más flexibles,

como el cobre clásico (Ethernet), 3G, LTE y DSL, mientras que con una VPN de capa

2, las opciones son limitadas.

VPN MPLS de Inter-AS: Para establecer una huella de escala global, los

proveedores VPN MPLS pueden establecer asociaciones con otros proveedores de

servicios para interconectar MPLS VPN y tener presencia en ciertos países donde

192

no tienen PE locales. Esto se conoce como interprovider MPLS VPN. Con este

modelo, el coste puede aumentar significativamente al cruzar un enlace entre

proveedores. Además, las VPN inter-AS MPLS pueden afectar la disponibilidad o el

comportamiento de servicios como QoS y multicast. Un proveedor puede apoyar

estos servicios de una manera diferente a otra, o un proveedor puede no apoyar un

servicio en absoluto. Por lo tanto, es importante considerar los acuerdos SP inter-

AS y si la implementación soporta sus requisitos de red.

Servicio de Gestión de CE: Uno de los servicios comunes ofrecidos por los

proveedores de servicios actuales es el CE administrado. Con este servicio, los

clientes empresariales pueden tener acceso inmediato a los beneficios de una red

MPLS, con la disponibilidad de la red y la seguridad gestionada por el proveedor de

servicios. Con este modelo, las empresas con un personal de TI limitado o un

conocimiento limitado del enrutamiento pueden descargar el despliegue y la

gestión de los nodos CE al proveedor de servicios como un servicio pagado. Sin

embargo, con el modelo de servicio administrado CE, es importante entender los

límites del control administrativo del dispositivo CE. Por ejemplo, se limitará al SLA

ofrecido por el proveedor de servicios para realizar cualquier cambio o solución de

problemas a los dispositivos y los clientes empresariales no siempre desean estas

circunstancias.

Como diseñador de red, debe considerar las respuestas a las siguientes preguntas durante

la planificación y antes de implementar una VPN MPAN de la WAN:

¿Quién es responsable de la gestión de enrutamiento de la WAN central? ¿Existen

limitaciones en la experiencia de enrutamiento con respecto al personal de TI?

¿Quién administra los dispositivos WAN de los clientes?

¿Cuál es el número de sitios remotos, y cuál es el porcentaje del crecimiento

proyectado, si lo hay?

¿Cómo se distribuyen geográficamente los sitios remotos? ¿Dentro de una ciudad o

en diferentes ciudades o países?

¿Existen restricciones presupuestarias?

¿Cuáles son las capacidades de la WAN necesarias para transportar aplicaciones

empresariales a través de la WAN con la experiencia deseada (como QoS, IP

multicast o IPv6)?

VPN DE MPLS DE CAPA 3

La implementación más común de una VPN de Capa 3 es la MPLS VPN. MPLS es una

tecnología que se utiliza para reenviar los paquetes a través de la red principal, realizando

decisiones de reenvío basadas en etiquetas. A veces se denomina conmutación de

193

etiquetas. Por otra parte, el concepto general de VPN se refiere a las tecnologías que

proporcionan un puente entre dos islas de red, tales como redes privadas a través de una

red pública (Internet). La VPN MPLS Capa 3 es la tecnología que se utiliza para conectar

múltiples sitios de clientes. Esta solución se basa principalmente en los siguientes

protocolos de control:

MPLS se utiliza para reenviar paquetes a través del núcleo del proveedor de

servicios (utilizado principalmente para la conmutación de etiquetas entre el nodo

de red con la red del proveedor de servicios).

El protocolo Core IGP se utiliza para intercambiar sólo prefijos internos (incluida la

dirección IP de loopback de los nodos PE para formar sesiones del protocolo de

BGP entre ellos).

MP-BGP se utiliza para intercambiar rutas de cliente entre enrutadores de borde

del proveedor de servicios.

Enrutamiento del borde del cliente es el punto en el que el proveedor de servicios

intercambia el enrutamiento con el nodo de borde del cliente. Esto puede ser un

Interior Gateway Protocol (que es diferente del IGP central), Border Border

Gateway Protocol (EBGP) o ruta estática.

La tecnología MPLS VPN de Capa 3 es relativamente simple desde el punto de vista del

cliente. Un cliente debe conectar el equipo directamente a la red del proveedor de

servicios. Si el cliente utiliza enrutamiento dinámico para transferir rutas a otra ubicación,

debe configurar el IGP en sus propios enrutadores. Este IGP debe ser desplegado alineado

con el proveedor de servicios soportado e implementado IGP, y ambas partes necesitan

acordar los parámetros IGP. Desde una perspectiva de enrutamiento IP, cuando el

proveedor de servicios recibe las rutas del IGP, debe transferir estas rutas a las otras

ubicaciones. En este caso, BGP se utiliza para propagar las rutas a través de la red SP (de

un PE a otro donde están conectados los enrutadores CE del cliente). Esta arquitectura

puede conectar fácilmente un gran número de sitios juntos porque MP-BGP está diseñado

correctamente para transportar un gran número de rutas.

194

Como diseñador de red o arquitecto, debe recordar que, si considera la VPN de capa 3

MPLS, debe depender del proveedor de servicios con respecto a la introducción de

servicios IP de red como multicast o IPv6. No es fácil cambiar el proveedor de servicios

porque el enrutamiento completo debe reconfigurarse en la red de borde de la

organización.

Además, cuando elige una solución MPLS VPN de capa 3 para conectar los sitios, la red de

proveedores de servicios será la principal WAN que une los diferentes sitios remotos

juntos. Sin embargo, los escenarios de enrutamiento a veces pueden ser complejos, como

en una topología hub-and-spoke del cliente, donde el tráfico hacia y desde cada radio se

enruta a través del concentrador. Sin embargo, el despliegue más común es una topología

cualquiera a cualquier, donde cualquier sitio de cliente puede conectarse directamente a

otros sitios que pertenecen al mismo cliente a través del núcleo de MPLS VPN de Capa 3.

Cuando los paquetes IP entran en el dominio del proveedor de servicios, se encaminarán

en función de la información de enrutamiento en la tabla VRF de la VPN del cliente

correspondiente y se encapsularán con etiquetas MPLS para garantizar el túnel adecuado

y la desmultiplexación a través del núcleo.

Con este modelo de enrutamiento, la convergencia de enrutamiento y la confiabilidad de la

red central WAN no estarán bajo su control, por lo que dependen en su mayoría del

proveedor de servicios. Por lo tanto, debe asegurarse de que estos aspectos estén

cubiertos y acordados como parte del SLA con los proveedores de servicios para satisfacer

sus requisitos de continuidad de negocio y aplicación.

Arquitectura MPLS VPN

MPLS, IGP y MP-BGP forman la base de la MPLS VPN como protocolos de control. Los

principales componentes de la arquitectura MPLS / VPN que utilizan estos protocolos y

realizan un enrutamiento y un reenvío de extremo a extremo son los siguientes:

Red de clientes: es un dominio controlado por el cliente.

Enrutador de borde del cliente (CE): los enrutadores CE se encuentran en el

borde de la red del cliente. Estos enrutadores tienen conectividad directa a la red

de proveedores de servicios, específicamente al enrutador de borde del proveedor

(PE).

Red del Proveedor (P): Este dominio controlado por el proveedor consiste en los

enrutadores de PE y de núcleo. Estos enrutadores conectan los sitios de los clientes

a través de una única infraestructura subyacente compartida. El enrutador P se

refiere a veces como un enrutador conmutador de etiquetas (LSR), en referencia a

su función principal en el núcleo de la red, realizando la conmutación / intercambio

de etiquetas del tráfico MPLS.

195

Enrutador de borde de proveedor (PE): El enrutador de PE se encuentra en el

borde de la nube de proveedor de servicios MPLS. Está conectado a los enrutadores

CE y P. Los enrutadores PE proporcionan la capacidad de terminar enlaces de

nodos CE de clientes diferentes sin comprometer los requisitos de separación de

enrutamiento por cliente. El PE se denomina a veces enrutador de borde de

etiqueta (LER) o enrutador conmutador de etiqueta de borde (ELSR) en referencia

a su papel en el borde de la nube MPLS, realizando la imposición y disposición de

etiquetas.

Enrutador P: Los enrutadores P se encuentran en el núcleo de la red del proveedor

y están conectados a otro enrutador P o al enrutador PE. Los enrutadores P

realizan una rápida conmutación de etiquetas MPLS para enviar paquetes lo más

rápido posible a través de la red central.

Como en cualquier diseño de enrutamiento típico, el cliente debe empujar todas las rutas

que serán accesibles en los otros sitios del cliente a los enrutadores CE locales. Por lo

tanto, el cliente es responsable de implementar el protocolo de enrutamiento adecuado

para esta tarea.

Basado en la arquitectura descrita anteriormente, el enrutador CE sólo compara con el

enrutador PE conectado directamente fuera de su propio sitio. El enrutador CE no

compara con ninguno de los enrutadores CE de los otros sitios a través de la red de

proveedores de servicios.

En consecuencia, para que el cliente anuncie las rutas locales hacia el nodo de extremo del

proveedor de servicios (PE), el cliente y el proveedor de servicios (enrutadores CE y PE)

necesitan intercambiar información de enrutamiento utilizando un protocolo de

enrutamiento dinámico tal como OSPF o utilizando enrutamiento estático. A continuación,

el cliente debe inyectar todas las rutas que necesitan ser accesibles a los otros sitios en ese

protocolo de enrutamiento; Este protocolo de enrutamiento (entre el CE y PE) puede ser

la misma instancia que el protocolo de enrutamiento interno en los sitios del cliente o uno

diferente. De hecho, la selección del protocolo de enrutamiento es una cuestión de acuerdo

entre el cliente y el proveedor de servicios. Además, los proveedores de servicios

normalmente soportan ciertos protocolos de enrutamiento que se utilizarán con el lado CE

(más comúnmente, estático, OSPF y EBGP).

Por otro lado, el enrutador PE de entrada redistribuye las rutas del cliente al protocolo de

enrutamiento BGP. A su vez, BGP (específicamente MP-iBGP) propagará estas rutas

redistribuidas a los otros enrutadores PE (PE de salida), que se utilizan para conectarse al

mismo cliente. Estas rutas se redistribuyen de MP-BGP en IGP. IGP entre los enrutadores

PE y CE es entonces responsable de transferir las rutas al enrutador CE. MP-BGP sesiones

se establecen sólo entre los enrutadores PE en la red.

196

Consideraciones sobre el enrutamiento empresarial

Cuando está diseñando enrutamiento WAN empresarial y el transporte WAN es

proporcionado por un proveedor de servicios VPN L3 MPLS, es importante comprender

qué podría afectar el diseño de enrutamiento empresarial a través de la WAN. También es

necesario comprender si se necesitan cambios en el protocolo de enrutamiento utilizado

por el cliente empresarial y

Cómo este protocolo interactúa con el SP. Las siguientes son algunas de las principales

consideraciones generales:

Límites de ruta: Algunos proveedores VPN MPLS de nivel 3 imponen límites al

número de rutas que puede anunciar el cliente, en las que es posible que deba

considerar el resumen de rutas cuando sea posible para evitar este problema o el

proveedor puede solicitar cargos adicionales ( Que idealmente debería ser parte

del SLA acordado).

Protocolos de enrutamiento y modelos de conectividad admitidos: Los

protocolos de enrutamiento utilizados o admitidos como protocolo de

enrutamiento de borde de cliente de borde de proveedor (PE-CE) por el proveedor

de servicios y lo que la empresa utiliza internamente pueden dar lugar a problemas

importantes si no lo hacen tomarlos en consideración durante la fase de

planificación y diseño. Por ejemplo, una empresa podría utilizar EIGRP como IGP y

eBGP como protocolo PE-CE. En este escenario, debe considerarse cuidadosamente

la distancia administrativa, la redistribución entre EIGRP de / a eBGP y los bucles

de enrutamiento que pueden producirse. Además, como diseñador de red, debe

conocer el modelo de conectividad soportado entre el PE y el CE por el proveedor

197

de servicios y su impacto. Por ejemplo, cuando se utiliza conectividad backdoor

(conectividad fuera del servicio MPLS VPN para conectar dos enrutadores CE

directamente), existe la posibilidad de problemas tales como bucles de

enrutamiento o enrutamiento subóptimo. En este caso, debe asegurarse de que el

diseño de enrutamiento de la empresa tenga esto en cuenta y debe comprender lo

que es compatible con el proveedor de servicios en situaciones como esta. Por

ejemplo, ¿son compatibles los enlaces falsos de OSPF? ¿El PE soporta BGP costo

comunidad o sitio de origen (SoO)?

Equilibrio de carga: Normalmente, cuando tiene un sitio (enrutador CE) con doble

sede en diferentes PE, puede aprovechar el modelo de conectividad y utilizar todos

los vínculos para el tráfico. Sin embargo, el equilibrio de carga CE-PE es controlado

por la empresa, mientras que el equilibrio de carga PE-to-CE es controlado por el

proveedor de servicios. Por lo tanto, debe averiguar si el proveedor de servicios es

compatible con esto, y debe coordinar con el SP para lograr equilibrio de carga

adecuado.

Provider Edge (PE) Arquitectura del enrutador

Los enrutadores PE son componentes críticos en la arquitectura MPLS VPN porque los

enrutadores tienen la mayor parte de la inteligencia en el entorno MPLS VPN y realizan

múltiples funciones.

Una de las principales funciones del enrutador PE es aislar las instancias de enrutamiento

y el tráfico de los clientes. Dado que el enrutamiento debe ser separado y privado para

cada cliente en un enrutador de PE, cada cliente / VPN debe tener su propia tabla de

enrutamiento. Esta tabla se denomina tabla de enrutamiento virtual de enrutamiento y

reenvío (VRF). Normalmente, cada interfaz hacia un enrutador CE del cliente pertenece a

sólo un VRF. Por lo tanto, cada paquete que se recibe en la interfaz es inequívocamente

identificado como perteneciente a ese VRF. Esta implementación es similar a tener un

enrutador para cada cliente.

El enrutador PE debe establecer la adyacencia de enrutamiento IGP con los enrutadores

CE para obtener las rutas del cliente. Estas rutas se instalan en la tabla de enrutamiento

aislada. Alternativamente, el enrutador PE podría tener una ruta estática en la tabla de

enrutamiento aislada. Puede ser una carga operativa cuando necesite manualmente

configurar muchas rutas estáticas. Debido a que las tablas de enrutamiento están

completamente aisladas, MPLS VPN Capa 3 ofrece la flexibilidad para soportar el espacio

de direcciones superpuesto entre los diferentes clientes.

Los enrutadores PE intercambian rutas que se instalan en la tabla de enrutamiento VRF

con los otros enrutadores PE con MP-BGP. Como se mencionó anteriormente, MPLS VPN

capa 3 soporta espacio de direcciones superpuestas entre diferentes clientes. Cuando BGP

lleva prefijos IPv4 a través de la red de proveedores de servicios, deben ser únicos. Si los

198

clientes tienen direccionamiento IP superpuesto, el enrutamiento sería incorrecto. Para

resolver este problema, se introdujo el concepto distintivo de ruta (RD). La idea básica es

que cada prefijo de cada cliente recibe un identificador único para distinguir el mismo

prefijo de diferentes clientes. Cuando un enrutador prefiere el RD a la ruta, la ruta se

convierte en un VPNv4 prefixbin MP-BGP.

Además, cada enrutador PE mantiene su propia tabla de enrutamiento global que se utiliza

principalmente para establecer conexiones MP-BGP con otros enrutadores PE. Además,

los enrutadores PE utilizan esta tabla de enrutamiento para definir etiquetas MPLS a los

otros enrutadores P y PE para el reenvío de tráfico a través de la red central del

proveedor.

Distintivos de rutas

199

La idea básica detrás del RD es que cada cliente recibe un identificador único para

distinguir entre el mismo prefijo de diferentes clientes. Para crear un prefijo único, se

combina el RD con el prefijo IPv4. La combinación se denomina prefijo VPNv4. MP-BGP

necesita llevar estos prefijos VPNv4 entre los enrutadores PE.

Un RD es un identificador único de 64 bits prefijado al prefijo de cliente de 32 bits

aprendido del enrutador CE. La combinación del RD y el prefijo generará un prefijo IP

único de 96 bits que se puede transportar a través del dominio MPL-BGP como un prefijo

único (para superar las direcciones IP superpuestas de los clientes). Hay dos formatos

para el RD. El primero es ASN: nn, donde ASN representa el número de sistema autónomo

y nn representa un número. El segundo formato es la dirección IP: nn. El primer formato

es el más utilizado.

Las direcciones VPNv4 se intercambian solamente entre enrutadores PE, si los

enrutadores PE forman parte del mismo dominio SP / MP-BGP (escenario de un solo

sistema autónomo) o entre diferentes SPs / dominios MP-BGP (escenario Inter-AS /

proveedor). Por el contrario, las direcciones VPNv4 nunca se utilizan entre enrutadores PE

a CE.

El enrutador PE de entrada recibe el mismo prefijo IPv4 de dos clientes diferentes. A

continuación, estos prefijos se instalan en la respectiva tabla de enrutamiento VRF de cada

cliente. Cuando el enrutador PE propaga estas dos rutas a los demás enrutadores PE (PE

de salida), prefiere un RD diferente para cada prefijo de cliente para realizar una ruta

VPNv4 única por cliente. Cuando los enrutadores PE de salida remota reciben estas rutas,

eliminan los RD del prefijo VPNv4 e instalan las rutas en la tabla de enrutamiento VRF

correspondiente a cada cliente. El prefijo IPv4 se envía a los enrutadores CE. El valor de

destino de ruta (RT) controla la ruta que se va a instalar en la tabla VRF. La sección

siguiente lo cubre con más detalle.

200

Objetivo de la ruta (RT)

RT se considera parte de los elementos del plano de control primario de una arquitectura

típica MPLS L3 VPN porque facilita la identificación de qué VRF puede instalar qué rutas

VPN. Además, sería difícil lograr escenarios VPN más complejos si sólo está utilizando RD.

Considere un escenario en el que uno de los sitios tiene que participar en más de una VPN.

Para habilitar escenarios más complejos, se introdujeron RTs en la arquitectura MPLS

VPN.

Un RT es una comunidad BGP-extendida que identifica la membresía VPN de las rutas. Las

comunidades de BGP se utilizan para implementar RT. Los 16 bits de orden superior de la

comunidad BGPextended (64 bits totales) están codificados con un valor correspondiente

a la pertenencia a VPN del sitio específico.

Los RT están conectados a una ruta de cliente en el momento en que el enrutador PE

convierte la ruta desde una ruta IPv4 a una ruta VPNv4. Los RT asignados a la ruta,

denominados RT de exportación, se configuran por separado para cada tabla de

enrutamiento virtual en un enrutador PE. Las RT de exportación identifican un conjunto

de VPN en las que pertenecen los sitios asociados a la tabla de enrutamiento virtual.

Cuando las rutas VPNv4 se propagan a otros enrutadores PE, esos deben seleccionar las

rutas a importar en sus tablas de enrutamiento virtuales. Esta selección se basa en RT de

importación. Cada tabla de enrutamiento virtual en un enrutador PE puede tener un

número de RTs de importación configuradas. Identifican el conjunto de VPNs desde las

que la tabla de enrutamiento virtual acepta rutas.

En otras palabras, cuando el enrutador PE recibe la ruta VPNv4, comprueba las RT de

exportación que están conectadas a la ruta. Este RT se compara con el RT de importación

configurado en todos los VRF. El enrutador PE inyecta la ruta en la tabla de enrutamiento

VRF si hay una coincidencia entre la RT recibida y la RT de importación para la tabla de

enrutamiento VRF específica.

El enrutador PE inyecta rutas que se reciben con RT 1: 1 en la tabla de enrutamiento VRF

para el Cliente A. Las rutas con RT 1: 2 se inyectan en la tabla de enrutamiento VRF para el

Cliente B. El enrutador PE inyecta rutas con RT 1: 100 En ambas tablas de enrutamiento

porque ambas aceptan rutas con RT 1: 100. La ruta con RT 1: 100 podría ser un servicio

compartido al que diferentes clientes necesiten acceso, como un servicio basado en

software (software como servicio o SaaS) alojado por el mismo proveedor.

201

Protocolo de enrutamiento PE-CE

Como sabemos de las secciones anteriores, para que los clientes empresariales y la VPN

MPLS de Capa 3 intercambien información de enrutamiento, debe habilitarse una forma

de enrutamiento entre los dispositivos CE y PE. Esto puede ser enrutamiento estático, IGP

o BGP. Desde el punto de vista del diseño, además del enrutamiento estático, es necesario

comprender el comportamiento de un protocolo de enrutamiento cuando se utiliza como

protocolo de enrutamiento PE-CE, junto con las implicaciones asociadas. Esta sección

cubre las consideraciones de diseño cuando EIGRP, OSPF o BGP se utiliza como protocolo

de enrutamiento PE-CE.

Uso de EIGRP como protocolo de enrutamiento PE-CE

Cuando está diseñando y desplegando EIGRP como protocolo de enrutamiento PE-CE, es

importante entender cómo se comporta EIGRP y se trata en un entorno VPN MPLS de Capa

3. Típicamente, en un entorno MPLS VPN de Capa 3, habrá redistribución de ruta entre

MP-BGP y EIGRP como protocolo de enrutamiento PE-CE. Técnicamente, la redistribución

de las rutas de BGP en EIGRP interpreta todas las rutas como rutas externas EIGRP. Esto

significa que algunas piezas de información se pierden durante la redistribución, y esta

202

situación puede causar algunos problemas cuando tiene vínculos de backdoor entre sitios.

Para aliviar estos problemas, se introducen nuevas comunidades BGP ampliadas. Estas

nuevas comunidades permiten a los enrutadores PE remotos reconstruir las rutas EIGRP

con todas sus características. Estas características son los componentes métricos, AS, tag y,

para rutas externas, el número AS remoto, ID remoto, protocolo remoto y métrica remota.

Tabla 8-1 Atributos ampliados de la comunidad BGP para EIGRP

Tipo Uso Valor

0x8800 EIGRP Información general sobre la ruta Bandera y etiqueta de la ruta

0x8801

Información de la métrica de ruta EIGRP y sistema

autónomo

Sistema Autónomo y Retraso

0x8802 Información de la métrica de ruta EIGRP Fiabilidad, próximo salto y ancho de

banda

0x8803 Información de la métrica de ruta EIGRP Reserva, carga y MTU

0x8804 Información de la ruta externa EIGRP Sistema remoto autónomo y ID

remoto

0x8805 Información de la ruta externa EIGRP Protocolo remoto y métrica remota

Los siguientes son los escenarios más comunes y posibles al implementar EIGRP como

protocolo de enrutamiento PE-CE:

La empresa ejecuta EIGRP en todos sus sitios utilizando el mismo número EIGRP

AS.

La empresa está ejecutando EIGRP en todos sus sitios usando números EIGRP AS

diferentes.

La empresa está ejecutando EIGRP en algunos sitios, mientras que otros usan

protocolos de enrutamiento diferentes.

La empresa ejecuta EIGRP y dos o más enrutadores CE están conectados con un

vínculo de puerta trasera como vínculo de respaldo. La siguiente sección cubre

cada uno de estos escenarios con más detalle.

EIGRP como protocolo de enrutamiento PE-CE Usando el mismo número AS

203

Como se muestra en la Figura, la empresa ejecuta EIGRP en todos sus sitios. La empresa

también está utilizando el mismo número AS en todos sus sitios. En este caso, se utilizan

los siguientes pasos:

Paso 1. El enrutador CE1 anuncia una red a través de EIGRP al enrutador local PE1. Esta

red puede ser interna o externa.

Paso 2. El enrutador PE1 redistribuye la red de EIGRP en MP-BGP con información de ruta

codificada en los atributos de comunidad extendida dentro de MP-BGP. Envía las

actualizaciones de enrutamiento a otros enrutadores PE.

Paso 3. El enrutador PE2 recibe la actualización MP-BGP, que incluye información de la

comunidad ampliada para EIGRP, así como un número EIGRP AS coincidente.

Paso 4. El enrutador PE2 vuelve a crear las rutas EIGRP y las envía al enrutador CE2. Estas

rutas tienen el mismo tipo de ruta que las rutas originales, y tienen la misma métrica que

el PE1 de envío tenía para estas rutas. La columna vertebral aparece como coste cero.

EIGRP como el protocolo de enrutamiento PE-CE utilizando diferentes números AS

Como se muestra en la Figura, la empresa está ejecutando EIGRP en todos sus sitios, pero

utiliza diferentes números EIGRP AS. En este caso, se utilizan los siguientes pasos:

Paso 1. El enrutador CE1 anuncia una red a través de EIGRP al enrutador local PE1.

204

Paso 2. El enrutador PE1 redistribuye la red de EIGRP en MP-BGP con información de ruta

codificada en los atributos extendidos de la comunidad dentro de MP-BGP.

Paso 3. El enrutador PE2 recibe la actualización MP-BGP que incluye información

extendida de la comunidad para EIGRP, así como un número EIGRP AS.

Paso 4. El enrutador PE2 vuelve a crear la ruta EIGRP como una ruta EIGRP externa

utilizando la métrica predeterminada configurada y anuncia la ruta al enrutador CE2.

EIGRP como el Protocolo de enrutamiento PE-CE en algunos sitios solamente

Como se muestra en la Figura 8-10, la empresa está ejecutando EIGRP en algunos sitios,

pero no en otros. En el ejemplo, uno de los sitios utiliza OSPF como protocolo de

enrutamiento. En este caso, se utilizan los siguientes pasos:

Paso 1. El enrutador CE1 anuncia una red a través de OSPF al enrutador PE1 local.

205

Paso 2. El enrutador PE1 redistribuye la red de OSPF en MP-BGP con información de ruta

codificada en los atributos de comunidad extendida dentro de MP-BGP.

Paso 3. El enrutador PE2 recibe la actualización MP-BGP, que no incluye ninguna

información extendida de la comunidad de EIGRP.

Paso 4. El enrutador PE2 vuelve a crear la ruta como una ruta EIGRP externa utilizando la

métrica predeterminada configurada y lo anuncia al enrutador CE2. El protocolo originado

parece ser BGP.

EIGRP como protocolo de enrutamiento PE-CE con un vínculo de puerta trasera entre los

sitios de clientes

Desde una perspectiva de diseño de red, este escenario es el más complicado, ya que

puede conducir a enrutamiento subóptimo o bucles de enrutamiento si no está diseñado

correctamente. Como se muestra en la Figura, los enrutadores CE se conectan mediante un

enlace de puerta trasera como enlace de respaldo. EIGRP AS-1 ejecuta el enrutamiento

EIGRP de intercambio entre CE1 y PE1 y entre CE1 y CE2. Cuando el enrutador CE1

anuncia un prefijo, se anuncia al enrutador PE1 y al enrutador CE2. PE1 instala esta ruta

en VRF, redistribuye esta ruta EIGRP en BGP y pasa la ruta al enrutador PE2. Asimismo, el

enrutador CE2 anuncia esta ruta al enrutador PE2. En esta etapa, el enrutador PE2 tiene

dos rutas BGP disponibles para el prefijo:

El anuncio IBGP del enrutador PE1

La ruta BGP localmente redistribuida del CE2 EIGRP

Esta decisión conduce a que el tráfico se transmita a través del enlace de puerta trasera

como su ruta principal. Este resultado puede no ser lo que usted desea alcanzar; por

206

ejemplo, el enlace de puerta trasera podría ser un enlace de baja capacidad de ancho de

banda y sólo desea utilizarlo como ruta de respaldo. Como diseñador de red, debe

asegurarse de que el diseño de la red siempre cumple los requisitos de las aplicaciones

críticas para su negocio. En este caso, si el tráfico se envía a través del enlace de puerta

trasera como la ruta principal, esto probablemente afectará la calidad de las aplicaciones y

la experiencia de los usuarios porque es un enlace de baja capacidad de ancho de banda.

El atributo adicional que se conoce como la comunidad de costos BGP se desarrolló para

manejar estos casos. La comunidad de costes BGP está configurada en el enrutador PE, que

adjunta un atributo de comunidad extendida. El valor de la comunidad de costos se

compara e influye en la determinación de la trayectoria. Cuando esta comunidad se ajusta

según sea necesario, el tráfico puede ser reenviado a la ruta correcta.

De forma predeterminada, cuando el PE redistribuye la ruta EIGRP en BGP, el atributo de

comunidad de costes BGP se rellena con la métrica EIGRP. Como se muestra en la Figura ,

PE2 tiene dos opciones: la ruta IBGP que se aprende de PE1 o vía BGP originada

localmente aprendida a través de la redistribución de la ruta EIGRP de CE2. La métrica

EIGRP de la ruta que se anuncia desde CE2 incluye el costo adicional de atravesar el enlace

de puerta trasera. Por lo tanto, la comunidad de costos BGP de la ruta IBGP es menor y por

lo tanto preferida e instalada.

Uso de OSPF como protocolo de enrutamiento PE-CE

Cuando está diseñando y desplegando OSPF como protocolo de enrutamiento PE-CE, es

importante comprender cómo se comporta OSPF y se trata en el entorno VPN MPLS de

capa 3.

207

En primer lugar, la naturaleza de OSPF como protocolo de enrutamiento de estado de

enlace y cómo se seleccionan rutas es completamente diferente de EIGRP. Como se

mencionó anteriormente, como diseñador de red, primero debe comprender cómo se

comporta el protocolo para poder optimizar el diseño. Dicho esto, el concepto general de

propagación de la ruta a través de la capa 3 MPLS VPN es el mismo con ligeras diferencias

basadas en el protocolo utilizado.

Al igual que EIGRP, OSPF puede ser diseñado para utilizar diferentes enfoques, tales como

los mismos números de área en todos los sitios, diferentes números de área, OSPF en

algunas veces sólo, y CEs con un enlace de puerta trasera. Además, la opción de diseño con

un enlace de puerta trasera entre CE es siempre la más compleja y necesita ser diseñada

cuidadosamente.

Como sabemos, OSPF usa áreas para crear una jerarquía de red. Área 0 es el área de la

columna vertebral que conecta todas las otras áreas. En un diseño PE-CE con VPN MPLS de

capa 3, el backbone MPLS VPN puede considerarse como una jerarquía añadida que es

superior al área de la columna vertebral OSPF. Se puede llamar la espina dorsal super de

MPLS VPN. En realidad, no es un área porque ejecuta IBGP. Sin embargo, actúa como un

área, y PE actúa como un ABR cuando se anuncia tipo 3 LSAs a los routers CE. O bien, actúa

como un ASBR cuando anuncia tipo 5 LSAs a los enrutadores CE. En otras palabras, el área

0 no es obligatoria cuando se conecta al servicio MPLS VPN incluso si los sitios remotos

utilizan números de área diferentes.

También, el mismo concepto se utiliza con EIGRP; Varias comunidades adicionales BGPextendidas

fueron definidas para transportar los atributos de las rutas OSPF a través del

backbone MPLS VPN, incluyendo

208

Tipo de ruta

Número de área

ID del enrutador OSPF

ID de dominio

Tipo métrico 1 ó 2

El PE puede reconstruir completamente la ruta OSPF con estas comunidades BGPextendidas

específicas de OSPF. El tipo de ruta indica qué tipo de ruta debe anunciar el PE

en OSPF. El PE remoto publicitará una ruta de resumen interaúrea (LSA tipo 3) en el área

OSPF para los tipos de ruta 1, 2 y 3 (tipos LSA 1, 2 y 3). El ID de dominio indica al

enrutador PE remoto cómo anunciar una ruta OSPF externa. De forma predeterminada, el

ID de dominio es el mismo que el ID de proceso. Si el ID de dominio de la ruta recibida es

diferente del proceso OSPF en VRF, la ruta se anuncia como una ruta externa OSPF (LSA

tipo 5) tipo 2. De lo contrario, la ruta se anuncia como una ruta interna.

Para conservar la métrica OSPF, el PE utiliza la métrica OSPF para establecer el atributo

BGP MED. Cuando la ruta se redistribuye de nuevo a OSPF en el PE remoto, el PE utiliza el

MED para establecer la métrica OSPF de la ruta OSPF interna o externa.

En consecuencia, es importante entender que OSPF como un protocolo de enrutamiento

PE-CE sobre una VPN MPLS se comporta ligeramente diferente de su comportamiento

normal en una red enrutada típica. Como se muestra en la Figura, CE2 espera recibir el

prefijo sitio-1 10.11.1.0/24 como la ruta Inter-area de resumen de tipo 3 desde el otro

sitio; Sin embargo, lo recibe como tipo externo 5.

209

Si observa más de cerca, verá que los identificadores de proceso OSPF en PE1 y PE2 son

diferentes. Normalmente, el ID del proceso OSPF sólo es localmente significativo; Sin

embargo, en una instalación MPLS VPN, la nube actúa como si fuera un solo enrutador

OSPF. Por lo tanto, el ID de proceso OSPF debe coincidir. De lo contrario, se generan rutas

externas de tipo 5. En otras palabras, cuando el PE de salida redistribuye la ruta MP-BGP

de nuevo al OSPF y el identificador de proceso OSPF no coincide con el ID de proceso OSPF

del PE de entrada, la ruta se inyectará como tipo externo 5.

El inconveniente de este resultado de diseño es que todas las rutas OSPF se convierten en

externas en el PE remoto cuando las rutas se redistribuyen de nuevo al OSPF. Cuando se

tiene un enlace de puerta trasera entre los CE que anuncian el mismo prefijo que una ruta

interaúrea (LSA tipo 3), esta redistribución hará que las rutas a través de MPLS VPN sean

menos preferibles que las rutas que se aprendieron a través del enlace de puerta trasera.

Además, en este escenario, el enrutador PE se convierte en un ASBR desde el punto de

vista CE porque generará rutas OSPF externas (LSA tipo 5).

Si este comportamiento puede causar un problema como un enrutamiento sub-óptimo a

través de un enlace de puerta trasera, debe asegurarse de que tanto los PE de entrada

como de salida tengan el mismo ID de proceso OSPF configurado o que necesite configurar

el mismo ID de dominio en ambos PE para resolver el problema.

Ambas opciones ofrecen una solución que evitará que las rutas redistribuidas se

conviertan en rutas externas OSPF. En cambio, las rutas se convertirán en rutas interareas.

Esto es diferente del comportamiento OSPF típico porque los enrutadores PE están

realizando redistribución, lo que normalmente generaría rutas OSPF externas (LSA tipo 5).

Los enrutadores PE en realidad se convierten en enrutadores ABR en lugar de enrutadores

ASBR. Sin embargo, todas las rutas internas de OSPF se convierten en rutas interaera tras

atravesar el backbone MPLS / VPN, incluso si el número de área coincide con diferentes

enrutadores PE / CE.

OSPF como protocolo de enrutamiento PE-CE con un vínculo de puerta trasera entre los

sitios de clientes

En la operación OSPF normal, las rutas intra-área son más preferidas que las rutas

interáreas. En la MPLS VPN, todas las rutas OSPF internas se convierten en rutas

interáreas en los sitios remotos. Cuando existe un enlace de puerta trasera entre los sitios,

puede haber un problema porque todas las rutas intra-área siguen siendo rutas intra-área

a través del enlace de puerta trasera. Por lo tanto, siempre se prefieren las rutas intraaéreas

que se anuncian a través del enlace de puerta trasera. Para evitar esta situación,

debe configurar un vínculo especial entre los enrutadores PE. Este enlace se denomina

enlace farsante.

210

El enlace simulado se incluye en el cálculo del SPF, al igual que cualquier otro enlace en

OSPF. Los LSAs están inundados a través del enlace farsante y todos los tipos de ruta OSPF

se conservan y no se convierten a LSA tipo 3 o 5. Si falla el enlace falso, el enrutamiento

sigue siendo posible, pero entonces todas las rutas se convierten en rutas interareas y

rutas a través de La puerta trasera toma preferencia.

Incluso si el vínculo falso existe y las rutas OSPF se inundan a través de él, el BGP debe

seguir la publicidad de las rutas OSPF como VPNv4 rutas de PE a PE. La razón de esto es

que BGP debe llevar etiquetas MPLS VPN para el reenvío correcto a través de la columna

vertebral VPN MPLS.

Consideración de diseño de resumen de ruta de OSPF

Cuando se utiliza OSPF como el protocolo de enrutamiento PE-CE, no habrá área de la

columna vertebral (área 0) en el centro para pegar todas las áreas diferentes. En su lugar,

la nube MPLS VPN actuará como una super columna vertebral para proporcionar el

transporte de prefijos OSPF utilizando MP-BGP. Como resultado, esta arquitectura

impondrá un cambio a la jerarquía clásica OSPF o a la estructura de las áreas; a su vez,

esto afectará cómo se puede hacer el resumen de rutas. Por ejemplo, en el escenario

representado en la figura, si el sitio HQ (área 0) necesita enviar una ruta de resumen a

todos los otros sitios, el sitio remoto 4 debe recibir sólo una única ruta de resumen para

otros sitios.

El resumen no se puede realizar en ninguno de los CE (lado del cliente) porque ABR y

ASBR no existen en el lado del cliente. Para cumplir con los requisitos de resumen

descritos anteriormente, PE1 puede enviar la ruta resumen de la red HQ a través de BGP y

211

anunciar la dirección resumida a todos los otros sitios. Además, para enviar una ruta de

resumen sólo al sitio 4, debe resumir todas las rutas de otro sitio en PE4.

Nota: Después de configurar la ruta de resumen en PE4, esta ruta de resumen se

propagará a todos los sitios como resultado de la redistribución de OSPF a BGP; Por lo

tanto, debe tener cuidado al habilitar el resumen en un entorno con OSPF. La ruta de

resumen debe ser filtrada mientras se redistribuye OSPF en BGP en PE4, a menos que sea

deseable enviar el resumen a otras PEs.

Uso de BGP como protocolo de enrutamiento PE-CE

BGP, específicamente EBGP, se puede utilizar como protocolo de enrutamiento PE-CE. De

hecho, es uno de los protocolos más comunes utilizados para el encaminamiento entre los

dispositivos CE y PE, ya que ofrece capacidades de diseño flexible para manejar todos los

diferentes modelos de conectividad PE-CE.

Después de elegir el MP-BGP como su protocolo PE-CE, debe determinar el esquema de

asignación de MP-BGP AS. La selección de un número de MP-BGP AS para sitios

empresariales es una consideración importante. Afecta a otros aspectos del

comportamiento de la red, como el equilibrio de carga, la prevención de bucles de ruta y la

caracterización del sitio sobre el origen AS.

212

Usted tiene básicamente dos opciones para la asignación de números BGP AS: puede

utilizar el mismo o un único MP-BGP AS para cada sitio de cliente.

Una de las principales ventajas de la asignación de un AS único por sitio es que identificar

al autor de la ruta. Puede lograrlo comprobando el atributo AS path del origen MP-BGP AS.

Esta identificación simplifica la solución de problemas. Un único AS por sitio también

permite filtros de ruta de AS simples para realizar manipulación de ruta MP-BGP para un

sitio en particular. Estas ventajas son las razones por las que el uso de un AS único por

sitio es la solución preferida. Sin embargo, esta solución puede introducir una limitación

con respecto a los números AS disponibles y al número de sitios por cliente (también

denominados colisiones AS).

Una de las ventajas de usar el mismo AS para cada sitio es que reduce la posibilidad de AS

colisiones. Sin embargo, el uso del mismo AS para cada sitio de cliente también crea cierta

complejidad.

Un par de MP-BGP realiza la prevención de bucle AS al verificar que el atributo AS path de

la actualización recibida contiene su propio número AS. Si la ruta cumple con estas

213

condiciones, se descarta. Dado que el CE en el otro sitio ve su propio número AS en el

atributo AS path, descarta la actualización.

Si desea utilizar el mismo número de AS para cada sitio de cliente, debe deshabilitar la

prevención de bucle AS. El proveedor de servicios utiliza el comando as-override para

realizar esta tarea. Cuando el proveedor de servicios utiliza este comando, sustituye el

número AS del cliente por su propio número en el atributo AS path.

Mecanismos como el anular la prevención de bucles producen algunos requisitos

adicionales de complejidad y configuración para el proveedor de servicios. Otro problema

al utilizar as-override es que ninguna de las rutas MP-BGP puede identificarse de forma

exclusiva como proveniente de un sitio específico que se basa en el atributo AS path. Si el

enrutador CE debe identificar el origen de la ruta que se basa en algún atributo, debe

utilizar otros mecanismos, como las comunidades estándar MP-BGP. Necesita una

configuración adicional en el enrutador CE para admitir esta opción.

La reescritura del atributo AS path impide que el enrutador CE detecte un bucle MP-BGP,

lo que puede crear problemas en sitios multihomed. Puede evitar esta situación utilizando

el atributo de comunidad extendida de sitio de origen (SoO). Este atributo extendido de la

comunidad se adjunta a una ruta MP-BGP y se utiliza para identificar el origen de la ruta.

Como se muestra en la Figura, si el valor SoO asociado al prefijo es el mismo que el adjunto

al SoO configurado para el peering / interface MP-BGP, se bloquea la publicación de la

ruta.

BGP como protocolo de enrutamiento PE-CE con un vínculo de puerta trasera entre los

sitios de clientes

214

Cuando el cliente tiene un enlace de puerta trasera entre los sitios, el escenario más

común es que la misma ruta se anuncia sobre el enlace de puerta trasera usando un IGP y

EBGP sobre el backbone MPLS / VPN. Debido a que es necesario redistribuir las rutas

desde el MP-BGP al IGP en el enrutador CE, las rutas que atraviesan el backbone MPLS /

VPN se convierten en externas, mientras que las rutas sobre el enlace de puerta trasera

son internas. Debido a que se prefiere una ruta interna sobre la externa, en este caso, el

enlace de puerta trasera se utilizará para alcanzar el otro sitio en lugar de la red principal

VPN de MPLS. Este comportamiento no siempre es deseable. Una manera simple de

resolver el problema es resumir las rutas sobre el enlace de puerta trasera. En este caso,

las rutas sobre el MPLS / VPN serán más específicas, por lo que los routers usarán esta

ruta.

VIRTUAL PRIVATE WIRE SERVICE (VPWS)

Desde el punto de vista del cliente, Virtual Private Wire Service ofrece una solución para

que los dispositivos vean los dispositivos en los sitios remotos como dispositivos

conectados directamente de una manera punto a punto. Dado que este servicio

proporciona un transporte de Nivel 2, los dispositivos CE pueden ser routers o switches.

Cuando conecta un enrutador al servicio VPWS, debe implementar enrutamiento, como un

protocolo de enrutamiento IGP, para reenviar el tráfico entre los sitios. Debido a que es un

servicio de nivel 2, la red es completamente transparente para los enrutadores de CE; por

215

lo tanto, los dispositivos de capa 3, como los enrutadores, necesitan formar una

adyacencia directa. La ventaja de esta solución es que usted obtiene un control completo

sobre su enrutamiento en la WAN. No necesita tener ningún acuerdo con el proveedor de

servicios. Si tiene varios enlaces a la WAN de los enrutadores CE, puede influir en qué

enlace sería el principal y cuál sería el secundario mediante el protocolo de enrutamiento

deseado. También puede utilizar las métricas de coste IGP para controlar el reenvío.

VPWS ofrece dos opciones de modo de operación desde el lado del proveedor de servicios:

Modo de puerto, en el que las tramas 802.1Q se tunelizan de forma transparente

Modo VLAN

El modo de operación PE afecta al despliegue de CE. Cuando el PE está operando en el

modo de puerto, el VPWS actuará como un tubo entre los nodos PE, en el que todo el

tráfico se tuneliza al sitio remoto. El CE necesita una dirección IP en la interfaz física. Debe

estar en la misma subred que la interfaz física en el sitio remoto. También puede usar

subinterfaces cuando desee tener varias conexiones de Capa 3 al sitio remoto. Cuando

conecte un nuevo sitio remoto, deberá conectar físicamente un enlace extra del CE al

enrutador PE del concentrador. Por lo tanto, esta solución se utiliza principalmente para

un número bajo de conexiones punto a punto. Por otro lado, cuando el PE está

funcionando en el modo VLAN, puede configurar varias subinterfaces en el enrutador PE.

Cada subinterfaz está conectada a un sitio remoto diferente, en el que cada etiqueta VLAN

802.1Q puede ser asignada a un circuito diferente emulado por VPWS (también conocido

como pseudowire, o PW). La solución se puede utilizar para topologías hub-and-spoke. En

216

dicho despliegue, también debe configurar diferentes subinterfaces en el enrutador de

concentrador CE, como se ilustra en la Figura. El modo VLAN se utiliza con un enrutador

de concentrador, mientras que el modo de puerto se utiliza con los radios.

También puede utilizar switches como dispositivos CE para extender la red de capa 2

entre sitios remotos. Esta solución suele usarse para proporcionar una Interconexión de

Data Center. Debe asegurarse de que STP está habilitado en los conmutadores y de que las

BPDU pasan por la red para evitar bucles de conmutación (dentro de cada DC) y filtrar STP

/ BPDU a través del DCI.

Usted debe considerar algunas otras características de la red al elegir la solución VPWS;

Estas características pueden influir en su implementación como cliente. Algunos de ellos

son la unidad de transmisión máxima (MTU) admitida en la WAN, el soporte de calidad de

servicio (QoS) y la transparencia.

Servicio de LAN Privada Virtual (VPLS)

Virtual Private LAN Service emula un segmento LAN a través del backbone MPLS.

Proporciona una conectividad de nivel 2 multipunto entre sitios remotos.

217

Como se muestra en la Figura, el VPLS que se ejecuta sobre MPLS emula un switch

Ethernet donde cada puerto está conectado a un sitio de cliente diferente. Los PE están

interconectados en una malla completa a través de la columna vertebral MPLS del

proveedor de servicios.

VPLS aprenderá automáticamente las asociaciones de origen MAC a puerto, y los marcos

se reenvían en función de la dirección MAC de destino. Si se desconoce la dirección de

destino o se trata de una dirección de difusión o de multidifusión, la trama se inunda en

todos los puertos que están asociados con el puente virtual. El núcleo VPLS no utiliza STP.

En su lugar, utiliza reenvío con horizonte dividido para que las tramas Ethernet no se

envíen de vuelta al mismo PW o a cualquier pseudowires (parte de la misma malla PW

cliente) parte del núcleo. Siempre y cuando haya una malla completa de PWs, no hay

necesidad de que ningún PE retransmita ningún paquete al núcleo; Por lo tanto, la regla

del horizonte dividido no reducirá la eficiencia de reenvío a través del núcleo.

218

VPLS actúa como un switch Ethernet para el cliente y aporta los mismos problemas de la

capa 2, incluyendo

Estabilidad de la red a medida que crece: El cliente debe comprobar si existe un

diseño de red básico apropiado para soportar el crecimiento futuro.

Impacto de las interrupciones de la red: El cliente debe preguntar acerca de lo

que sucede con el tráfico si hay una interrupción.

Multicast y tráfico de difusión entre sitios: Debido a que la red VPLS actúa como

un switch, todas las difusiones y difusiones de clientes se envían a todos los sitios.

Cuando diseña una red que tendrá cantidades significativas de tráfico de

multidifusión, debe segmentar su red de tal forma que reduzca el alcance de las

inundaciones de multidifusión.

Escalabilidad de peering de IGP: La red VPLS es un dominio de difusión, por lo

que todos los enrutadores conectados normalmente serían pares de enrutamiento.

A medida que aumenta el número de pares de enrutamiento, la malla completa de

las conexiones se convierte en un problema de escala. El único protocolo que está

diseñado para un gran número de compañeros es BGP. Por lo tanto, debe

considerar el uso de BGP como el protocolo de enrutamiento en grandes redes

VPLS.

Impacto del bucle STP de otro cliente: Debido a que VPLS utiliza multiplexación

estadística, todos los clientes comparten el ancho de banda. Es razonable

preguntarse cuál sería el impacto de un cliente con un bucle de árbol de expansión

en otros clientes. Si el cliente está conectado a través de un conmutador de capa 2,

todos los paquetes del bucle necesariamente serían inundados dentro de los

enlaces que están interconectando sus sitios VPLS. Si se conectan a 1 Gbps y los

trunks del proveedor son 20 Gbps, el impacto puede no ser tan malo. Si los enlaces

de proveedores son 2 Gbps, el impacto podría ser mucho mayor, especialmente si

EtherChannel está en uso.

Consideraciones sobre la seguridad de la capa 2: Debido a que el tráfico de

todos los clientes atraviesa la misma red central, debe verificar que el proveedor ha

implementado medidas de seguridad adecuadas para la capa 2.

Consideraciones de escalabilidad de VPLS

Un proveedor de servicios VPLS diseño debe abordar tres factores principales de escala:

Escalado de la malla completa de pseudowires entre los dispositivos de PE: A

medida que crece el número de dispositivos de PE, cada dispositivo de borde debe

formar una adyacencia con todos los demás dispositivos de PE. Esta adyacencia

requiere que los dispositivos de borde tengan la dirección IP de todos los PE

remotos en su tabla de enrutamiento. También requiere que las rutas PE

intercambien información de etiquetas entre ellas. Esto introduce un problema de

escalado del plano de control N-1.

219

Replicación y reenvío de tramas: el VPLS reenvía las tramass Ethernet utilizando

las direcciones MAC de capa 2. El funcionamiento de VPLS es el mismo que el

encontrado en los puentes 802.1. En ese caso, el switch aprende las asociaciones

MAC de origen de puerto a puerto y reenvía las tramas basándose en la dirección

MAC de destino. Si se desconoce la dirección de destino o se trata de una dirección

de difusión o de multidifusión, la trama se inunda en todos los puertos que están

asociados con el puente virtual.

Tamaño de la tabla de direcciones MAC: Una de las principales consideraciones

en el diseño del proveedor de VPLS es el aprendizaje de direcciones MAC. Los

dispositivos de PE deben ser capaces de administrar tablas de direcciones MAC

para muchos dispositivos de clientes y muchos clientes. Ese número es mucho

mayor de lo que un conmutador de campus empresarial típico necesita administrar

hoy.

Nota: Los nodos PE con VPWS no necesitan mantener la información de la dirección MAC

del cliente. VPLS, sin embargo, tiene que mantener todas las direcciones MAC del cliente

en el PE.

Para abordar los problemas de escalamiento en las implementaciones de VPLS grandes, se

introdujo VPLS jerárquico. H-VPLS reduce la sobrecarga de señalización y los requisitos de

replicación de paquetes para el borde del proveedor. Como se muestra en la Figura 8, en

este modelo se definen dos tipos de dispositivos de borde de proveedor: un borde de

proveedor orientado al usuario denominado borde de proveedor de usuario (UPE) y un

borde de proveedor de red (NPE). El cliente relaciona directamente y agrega el tráfico

VPLS antes de que llegue al NPE donde se realiza el reenvío de VPLS.

El H-VPLS aborda algunos de los factores de escala, incluyendo los siguientes:

220

Escalado de la malla completa de pseudowires entre los dispositivos PE: H-

VPLS ayuda a resolver este problema utilizando dispositivos UPE para distribuir la

carga de trabajo de borde a través de múltiples dispositivos menos costosos. Un

número menor de pseudowires entre los dispositivos NPE ayuda a escala de la red

mediante la reducción de la carga sobre el núcleo de replicación de fotogramas y

reenvío.

Replicación y reenvío de tramas: H-VPLS necesita un menor número de

pseudowires porque sólo los dispositivos NPE están conectados en una malla

completa. Ayuda a reducir la carga en el núcleo para la replicación de fotogramas y

el reenvío.

Tamaño de la tabla de direcciones MAC: H-VPLS permite que las tablas MAC se

distribuyan entre varios dispositivos de bajo costo para escalar el borde. Los

dispositivos UPE sólo necesitan aprender sus dispositivos NPE locales y por lo

tanto no necesitan soportar la tabla de enrutamiento grande. Los dispositivos Core

NPE todavía necesitan administrar tablas de direcciones MAC muy grandes. El uso

de MPLS en el núcleo elimina el requisito de aprendizaje MAC de los dispositivos

proveedores.

El cliente debe estar interesado en lo bien que el diseño del proveedor maneja todos estos

factores. Un diseño deficiente de VPLS puede conducir a problemas de escalado y

estabilidad a medida que crece la red P. El cliente no necesita estar íntimamente

familiarizado con los diseños de VPLS para evaluar el servicio. Sin embargo, escuchar las

respuestas del proveedor de servicios sobre estos temas puede proporcionar información

sobre las calificaciones de ese proveedor.

Además, la escalabilidad IGP puede ser un problema sobre las redes VPLS emulado. Todos

los enrutadores que están conectados a las redes VPLS ven el segmento como un segmento

221

de difusión. IGP actúa como si muchos enrutadores estuvieran conectados al mismo

segmento de difusión.

Cuando se utiliza OSPF como un protocolo de enrutamiento, se recomienda utilizar

algunos vecinos en el mismo segmento de difusión. En general, ningún enrutador debe

tener más de 60 vecinos. Este número se puede alcanzar rápidamente en redes VPLS más

grandes. El problema es que, si algunos sitios experimentan pérdida de paquetes, el

procesamiento OSPF puede consumir más CPU de enrutador en todos los enrutadores del

segmento. El mismo problema puede estar presente cuando algunos enlaces están

aleteando.

Otro problema que puede causar inestabilidad en la red VPLS es la pérdida de

conectividad entre el enrutador designado (DR) y el enrutador designado de respaldo

(BDR). El protocolo de enrutamiento OSPF reduce el número de adyacencias que se

necesitan mediante DR / BDR. Cuando los enrutadores están conectados a redes VPLS,

eligen uno de estos como DR. Todos los enrutadores forman adyacencia con este

enrutador. Si la conectividad entre el DR y el BDR se pierde debido a un fallo con algunos

pseudowires de circuitos virtuales emulados a través de la red VPLS, el BDR se convierte

en un DR, lo que causará problemas en la red de difusión porque habrá dos DRs. Estos

problemas hacen que OSPF sea menos preferible para una red VPLS. Por lo tanto, es más

conveniente considerar el tipo de interfaz punto a multipunto OSPF para evitar este

problema DR y DBR.

Un problema similar se aplica a EIGRP. También debe evitar tener muchos compañeros

con EIGRP.

Cuando tiene una implementación de VPLS grande, puede particionar su red para reducir

el número de adyacencias entre routers. Otra alternativa es utilizar BGP como el protocolo

de enrutamiento porque está diseñado para tener muchos pares. O, puede considerar el

uso de una VPN MPLS de Capa 3 si tiene un gran número de sitios.

Consideraciones de Resiliencia de VPLS

Una ventaja de usar VPLS es que MPLS se utiliza para el plano de datos. Si se produce un

fallo en la red P, el tráfico se encaminará automáticamente a lo largo de rutas de respaldo

disponibles en la red P.

Sin embargo, hay un costo para esta conmutación rápida. Si los pseudowires redundantes

se utilizan desde dispositivos PE redundantes, un fallo puede requerir el envejecimiento

de direcciones MAC, seguido de unicast inundación. Los paquetes perdidos resultantes,

seguidos de una oleada de tráfico, tendrían un impacto negativo en el tráfico de clientes.

El redireccionamiento de PW alrededor de interrupciones impide este problema potencial.

Aunque el redireccionamiento PW aumenta la disponibilidad del servicio VPLS dentro de

la red de proveedores, no protege contra fallas en el bucle local o el dispositivo CE. La

222

implementación de dispositivos CE redundantes y bucles locales redundantes es un

desafío porque no existe un Protocolo Spanning Tree que se ejecute entre el cliente y el

proveedor para ayudar a prevenir posibles bucles de puenteo.

Nota: Diferentes tecnologías y enfoques se utilizan en las redes de hoy para superar los

problemas de bucle discutidos aquí. Incluyen la solución Cisco A-VPLS, Cisco IOS EEM y N-

PE. Además, la próxima generación de VPLS, también conocida como Ethernet VPN

(EVPN), supera estas limitaciones. Para obtener más información, consulte IETF RFC

7432.

VPLS Versus VPWS

Aunque tanto VPLS como VPWS son tecnologías que ofrecen transporte de la capa 2 WAN

entre los sitios de los clientes, no son idénticos. Como diseñador de redes, usted debe ser

consciente de las diferencias entre estas dos tecnologías para que pueda seleccionar la

tecnología adecuada al elegir el transporte WAN e identificar las limitaciones de la que

está actualmente en uso por un cliente como tecnología WAN.

Tanto VPWS como VPLS ofrecen la conectividad VPN de capa 2 entre sitios remotos. Sin

embargo, VPWS es una tecnología punto a punto en la que cada enrutador PE tiene

conexiones pseudowire con los otros enrutadores PE. Debido a que es una tecnología

punto a punto, se necesita un pseudowire para cada sitio remoto. Claramente, este

enfoque podría plantear problemas de escalabilidad cuando hay muchos sitios remotos.

VPLS puede superar este problema porque ofrece un modelo de conectividad punto a

multipunto.

Debido a que VPWS es una tecnología punto a punto y VPLS es una tecnología punto a

multipunto, eso también significa que los requisitos en los dispositivos CE son diferentes.

En VPWS, el dispositivo CE debe realizar la conmutación, lo que significa que el CE debe

elegir qué pseudowire debe utilizar para enviar datos al sitio remoto. El enrutador de CE

en VPLS simplemente envía datos que se destinan al enrutador PE del sitio remoto. El

enrutador PE debe entonces decidir dónde enviar este tráfico.

Debido a que la red VPLS actúa como el conmutador Ethernet, también debe proporcionar

algunas de las características que son las funciones principales del conmutador de red.

Además del reenvío, también debe cuidar la prevención del bucle, el aprendizaje dinámico

del MAC para el reenvío correcto a los sitios remotos y el envejecimiento del MAC. Está

claro que los enrutadores PE deben realizar más tareas que no son necesarias con VPWS.

VPWS puede ser la opción principal cuando se desea conectar algunos sitios remotos. Por

ejemplo, puede utilizar VPWS cuando desee conectar sus dos centros de datos en la misma

red de capa 2. Por otra parte, cuando usted tiene muchos sitios, usted utilizaría muy

223

probablemente la tecnología de VPLS. Si desea configurar una topología hub-and-spoke,

puede configurar una conexión punto a punto para cada sitio desde el enrutador

concentrador. También puede configurar punto a multipunto en el concentrador y punto a

punto en los radios.

En general, el Portador Ethernet de hoy utiliza estas tecnologías a través de una única red

básica unificada basada en MPLS para ofrecer la capacidad de interconectar diferentes

islas Metro Ethernet, como se ilustra en la Figura.

224

Capítulo 9

WAN Gestionada por la

Empresa

225

VISTA GENERAL DE LA VPN GESTIONADA POR LA EMPRESA

Las conexiones VPN permiten a los usuarios enviar datos entre ubicaciones de sitios

remotos y acceder a recursos corporativos centralizados de una manera segura y eficiente.

Las dos principales categorías de soluciones VPN son

Soluciones VPN remotas

Soluciones VPN de sitio a sitio

El objetivo de las soluciones VPN remotas es conectar usuarios específicos a través de

capacidades específicas de dispositivos entre sí ya recursos centralizados. Un ejemplo de

una solución VPN remota moderna es SSLVPN. Las soluciones VPN remotas normalmente

requieren que los usuarios tengan un software especial en sus dispositivos para establecer

la conectividad de nuevo a la empresa.

El objetivo de las soluciones VPN de sitio a sitio y el enfoque de este capítulo es conectar

dos LAN a través de dos o más ubicaciones de sitios remotos a través de un transporte de

terceros para formar una VPN administrada por la empresa. Ejemplos de estas soluciones

VPN son enrutamiento genérico.

Encapsulación (GRE), seguridad de protocolo de Internet (IPsec), GRE sobre IPsec, red

privada virtual multidimensional dinámica (DMVPN) y muchas otras soluciones de VPN

administradas por la empresa que se tratan en este capítulo. Una capacidad común

introducida por muchas de estas soluciones es crear túneles virtuales y superposiciones

para reenviar tráfico. La implementación de VPNs administradas por la empresa suele

implicar dependencias de equipos de red.

Las VPNs gestionadas por la empresa son la opción correcta si desea implementar su

propia infraestructura de enrutamiento sin la participación del proveedor. Muchas

organizaciones prefieren este enfoque porque resulta en un modelo operativo de

enrutamiento consistente y proporciona flexibilidad futura asociada con las migraciones

de proveedores. Las conexiones VPN gestionadas por la empresa se establecen a través de

una infraestructura de terceros y pueden aprovechar las VPN de Internet o proveedores

para la conectividad de transporte subyacente.

Las VPN administradas por empresas que se aprovechan de Internet son relativamente

baratas en comparación con las que dependen de los servicios VPN gestionados por los

proveedores. El inconveniente de usar Internet como tecnología de transporte subyacente

es que no hay soporte de calidad de servicio (QoS). Los proveedores de servicios de

Internet transportan datos con "el mejor esfuerzo", y como resultado, no hay un acuerdo

de nivel de servicio (SLA) para garantizar niveles de servicio mínimos. Además, cuando se

extienden las redes privadas a través de una red pública como Internet, las conexiones

VPN se establecen sobre una infraestructura insegura. La incorporación de cifrado en

estos casos es muy recomendable, ya menudo oratoria, porque el envío de datos en texto

226

claro puede exponer información sensible a los atacantes y dar lugar a problemas de

cumplimiento.

Para superar estos inconvenientes, las empresas pueden utilizar los servicios VPN

gestionados por proveedores para sentar las bases de la red subyacente e implementar

soluciones VPN gestionadas por la empresa a través de la infraestructura del proveedor.

La motivación para implementar una VPN emprendida a través de una VPN administrada

por el proveedor es que estos servicios normalmente vienen con SLAs establecidos para

las conexiones. Para promover la coherencia operacional y minimizar el riesgo con un

enfoque en la seguridad, puede establecer cifrado de tráfico incluso cuando utiliza

servicios VPN administrados por el proveedor; esta es una buena práctica. El

inconveniente de usar VPNs gestionadas por un provedor es que esta solución es a

menudo más costosa que las soluciones VPN a través de Internet.

DESCRIPCIÓN DE GRE

Establecer una VPN gestionada por la empresa requiere una solución que pueda enviar

por túneles los paquetes, e incluso multicast, sobre la infraestructura de transporte

subyacente.

Encapsulado de enrutamiento genérico (GRE), que utiliza el protocolo número 47, fue

desarrollado por Cisco y ahora es estandarizado por el Internet Engineering Task Force

(IETF). Este protocolo proporciona la capacidad de túnel de unicast o paquetes de

multidifusión.

Además de soportar la multidifusión, esta solución admite el uso de protocolos de

enrutamiento sobre el mecanismo de tunelización. Esta tecnología, en su forma más

básica, crea una conexión virtual punto a punto entre dos enrutadores, aprovechando una

interfaz de fuente de túnel y la dirección IP de destino de cada lado. El enrutador

encapsula el tráfico con un encabezado GRE y un nuevo encabezado IP. Este nuevo

paquete se envía al enrutador en el otro extremo del túnel utilizando el encabezado IP

externo para las decisiones de reenvío. El enrutador en el otro lado del túnel tira el

encabezado IP externo y el encabezado GRE y envía paquetes basados en la tabla de

enrutamiento.

Dos extremos del túnel GRE actúan como si estuvieran conectados directamente. La

aparición de que los puntos finales están conectados directamente significa que

implementa el enrutamiento de la misma manera que lo haría para las interfaces

enrutadas normales. Tiene la flexibilidad de usar protocolos de puerta de enlace interior

(IGP), como RIP, EIGRP y OSPF; y EGP, como BGP. Cuando implemente el enrutamiento,

debe tener cuidado de evitar bucles recursivos. Un bucle ocurriría si usted configurara mal

un enrutador de tal manera que intenta encaminarse a la dirección de destino del túnel a

227

través del túnel usando la interfaz del túnel. Los bucles recursivos pueden causar

inestabilidad temporal como resultado del aleteo de la ruta en otra parte de la red. Puede

evitar estas situaciones con un filtrado adecuado o utilizando una instancia de protocolo

de enrutamiento diferente para los túneles GRE que la que utiliza la red de transporte.

En este tipo de diseño, el enrutador de concentrador debe establecer un túnel punto a

punto independiente con cada enrutador radio. Este diseño requiere el uso de una subred

única en cada una de las conexiones punto a punto entre los sitios. Aquellos que desean

agregar alta disponibilidad a este tipo de diseño GRE usualmente implementan dos

enrutadores en el sitio central y un enrutador en la sucursal. Cada enrutador de

concentrador en el sitio central tiene una conectividad independiente con la WAN. El

enrutador de rama se conecta entonces a la WAN a través de dos conexiones ascendentes

y aprovecha dos túneles GRE separados sobre cada una de estas conexiones para una alta

disponibilidad. Cada túnel terminaría en un enrutador de concentrador en el sitio central,

y el protocolo de enrutamiento se sintonizaría para seleccionar un túnel GRE principal al

sitio central.

La principal ventaja del túnel GRE es que puede transportar protocolos que normalmente

no pasarían por la red. Un ejemplo es el tráfico multicast de túneles a través de Internet

utilizando un túnel GRE entre dos sitios. Tradicionalmente, la única preocupación acerca

del uso de GRE de esta manera a través de un transporte inseguro es que GRE no

proporciona ninguna protección criptográfica de tráfico. En estas situaciones, GRE

generalmente se combina con IPsec para garantizar que las propiedades de protección de

tráfico necesarias están en su lugar. Una desventaja es que el estándar GRE no define

ningún mecanismo keepalive. Cisco ofrece una solución propietaria GRE keepalive para

abordar esta preocupación. Cuando implementa túneles GRE, puede tener problemas

relacionados con la fragmentación de MTU y IP. GRE agrega 24 bytes adicionales (un

encabezado GRE de 4 bytes y un nuevo encabezado IP de 20 bytes) al paquete. Debe

configurar el valor MTU apropiado para admitir cabeceras adicionales. Aunque bien

documentada, esta consideración es a menudo ignorada o mal entendida.

228

DESCRIPCIÓN DE MULTIPOINT GRE

Debido a que GRE clásico es una tecnología punto a punto y varias limitaciones y

problemas de escalabilidad asociados con el suministro de punto a punto puede existir, en

muchos casos, se necesita algo más capaz. El GRE multipunto (mGRE) extiende la solución

GRE añadiendo soporte multipunto, lo que significa que el único interfaz GRE soporta

múltiples conexiones de túnel GRE simultáneamente. La figura muestra un mGRE. Debido

a que sólo se necesita un túnel para todos los demás pares de GRE multipunto, mGRE

simplifica enormemente la configuración general. Todos los túneles GRE utilizan la misma

subred, lo que hace que los concentradores ya no requieran una subred única para cada

conexión de radios hablados. Al igual que los túneles GRE clásicos, los túneles mGRE

admiten el tráfico unicast, multicast y broadcast.

Cuando utiliza túneles GRE de punto a punto, especifica manualmente la fuente y el

destino del túnel. Con el GRE multipunto, usted todavía necesita especificar la fuente del

túnel, pero el aprendizaje de los pares ocurre dinámicamente. Para aprender

dinámicamente acerca de los compañeros, necesita un protocolo especial que correlacione

la dirección IP del túnel con la dirección IP física de no acceso múltiple (NBMA). Cisco

aprovecha un protocolo llamado Next-Hop Resolution Protocol (NHRP) para lograr esto

(NHRP se describe en IETF RFC 2332). NHRP se utiliza de forma similar al Protocolo de

resolución de direcciones (ARP) en Ethernet. El NHRP registra dinámicamente el mapeo

de la dirección de la interfaz del túnel y la dirección física (NBMA) a los otros pares. Este

registro dinámico también permite el uso de direcciones asignadas dinámicamente.

229

COMPARACIÓN PUNTO A PUNTO Y MULTIPUNTO GRE

Debido a que puede elegir entre dos tipos de GRE con varias diferencias, podría ser

beneficioso examinar las características de cada tipo de lado a lado en una tabla.

La Tabla 9-1 presenta gran parte de la información ya compartida en un formato

simplificado.

Punto a punto GRE

Normalmente se utiliza para los túneles punto a

puntos simples que emulan un enlace punto a

punto WAN o en enrutadores de habla en VPNs

hub-and-spoke.

Multipunto GRE

Se usa normalmente en enrutadores de

concentrador en topologías de concentrador y de

radio o en todos los enrutadores en topologías de

malla o de malla parcial.

En cada dispositivo, se configura una interfaz de

túnel GRE independiente para cada par GRE.

Una sola interfaz GRE está configurada para

varios túneles GRE.

Se necesita una subred única para cada túnel

GRE.

Esto no requiere NHRP porque otros pares tienen

una dirección de destino configurada

estáticamente.

La misma subred está configurada para todos los

túneles GRE.

Esto requiere que NHRP construya túneles GRE

dinámicos y aprenda sobre las direcciones IP de

los otros compañeros.

Esto admite unidifusión, multicast y tráfico de

difusión.

Esto admite unidifusión, multicast y tráfico de

difusión.

230

1. En el diagrama de la izquierda, una red de hub-and-spoke utiliza un conjunto de

túneles punto-a-punto utilizando sólo interfaces GRE. En el concentrador,

necesitaría crear tantos interfaces GRE como radios, y en un radio, se requeriría

una interfaz GRE. Todo el tráfico entre los radios fluye estrictamente sobre el hub.

2. El diagrama del centro muestra el concentrador optimizado con una interfaz mGRE.

En esta configuración, sólo se requiere una sola interfaz en el concentrador. Sin

embargo, debe implementar NHRP para que el concentrador aprenda las

direcciones de los radios y suministre correctamente los túneles del GRE de radio a

hub.

3. En el diagrama de la derecha, todos los dispositivos en una red de concentrador

utilizan un interfaz mGRE. Usando NHRP, estos dispositivos pueden establecer una

malla parcial o malla completa de túneles GRE configurando sólo una sola interfaz

mGRE en cada dispositivo. Esta opción simplifica en gran medida la configuración y

mejora la capacidad de gestión.

GRE es una poderosa solución para diseñar e implementar VPNs gestionadas por la

empresa; sin embargo, GRE no siempre es adecuado para abordar todos los requisitos.

Como ya se mencionó, cuando se crean superposiciones GRE sobre la conectividad de

transporte insegura, GRE se combina normalmente con IPsec para garantizar que las

propiedades de protección de tráfico necesarias están en su lugar.

231

DESCRIPCIÓN DE IPSEC

IPsec está diseñado para proporcionar seguridad de transmisión abierta, de alta calidad y

basada en criptografía al tráfico IP. IPsec está definido en RFC 4301. Ofrece

confidencialidad de datos, integridad de datos, autenticación de origen de datos y servicios

de seguridad anti-replay.

IPsec proporciona servicios de seguridad en la capa IP, ofreciendo protección para IP y

protocolos de capa superior. Permite a un sistema seleccionar protocolos de seguridad,

determina los algoritmos a utilizar y negocia las claves criptográficas que se requieren

para proporcionar los servicios solicitados. IPsec puede proteger una o más rutas entre un

par de dispositivos de red. El protocolo IPsec proporciona encriptación de capa de red IP y

define un nuevo conjunto de encabezados que se agregarán a los datagramas IP. Los

nuevos encabezados proporcionan información para asegurar la carga útil del paquete IP.

IPsec combina los siguientes protocolos de seguridad:

Internet Key Exchange (IKE) proporciona administración de claves a IPsec.

Autenticación del Encabezado (AH) define una encapsulación de tráfico de

usuario que proporciona integridad de datos, autenticación de origen de datos y

protección contra la repetición al tráfico de usuarios.

Encapsulación Segura de la carga útil (ESP) define una encapsulación de tráfico

de usuario que proporciona integridad de datos, autenticación de origen de datos,

protección contra repeticiones y confidencialidad al tráfico de usuarios.

El concepto de una Asociación de Seguridad (SA) es fundamental para IPsec. Tanto AH

como ESP usan SAs, y una función principal de IKE es establecer y mantener las SAs. Un SA

es una descripción simple de los parámetros actuales de protección de tráfico (algoritmos,

claves, especificaciones de tráfico, etc.) que se aplicaría a flujos de tráfico de usuarios

específicos. Los servicios de seguridad se proporcionan a una SA mediante el uso de AH o

ESP. Si se aplica una protección AH o ESP a un flujo de tráfico, se crean dos (o más) SA

para proporcionar protección al flujo de tráfico. Para asegurar la comunicación

bidireccional típica entre dos hosts o entre dos pasarelas de seguridad, se necesitan dos

SA (una en cada dirección).

IKE opera en dos fases distintas:

Fase 1: La primera fase establece la negociación inicial entre dos pares. La fase 1

comienza con la autenticación en la que los cripto-oparadores verifican la identidad

entre sí. Cuando se autentican, los pares cripto coinciden en el algoritmo de cifrado,

el método hash y otros parámetros. Los pares establecen SAs bidireccionales. El

232

objetivo de la Fase 1 es que IKE negocie los parámetros de SA de IPsec y establezca

un canal seguro para la Fase 2.

Fase 2: El objetivo de la Fase 2 es establecer un canal seguro para el intercambio

de datos. Los pares establecen dos (o más) SA unidireccionales. El intercambio de

fase 2 se denomina modo rápido IKE.

No es raro oír que, en la Fase 1, IKE puede operar en modo principal o agresivo. Las

principales características de estos modos son las siguientes:

Modo principal: Este modo tiene tres intercambios bidireccionales entre pares.

Permite una negociación de políticas de protección IKE más flexible y siempre

protege la identidad de los pares. Un inconveniente del modo principal es que no

admite a los pares de direcciones dinámicas al realizar la autenticación de clave

pre-compartida. Los pares dirigidos dinámicamente sólo se admiten con la

autenticación facilitada por PKI. La excepción es cuando se utilizan claves wildcard

pre-compartidas. Sin embargo, el uso de claves wildcard se desaconseja.

Modo agresivo: En este modo, se realizan menos intercambios y con menos

paquetes. Por lo tanto, es más rápido que el modo principal. La desventaja de

aprovechar el modo agresivo es que no protege las identidades de los pares, ya que

los nombres de los compañeros que se comunican se envían a través de la red no

confiable en texto plano. El principal beneficio del modo agresivo es que admite la

autenticación de clave previamente compartida para los pares de direcciones

dinámicas.

IPsec, similar a IKE, también funciona en uno de dos modos:

Modo túnel: este modo introduce un nuevo encabezado IPsec en el paquete y el

paquete IP completo del usuario se encapsula como carga útil.

Modo de transporte: este modo conserva el encabezado IP original y las

decisiones de reenvío se basan en este encabezado original.

Con referencia a la figura 9, cuando IPsec opera con AH, el modo de transporte protege el

encabezado IP externo junto con la carga útil de datos. Los servicios AH protegen todos los

campos de la cabecera que no cambian en el transporte. El encabezado AH va después del

encabezado IP y antes de los otros protocolos de capa superior. En modo de túnel, el

encabezado original entero es autenticado y se crea una nueva cabecera IP. El nuevo

encabezado IP está protegido de la misma manera que el encabezado IP en el modo de

transporte.

233

Cuando IPsec opera con ESP, la carga útil de IP está encriptada y los encabezados

originales quedan intactos en el modo de transporte. El encabezado ESP se inserta

después del encabezado IP y antes del encabezado del protocolo de la capa superior. Los

protocolos de la capa superior se cifran y autentican junto con el encabezado ESP. ESP no

autentica la cabecera IP. Cuando se usa ESP en modo túnel, el encabezado IP original está

bien protegido porque todo el datagrama IP original está encriptado. Con un mecanismo

de autenticación ESP, se incluyen el datagrama IP original y el encabezado ESP; Sin

embargo, la nueva cabecera IP no se incluye en la autenticación.

IPsec y GRE

Cuando se considera IPsec y GRE independientemente, cada uno tiene sus limitaciones.

Aunque IPsec proporciona un método seguro para crear túneles de datos a través de una

red IP, se queda corto en muchos escenarios de diseño debido a su incapacidad de

soportar la difusión IP, la multidifusión IP o las capacidades de tráfico multiprotocolo.

Estas limitaciones impiden el uso de protocolos que dependen de estas características,

234

como los protocolos de enrutamiento. El soporte del protocolo de enrutamiento es

fundamental para garantizar que puede ofrecer una solución dinámica y escalable.

Sin embargo, GRE puede utilizarse para transportar protocolos tales como difusión IP o

multidifusión IP, así como protocolos no IP. El inconveniente de GRE, como ya se ha

señalado unas cuantas veces, es que no proporciona ningún mecanismo de cifrado.

El matrimonio ideal es una solución que combina ambas tecnologías. Puede utilizar

túneles GRE para transferir el tráfico deseado e IPsec para cifrar los túneles GRE. GRE

sobre IPsec ofrece capacidad de túnel punto a punto. Normalmente se utiliza en

situaciones en las que una empresa debe utilizar protocolos de enrutamiento en la WAN y

cuando el tráfico debe estar protegido durante el transporte. El transporte subyacente

puede ser basado en Internet o incluso una VPN administrada por proveedores. Las

soluciones punto a punto como esta son apropiadas para un pequeño número de túneles y

pueden convertirse en una carga operativa en los despliegues más grandes que requieren

una escala considerable.

IPsec se puede utilizar en modo de túnel o modo de transporte con una solución GRE

sobre IPsec. El modo Tunnel añade 20 bytes adicionales al tamaño total del paquete, por lo

que se debe tener en cuenta al configurar MTU y tcp-adjust la configuración del MSS.

Aunque ambos modos funcionan con GRE sobre IPsec, ciertos escenarios requieren que

aproveche un modo de operación específico de IPsec. Un ejemplo es cuando GRE sobre

IPsec transita un dispositivo NAT o PAT. Cuando se presenta este tipo de escenario, se

requiere el modo de túnel. El modo de túnel también es necesario si los puntos finales del

túnel GRE y los puntos extremos del túnel criptográfico son diferentes.

Las dos opciones al implementar una solución GRE sobre IPsec son

Uso de mapas criptográficos (crypto-maps):

o El paquete se enruta a la interfaz del túnel.

o El paquete está encapsulado con GRE.

o El paquete encapsulado se envía de acuerdo con la tabla de enrutamiento a

la interfaz apropiada.

o El paquete encapsulado se cifra utilizando la configuración del mapa de

cifrado.

Uso de la protección de túneles:

o El paquete se enruta a la interfaz del túnel.

o El GRE encapsula el paquete, mientras que IPsec añade cifrado al túnel GRE.

o El paquete cifrado y encapsulado se reenvía al destino de acuerdo con la

tabla de enrutamiento.

La solución para aprovechar los mapas criptográficos es más compleja y, por lo tanto, se

recomienda que utilice el método de protección de túneles cuando sea posible. A veces,

235

cuando se realiza cifrado y encapsulación en diferentes dispositivos, es necesario utilizar

mapas criptográficos. Las siguientes secciones exploran algunas alternativas para

aprovechar GRE sobre IPsec, como las interfaces de túnel virtual (VTI) y las interfaces

dinámicas de túnel virtual (DVTI).

IPSEC Y LA INTERFAZ DE TÚNEL VIRTUAL

Una interfaz de túnel IPsec virtual es una alternativa a los túneles GRE sobre IPsec y

proporciona otro mecanismo para admitir VPN. Una VTI admite tunelización IPsec nativa

y permite que los comandos y capacidades de interfaz comunes se apliquen directamente

a los túneles IPsec, aprovechando un tipo de interfaz enrutable. Las VTI apoyan la

interoperabilidad con instalaciones basadas en estándares IPsec de otros proveedores.

El uso de las VTI IPsec es muy popular porque simplifica en gran medida el proceso de

configuración y ofrece una manera fácil de definir la protección entre sitios para formar

una red de superposición, como se muestra en la Figura.

Las VTI tienen las siguientes características:

Se comportan como un túnel regular, uno para cada sitio remoto de la VPN.

Su encapsulación debe ser IPsec ESP o AH.

Su protocolo de línea depende del estado del túnel VPN (asociaciones de seguridad

IPsec).

Una de las principales ventajas de las VTI de IPsec es que la configuración no requiere una

asignación estática de sesiones IPsec a una interfaz física. Cuando utiliza el enfoque VTI,

configura una interfaz de túnel virtual y aplica un perfil IPsec en él mediante la protección

de túnel. Este enfoque resulta en menos líneas de configuración porque los mapas

criptográficos se generan automáticamente para cada túnel cuando se aplica la protección

de túnel. Las características de los paquetes de texto claro se configuran en el VTI,

mientras que las características de los paquetes cifrados se aplican en la interfaz física.

236

Los casos de uso más comunes para aprovechar la configuración de VTI son para

implementaciones de topología de pequeña escala y hub-and-spoke. A continuación, se

presenta una revisión de los beneficios de VTI seguida de sus limitaciones:

Configuración simplificada: los clientes pueden utilizar las construcciones de

túnel virtual para configurar un peering IPsec para simplificar la configuración VPN

en comparación con los mapas criptográficos o los túneles IPsec GRE.

Soporte de funciones de interfaz flexible: Un VTI de IPsec es un encapsulado que

utiliza su interfaz de software IOS de Cisco. Esta característica ofrece la flexibilidad

de definir características para ejecutarse en la interfaz física que opera en el tráfico

cifrado o en la VTI IPsec que opera en tráfico de texto claro.

Soporte de multidifusión: los clientes pueden utilizar las VTI de IPsec para

transferir de forma segura el tráfico de multidifusión, como las aplicaciones de voz

y vídeo, de un sitio a otro.

Escalabilidad mejorada: las VTI de IPsec necesitan menos SA establecidas para

cubrir diferentes tipos de tráfico, como la unidifusión y la multidifusión, lo que

permite una mayor escalabilidad.

Interfaz de enrutamiento: Al igual que GRE IPsec, las VTI de IPsec admiten de

forma nativa todos los tipos de protocolos de enrutamiento IP, ofreciendo

escalabilidad y redundancia mejoradas.

Las limitaciones de VTI incluyen las siguientes cuestiones:

Falta de compatibilidad con varios protocolos: La VTI de IPsec se limita a sólo

unidifusión de IP y tráfico de multidifusión, a diferencia de los túneles de GRE, que

tienen un soporte multiprotocolo más amplio.

No hay conmutación por error con estado IPsec: el software IOS no admite la

conmutación por error con estado IPsec para VTI de IPsec. Puede utilizar métodos

alternativos de conmutación por error, como capacidades de protocolo de

enrutamiento dinámico para lograr una funcionalidad similar, pero la conmutación

por error con estado no es inherente a la solución.

IPSEC Y VTI DINÁMICO

VTI dinámico (DVTI) amplía la funcionalidad de VTI para proporcionar capacidades de

configuración de concentrador altamente escalables como parte de las implementaciones

de VPN diseñadas para admitir la conectividad de sitio a sitio y de acceso remoto. La

funcionalidad de VTI dinámica requiere una configuración mínima en el enrutador de

concentrador cuando se utiliza para implementaciones VPN hub-and-spoke. Para la

configuración, las VTI dinámicas en el concentrador no aparecen como interfaces de túnel,

sino que aparecen como interfaces de acceso virtual, que se clonan automáticamente

237

desde la plantilla de interfaz virtual. La plantilla de interfaz virtual incluye un conjunto de

configuraciones comunes heredadas por las VTI dinámicas. La configuración de la plantilla

virtual incluye la configuración de IPsec y cualquier configuración de la característica de

software de Cisco IOS que de otro modo se configuraría en una interfaz normal, como QoS,

NetFlow, ACL, etc. El concentrador llena todos los demás parámetros dinámicos, como la

información de la dirección del túnel del radio, a medida que se conecta el interlocutor a

distancia.

El par de hablantes utiliza VTI estática para iniciar la conexión VPN y crear el túnel que

activa la creación del hub DVTI. Más específicamente, las VTI dinámicas se crean cuando

los interlocutores hablantes crean una sesión IKE en el dispositivo concentrador y

negocian las directivas IPsec. Estos túneles dinámicos proporcionan interfaces de acceso

virtual independientes bajo demanda para cada sesión VPN.

El caso de uso más común para VTI dinámico es para grandes despliegues de concentrador

y de radio, en los que se desea el aprovisionamiento VPN simplificado en el enrutador de

concentrador. También puede utilizar una implementación de VTI dinámica en entornos

en los que los radios aprovechan el direccionamiento IP dinámico de la WAN. Otras

tecnologías VPN patentadas de Cisco se expanden en muchas de las capacidades que ya se

han discutido y que han ganado popularidad en los últimos años. La siguiente sección

explora una de las soluciones Cisco VPN más ampliamente implementadas.

DESCRIPCIÓN DE DMVPN

Cisco Dynamic Multipoint VPN (DMVPN) es una característica que simplifica el despliegue

de grandes redes virtuales de alta densidad, en malla parcial o malla completa. DMVPN

combina túneles mGRE, encriptación IPsec y NHRP para proporcionar un

aprovisionamiento simplificado para escalar mejor las VPN IPsec grandes y pequeñas.

Aunque estas capacidades ya han sido revisadas, el siguiente es un resumen consolidado

de estos tres pilares DMVPN:

238

mGRE: Multipoint GRE permite una interfaz GRE única para soportar múltiples

túneles GRE y simplifica la complejidad de la configuración. Los túneles GRE

proporcionan soporte para la multidifusión IP, que a su vez le permite, como

diseñador de la red, utilizar protocolos de enrutamiento para distribuir

información de enrutamiento y detectar cambios en la VPN. Todos los miembros de

DMVPN utilizan interfaces GRE o mGRE para construir túneles entre dispositivos.

NHRP: En este protocolo cliente y servidor (descrito en RFC 2332), el concentrador

actúa como un servidor NHRP y los radios actúan como clientes NHRP. El

concentrador mantiene una base de datos NHRP de asignaciones entre las

direcciones IP externas (pública, física, NBMA) y el túnel (dentro de la interfaz del

túnel) de cada radio. Cada uno de los radios registra sus direcciones de túnel

público e interno cuando se inicia con el concentrador, que también se considera el

servidor de siguiente salto (NHS). En los despliegues de malla parcial y de malla

completa, los radios consultan la base de datos de la NHRP para las direcciones de

otros radios con el propósito de construir túneles directos de radios hablados.

NHRP reduce la Complejidad de la configuración de VPN de malla completa y VPN

de malla parcial. Los radios NHRP sólo requieren una configuración estática para

comunicarse con el concentrador, y el concentrador comparte la información de la

base de datos a su vez para facilitar la conectividad de habla a radio.

IPsec: Internet Protocol Security proporciona protección de transmisión para

túneles GRE. Los DMVPN forman una VPN IPsec permanente con concentrador y

radio que puede reconocer dinámicamente cifras en VPN de malla parcial o de red

completa según sea necesario.

Las principales características de la solución DMVPN son las siguientes:

Reducción de la configuración

Despliegue de Zero-touch (ZTD)

Soporte de protocolo de enrutamiento dinámico

Soporte QoS y por túnel de QoS

Soporte de multidifusión de concentrador y de radio

Apoyo a los pares dirigidos dinámicamente

Soporte para dispositivos detrás de NAT

Capacidades VPN de malla parcial y de malla completa

Capacidad para usar con o sin cifrado IPsec

Como resultado de usar mGRE, que aprovecha una configuración de interfaz única en el

enrutador de concentrador para soportar toda la conectividad de los radios, con DMVPN

puede reducir en gran medida la configuración en el enrutador de concentrador. El NHRP,

junto con el enrutamiento dinámico, hace que los despliegues sin contacto sean posibles.

El NHRP proporciona registro dinámico de los enrutadores de radios, mientras que los

protocolos de enrutamiento dinámico que funcionan sobre DMVPN proporcionan

distribución automática de rutas de radios, lo que permite una conectividad IP escalable

de extremo a extremo. Es posible no sólo configurar la QoS jerárquica para el tráfico

239

tunelizado, sino también implementar políticas de QoS de túnel que resulten en configurar

el tráfico hasta la tasa de información comprometida para cada ubicación de sitio remoto

antes de incrustar la calidad de servicio en el formateador por sitio predeterminado.

DMVPN soporta enrutadores que aprovechan el direccionamiento IP dinámico y utiliza

NHRP para registrar las direcciones IP dinámicas de los enrutadores de radios dentro del

enrutador de concentrador. Además de soportar el direccionamiento IP dinámico en los

radios, la solución DMVPN soporta hablantes de enrutadores detrás del NAT dinámico. Los

enrutadores de concentrador también se admiten detrás de NAT, pero deben utilizar la

configuración NAT estática, dado que todos los radios aprovecharán las asignaciones

estáticas de NHRP para comunicarse con el concentrador.

DMVPN con o sin cifrado IPsec es una solución poderosa cuando se requiere una

capacidad de malla parcial o de malla completa. Siempre es importante diseñar con una

visión a largo plazo en mente. Esto se traduce típicamente en seleccionar soluciones como

DMVPN que ofrecen la flexibilidad y adaptabilidades necesarias para introducir nuevas

capacidades sin tener que extraer, reemplazar y rediseñar la infraestructura mientras

pasa por el plan, construye y administra el ciclo de vida.

DMVPN admite dos modelos de implementación:

Hub and spoke: Un modelo de despliegue DMVPN de hub y spoke estricto requiere

que cada ramificación se configure con una interfaz GRE punto a punto al

concentrador. Todo el tráfico entre las redes de radios debe fluir a través del

enrutador de concentrador. DMVPN proporciona una configuración escalable al

enrutador de concentrador, pero no facilita la comunicación directa de radios

hablados.

Spoke to spoke: un modelo de despliegue DMVPN de radios requiere que cada

rama se configure con una interfaz mGRE en la que se utilizan túneles dinámicos

rayo a rayo. En este modelo, DMVPN proporciona un modelo de configuración

escalable para todos los dispositivos involucrados y también permite que los

dispositivos de radio puedan asociarse dinámicamente y establecer rutas óptimas.

El DMVPN no producirá inmediatamente una topología de malla parcial o completa.

DMVPN inicialmente establece una topología de hub-and-spoke permanente, a

partir de la cual se genera dinámicamente una malla parcial o malla completa

basada en patrones de tráfico y configuración de Fase 2 o Fase 3 de DMVPN.

240

Los siguientes son los principales beneficios del DMVPN:

La creación de una topología VPN totalmente escalable con muchos pares, donde

los túneles se configuran dinámicamente según sea necesario.

Relativamente poco esfuerzo de configuración en curso dado que la configuración

de los enrutadores de concentrador no cambia a medida que se agregan nuevos

pares a la red.

Funciones avanzadas como configuración de protocolos de enrutamiento dinámico,

métodos de calidad de servicio, funciones de seguridad, multidifusión, etc.

Apoyo a redes privadas y públicas que no admiten información de enrutamiento de

clientes, como Internet.

A continuación, se enumeran las limitaciones del DMVPN:

La autenticación PKI (Public Key Infrastructure) de los pares es necesaria para

proporcionar una autenticación escalable de IKE.

Solución de problemas DMVPN es más complejo en comparación con la solución de

problemas de los túneles clásicos de IPsec debido a la dependencia de las

tecnologías NHRP y mGRE.

Es posible que se pregunte cuáles son algunos de los ejemplos de implementación más

comunes cuando se selecciona DMVPN como tecnología preferida.

Los ejemplos de despliegue de DMVPN más comunes son los siguientes:

Gran número de radios de bajo ancho de banda: Un ejemplo práctico incluye

una red ATM bancaria. Estas redes suelen ser grandes con muchos radios de bajo

241

ancho de banda que requieren conectividad al sitio de concentrador para el

procesamiento de back-end. El DMVPN permite a estos sitios conectarse a través de

Internet, proporcionando privacidad e integridad de datos, cumpliendo con los

requisitos de rendimiento de las aplicaciones críticas para el negocio.

Acceso SOHO al entorno corporativo: El DMVPN puede proporcionar acceso al

trabajo desde oficinas pequeñas o domésticas. La solución soporta un gran número

de radios que necesitan acceso a los recursos del centro de datos corporativo,

incluyendo servicios de tono de marcación centralizados para despliegues

extendidos de VoIP. La conectividad de radios de DMVPN es ideal para soportar

patrones de tráfico peer-to-peer tales como comunicaciones de voz y video.

Extranet empresarial: las grandes empresas frecuentemente requieren

conectividad con muchos socios comerciales. Puede utilizar el DMVPN para

asegurar el tráfico entre la empresa y varios sitios asociados. La solución puede

proporcionar la segregación de la red al ayudar a garantizar que no se permite el

tráfico de radio hablada a través del control del concentrador.

Respaldo de conectividad WAN empresarial: Quizás uno de los casos de uso más

comunes ha sido aprovechar el DMVPN a través de Internet como una solución de

respaldo para WAN privadas.

Servicios VPN del proveedor de servicios: El DMVPN permite a los proveedores

de servicios ofrecer servicios VPN gestionados. El tráfico de varios clientes puede

agregarse en un solo enrutador de borde de proveedor y mantenerse aislado

mediante funciones como VRF.

Dependiendo de los requisitos de diseño y el caso de uso, el DMVPN admite tres versiones

de implementación denominadas fases. Cada fase proporciona beneficios únicos y tiene

advertencias que deben ser entendidas para asegurar la ejecución exitosa de los modelos

de implementación de hub-and-spoke, de malla parcial y de malla completa.

DMVPN Fase 1

DMVPN Fase 1 es el modelo básico de implementación DMVPN. En la fase 1, como se

muestra en la figura, el enrutador de concentrador utiliza mGRE para conectarse a los

enrutadores de radios. Los enrutadores usan túneles regulares punto a punto GRE.

242

Aunque todos los enrutadores en DMVPN Fase 1 deben utilizar la misma subred, los

enrutadores sólo pueden llegar directamente al concentrador y deben pasar por el

concentrador para llegar a cualquier otro rayo. Los principales beneficios de DMVPN Fase

1 son la configuración simplificada en los enrutadores de concentrador y las

comunicaciones controladas de radios con radios para las circunstancias en las que esta

funcionalidad resultaría útil. En DMVPN Fase 1, el concentrador actúa como un servidor

NHRP. Los radios se registran con el hub, lo que significa que anuncian la correspondencia

entre la dirección IP del túnel y la dirección en la interfaz física. De esta manera, el

concentrador sabe cómo llegar a cada radio y registra esta información en una base de

datos. Debido a que el proceso de registro es activado por el rayo y ocurre

automáticamente en el concentrador, el DMVPN habilita direcciones IP asignadas

dinámicamente en los enrutadores de radios.

La desventaja de DMVPN Fase 1 en muchos casos es la imposibilidad de establecer túneles

de rayo a rayo. La conectividad de rayo a rayo a menudo se requiere para dar cabida a un

mejor manejo del tráfico y el rendimiento de la aplicación.

Puede utilizar casi cualquier protocolo de enrutamiento como parte de una

implementación de DMVPN Fase 1. Dado que la Fase 1 de DMVPN no permite el

establecimiento de túneles de rayo a rayo, todo el tráfico debe pasar por el enrutador de

concentrador; Por lo tanto, el siguiente salto siempre debe ser el enrutador de

concentrador. Un enfoque común para el enrutamiento con las implementaciones de la

fase 1 de DMVPN es tener sólo una ruta predeterminada que apunte de nuevo al

concentrador configurado en los enrutadores de radios. Esta ruta predeterminada se

puede configurar estáticamente o anunciarse desde el concentrador mediante un

protocolo de enrutamiento.

Cuando usa EIGRP como un protocolo de enrutamiento en el DMVPN, debe entender la

regla del horizonte dividido. El horizonte dividido evita los bucles de enrutamiento en la

243

red. La regla establece que el enrutador nunca debe anunciar una ruta fuera de la interfaz

a través de la cual aprende la Ruta. Cuando se utiliza DMVPN fase 1, el concentrador utiliza

sólo una interfaz para conectar a todos los radios. Cuando el concentrador recibe la

actualización de enrutamiento de un radio, debe entregar la misma actualización de la

misma interfaz. El horizonte dividido está habilitado de forma predeterminada y evita este

comportamiento en el enrutador de concentrador. Usted puede hacer una de las tres cosas

para asegurarse de que los radios lleguen a otros radios a través del hub:

Deshabilitar el horizonte dividido.

Aprovechar el resumen en el concentrador si las rutas de radios pueden agregarse

como parte de un prefijo de coincidencia más corto.

Aprovechar una ruta predeterminada catchall que apunte de nuevo al concentrador

si no está en conflicto con la conexión directa a Internet y la configuración de túnel

dividido.

Si utiliza OSPF como protocolo de enrutamiento en el DMVPN, debe utilizar el tipo de red

punto a multipunto en los enrutadores hub-and-spoke. El tipo de red OSPF

predeterminado en la interfaz del túnel es punto a punto. Si deja el tipo de red

predeterminado, la adyacencia OSPF se tapa continuamente entre enrutadores. Al

configurar el tipo de red punto a multipunto, OSPF trata este tipo de red como una

colección de enlaces punto a punto.

Si decide utilizar BGP como protocolo de enrutamiento en su DMVPN, debe considerar

utilizar eBGP para acomodar un diseño simplificado y un aprovisionamiento general

simplificado. IBGP no anuncia los prefijos que se reciben a través de iBGP a otros pares de

iBGP y requerirá configurar el enrutador de concentrador DMVPN como reflector de ruta.

Cuando se utiliza eBGP, es necesario configurar la opción next-hop-self porque eBGP no

cambia los atributos next-hop cuando los pares están en la misma subred. Si examina esto

de cerca en el contexto de DMVPN, al configurar las relaciones eBGP entre direcciones IP

en las interfaces de túnel, el rayo anuncia prefijos con la dirección IP de siguiente salto de

la interfaz de túnel. Cuando los prefijos llegan al enrutador de concentrador, este

enrutador anuncia prefijos a los otros radios y no cambia el siguiente atributo de salto. El

resultado de esta situación es que los radios no tendrán accesibilidad a las redes detrás de

otros radios porque los próximos IPs de salto de estos radios no están disponibles.

244

DMVPN Fase 2

Para superar las limitaciones de la Fase 1 de DMVPN y habilitar la capacidad de túnel de

radios directos, es necesario preparar la infraestructura configurando el GRE multipunto

en todas las interfaces de túnel de enrutador de concentrador y radio.

Este modelo garantizará que cuando el enrutador establezca un túnel directo al rayo,

puede enviar datos directamente al radio sin necesidad de enviar datos a través de un

enrutador de concentrador. Esta característica se aplica únicamente al tráfico de

unidifusión. Cuando está aprovechando el DMVPN, el tráfico multicast puede ser enviado

sólo entre enrutadores hub-and-spoke. Esta limitación da lugar a que las adyacencias de

enrutamiento se establezcan sólo entre los enrutadores hub y spoke. Si desea adyacencias

directas entre enrutadores de radios para soportar ciertos escenarios de diseño, debe

configurar estáticamente a los vecinos en los enrutadores de hablantes.

NHRP cumple dos funciones en DMVPN Fase 2. La primera función es similar a DMVPN

Fase 1 en la que NHRP se utiliza para el registro de radios dinámicos y puede acomodar

radios con direcciones IP dinámicas. La segunda función de NHRP con DMVPN Fase 2 es

para la resolución de destino de túnel bajo demanda. Cuando un rayo quiere comunicarse

con algún otro hablante basado en la información de salto siguiente no modificada, usa

NHRP para preguntar al hub sobre la dirección IP del túnel del otro hablante a un mapa de

direcciones IP real. Para que la Fase 2 de DMVPN funcione correctamente, los enrutadores

de radios deben tener información de alcance total, incluyendo la tabla de enrutamiento

completa y la dirección IP del siguiente salto de túnel no modificada de los otros radios. El

requisito de información de accesibilidad total significa que el aprovechamiento de la

agregación en el enrutador de concentrador no es compatible con DMVPN Fase 2. Esta es

una limitación importante a tener en cuenta al diseñar la escalabilidad en redes grandes. A

245

continuación, observe el papel que desempeñan los diferentes protocolos de enrutamiento

en las implementaciones de la fase 2 de DMVPN.

Cuando utilice EIGRP con DMVPN Fase 2, no sólo debe desactivar el horizonte dividido en

el enrutador de concentrador, sino que también debe desactivar la opción next-hop-self

para garantizar que la información del siguiente salto no cambia. Esta configuración le

indica al enrutador concentrador que establezca la información de direccionamiento IP

del siguiente salto a la dirección IP del radio que originó la ruta. Cuando el rayo de

recepción recibe la ruta, ve la dirección IP de la interfaz de túnel en el otro enrutador radio

como la dirección IP del siguiente salto. Cuando el rayo desea enviar datos a esta red, trata

de establecer un túnel de radio directo basado en la configuración de interfaz de túnel GRE

multipunto y la información de enrutamiento de salto siguiente.

Cuando utilice OSPF como parte de una implementación de DMVPN Phase 2, recuerde que

el DMVPN se comporta como un segmento de LAN. Debido a este comportamiento de tipo

246

LAN, al aprovechar OSPF como protocolo de enrutamiento, debe configurar el tipo de red

OSPF como broadcast en todas las interfaces de túnel del enrutador. También puede

utilizar el tipo de red OSPF de nonbroadcast, pero esto requeriría configurar

estáticamente declaraciones de vecino en el enrutador concentrador que apunta a cada

una de las direcciones IP del túnel del enrutador de radio. Configurar el tipo de red OSPF

como punto a multipunto resultaría en que todo el tráfico continúe fluyendo a través del

enrutador de concentrador y evitaría que usted lograra un modelo de implementación de

Fase 2. Debido a que la elección de OSPF DR / BDR se realiza en el segmento de difusión

cuando las interfaces de túnel se configuran con la difusión de tipo de red, es fundamental

configurar el enrutador de concentrador para ganar el proceso de elección. No sólo debe

establecer la prioridad de OSPF DR al valor más alto en el concentrador, sino que también

debe establecer la prioridad de DR en todos los enrutadores de habla a cero. Establecer

una prioridad de cero evita que los enrutadores hablantes participen en el proceso de

elección DR / BDR.

Cuando un rayo desea enviar el tráfico destinado a la red en el otro rayo, comprueba la

tabla de enrutamiento. La dirección IP del salto siguiente en la tabla de enrutamiento

apunta directamente al otro enrutador de radio. Si el túnel directo no estaba ya

establecido, se utiliza el siguiente procedimiento:

1. Consulta NHRP: El rayo envía una consulta NHRP al servidor NHRP (concentrador

NHS / DMVPN) para resolver la dirección IP del siguiente salto a la dirección del

punto final del túnel.

2. Respuesta NHS: El servidor NHRP envía una respuesta NHRP a los enrutadores de

radios con la información de asignación correcta que se almacenó durante el

proceso inicial de registro de radio a hub.

3. IPsec Trigger: El enrutador de radios recibe la respuesta NHRP del concentrador,

lo que desencadena el proceso IPsec para el establecimiento directo del túnel de

radios.

4. Establecimiento unidireccional del túnel: Una vez creado el túnel IPsec, todos

los paquetes evitan el concentrador. En este punto, el túnel a rayo puede pasar el

tráfico en una sola dirección.

5. Dirección inversa NHRP Query: Para proporcionar conectividad bidireccional, el

otro hablante también necesita aprovechar la información de salto siguiente no

modificada. El otro envía una consulta NHRP cuando el primer paquete necesita ser

reenviado. Cuando el mapeo NHRP está en su lugar y la asociación GRE se

construye, el paquete de respuesta se enviará directamente al radio.

DMVPN Fase 2 es un modelo común y ampliamente utilizado de despliegue VPN. Sin

embargo, como resultado de las limitaciones con la escalabilidad, muchas organizaciones

empresariales eligen la Fase 3 de DMVPN para implementaciones iniciales o están en

proceso de migrar las implementaciones existentes de la Fase 2 a la Fase 3.

247

DMVPN Fase 3

DMVPN Fase 3 es similar a DMVPN Fase 2, ya que permite la creación de túneles de

dinámicos entre rayos para soportar el manejo optimizado del tráfico. Ahora examine

similitudes y diferencias explorando operaciones de Fase 3 de DMVPN:

1. Registro: El paso inicial en DMVPN Fase 3 es similar al de DMVPN Fase 2. El

enrutador de radio registra el túnel y la asignación de dirección IP externa al

enrutador de concentrador. Este registro permite que el concentrador detecte

dinámicamente todos los radios.

2. Enrutamiento: Una vez establecida la conectividad inicial, el concentrador y el

radio pueden establecer una adyacencia de enrutamiento para intercambiar rutas.

En DMVPN Fase 2, los enrutadores de concentrador deben conservar la dirección

IP del siguiente salto al enviar la ruta hacia los otros radios. En DMVPN Fase 3, el

enrutador de concentrador no necesita conservar la información de salto siguiente

de IP. A diferencia de la Fase 2, DMVPN Fase 3 también admite el envío de

información de resumen o incluso simplemente el envío de información de

encaminamiento predeterminada como parte del anuncio de enrutamiento. La

capacidad de aprovechar el resumen de rutas le permite reducir en gran medida el

tamaño de la tabla de enrutamiento en los enrutadores de radio que participan en

grandes implementaciones de DMVPN.

3. Primer paquete: Cuando el enrutador radio desea enviar paquetes IP a los otros

enrutadores de habla, envía el primer paquete al enrutador de concentrador.

4. NHRP Redirect: El router concentrador envía paquetes al rayo correcto, pero

también responde al originador del tráfico con redirecciones NHRP. Este mensaje

de redireción le dice al emisor que el reenvío es subóptimo y que debe enviar

tráfico directamente al otro radio. El mensaje contiene la dirección IP de destino

del paquete IP original.

5. Solicitud de NHRP: El rayo envía una solicitud NHRP para la dirección IP original

usando la tabla de enrutamiento.

6. Reenvío de solicitud: La solicitud recorrerá el enrutador de concentrador, que

enviará esta solicitud al radio correcto.

7. Respuesta Directa: Cuando el otro hablante recibe la solicitud de la NHRP,

responde directamente al originador.

8. Reescritura de tabla NHRP: Cuando la respuesta llega al originador, conoce la

dirección IP externa del destino y puede volver a escribir la tabla NHRP con la

entrada correcta.

248

Si está interesado en migrar de DMVPN Fase 2 a Fase 3, debe agregar el comando IP NHRP

Redirect a la interfaz de túnel de concentrador y el comando de acceso directo IP NHRP a

todas las interfaces de túnel de enrutador de radio. El siguiente conjunto de cambios

depende del protocolo de enrutamiento utilizado y se refieren a que ya no es necesario

preservar la información de salto siguiente de IP.

Si está aprovechando EIGRP como protocolo de enrutamiento, ya no será necesario

deshabilitar el siguiente salto en el enrutador de concentrador y, por lo tanto, se

recomienda eliminar esta configuración. El horizonte dividido puede permanecer

deshabilitado, y ahora puede usar comandos de resumen para reducir el número de rutas

en los radios DMVPN.

Si desea migrar de DMVPN Fase 2 a Fase 3 y si está utilizando OSPF, cambie el tipo de red

a punto a multipunto en todos los hubs y radios. Después de realizar este cambio, también

puede eliminar la configuración de prioridad IP ospf relacionada con DR / BDR porque ya

no se necesita cuando se configuran los tipos de red OSPF punto a multipunto.

249

DMVPN Fase 1-3 Resumen

Antes de pasar a la redundancia DMVPN, la escalabilidad y otros casos de uso avanzado de

DMVPN, vamos a cerrar estas últimas secciones comparando cada una de las fases DMVPN

entre sí. La Tabla 9-2 proporciona una comparación de resumen.

250

Tabla 9-2 Comparación de la fase 1-3 del DMVPN

Fase 1 Fase 2 Fase 3

Funcionalidad Huband-spoke

solamente.

Funcionalidad de radios

radiales

Funcionalidad de radios

radiales

Configuración de la

interfaz GRE punto a

punto en los radios


interfaz mGRE en los

hubs y radios


interfaz mGRE en los

hubs y radios

Configuración mGRE

en los hubs

Configuración

simplificada y menor

en los hubs

Soporte para CPEs

dinámicamente

dirigidos (NAT)

Soporte para

protocolos de

enrutamiento y

multidifusión

Los rayos no necesitan

una tabla de

enrutamiento completa

y por lo tanto pueden

ser utilizados en los

hubs

El tráfico de datos de

rayos a rayo directo

reduce la carga en los

concentradores y

proporciona un manejo

óptimo del tráfico para

aplicaciones peer-to-peer

Los rayos deben tener

tabla de enrutamiento

completa y, por lo tanto,

el resumen no se admite

Túnel de radios de rayo

accionado por el propio

parlante

Limitaciones del

protocolo de

enrutamiento

Los despliegues de

multihub deben

interconectar los hubs de

una manera en cadena

El tráfico directo de datos

hablados a rayos reduce

la carga en los

concentradores y

proporciona un manejo

óptimo del tráfico para

aplicaciones peer-to-peer

Los rayos no necesitan

una tabla de

enrutamiento completa y

por lo tanto pueden

resumirse para soportar

una escala mejorada

Túnel de radios de rayo

accionado por los hubs

(requiere que el radio

tenga configurado el

comando de acceso

directo ip nhrp)

Elimina las limitaciones

del protocolo de

enrutamiento, como el

requisito de no ip nexthop-self

En palabras sencillas:

La Fase 1 permite las topologías de hub-and-spoke simples.

La Fase 2 y DMVPN Phase 3 permiten complejas topologías de hub-and-spoke, fullmesh

o híbridas.

La Fase 3 agrega mayor escalabilidad y soporte para diseños jerárquicos.

251

DMVPN y redundancia

Un enfoque común para proporcionar alta disponibilidad en los DMVPNs es implementar

múltiples routers de concentrador en el sitio central.

La Figura presenta las dos opciones de implementación típicas que están más presentes en

los entornos empresariales:

Dual hub doble DMVPN nube

Nube dual de doble canal de DMVPN

Nota: Aunque se menciona el hub dual, puede utilizar más de dos routers en el sitio central

para una alta disponibilidad. Dual hub es sólo un despliegue típico.

En ambas topologías, al menos dos enrutadores de concentrador se despliegan para la

redundancia, el segundo enrutador de concentrador proporciona una alta disponibilidad.

El concentrador puede estar en la misma subred DMVPN que el enrutador de

concentrador principal, como con una sola topología de nube DMVPN o un diseño DMVPN

de doble hub. El segundo enrutador de concentrador también puede prestar servicio a su

propia subred DMVPN, que se conoce como una topología de doble nodo DMVPN o un

diseño dual DMVPN de doble hub. Tanto las topologías de doble nodo DMVPN como las de

doble nodo DMVPN se basan en protocolos de enrutamiento que se ejecutan dentro de los

túneles para determinar la selección de la ruta del túnel.

La diferencia entre las dos topologías es evidente en el enrutador de la sucursal. Con una

sola subred DMVPN, el enrutador de la sucursal tiene un solo túnel mGRE y ambos

252

enrutadores de concentrador se asignan a este túnel a través de esta interfaz mGRE. En

una topología DMVPN dual, el enrutador de la rama tiene un túnel único que apunta a cada

uno de los enrutadores de concentrador únicos. Los protocolos de enrutamiento estándar

como EIGRP, BGP u OSPF determinan el concentrador activo sobre cualquier topología. En

la única topología DMVPN, los hubs aparecen como dos diferentes saltos siguientes a

través de una interfaz de túnel mGRE. En la topología dual DMVPN, los hubs aparecen

como dos saltos diferentes a través de las dos interfaces GRE o mGRE.

En general, la topología de nube única DMVPN es mejor cuando se requieren túneles

dinámicos de radios porque los túneles sólo se pueden construir dentro de una nube

DMVPN, no entre nubes DMVPN. La topología dual de la nube de DMVPN es a menudo más

fácil para las redes del eje-y-solo-habla. Puede ser más fácil configurar el protocolo de

enrutamiento para que prefiera una nube DMVPN (hub) sobre la otra. La razón de esto es

que el enrutador recibe información de enrutamiento desde los concentradores en

diferentes interfaces de túnel. Se trata simplemente de recomendaciones y no de

requisitos, ya que la topología de la nube de DMVPN se puede configurar tanto para redes

con concentrador y radio como con rayo a rayo. Las topologías de nubes DMVPN también

se pueden usar en combinación para satisfacer los requisitos de redes más complejas.

DESCRIPCIÓN GENERAL DE VPN SSL

La VPN con Secure Sockets Layer (SSL) permite extender el acceso a su red empresarial

segura para cualquier usuario autorizado proporcionando conectividad de acceso remoto

a través de una pasarela VPN habilitada para SSL. La conectividad segura de acceso

remoto es posible desde casi cualquier ubicación habilitada para Internet usando sólo un

navegador web que soporta nativamente el cifrado SSL. Además de soportar los

dispositivos y ubicaciones corporativas, una de las ventajas de la VPN SSL es la capacidad

de soportar el acceso desde máquinas y ubicaciones no corporativas, incluyendo

computadoras domésticas, quioscos de Internet y puntos de acceso inalámbricos. Estas

ubicaciones son lugares difíciles de implementar y administrar el software de cliente VPN

y las configuraciones remotas necesarias para admitir la conectividad VPN IPsec.

Sin cliente: el modo sin cliente proporciona acceso seguro a los recursos web

privados y al contenido web. Este modo es útil para acceder a la mayoría del

contenido que se espera tener acceso en un navegador web. Los ejemplos incluyen

acceso a la intranet, acceso a Internet, bases de datos y herramientas en línea que

emplean una interfaz web.

Thin client: el modo Thin-client amplía la capacidad de las funciones criptográficas

del navegador web. Esta opción permite el acceso remoto a aplicaciones basadas en

253

TCP como POP3, SMTP, IMAP, Telnet y SSH. El usuario remoto descarga un applet

Java haciendo clic en el vínculo que se proporciona en la página del portal o

descargando el applet automáticamente. El applet Java actúa como un proxy TCP en

la máquina cliente para los servicios que se configuran en la puerta de enlace.

Modo de túnel: el modo de cliente de túnel completo ofrece un amplio soporte de

aplicaciones a través de su cliente Cisco AnyConnect VPN para VPN SSL SSL

descargable dinámicamente. El modo de cliente tunel completo ofrece un cliente de

tunelización SSL VPN ligero, configurado centralmente y fácil de soportar que

proporciona acceso a la capa de red a prácticamente cualquier aplicación.

DESCRIPCIÓN GENERAL DE FLEXVPN

La implementación de VPN IPsec sobre redes IP puede ser compleja y a menudo resulta en

altos costos asociados con la implementación de varios tipos de soluciones VPN para

cumplir con diferentes tipos de requisitos de conectividad.

FlexVPN fue creado para simplificar la implementación de VPNs y diseñado para

solucionar la complejidad asociada con el despliegue de múltiples soluciones. FlexVPN

cubre todos los tipos de conectividad VPN: acceso remoto, teletrabajador, sitio a sitio,

movilidad, servicios de seguridad administrados y otros.

FlexVPN es una sólida tecnología de cifrado basada en estándares que ayuda a las

organizaciones a conectar de forma segura las sucursales y los usuarios remotos. La

solución puede proporcionar ahorros significativos en comparación con soportar

múltiples tipos independientes de soluciones VPN tales como soluciones basadas en GRE,

Crypto y VTI. FlexVPN se basa en IKEv2 basado en estándares abiertos como tecnología de

254

seguridad y también proporciona muchas mejoras específicas para proporcionar altos

niveles de seguridad, valor añadido y diferenciación competitiva.

FlexVPN proporciona los siguientes beneficios:

Red de transporte: La solución se puede implementar a través de Internet pública

o VPN privada MPLS.

Estilo de implementación: La solución fue diseñada para la concentración de VPN

de sitio a sitio y de acceso remoto. Un único despliegue FlexVPN puede aceptar

ambos tipos de solicitudes de conexión al mismo tiempo.

Redundancia de conmutación por error: se pueden implementar tres tipos

diferentes de modelos de redundancia con FlexVPN: protocolos de enrutamiento

dinámico, distribución de rutas dinámica basada en IKEv2 con agrupación de

servidores y conmutación por error de estado activo / en espera de IPsec / IKEv2

entre dos chasis.

Compatibilidad con otros fabricantes: La solución FlexVPN proporciona

compatibilidad con cualquier proveedor de VPN de terceros basado en IKEv2,

incluidos los clientes VPN nativos de Apple iOS y dispositivos Android.

Soporte de multidifusión IP: FlexVPN admite de forma nativa la multidifusión IP.

Calidad de servicio superior: La arquitectura de FlexVPN permite fácilmente

integrar la QoS jerárquica por túnel o por SA.

Control de políticas centralizado: las políticas de VPN dinámicas se pueden

integrar completamente con el uso de un servidor AAA / RADIUS y aplicarse por

cada par. Estas políticas dinámicas incluyen la política de túnel dividido, la política

de red de cifrado, la selección VRF, la resolución del servidor DNS (para acceso

remoto), etc.

Conciencia VRF: FlexVPN soporta VRF interior y VRF de puerta frontal para un

despliegue de aislamiento de vías de extremo a extremo VRF. También puede

administrar la política de asignación interna de VRF con el servidor AAA

centralizado.

Arquitectura de FlexVPN

FlexVPN ofrece un marco simple pero modular que utiliza extensivamente el paradigma

de la interfaz del túnel mientras que sigue siendo compatible con las implementaciones

VPN heredadas que usan mapas criptográficos. FlexVPN es la implementación de Cisco del

estándar IKEv2; es compatible con un único enfoque de configuración para todos los tipos

de VPN. IKEv2 es un protocolo de administración de claves de próxima generación que se

basa en RFC 4306 y es una mejora del protocolo IKE. IKEv2 se utiliza para realizar

autenticación mutua y establecer y mantener SA.

255

FlexVPN admite configuraciones por par de parámetros de servicio, como QoS,

mecanismos de firewall, directivas y configuraciones relacionadas con VRF. Es ideal para

la agregación de servicios que abarca tanto el acceso remoto como las VPN de sitio a sitio.

Proporciona una mejor gestión de servicios a través de la integración con bases de datos

AAA externas y funciona bien en escenarios de multinacionales.

Capacidades FlexVPN

FlexVPN admite una amplia gama de capacidades para implementaciones de VPN de sitio

a sitio y de acceso remoto. Quizás la manera más fácil de entender las capacidades de

FlexVPN es realizar una comparación de capacidades VPN.

La Tabla proporciona un resumen de las capacidades VPN a través de varias soluciones

VPN.

EasyVPN DMVPN Crypto MAP Flex VPN

Enrutamiento dinámico No Yes No Yes

Spoke-to-Spoke Directo No Yes No Yes

Acceso remoto Yes No Yes Yes

Empuje de configuración Yes No No Yes

Configuración por usuario Yes No No Yes

Per-Peer QoS Yes Yes-Grupo No Yes

Gestión completa de AAA Yes No No Yes

256

Bloques de configuración FlexVPN

Para implementar FlexVPN en el enrutador, debe configurar varios bloques de

construcción con valores personalizados y predeterminados. La Figura proporciona una

descripción general del bloque de configuración de FlexVPN.

Como se muestra en el diagrama, los bloques de configuración para FlexVPN son

Propuesta IKEv2: Define los atributos de protección que se utilizarán en la

negociación de IKEv2 SA. Después de crear una propuesta IKEv2, adjúntela a una

directiva IKEv2 para que la propuesta se seleccione para la negociación.

Política IKEv2: Vincula la propuesta a un compañero VPN. La directiva IKEv2 hace

referencia a la propuesta IKEv2.

Llavero IKEv2: Permite definir claves previamente compartidas, que pueden ser

asimétricas.

Perfil IKEv2: Proporciona un repositorio de parámetros no negociables de IKE SA,

como la dirección de peer VPN y los métodos de autenticación que se utilizarán. No

hay un perfil predeterminado IKEv2, por lo que debe configurar uno y adjuntarlo a

un perfil IPsec en el iniciador. Si se utiliza autenticación de clave previamente

compartida, el perfil IKEv2 hace referencia al llavero IKEv2.

Conjunto de transformaciones IPsec: Especifica una combinación aceptable de

protocolos de seguridad y algoritmos para la IPsec SA.

Perfil IPsec: resume la configuración de FlexVPN en un solo perfil que se puede

aplicar a una interfaz. El perfil IPsec hace referencia al conjunto de

transformaciones IPsec y al perfil IKEv2.

257

Para minimizar la configuración de FlexVPN, puede usar una característica IKEv2 llamada

Smart Defaults. Esta función incluye la configuración predeterminada para todos los

bloques de configuración, excepto el perfil IKEv2 y el llavero. IKEv2 Smart Defaults

también se puede personalizar para casos de uso específicos; Sin embargo, esta práctica

no suele ser recomendada.

GETVPN

La última tecnología VPN discutida es la VPN de transporte cifrado de Grupo (GETVPN).

Las VPN completamente malladas presentan un desafío de escalabilidad y manejabilidad.

Históricamente, muchos clientes han evitado usar VPN de malla completa. La tecnología

GETVPN proporciona una solución VPN sin túneles para abordar estos desafíos y permite

a las organizaciones desplegar fácilmente redes complejas, redundantes, totalmente

redundantes y seguras.

GETVPN ofrece un nuevo modelo de seguridad IPsec basado en estándares basado en el

concepto de miembros de grupo "de confianza". Los enrutadores miembros confiables

usan una metodología de seguridad común que es independiente de cualquier relación de

túnel IPsec punto a punto.

Los controladores de grupo, también conocidos como servidores de claves, y los miembros

del grupo son los dos componentes clave de la arquitectura GETVPN. El servidor de claves

autentica todos los miembros del grupo, realiza el control de admisión al dominio GETVPN

y crea y suministra claves de autenticación de grupo y SA a los miembros del grupo. Los

miembros del grupo proporcionan el servicio de protección de transmisión a tráfico

sensible de sitio a sitio (de miembro a miembro). La Figura muestra el flujo general del

protocolo GETVPN.

258

Un servidor de claves distribuye claves y políticas a todos los miembros de grupo

registrados y autenticados. Al distribuir claves y políticas desde un punto centralizado y

compartiendo el mismo grupo SA con miembros de grupo autenticados, simplifica

enormemente la distribución y administración de claves.

La comunicación entre un servidor de claves y los miembros del grupo se cifra y asegura

mediante el protocolo IKE Group Domain of Interpretation (GDOI). IKE GDOI es un

protocolo de gestión de claves de grupo ISAKMP basado en estándares que está diseñado

para proporcionar comunicaciones de grupo seguro y está estandarizado en RFC 3547.

GETVPN utiliza IKE GDOI funcionamiento.

Sobre el puerto UDP 848 como el mecanismo de clave de grupo. IKE GDOI admite el uso de

dos claves. La clave de cifrado de tráfico (TEK) se utiliza para proteger el tráfico entre los

miembros del grupo, mientras que la clave de cifrado clave (KEK) se utiliza para proteger

las claves (actualización de claves) entre los servidores de claves y los miembros del

grupo. El servidor de claves distribuye el TEK a todos los miembros del grupo. Los

miembros del grupo utilizan TEK descargado para comunicarse de forma segura entre el

grupo y para crear y verificar paquetes IPsec. El servidor de claves también distribuye el

KEK, que los miembros del grupo utilizan para descifrar los mensajes de rekey entrantes

del servidor de claves.

Una diferencia importante de GDOI IKE es que GDOI IKE SA no necesita permanecer entre

los miembros después del establecimiento inicial. GDOI IKE SA puede dejarse expirar

rápidamente después de que un miembro del grupo se haya autenticado en el servidor de

claves y haya obtenido la directiva de grupo. La segunda gran diferencia es que las

sesiones GDOI IKE no se establecen entre todos los compañeros en una VPN. Las sesiones

se establecen sólo entre cada miembro del grupo y el servidor de claves (o varios

servidores de claves para la redundancia). Otra diferencia notable de una VPN basada en

GDOI es que todos los miembros del grupo utilizan el mismo conjunto de claves de sesión

para proteger el tráfico de la red. Esto es diferente de las implementaciones VPN IPsec

clásicas, en las que cada par de pares tiene un conjunto privado de SA de IPsec que sólo se

comparte entre los dos pares.

Los miembros del grupo deben registrarse en el servidor de claves para recibir directivas

desde el servidor de claves. Al recibir los mensajes de registro de un miembro del grupo, el

servidor de claves genera la información que contiene la política de rekey (una KEK) y las

nuevas SA de IPsec (múltiples atributos de TEK, información de política de cifrado de

tráfico, vida útil, fuente y destino acerca de El tráfico que debe protegerse y el ID del índice

de parámetros de seguridad [SPI] asociado a cada TEK). La nueva IPsec SA se envía

entonces al miembro del grupo.

En el plano de datos GETVPN, los miembros del grupo que tienen SAs de grupo IPsec

apropiadas pueden proteger el tráfico y enviar el tráfico a otros miembros del grupo. Estos

259

miembros del grupo pueden descifrar los paquetes porque tienen el mismo grupo IPsec

SAs.

GETVPN utiliza mensajes de rekey para actualizar las SA de IPsec (claves de sesión) fuera

de las sesiones de IKE. Cuando las SA de grupo IPsec están a punto de expirar, se genera en

el servidor de claves un único mensaje de rekey para un grupo en particular. No se crean

nuevas sesiones IKE para la distribución de mensajes de rekey.

A continuación, se presentan dos opciones de cambio de clave:

Reincorporación por unidifusión: cuando se utiliza una clave unicast con muchos

miembros del grupo, el servidor de claves genera mensajes de rekey para sólo unos

pocos miembros del grupo a la vez. El servidor de claves también garantiza que

todos los miembros del grupo reciban los mensajes de rekey para la nueva SA antes

de que la antigua SA expire. Este proceso ayuda a reducir los problemas de latencia.

Además, cuando un grupo unicast recibe el mensaje de rekey desde el servidor de

claves, un miembro del grupo envía un mensaje ACK cifrado al servidor de claves.

Utiliza las teclas que se reciben como parte del mensaje de rekey.

Reincorporación por multidifusión: con el rekeying de multidifusión, el servidor

de claves envía rekey de multidifusión a los miembros del grupo. Envía un único

paquete de rekey multidifusión al núcleo y el núcleo realiza la replicación para

todos los miembros del grupo. Debido a que el miembro del grupo no envía ningún

acuse de recibo, las repeticiones se retransmitirán dos o tres veces durante cada

período de rekey. El uso de transporte multicast es eficiente y altamente

recomendado para una red más grande. A su vez, la reestructuración multicast

reduce la carga en el servidor de claves para procesar los mensajes de rekey para

cada miembro del grupo y los acuses de recibo recibidos de cada miembro del

grupo. Además, el miembro del grupo no envía ningún acuse de recibo, como se

requiere en el mecanismo de transporte de unidifusión.

Si la red empresarial tiene capacidad de multidifusión, se recomienda que utilice el

rekeying de multidifusión, que es un mecanismo más escalable.

Las siguientes son algunas pautas generales para rekeying:

Si la mayoría de los miembros del grupo sólo son capaces de unicast, utilice unicast

rekeying.

Si la mayoría de los miembros del grupo son capaces de multidifusión (y toda la red

de transporte es capaz de multidifusión), utilice el cambio de multicast.

GETVPN tiene los siguientes beneficios:

La configuración es escalable porque la configuración no crece significativamente

cuando se agregan miembros del grupo en un escenario totalmente mapeado.

Proporciona soporte escalable para tráfico multicast. Hay, sin embargo, algunas

limitaciones:

260

Las direcciones VPN deben ser enrutables en la red de transporte. Esta limitación

es una consecuencia directa de la preservación del encabezado IP original y, en la

mayoría de los casos, evita que GETVPN se utilice a través de Internet.

El compromiso de un compañero puede tener un efecto perjudicial en la seguridad

de otros compañeros porque las claves de grupo se comparten y un atacante podría

descifrar cualquier tráfico en el GETVPN.

Los servidores clave deben estar disponibles durante las repeticiones y el registro

para que toda la red funcione.

Puede utilizar redes basadas en GETVPN en varios entornos de WAN, incluyendo IP y

MPLS. MPLS VPNs que utilizan esta tecnología de protección de transmisión son altamente

escalables, manejables y rentables; Además, cumplen con los requisitos de protección de

transmisión reglamentarios. La naturaleza flexible de GETVPN permite a las empresas

conscientes de la seguridad gestionar su propia seguridad de red a través de un servicio

WAN de un proveedor de servicios o descargar servicios de cifrado a sus proveedores.

GETVPN simplifica la seguridad de grandes redes de Capa 2 o MPLS que requieren

conectividad de malla parcial o total.

Cuando está diseñando un GETVPN, tiene varias opciones de implementación. Debe

decidir si va a utilizar la clave previamente compartida o la autenticación basada en PKI. El

uso de la clave previamente compartida es más sencillo, pero la seguridad es

generalmente más fuerte cuando se utiliza una infraestructura PKI. Cuando está utilizando

la clave previamente compartida, no puede utilizar miembros de grupo dirigidos

dinámicamente. Debe utilizar autenticación basada en PKI para esta tarea. Para ofrecer

alta disponibilidad, puede tener varios servidores de claves. Cada servidor de claves es un

servidor de claves activo que gestiona solicitudes de los miembros del grupo. Uno de los

servidores clave es un servidor de clave principal y se utiliza para actualizar las directivas

a los otros servidores de claves.

Debe considerar tres pautas principales al implementar una VPN usando la tecnología

GETVPN:

Se recomienda que considere GETVPN como su tecnología primaria para

implementar una conectividad escalable y totalmente maquinada con varios sitios

privados.

Cuando implementa GETVPN a través de Internet, es obligatorio utilizar

direcciones IP enrutables en todas las redes incluidas en la VPN. Por lo general, esta

opción no es posible porque las empresas utilizan direcciones privadas basadas en

RFC 1918 dentro de sus redes internas.

En un GETVPN, no hay ningún problema de escalabilidad con el enfoque PSK

porque sólo necesita configurar un número limitado de sesiones IKE. Se deben

utilizar otros criterios para decidir entre PSK y PKI, especialmente ponderando la

complejidad de PKI frente a posibles problemas de seguridad (PSK débiles) con

PSKs.

261

Capítulo 10

Diseño de la Resiliencia

de la WAN Empresarial

262

DESCRIPCIÓN DEL SITIO REMOTO DE WAN

La mayoría de los sitios remotos están diseñados con un borde WAN de un solo enrutador.

Sin embargo, ciertos tipos de sitios remotos requieren un borde WAN de doble enrutador.

Los sitios candidatos a enrutador dual incluyen oficinas regionales o ubicaciones de

campus remotas con grandes poblaciones de usuarios o sitios con necesidades críticas de

negocio que justifiquen redundancia adicional para eliminar puntos de fallo únicos, como

centros de contacto o almacenes de distribución. El tamaño de la LAN del sitio remoto

depende de factores como el número de usuarios conectados y el diseño físico del sitio

remoto.

La selección de la plataforma de enrutamiento WAN del sitio remoto es impulsada por

requisitos de diseño lógico y la especificación determinada está estrechamente vinculada a

factores tales como ancho de banda, servicios agregados, redundancia de componentes y

otros factores que afectan el rendimiento, la escala y la resiliencia. Cisco Integrated

Services Enrutadores (ISR) admite módulos adiciones y, en versiones más recientes,

actualizaciones de rendimiento de ancho de banda. Su capacidad para implementar un

diseño de solución con varias opciones es una de las ventajas de un enfoque de diseño

modular enfocado en acomodar las necesidades a largo plazo.

Debe considerar muchos factores en la selección de enrutadores de sitios remotos WAN.

Uno de estos factores es la capacidad de procesar la cantidad y el tipo de tráfico esperado.

Otras áreas de consideración son asegurar que haya suficientes interfaces y ranuras de

módulos, y la capacidad de licenciamiento necesaria para permitir el conjunto de

características requeridas para soportar el diseño acordado.

Una vez que se ha determinado el diseño de la WAN, la topología general que se utiliza

para varios sitios remotos debe ser esencialmente la misma, independientemente del tipo

de sitio. Las diferencias asociadas con varias opciones de transporte WAN son evidentes

después de iniciar la implementación y configuración de los enrutadores WAN.

Tabla 10-1 Opciones de transporte WAN de agregación WAN y de sitios remotos

WAN Aggregation

Design Model

(Primary)

WAN

Aggregation

Design Model

(Secondary)

WAN

Remote Site

Enrutadores

WAN

Transports

Primary

Transport

Secondary

Transport

MPLS Static

MPLS Dynamic

Dual MPLS

Layer 2 Simple

Layer 2 Trunked

Único Único MPLS VPN

Único Único MetroE/

VPLS

263

DMVPN Only

Dual DMVPN

DMVPN Only

Dual DMVPN

Único Único Internet


3G/4G

Dual MPLS Dual MPLS Único Dual MPLS VPN A MPLS

VPN B

MPLS Static

MPLS Dynamic

Dual MPLS

MPLS Static

MPLS Dynamic

Dual MPLS

Layer 2 Simple

Layer 2 Trunked

DMVPN

Backup Shared

DMVPN Backup

Dedicated

DMVPN Backup

Shared

DMVPN Backup

Dedicated

Único Dual MPLS VPN Internet


3G/4G

Único Dual MetroE/VPLS Internet

Dual DMVPN

Dual MPLS

MPLS Dynamic

Dual MPLS

MPLS Dynamic

Dual MPLS

Layer 2 Simple

Layer 2 Trunked

Dual DMVPN

DMVPN Backup

Dedicated

Dual DMVPN

Dual MPLS

DMVPN Backup

Dedicated

DMVPN Backup

Dedicated

DMVPN Backup

Dedicated

Único Dual Internet Internet

Dual Dual MPLS VPN A MPLS VPN

B

Dual Dual MPLS VPN Internet


3G/4G

Dual Dual MetroE/VPLS Internet

264

MODELOS DE DISEÑO WAN DE LA CAPA 3 DE MPLS

Las VPN MPLS de Capa 3 utilizan un modelo VPN peer-to-peer que aprovecha BGP

Multiprotocolo (mBGP) dentro de la red de proveedores para distribuir información

privada de prefijo y VPN. Este modelo peer-to-peer permite a los suscriptores

subcontratar a los proveedores de servicios la responsabilidad de enrutamiento de sitio a

sitio de la empresa. Este modelo de diseño típicamente resulta en islas de campus

corporativo y enrutamiento de enrutamiento IGP interconectados con las relaciones eBGP

de borde de cliente a cliente.

Los diseños de agregación de WAN MPLS (hub) incluyen uno o dos enrutadores de borde

WAN. Cuando se hace referencia a los enrutadores de borde WAN en el contexto de la

conexión a un proveedor de servicio o proveedor, normalmente se les conoce como

enrutadores de cliente (CE). Todos los enrutadores CE de borde WAN en el sitio de

concentrador normalmente se conectan a una capa de distribución LAN.

Las opciones de transporte WAN incluyen VPN MPLS utilizadas como transporte primario

o secundario. Cada transporte se conecta a un enrutador CE dedicado en el sitio del

concentrador. Un método similar de conexión y configuración es apalancado para ambos

hubs.

Tres modelos de diseño de agregación WAN MPLS comunes aprovechan el enrutamiento

estático o dinámico con el proveedor de servicios MPLS. La diferencia principal entre los

diversos diseños es el uso de los protocolos de enrutamiento. Varias opciones de la

plataforma de enrutador con diferentes niveles de rendimiento y capacidad de resiliencia

son adecuadas para cada modelo.

265

Cada uno de los modelos de diseño utiliza conexiones LAN en una capa de núcleo /

distribución doblada o en una capa de distribución de WAN dedicada. No existen

diferencias funcionales entre estos dos métodos desde la perspectiva de agregación WAN.

En todos los diseños de agregación de WAN, se realizan tareas como la supresión de rutas

IP en la capa de distribución. Otros dispositivos diversos admiten servicios de borde WAN,

como optimización de aplicaciones y encriptación, y estos dispositivos también deben

conectarse a la capa de distribución.

Cada portadora MPLS termina en un enrutador WAN dedicado con el objetivo principal de

eliminar cualquier punto de fallo.

A continuación, se presentan las recomendaciones de diseño para las opciones de

conectividad WAN:

MPLS Estática:

o Apropiado para implementaciones más pequeñas

o Utiliza enrutamiento estático entre los enrutadores CE y PE

o Utiliza un único proveedor de servicios MPLS

o Requiere que el proveedor de servicios MPLS inyecte rutas estáticas y

anuncie prefijos de sitio existentes y futuros en nombre del cliente

MPLS dinámico:

o Adecuado para WAN de tamaño mediano

o Utiliza enrutamiento dinámico entre los enrutadores CE y PE

o Utiliza un único proveedor de servicios MPLS

o Por lo general, aprovecha eBGP para peering PE-CE

Dual MPLS:

o Adecuado para WANs más grandes

o Utiliza enrutamiento dinámico entre los enrutadores CE y PE

o Por lo general, aprovecha eBGP para peering PE-CE

o Usualmente utiliza múltiples enrutadores CE para una alta disponibilidad

En la Figura se muestran los tres modelos de diseño de sitios remotos WAN típicos:

MPLS WAN no redundante

MPLS WAN con enlace redundante

MPLS WAN con enlace redundante y enrutador

266

La variante no redundante es la única que es compatible con los modelos de diseño de una

sola portadora (MPLS Static o MPLS Dynamic). Las variantes redundantes son compatibles

con el modelo de diseño Dual MPLS. Si ha implementado el modelo de diseño Dual MPLS,

también puede conectar un sitio remoto no redundante a cualquier soporte.

El sitio remoto típico utiliza sólo un único enrutador WAN debido al impacto de

restricciones como la asequibilidad. Algunos sitios remotos que son de naturaleza crítica

pueden utilizar un modelo de diseño de enrutador dual. Estos sitios remotos suelen ser

oficinas regionales, ubicaciones con muchos usuarios o sitios que son críticos para el

negocio y necesitan redundancia adicional para eliminar puntos de falla únicos.

MODELOS DE DISEÑO DE WAN DE CAPA 2

Los transportistas WAN de nivel 2 están ampliamente disponibles en los proveedores de

servicios. Las implementaciones más comunes de la WAN de capa 2 se utilizan para

proporcionar Ethernet a través de la WAN utilizando un servicio punto a punto (EoMPLS)

o un servicio punto a multipunto (VPLS). Muchos proveedores de servicios también

ofrecen servicios Ethernet Carrier o Metro Ethernet que normalmente se limitan a un área

geográfica relativamente pequeña.

267

El diseño puede utilizar una demarcación simple (un enlace con una VLAN) o una

demarcación troncalizada (varias VLAN). La diferencia principal entre la demarcación

simple y el modelo de diseño de demarcación troncalizada es el número de dominios de

difusión o VLAN que se utilizan para comunicarse con un subconjunto de enrutadores de

sitios remotos.

Cuando utiliza el modelo de diseño de demarcación simple, el proveedor de servicios

conecta su equipo con una sola VLAN. Esta VLAN proporciona la conectividad de Nivel 2

entre el sitio central y el sitio remoto. Cuando utiliza el modelo de diseño de demarcación

de enlaces troncales, conecta sus sitios centrales y remotos utilizando el etiquetado VLAN

802.1Q. Los proveedores de servicios a menudo se refieren a un servicio truncado como

túnel Q-in-Q (QinQ).

Cada uno de los modelos de diseño utiliza conexiones de LAN en una capa de distribución

o capa de distribución colapsada o en una capa de distribución de WAN dedicada. No

existen diferencias funcionales entre estos dos métodos desde la perspectiva de

agregación de WAN.

En el diseño de agregación WAN, se realizan tareas como la supresión de rutas IP en la

capa de distribución. Otros dispositivos diversos admiten servicios de borde WAN, como

la optimización de la aplicación y el cifrado, y estos dispositivos también deben conectarse

a la capa de distribución.

268

Con un modelo de diseño WAN de capa 2, el cliente empresarial es responsable de todo el

enrutamiento de extremo a extremo sobre la WAN. A diferencia de los servicios MPLS,

existen relaciones entre los dispositivos CE y PE.

MODELOS COMUNES DE DISEÑO DE WAN VPN

La VPN WAN pueden utilizar Internet como tecnología de transporte WAN. Internet es

esencialmente una WAN pública a gran escala compuesta por múltiples proveedores de

servicios interconectados. Internet puede proporcionar conectividad confiable de alto

rendimiento entre varias ubicaciones, aunque carece de garantías explícitas para estas

conexiones. A pesar de la naturaleza del "mejor esfuerzo", Internet es una opción sensata

para un transporte primario cuando no es factible conectar con otra opción de transporte.

La flexibilidad adicional puede ser introducida en un diseño existente utilizando servicios

de WAN MPLS o Capa 2 utilizando Internet como alternativa de transporte.

Dada su amplia capacidad, la Red Privada Virtual Multipunto (DMVPN) ha sido la opción

más ampliamente implementada para proporcionar servicios de VPN WAN. DMVPN es una

solución altamente escalable que soporta la conectividad de malla completa bajo demanda

con una configuración simple de concentrador y de radio y un modelo de implementación

de concentrador de cero toque para agregar sitios remotos. La capacidad de soportar

enrutadores de enrutamiento dinámico, multidifusión y de habla que han asignado

dinámicamente direcciones IP son otros factores que la convierten en la opción ideal.

Los modelos de diseño de agregación WAN múltiples son ampliamente utilizados. El

modelo de diseño DMVPN utiliza sólo una VPN de Internet como medio de transporte. El

modelo de diseño Dual DMVPN utiliza Internet VPN como transporte primario y

secundario, aprovechando los proveedores de servicios de Internet redundantes.

En los modelos de diseño DMVPN simple y Dual DMVPN, los enrutadores de concentrador

VPN se conectan a la interfaz DMZ de firewall en lugar de conectarse directamente con

269

enrutadores de proveedores de servicios de Internet. La interfaz DMZ está contenida en el

borde de Internet, proporcionando una capa adicional de seguridad. Ambos modelos de

diseño pueden utilizar uno o dos enrutadores de concentrador. La Figura proporciona una

representación visual de los modelos de diseño DMVPN Only y Dual DMVPN.

Como se puede ver en la Figura, al usar el modelo de diseño DMVPN simple, sólo tiene un

proveedor de servicios de Internet en el sitio central. En contraste, el modelo de diseño

Dual DMVPN utiliza dos proveedores de servicios de Internet para proporcionar alta

disponibilidad. De forma similar a los modelos de diseño MPLS y Layer 2 WAN, cada uno

de los modelos de diseño VPN WAN tiene conexiones LAN en una capa de distribución /

distribución de red o una capa de distribución WAN dedicada. Además, al igual que con las

otras opciones de diseño, desde una perspectiva de agregación WAN, no hay diferencias

funcionales entre estos dos métodos. El resumen de rutas IP y tareas similares se realizan

consistentemente en la capa de distribución como una mejor práctica común.

Los modelos de diseño de respaldo de DMVPN utilizan la VPN de Internet como respaldo

de un transporte WAN de MPLS WAN o Capa 2 primario existente. La principal diferencia

entre los diseños de respaldo DMVPN es si el concentrador VPN se implementa en un

enrutador MPLS CE existente, que se conoce como respaldo compartido de DMVPN o el

concentrador VPN se implementa en un enrutador de concentrador VPN dedicado,

denominado DMVPN de respaldo dedicado.

270

En el modelo DMVPN de respaldo compartido, el enrutador DMVPN también es el

enrutador MPLS CE. Si no desea dedicar una interfaz física independiente para la

conectividad WAN DMVPN, es posible aprovechar una subinterfaz en el enrutador

utilizando la conexión que ya está en su lugar entre el enrutador y la capa de distribución

o núcleo. La conexión a Internet se establece a través de esta subinterfaz recién definida y

una interfaz de firewall que está contenida en el borde de Internet. Esta opción de

conectividad elimina el requisito de aprovechar una interfaz dedicada y DMZ para este

modelo de diseño.

En los modelos de diseño DMVPN de respaldo dedicado, los enrutadores de concentrador

DMVPN se conectan a Internet indirectamente a través de una interfaz DMZ de firewall

que se encuentra dentro del borde de Internet. Los enrutadores de concentrador VPN

están conectados en la interfaz DMZ del firewall, en lugar de conectarse directamente con

los enrutadores de proveedores de servicios de Internet.

El diseño DMVPN de respaldo dedicado tiene múltiples variantes. La diferencia entre ellos

es el tipo de transporte primario. Algunos de los diseños son

DMVPN de respaldo, modelo de diseño dedicado con MPLS Dynamic como

transporte primario

DMVPN de respaldo, modelo de diseño dedicado con Dual MPLS como transporte

primario

DMVPN de respaldo, modelo de diseño dedicado con WAN de capa 2 como

transporte primario

271

Hay varias opciones para diseños de sitios remotos de WAN. Estas opciones se basan en

varias combinaciones de transportes WAN asignados a los requisitos específicos del sitio

para niveles de servicio y redundancia. Los diseños de sitios remotos incluyen un borde de

WAN simple o doble enrutadores Estos enrutadores pueden ser enrutadores CE (para

MPLS o WAN de capa 2) o enrutadores de VPN. En algunos casos, un único enrutador de

borde WAN puede realizar el rol del enrutador CE y del enrutador de radio VPN.

Las posibles combinaciones basadas en el transporte WAN incluyen

Internet WAN:

o No redundante

o Enlaces redundantes

o Enlaces y enrutadores redundantes

MPLS y WAN de Internet:



WAN de capa 2 y WAN de Internet:



MODELOS DE DISEÑO VPN 3G / 4G

Conectividad de cobre y fibra no siempre son una opción cuando se conecta una sucursal

remota. La conectividad celular proporciona una solución alternativa para estos casos y se

está volviendo más común.

Un VPN de Internet que se ejecuta a través de una WAN inalámbrica 3G o 4G se utiliza

normalmente como una solución de respaldo para el transporte primario MPLS o Layer 2

WAN. Es importante notar, sin embargo, que este tipo de conectividad también se puede

utilizar como la conectividad principal para las sucursales remotas más pequeñas. Las

interfaces 3G / 4G WAN suelen utilizar direcciones IP dinámicas. DMVPN es especialmente

útil para esta opción de despliegue considerando que soporta direccionamiento dinámico.

272

SITIO REMOTO USANDO INTERNET LOCAL

Tradicionalmente, muchas de las aplicaciones y servicios que utilizan los usuarios de sitios

remotos se han localizado y consolidado en el centro de datos de la empresa. Con

tendencias como la nube pública y el software público alojado en Internet como una

aplicación de servicio, existen ventajas al proporcionar acceso local a Internet en cada

ubicación del sitio remoto. El diseño del sitio remoto proporciona a la oficina remota

soluciones locales de acceso a Internet para navegación web y servicios en la nube. Esta

solución se conoce como el modelo local de Internet.

Con el modelo de Internet local, se permite que el tráfico web de usuarios y el tráfico de

servicios en la nube alojados utilicen el enlace de Internet local de forma dividida. En este

modelo, una ruta predeterminada se genera localmente, conectando cada sitio remoto

directamente al proveedor de Internet. Las conexiones WAN privadas que utilizan DMVPN

a través de una WAN de Internet, MPLS o de Capa 2 proporcionan rutas internas al centro

de datos y al campus. En algunas configuraciones, el enrutamiento de Internet de respaldo

se proporciona a través de las conexiones WAN privadas.

273

El tráfico local se reenvía directamente a Internet utilizando la ruta predeterminada. Esta

ruta predeterminada se dirige al enrutador de siguiente salto en la red del ISP. Debido a

que las direcciones RFC 1918 se utilizan para redes internas, todo el tráfico vinculado a

Internet se traduce a una dirección pública mediante PAT en la interfaz al ISP. Además de

PAT, también es importante proporcionar inspección con estado para aplicar una directiva

que permite el tráfico de devolución sólo para sesiones iniciadas por usuarios internos.

Cuando se está aprovechando un modelo de Internet local, si no se utiliza una instancia de

enrutamiento y reenvío virtual de puerta frontal (fVRF) junto con el diseño de DMVPN

para segmentar la tabla de enrutamiento, no se permitirá una ruta predeterminada a

través de túneles VPN basados en Internet porque puede ocurrir. En el caso de que falte el

fVRF, el enrutamiento de Internet de respaldo no es posible a través de estos túneles VPN,

por lo que la mejor práctica recomendada es filtrar la ruta predeterminada del sitio

central para que no se aprenda en la interfaz túnel. Garantizar que la ruta predeterminada

al ISP local es preferible a la ruta predeterminada del sitio central al aprovechar una

distancia administrativa más baja también ayuda a evitar problemas si la ruta

predeterminada no se filtra debido a configuraciones erróneas. La reposición central de

Internet es posible con los servicios WAN basados en MPLS. También es posible realizar

una reposición central de Internet con servicios WAN basados en VPN cuando una

combinación de fVRF, DMVPN y filtración de rutas se aprovechan como parte del diseño

de la solución. Consulte las siguientes guías de diseño validadas de Cisco para obtener más

información sobre este tema avanzado:

Guía de diseño de tecnología WAN de VPN

Sitio remoto VPN a través de la Guía de diseño de tecnología 3G / 4G

La Tabla resume las opciones de transporte WAN para sitios remotos que usan Internet

local. Es importante tener en cuenta que los cambios de configuración de enrutamiento de

sitios remotos cuando se despliega el acceso local a Internet. Por ejemplo, debe asegurarse

de que no se recibe ninguna ruta por defecto sobre la interfaz del túnel para enviar tráfico

274

de Internet utilizando el enlace local de Internet, mientras que el tráfico destinado al

concentrador o sitios remotos debe pasar por la interfaz del túnel

Tabla 10-2 Opciones de transporte WAN para sitios remotos que usan Internet local

WAN Aggregation

Design Model

(Primary)

WAN

Aggregation

Design Model

(Secondary)

WAN

Remote

Site

Routers

WAN

Transports

Primary

Transport

Secondary

Transport

DMVPN Only

Dual DMVPN

DMVPN Only

Dual DMVPN

MPLS Static

MPLS Dynamic

Dual MPLS

MPLS Static

MPLS Dynamic

Dual MPLS

Capa 2 Simple

Capa 2 Trunked

Dual DMVPN

DMVPN Backup

Shared

DMVPN Backup

Dedicated

DMVPN Backup

Shared

DMVPN Backup

Dedicated

DMVPN Backup

Dedicated



3G/4G



3G/4G

Único Dual MetroE/VPLS Internet

Unico Dual Internet Internet

MPLS Dynamic

Dual MPLS

MPLS Dynamic

Dual MPLS

Capa 2 Simple

Capa 2 Trunked

Dual DMVPN Dual Dual MPLS VPN Internet

DMVPN Backup

Dedicated

DMVPN Backup

Dedicated


3G/4G

Dual Dual MetroE/VPLS Internet

Dual DMVPN

DMVPN Backup

Dedicated

Dual Dual Internet Internet

LAN DEL SITIO REMOTO

El papel principal de la WAN es interconectar LANs de sitios primarios y de sitios remotos.

En sitios remotos, la topología de la LAN depende del número de usuarios conectados y de

la geografía física del sitio. Usted tiene diferentes opciones cuando está diseñando una red

de sitio remoto. Los sitios grandes pueden requerir el uso de una capa de distribución

para admitir múltiples conmutadores de capa de acceso. Otros sitios pueden requerir sólo

275

un conmutador de capa de acceso que esté conectado directamente a los enrutadores de

sitios remotos de la WAN. Las principales opciones de diseño son:

Enrutadores de sitios remotos WAN sencillos o duales

Transporte de WAN simple o dual

Una topología de LAN que sólo puede ser de acceso o capa de distribución / acceso

Por coherencia y modularidad, debe configurar todos los sitios remotos WAN con el

mismo esquema de asignación de VLAN.

Este modelo se puede escalar fácilmente a armarios de acceso adicionales mediante la

adición de una capa de distribución.

La figura muestra el impacto de agregar una capa de distribución en el diseño.

276

Los sitios remotos WAN que no requieren dispositivos adicionales de enrutamiento de la

capa de distribución LAN se consideran planos o, desde una perspectiva de LAN, se

consideran no enrutados Capa 2 Sitios. Los enrutadores WAN adjuntos proporcionan

todos los servicios de Capa 3. Los conmutadores de acceso pueden soportar servicios tales

como datos y voz utilizando varias VLAN. El beneficio de este diseño es que puede

configurar todos los conmutadores de acceso de forma idéntica independientemente del

número de sitios en esta configuración.

Las subredes IP se asignan en una base por VLAN. Normalmente, puede utilizar la máscara

/ 24 para la capa de acceso incluso si se requieren menos de 254 direcciones IP. Debe

configurar la conexión entre el enrutador y el conmutador de acceso para trunking VLAN

802.1Q con subinterfaces en el enrutador que se asignan a las respectivas VLAN del

conmutador. Las diversas subinterfaces del enrutador actúan como las puertas de enlace

predeterminadas IP para cada una de las combinaciones de subredes IP y VLAN.

El diseño de capa plana 2 se puede extender a un borde de doble enrutador. Este cambio

de diseño introduce alguna complejidad adicional. Por lo general, se ejecutará un

protocolo de enrutamiento internamente dentro del sitio remoto con un diseño de

enrutador dual. El protocolo de enrutamiento se configura entre los enrutadores. Los

diseños de doble enrutador también garantizan un componente de red de tránsito

adicional que se requiere para el enrutamiento adecuado en ciertos escenarios. En estos

casos, el flujo de tráfico desde un host remoto puede ser enviado a un destino accesible a

través del transporte WAN alternativo (por ejemplo, un sitio remoto dual MPLS que se

comunica con un sitio remoto MPLS B-simple). El enrutador de transporte WAN primario

envía el tráfico de vuelta a la misma interfaz de datos donde fue recibido de la LAN para

277

enviarlo a la WAN alternativa. Este enrutador luego reenvía el tráfico al destino correcto.

Este problema se conoce como horquilla.

El método apropiado para evitar el envío del tráfico a la misma interfaz es introducir un

enlace adicional entre los enrutadores y designar el enlace como una red de tránsito. No

hay hosts conectados a la red de tránsito, y se utiliza sólo para la comunicación routerrouter.

El protocolo de enrutamiento se ejecuta entre los subinterfaces del enrutador

asignados a la red de tránsito. No se requieren interfaces de enrutador adicionales con

esta modificación de diseño porque la configuración de troncales VLAN 802.1Q puede

acomodar fácilmente una subinterfaz adicional.

Debido a que hay dos enrutadores por subred y las subinterfaces del enrutador siguen

proporcionando funcionalidad de puerta de enlace predeterminada, debe implementar un

protocolo de redundancia de primer salto (FHRP). Puede utilizar HSRP, VRRP o el

protocolo GLBP. FHRP ofrece alta disponibilidad al proporcionar redundancia de

enrutamiento de primer salto para hosts IP configurados con una dirección IP de puerta

de enlace predeterminada. La Figura se basa en una Figura anterior mediante

superposición en FHRP y, más específicamente, en servicios HSRP.

En un diseño de enrutador dual con enrutadores aprovechando un FHRP como HSRP, se

necesita algo para activar la conmutación por error HSRP de Active a Standby cuando la

ruta WAN conectada no está disponible. Enhanced Object Tracking (EOT) proporciona una

metodología consistente para diversas funciones de enrutador y conmutación para

modificar condicionalmente su funcionamiento basado en objetos de información

disponibles en otros procesos. Algunos ejemplos de objetos que pueden rastrearse

incluyen el Protocolo de Línea de Interfaz, la accesibilidad de la ruta IP y la accesibilidad

de SLA IP. Para mejorar los tiempos de convergencia después de una falla de WAN

primaria, el enrutador puede monitorizar la accesibilidad de un vecino IP de siguiente

salto (MPLS PE, WAN CE de capa 2 o DMVPN) utilizando EOT e IP SLA. Esta combinación

permite a un enrutador renunciar a su función activa de HSRP si su vecino ascendente no

278

responde. Las capacidades de servicios integrados como éstas, cuando son apalancadas

como parte de un enfoque de diseño holístico, proporcionan flexibilidad de red adicional.

Los sitios remotos de gran tamaño pueden requerir un entorno LAN similar al de una

pequeña LAN de campus que incluye una capa de distribución y una capa de acceso, como

se muestra en la Figura.

Esta topología funciona bien con un borde de WAN de uno o doble enrutador. Para

implementar este diseño, los enrutadores deben conectarse a través de enlaces

EtherChannel al switch de distribución. Estos enlaces EtherChannel están configurados

como troncales VLAN 802.1Q. Este EtherChannel debe soportar un enlace enrutado punto

a punto para el enrutamiento con el conmutador de distribución (VLAN 101 y VLAN 102)

y en el diseño de enrutador dual, para proporcionar una red de tránsito para la

comunicación directa entre los enrutadores WAN (VLAN 100). El conmutador de

distribución de LAN controla el enrutamiento de la capa de acceso, con las VLAN

troncalizadas para acceder a los conmutadores. No se requiere FHRP en el borde WAN

cuando el diseño incluye una capa de distribución.

NGWAN, SDWAN Y IWAN; DESCRIPCIÓN GENERAL DE LA

SOLUCIÓN

Las aplicaciones ricas en medios, un mayor número de dispositivos que se conectan a la

red, el acceso de invitados, Internet of Things (IoT), ofertas de nube y otros factores

causan no sólo una mayor demanda de ancho de banda en la sucursal, sino también la

279

necesidad de organizaciones para reconsiderar el impacto asociado con un cambio en los

patrones de tráfico.

Hasta hace poco tiempo, la única manera de obtener conectividad confiable con un

rendimiento predecible era aprovechar una WAN privada que usaba MPLS o servicios de

líneas arrendadas. Los MPLS basados en operadores y los servicios de línea arrendada

pueden ser costosos y no siempre son una opción rentable para soportar los requisitos de

ancho de banda crecientes para la conectividad de sitios remotos. Las organizaciones

están buscando maneras de reducir su presupuesto operativo mientras proveen

adecuadamente el transporte de la red para un sitio remoto.

Conexiones a Internet más baratas se han vuelto más confiables y son más económicas en

comparación con los enlaces dedicados; Sin embargo, las empresas están principalmente

desplegando VPN por Internet en sus sitios más pequeños o como una ruta de respaldo

dados los riesgos percibidos y las insuficiencias de rendimiento. Las ganancias de precio a

rendimiento se han vuelto demasiado atractivas para ignorarlas, y las organizaciones

desean aprovechar el ancho de banda más barato en las sucursales, sin comprometer el

rendimiento, la disponibilidad o la seguridad de las aplicaciones.

Cisco IWAN permite a las organizaciones aprovechar las capacidades innovadoras que

mejoran el rendimiento para ofrecer una experiencia sin concesiones sobre cualquier

conexión. Cisco IWAN permite a las organizaciones de TI proporcionar más ancho de

banda a sus sucursales mediante el uso de opciones de transporte WAN menos caras sin

afectar el rendimiento, la seguridad o la fiabilidad. Con la solución IWAN, el tráfico se

enruta dinámicamente en función de la visibilidad de la aplicación, los SLA, el tipo de

punto final y las condiciones de la red para ofrecer la experiencia de mejor calidad. Los

ahorros obtenidos de IWAN no sólo pagan potencialmente por las mejoras de

infraestructura, sino también recursos gratuitos para la innovación empresarial.

Cuando las organizaciones consideran el estado actual de su WAN y el viaje hacia la

próxima generación de WAN, es importante mirar el panorama general y todos los

requisitos de capacidad necesarios para atender las necesidades a largo plazo del negocio.

Es obvio que los principales impulsores desde una perspectiva de negocio son la

reducción de costos, el mejor desempeño de las aplicaciones, la entrega acelerada de

nuevos servicios y la flexibilidad para innovar al enfrentar las limitaciones técnicas que

limitan la introducción de nuevas tecnologías necesarias para impactar las capacidades

empresariales globales.

Los requisitos de capacidad técnica que se muestran en la Figura. Estos requisitos para la

evaluación de la próxima generación de soluciones son

Diseño independiente del transporte (TID)

Control de trayectoria inteligente (IPC)

Optimización de aplicaciones (AO)

Conectividad segura (SC)

280

Además de los cuatro pilares TID, IPC, AO y SC, la manejabilidad general de la solución no

puede pasarse por alto. La capacidad de gestión de la solución puede afectar el tiempo de

actividad y simplificar o complicar el proceso de solución de problemas. Examinamos los

detalles de cada uno de estos requisitos de capacidad antes de pasar a la descripción del

diseño de IWAN.

Diseño independiente del transporte

Las organizaciones están pidiendo un diseño independiente del transporte. Teniendo en

cuenta los precios agresivos asociados con diferentes opciones de transportista y el deseo

de obtener el mejor beneficio por dólar, las organizaciones están buscando maneras de

realizar transporte y flexibilidad WAN de transporte. Ellos prevén un modelo operacional

consistente sobre todas las redes de acceso para eliminar la complejidad de enrutamiento

mientras se abordan la escalabilidad, la modularidad y la seguridad. El aprovechamiento

de un modelo de diseño independiente del transporte simplifica las migraciones de los

proveedores y no implica un rediseño completo o soluciones alternativas sofisticadas para

abordar un cambio en las necesidades del negocio. Internet con una superposición de

enrutamiento IPsec suele ser la solución que muchas organizaciones consideran e

implementan.

281

IWAN aprovecha una combinación de reenvío de enrutamiento virtual de puerta frontal

(fVRF) y superposiciones basadas en DMVPN en toda la conectividad disponible.

Ocultando el transporte subyacente con un fVRF único y haciéndolo accesible sólo por la

superposición DMVPN permite a las organizaciones utilizar cualquier conectividad

disponible y proporciona la flexibilidad para agregar o reemplazar conexiones de red sin

tener que modificar la arquitectura de red.

Control de trayectoria inteligente

Las organizaciones se dan cuenta de que para optimizar el rendimiento de las aplicaciones

y para implementar SLAs, necesitan la capacidad inteligente de control de rutas. El control

de trayectoria inteligente es más que la redirección de ruta disponible con la tecnología

clásica de enrutamiento. La mejor selección de rutas de aplicación implica definir una

preferencia de ruta vinculada a los SLA que protegen el tráfico crítico. Los SLAs se basan

en la medición de métricas tales como retraso, pérdida y jitter y están en el contexto de los

umbrales por aplicación requeridos para un rendimiento óptimo. La clase de tráfico de

esfuerzo mejor no clasificado necesita ser balanceado de forma eficiente a través de los

enlaces WAN independientemente de las discrepancias de ancho de banda.

IWAN aprovecha el Cisco Performance Routing (PfR) para mejorar la entrega de

aplicaciones y la eficiencia de la WAN. Cisco PfR controla dinámicamente las decisiones de

reenvío de paquetes de datos al examinar el tipo de aplicación, el rendimiento, las políticas

y el estado de la ruta.

Optimización de aplicaciones

Muchas aplicaciones están ocultas por HTTP. Las organizaciones deben ser capaces de ver

esas aplicaciones para optimizarlas para que puedan obtener un mejor rendimiento. Las

organizaciones quieren saber qué hay en sus redes y ser capaces de controlarlo. Imagine

tener la capacidad de monitorear e informar sobre cientos de aplicaciones y luego tener la

capacidad de aplicar la política QoS necesaria. El objetivo es asignar de forma fácil y

apropiada ancho de banda, así como la prioridad a las aplicaciones críticas mientras que

limita la utilización de recursos para aquellas aplicaciones que no son tan críticas.

En varias situaciones, las organizaciones quieren realizar aún más mediante el uso de

soluciones de aceleración y caché de aplicaciones. Ellos prevén cargas de página

inmediata, descargas de archivos, posicionamiento previo de los archivos de contenido, y

los beneficios de más ahorros de ancho de banda que resultan de la habilitación de

optimización adicional y capacidades de caché HTTP / HTTPS.

282

IWAN aprovecha la Visibilidad y el Control de Aplicaciones (AVC) de Cisco, los Servicios de

Aplicaciones de Área Amplia de Cisco (WAAS) y la capacidad de la función Akamai Connect

para proporcionar visibilidad y ayudar a las organizaciones a optimizar el rendimiento de

las aplicaciones a través de enlaces WAN.

Conectividad segura

La capacidad de proporcionar cifrado certificado con soporte AES-256-GCM es cada vez

más importante para proteger la información de la intrusión. Con los servicios directos de

Internet en el sitio de la sucursal para proporcionar un transporte seguro entre las

ubicaciones y los recursos críticos del centro de datos, las organizaciones se dan cuenta de

que ahora también tienen la flexibilidad de dirigir el tráfico enlazado a Internet

directamente de estos circuitos si deciden hacerlo. Los patrones de tráfico están

cambiando a medida que las aplicaciones de productividad SaaS pública se vuelven más

frecuentes. Cuando el tráfico se destina a Internet, el tráfico de enrutamiento a través de la

conectividad centralizada del centro de datos a menudo resulta en patrones de tráfico

subóptimos.

La seguridad suele ser la razón por la que las organizaciones retrasen la decisión de

utilizar el acceso directo a Internet en una sucursal. Como mínimo, con múltiples puntos

de contacto de Internet distribuidos, las organizaciones se preocupan de cómo los

asegurarán. Las características tales como NAT, firewall y seguridad en la web se están

volviendo más importantes en el borde remoto de la WAN para acomodar un cambio a los

servicios de Internet descentralizados.

IWAN aprovecha las capacidades de servicios integrados dentro de las plataformas de

enrutamiento como el NAT, el firewall de políticas basadas en zonas (ZFW) y el Conector

de nube de Cisco Web Security (CWS) para garantizar que la solución proporcione el nivel

de seguridad necesario para cumplir con los requisitos de WAN de próxima generación.

Administración

Las organizaciones están solicitando modelos simplificados para la provisión de servicios

de WAN, y TI y tiende a gravitar hacia las ofertas de despliegue basadas en asistentes y

automatizadas. Las organizaciones con un gran número de sitios normalmente les gustaría

enviar el hardware directamente desde el fabricante hasta el destino del sitio final sin

tener que configurarlo en una instalación de preparación antes de enviarlo. El despliegue

plug-and-play es "agradable" para muchas organizaciones, pero es una necesidad para

otras personas que buscan acelerar el cambio de sitio.

283

Cisco ofrece opciones de administración completas para ayudar a las organizaciones a

obtener todos los beneficios de la experiencia Cisco IWAN y cubre todo: el Día 0 (diseño y

preparación), Día 1 (instalación y puesta en funcionamiento) y Día 2 (monitor,

optimización, ocupaciones. Una de las opciones más comunes de la solución de

administración incluye Cisco Prime Infrastructure para la administración local,

independiente o integrada con LiveAction para la visualización avanzada de métricas de

rendimiento de aplicaciones. Otra opción común de solución de gestión aprovecha las

redes de Glue para las WAN basadas en la nube y en el software de varios proveedores. La

solución de gestión crece en popularidad ya que su lanzamiento es el Cisco Application

Policy Infrastructure Controller (APIC) con el Enterprise Module (EM) aprovechando el

módulo de aplicación IWAN integrado. APIC-EM simplifica y agiliza la gestión de los

servicios de red que proporcionan los enrutadores de acceso y los conmutadores. La

aplicación IWAN con licencias separadas para APIC-EM simplifica en gran medida los

despliegues WAN al proporcionar una interfaz altamente intuitiva basada en políticas que

ayuda a la TI a abstraer la complejidad de la red y el diseño para la intención comercial.

Las organizaciones deben tener en cuenta las capacidades de TID, IPC, AO, SC y gestión de

manera holística mientras se embarcan en el viaje para diseñar e implementar la próxima

generación de WAN. Centrarse en consideraciones de diseño a largo plazo garantizará

resultados sostenibles y la experiencia de aplicación más consistente para los usuarios de

sucursales. IWAN ofrece la flexibilidad de enfocarse en sólo unos cuantos pilares basados

en prioridades inmediatas tales como el diseño independiente del transporte y el control

de trayectoria inteligente basado en los requisitos de diseño y prioridades, y más tarde

puede construirlo agregando otras capacidades como la optimización de la WAN y el

almacenamiento en caché Para ayudar a las aplicaciones a ejecutar más rápido. Las

siguientes secciones exploran el diseño de IWAN y los detalles específicos de PfR.

Vista General del Diseño IWAN

El diseño independiente del transporte simplifica el despliegue de la WAN mediante una

superposición IPsec VPN sobre todas las opciones de transporte WAN, incluyendo MPLS,

Internet y Celular (3G / 4G). Aprovechar las superposiciones de VPN en la parte superior

de toda la conectividad de transporte y no sólo para acomodar las implementaciones de

VPN de Internet reduce el enrutamiento y la complejidad de seguridad y proporciona

flexibilidad al elegir proveedores y opciones de transporte. Como se destacó en la sección

anterior, Cisco Dynamic Multipoint VPN (DMVPN) es la tecnología utilizada para

establecer la superposición Iwan IPsec.

La arquitectura de IWAN aprovecha a dos o más proveedores para ofrecer flexibilidad y

disponibilidad de aplicaciones. La diversidad de rutas de proveedores proporciona la base

284

para que Cisco Performance Routing (PfR) circule en torno a las fluctuaciones en el

rendimiento de los proveedores para proteger de situaciones de apagón.

Las conexiones a Internet normalmente se incluyen en las discusiones que son relevantes

para el módulo de borde de Internet y las conversaciones de diseño del centro de datos.

Los enrutadores de sitios remotos también suelen tener conexiones de Internet utilizadas

para proporcionar conectividad de transporte aumentada, pero estos enrutadores no

proporcionan necesariamente la misma amplitud de servicios que los dispositivos

apalancados dentro del módulo de borde de Internet. Por razones de seguridad y otras

razones, el acceso a Internet en sitios remotos suele estar enrutado a través del sitio

principal.

Dos modelos de diseño IWAN usan Internet como una tecnología de transporte:

Diseño de WAN híbrido

Diseño dual de Internet WAN

El modelo de diseño WAN híbrido de IWAN utiliza MPLS emparejado con VPN de Internet

para conectividad de transporte WAN. En este modelo de diseño, la WAN MPLS puede

proporcionar más ancho de banda para las clases críticas de servicios que se necesitan

para las aplicaciones clave y puede proporcionar garantías SLA para estas aplicaciones. El

modelo de diseño de IWAN Dual Internet utiliza un par de proveedores de servicios de

Internet para reducir aún más los costos manteniendo un alto nivel de resiliencia para la

WAN.

Los diseños de agregación WAN WAN (hub) incluyen dos enrutadores de borde WAN. Los

enrutadores de agregación WAN que terminan el tráfico VPN también se denominan

enrutadores de concentrador VPN. En el contexto de IWAN, un enrutador MPLS A CE

también se utiliza como enrutador de concentrador VPN. Al igual que con los modelos de

diseño tradicionales, al aprovechar los modelos de diseño IWAN, los enrutadores de

agregación WAN siempre se conectan a un par de switches de capa de distribución.

Modelo de diseño híbrido IWAN

El diseño híbrido de IWAN requiere enrutadores de agregación WAN doble para soportar

el par de nubes DMVPN. Esas dos nubes son necesarias para proporcionar conexiones

resistentes a todos los sitios remotos.

El diseño IWAN Hybrid utiliza fVRF en ambos enlaces de transporte. El fVRF proporciona

separación del plano de control de los proveedores y una capa de seguridad adicional

entre redes internas y externas. La Figura proporciona una visión general de la

funcionalidad fVRF.

285

VRF permite múltiples instancias de una tabla de enrutamiento para coexistir en el mismo

enrutador al mismo tiempo. La interfaz física WAN está en su propio tráfico de

enrutamiento VRF a través de la red de transporte (Internet o MPLS) para permitir que se

establezcan túneles DMVPN. El VRF global encamina el tráfico a través de los túneles

DMVPN establecidos, proporcionando conectividad de extremo a extremo de sitio a sitio.

Dado que las instancias de enrutamiento son independientes, es posible utilizar las

mismas direcciones IP solapadas dentro del espacio de direccionamiento público y

privado sin conflictos entre sí.

IWAN utiliza VRF para proporcionar:

286

Separación de ruta predeterminada entre el tráfico de usuarios y el establecimiento

de túneles del DMVPN

Control y separación de planos de datos entre redes internas y externas con fines

de seguridad

Tradicionalmente, las organizaciones no permiten el acceso directo a Internet para

usuarios remotos, y como resultado, cualquier host remoto que accede a Internet debe

hacerlo a través de Internet en el sitio principal o en el centro de datos. Los enrutadores

de sitios remotos requieren una ruta predeterminada para todos los enrutadores externos

y destinos de Internet. Si las organizaciones continúan prohibiendo el acceso directo a

Internet, la ruta predeterminada en el borde del sitio remoto debe forzar el tráfico a través

de los túneles DMVPN de transporte primario o secundario de WAN. DMVPN también

tiene un requisito de ruta predeterminado para establecer túneles entre sitios como parte

de un despliegue de DMVPN fase 3. La ruta predeterminada para el tráfico de usuario

sobre DMVPN está en conflicto con la ruta predeterminada necesaria para que DMVPN

establezca túneles entre los sitios. Además, sólo se puede enviar un resumen del

concentrador que resume las subredes de sucursal hacia los enrutadores de filial sobre el

túnel DMVPN si el diseño requiere el uso de un enlace local de Internet para acceder a

Internet.

El uso de VRFs en el enrutador resuelve el problema asociado con la necesidad de

múltiples rutas predeterminadas en el borde del sitio remoto. Un enrutador puede tener

varias tablas de enrutamiento que se mantienen lógicamente separadas en el dispositivo.

Esta separación es similar a un enrutador virtual desde una perspectiva de plano de

desvío. El VRF global corresponde a la tabla de enrutamiento tradicional, y VRFs

adicionales reciben nombres y, en algunos casos de uso de diseño, valores de distinción de

ruta (RD).

Ciertas funciones del enrutador son compatibles con VRF, incluyendo enrutamiento

estático, protocolos de enrutamiento, reenvío de interfaz y túnel IPsec. Este conjunto de

características se utiliza con DMVPN para permitir el uso de múltiples rutas

predeterminadas tanto para los enrutadores de concentrador DMVPN como para los

enrutadores de radio DMVPN. Una de las opciones es usar un VRF global para el tráfico de

tráfico del usuario y un VRF para cada interfaz física WAN específicamente utilizada para

el establecimiento del túnel DMVPN. Esta combinación de características se conoce como

fVRF porque la VRF se enfrenta a la WAN y las interfaces de túnel internas LAN y DMVPN

del enrutador permanecen todas en el VRF global.

El uso de fVRF con DMVPN para toda la conectividad de transporte proporciona la base

necesaria para estratificar en capacidades de características innovadoras como PfR.

287

DESCRIPCIÓN GENERAL DE CISCO PFR

El enrutamiento de rendimiento (PfR) ha estado disponible por más de 10 años y comenzó

originalmente como enrutamiento de borde optimizado (OER). PfRv2 introdujo el

enrutamiento de aplicaciones basado en métricas de rendimiento en tiempo real, y PfRv3

fue diseñado desde el principio con la simplificación de la configuración y mayor

escalabilidad en mente.

Operaciones de Cisco PfR

288

Cisco PfRv2 aprovecha un ciclo de vida operacional de cinco etapas basado en métricas

diferentes de rendimiento para mejorar el rendimiento de la WAN, las cinco etapas de

PfRv2 son

Aprender: El controlador maestro le indica al enrutador fronterizo que aprenda

aplicaciones "interesantes", llamadas clases de tráfico (TC). Estas clases de tráfico

podrían ser un prefijo de destino con o sin el puerto, DSCP, prefijo de origen o

incluso aplicación mediante Network-Based Application Recognition (NBAR). Este

proceso de creación de perfiles puede ser totalmente automático basado en los

hablantes principales (utilizando NetFlow) o configurado manualmente.

Medida: Cisco PfR recopila estadísticas de clase de tráfico para aplicaciones

aprendidas:

o Modos de monitorización: Pasivo, Activo, Ambos, Rápido, Especial (Cat6K)

o NetFlow para UDP (ancho de banda) y flujos TCP (disponibilidad, retraso,

ancho de banda, pérdida)

SLA IP para los flujos TCP y UDP (disponibilidad, retraso, pérdida, fluctuación de

fase, MOS)

Aplicar directiva: Utilice datos de aplicación medidos para determinar si la clase

de tráfico administrado está fuera de política (OOP) y si una ruta alternativa puede

cumplir los requisitos de directiva.

Aplicar:

o Prefijo de control: Enrutadores fronterizos directos (BRs) para cada clase

de tráfico e inyectar rutas BGP o estáticas.

o Control de aplicaciones: Mapa de rutas dinámico / PBR para clases de

tráfico definidas por ACL, NBAR. Los protocolos de enrutamiento no

soportados son OSPF, IS-IS o enrutadores de frontera que ejecutan una

mezcla de protocolos de enrutamiento.

289

Verificar: Compruebe que el flujo de tráfico en la nueva ruta de acceso coincide

con la directiva y vuelve a una ruta más saludable si el rendimiento permanece

fuera de la política y dicha ruta está disponible.

Cisco IWAN y PfRv3

La versión de Cisco Performance Routing (PfR) utilizada como parte de la solución IWAN

2.0 es Performance Routing Version 3 (PfRv3). PfRv3 es una solución de un solo toque

para la provisión y coordinación multi-sitio que simplifica el aprovisionamiento de red.

Permite que la inteligencia de los dispositivos Cisco mejore el rendimiento y la

disponibilidad de las aplicaciones. PfRv3 es un framework de políticas basado en

aplicaciones que proporciona optimización de ancho de banda y control de trayectoria

multisite-aware para WAN y aplicaciones basadas en nube.

PfRv3 monitorea el rendimiento de la red y selecciona la mejor ruta para cada aplicación

basada en criterios tales como accesibilidad, retraso, jitter y pérdida. PfRv3 distribuye de

manera uniforme el tráfico y mantiene niveles de utilización de enlace equivalentes

mientras se equilibra el tráfico de carga.

PfRv3 está estrechamente integrado con los componentes AVC existentes, tales como

monitorización del rendimiento, calidad de servicio (QoS) y NBAR2. PfRv3 es útil para

proveedores de servicios empresariales y administrados que buscan maneras de

aumentar su confiabilidad y disponibilidad WAN mientras ahorran costos.

PfRv3 incluye las siguientes mejoras clave:

Dominio empresarial: todos los sitios pertenecen a un dominio empresarial y

están conectados con peering. El mecanismo de peering se utiliza para el

intercambio de servicios, el descubrimiento automático de la red y el

aprovisionamiento de un solo toque. Este mecanismo de peering se introdujo con

Cisco Performance Routing versión 2 (PfRv2) como una característica llamada

Target Discovery (TD), pero esta característica de peering se ha mejorado mucho

para convertirse en el núcleo de Cisco PfRv3.

Centrada en la Aplicación: La solución Cisco PfRv3 se centra más en las

aplicaciones. Proporciona una forma sencilla de proporcionar políticas basadas en

la visibilidad y la clasificación de las aplicaciones. La clasificación de aplicaciones se

basa en el motor de inspección de paquetes de Cisco, Network-Based Application

Recognition versión 2 (NBAR2). La solución ofrece visibilidad de las aplicaciones y

los flujos de tráfico mediante la integración con Monitoreo Unificado (Monitor de

290

rendimiento). La visibilidad de la aplicación incluye ancho de banda, rendimiento,

correlación con las colas QoS, etc.

Provisión sencilla: Cisco PfRv3 tiene políticas simplificadas con plantillas previas.

La configuración de la política se encuentra en una ubicación central y se distribuye

a todos los sitios mediante peering. Esta solución simplifica el aprovisionamiento y

garantiza la coherencia en toda la red.

Descubrimiento automático: los sitios empresariales se detectan mediante

peering. Cada sitio comparte con el sitio de concentrador. Los prefijos específicos

de los sitios se anuncian junto con un ID de sitio. El mapeo de prefijo de sitio a ID de

sitio se utiliza para monitoreo y optimización. Esta asignación también se utiliza

para crear informes para sitios específicos. Las interfaces WAN en cada sitio se

descubren utilizando un mecanismo especial de sondeo. Este mecanismo de sondeo

reduce aún más el aprovisionamiento en los sitios de sucursal simplemente al

despliegue general de PfRv3.

Supervisión pasiva escalable: Cisco PfRv3 utiliza Monitoreo unificado (también

llamado Monitor de rendimiento) para supervisar el tráfico que entra en los

enlaces WAN y el tráfico procedente de los enlaces WAN. Supervisa las métricas de

rendimiento según el punto de código de servicios diferenciados (DSCP) en lugar

de supervisar una base por flujo o por prefijo.

Sondeo inteligente: Cisco PfRv3 utiliza un mecanismo de sondeo ligero que

generará tráfico cuando no hay tráfico, así como con tráfico de datos. El enrutador

genera tráfico RTP, lo que le permite medir el jitter y la pérdida de paquetes a

través de monitores de rendimiento regulares. Reduce la necesidad de que los

mensajes de control transmitan estadísticas al remitente.

Escalado: Cisco PfRv3 utiliza el hardware de la plataforma siempre que sea posible

para generar las sondas en los enrutadores fronterizos. Aparte de las sondas

artificiales, Cisco PfRv3 también utiliza el tráfico existente para sondeo. Sin

embargo, cuando no hay tráfico, Cisco PfRv3 utiliza sus propias sondas para medir

métricas importantes, tales como retardo y fluctuación de fase. Como parte de la

versión IWAN 2.0, Cisco PfRv3, como parte de la oferta de soluciones IWAN, puede

escalar hasta una implementación de 2000 sucursales. En comparación con las

versiones anteriores, la supervisión pasiva escalable y la capacidad de sondeo

inteligente son lo que permiten a Cisco PfRv3 alcanzar este nivel de escala.

Compatibilidad con VRF: Cisco PfRv3 es consciente de VRF. Siempre que necesite

segmentar su red en diferentes redes lógicas usando túneles DMVPN separados, se

pueden crear instancias de Cisco PfRv3 para cada VRF.

291

Un dispositivo puede desempeñar diferentes funciones en la configuración de PfRv3, como

se muestra en la Figura y se describe en la siguiente lista:

Controlador principal del concentrador (MC): El controlador maestro en el sitio

del concentrador, que puede ser un centro de datos o una sede. Todas las políticas

se configuran en el concentrador MC. Actúa como controlador maestro del sitio y

toma decisiones de optimización.

Enrutador de borde del concentrador: El controlador de borde en el sitio del

concentrador. La interfaz WAN termina en los enrutadores fronterizos del

concentrador. PfRv3 está habilitado en estas interfaces. Un concentrador BR puede

soportar sólo un transporte. Puede disponer de varios dispositivos de borde de

concentrador. Un concentrador BR generará sondas de descubrimiento para

ayudar a los sitios de sucursales a descubrir sus interfaces externas.

Controlador principal de tránsito: El controlador maestro en un sitio de tránsito,

que puede ser un centro de datos o una sede. Actúa como un controlador maestro

para el sitio.

Enrutador fronterizo de tránsito: El controlador fronterizo en un sitio de

tránsito, la interfaz WAN termina en los enrutadores de frontera de tránsito. PfRv3

está habilitado en estas interfaces. Una BR de tránsito puede soportar sólo un

transporte. Puede tener varios dispositivos de frontera de tránsito. Una BR de

tránsito generará sondas de descubrimiento para ayudar a los sitios de sucursales a

descubrir sus interfaces externas.

Controlador principal de sucursal: El controlador maestro de ramificación es el

controlador maestro en el sitio de la sucursal. No hay configuración de políticas en

292

este dispositivo. Recibe la política desde el concentrador MC. Este dispositivo actúa

como controlador maestro para ese sitio para tomar decisiones de optimización.

Enrutador de frontera de filial: El dispositivo de frontera en el sitio de la

sucursal. No hay ninguna configuración que no sea la habilitación del borde MC de

PfRv3 en el dispositivo. La interfaz WAN que termina en el dispositivo se detecta

automáticamente.

Consideraciones sobre el diseño y la implementación de Cisco

PfRv3

El despliegue de Cisco PfRv3 debe planificarse cuidadosamente. Los siguientes son

algunos aspectos a tener en cuenta al integrar Cisco PfRv3 como parte de un diseño y

despliegue de IWAN:

Debe evaluar los protocolos y políticas de enrutamiento que se utilizan en la WAN y

decidir cómo el Cisco PfR integrará e influirá en las decisiones de enrutamiento.

Dependiendo del protocolo de enrutamiento que está en uso en la red, podría

haber advertencias potenciales. Aunque EIGRP y BGP son los protocolos preferidos

porque PfRv3 tiene la capacidad de hacer referencia a las rutas secundarias

incluidas en la base de datos de topología de estos protocolos de enrutamiento,

tanto EIGRP como BGP ofrecen el diseño de enrutamiento más estable y escalable

sobre hub y radios y una más flexible optimización de diseño sobre DMVPN.

Deberá decidir qué enrutadores serán los enrutadores fronterizos y los

controladores maestros. Los enrutadores que están conectados a las salidas de

cada sitio deben configurarse como enrutadores de frontera. Cada sitio necesita su

propio controlador maestro que controla los enrutadores de frontera para ese sitio.

El controlador maestro es una función de plano de control y se puede combinar en

un enrutador de borde o ejecutar en un enrutador independiente. La consideración

principal es la escala. En el sitio de la sucursal, la función de controlador maestro se

puede implementar fácilmente en uno de los enrutadores fronterizos. En el centro

principal de WAN o en los centros de datos, es mejor implementar un enrutador

independiente como controlador maestro para escalar para soportar el número

proyectado de clases de tráfico. En el sitio principal, proporcionará el controlador

maestro de concentrador. Los centros de datos secundarios o terciarios deberán

configurarse con un controlador maestro de tránsito.

Deberá determinar qué tipo de tráfico desea controlar y definir una directiva de

dominio en el controlador maestro de concentrador que se enviará a través de la

infraestructura de peering a todos los controladores maestros de la sucursal. Las

políticas se pueden definir por aplicación o por punto de código de servicio

diferenciado (DSCP). No puede mezclar y combinar políticas DSCP y basadas en

293

aplicaciones en el mismo grupo de clases. El tráfico que no coincide con ningún de

las sentencias de clasificación y coincidencia cae en un grupo predeterminado, que

se encaminará de forma predeterminada o con equilibrio de carga si el balanceo de

carga está habilitado (en ambos casos, no se realiza ninguna medición de

rendimiento).

Debe decidir qué métricas de rendimiento desea medir como parte de la directiva

de dominio. Los ejemplos incluyen retraso, pérdida y fluctuación de fase. Las

plantillas de políticas predefinidas están disponibles para la selección con PfRv3 e

incluyen las aplicaciones más comunes y los valores de umbral de mejores

prácticas asociados. La Figura muestra estas plantillas de políticas predefinidas.

También es posible definir políticas personalizadas basadas en requisitos de

aplicación únicos.

294

GESTIÓN DE ACCESO Y WAN EMPRESARIAL

Las organizaciones de TI están analizando tendencias tales como Software-Defined

Networking (SDN) para proporcionar el nivel necesario de programación y control de red

automatizado para ayudarles a responder rápidamente a las nuevas oportunidades de

negocio.

El Módulo Empresarial del Controlador de Infraestructura de Aplicaciones de Cisco (APIC-

EM) proporciona una oportunidad para aprovechar APIs de programación abiertas para

administrar servicios de red a través de un solo controlador. Esta capacidad le

proporciona una abstracción de la red, simplificando así la gestión de los servicios de red.

OnePK es un conjunto de herramientas fácil de usar para el desarrollo, la automatización y

la creación rápida de servicios; Que permite el acceso directo a dispositivos individuales,

lo que le permite ampliar la funcionalidad que se proporciona por estos dispositivos.

Para escalabilidad, facilidad de uso y desarrollo más rápido de nuevas aplicaciones, debe

elegir la solución con el Cisco APIC-EM. Para obtener la máxima flexibilidad y

personalización de los dispositivos individuales, debe elegir la solución en la que se usan

las API de los dispositivos que aprovechan onePK. Es importante tener en cuenta que hay

una mayor carga de desarrollo cuando las aplicaciones necesitan controlar dispositivos

individuales y la red como un todo, como cuando se usa onePK independientemente de las

capacidades del controlador.

APIC-EM

Utilice el APIC-EM de Cisco para simplificar y agilizar la gestión de los servicios de red que

proporcionan los enrutadores y conmutadores WAN y de acceso. El APIC-EM de Cisco

ofrece un enfoque abierto y programable para establecer redes a través de API abiertas

para la administración y la seguridad basadas en políticas. El enfoque automatiza lo que

normalmente ha sido una tediosa configuración manual.

295

El controlador proporciona servicios de red de forma consistente y proporciona

información de red y análisis ricos en todos los recursos de red: LAN y WAN, cable e

inalámbrica e infraestructuras físicas y virtuales. Esta visibilidad le permite optimizar

servicios y soportar nuevas aplicaciones y modelos de negocio. El controlador rellena la

brecha entre los elementos de red programables abiertos y las aplicaciones que se

comunican con ellos, automatizando el aprovisionamiento de toda la infraestructura de

extremo a extremo.

APIC-EM es una evolución hacia un enfoque en capas, donde la abstracción es clave. Esta

abstracción le permitirá aprovechar funciones comunes como el servicio PKI, los servicios

plug-and-play y el descubrimiento de red. El APIC-EM de Cisco abstrae la capa de

dispositivo, haciendo posible aprovechar la representación de configuración para

dispositivos de red en muchas aplicaciones diferentes. Esto, a su vez, permite un

desarrollo más rápido de las aplicaciones modulares que aprovechan la infraestructura de

servicios proporcionada por APIC-EM a través de APIs RESTful.

La interfaz de aplicaciones del controlador APIC-EM abstrae y oculta la complejidad de

administrar dispositivos de red individuales. Muchos socios están desarrollando sus

propias soluciones y componentes de infraestructura para cabalgar sobre el controlador

APIC-EM, lo que resultará en la creación de aplicaciones adicionales que los clientes

pueden seguir utilizando para obtener un valor adicional.

Cisco y las aplicaciones de administración de redes de partners como Cisco Prime,

GluWare y LiveAction han comenzado a aprovechar el controlador APIC-EM para el

aprovisionamiento y el análisis, así como para la generación de informes y análisis.

296

El Cisco APIC-EM simplifica y agiliza las operaciones de red al tiempo que reduce los

costes. Libera al departamento de TI para enfocarse en la innovación empresarial al

desplegar rápidamente nuevos dispositivos y aplicaciones de red. Algunos de los

beneficios de APIC-EM son

Coherencia en toda la red empresarial, lo que reduce al mínimo el tiempo de

inactividad y reduce la complejidad operacional y el coste asociado.

Provisión y configuración automatizadas de extremo a extremo para permitir el

despliegue rápido de aplicaciones y servicios. Los tiempos de aprovisionamiento

disminuyen de meses a horas.

Dispositivos de red abiertos y programables, políticas, datos y análisis para

impulsar la innovación empresarial, facilitando el acceso a la inteligencia de la red.

Apoyo para implementaciones greenfield y brownfield, lo que permite a la TI

implementar la programación y la automatización dentro de la infraestructura

existente que ya existe.

Diseño de APIC-EM

Las siguientes son algunas de las características de APIC-EM que están desarrolladas o en

desarrollo y que potencialmente podrían ser aprovechadas como parte del diseño de la

solución:

Base de datos de información de red: Cisco APIC-EM explora periódicamente la

red para crear una "fuente única de verdad" para TI. Este inventario incluye todos

los dispositivos de red, junto con una abstracción para toda la red empresarial. Esta

base de datos permite que las aplicaciones sean independientes del dispositivo, por

lo que las diferencias de configuración entre los dispositivos no son un problema.

Visualización de topología de red: Cisco APIC-EM descubre automáticamente y

asigna dispositivos de red a una topología física con datos detallados a nivel de

dispositivo. La característica de autovialización proporciona un mecanismo

altamente interactivo para ver y solucionar problemas de la red. Una característica

muy útil es la capacidad de personalizar fácilmente su interfaz gráfica de usuario.

Implementación de toque cero: cuando el escáner del controlador descubre un

nuevo dispositivo de red, crea una entrada de base de datos de información de red

para él y lo configura automáticamente. Esta capacidad elimina la necesidad de

intervención manual, ahorrando tiempo y ayudando a prevenir errores.

Plug-and-Play: Cisco Network Plug-and-Play proporciona una experiencia de

despliegue de cero-tacto, altamente escalable, transparente y unificada para los

clientes en toda la cartera de redes empresariales de dispositivos inalámbricos e

inalámbricos. Reduce la carga de las empresas simplificando en gran medida el

297

proceso de implementación de nuevos dispositivos, lo que también puede reducir

significativamente los gastos operativos (OpEx).

Aplicación Cisco WAN Inteligente (IWAN): La aplicación IWAN con licencias

separadas para APIC-EM simplifica enormemente el aprovisionamiento de perfiles

IWAN con políticas empresariales sencillas.

Infraestructura de clave pública: el servicio PKI proporciona un servidor de

autenticación integrado para la administración automatizada de claves. Automatiza

la gestión del ciclo de vida de la emisión, renovación y revocación del certificado

PKI X.509 para aplicaciones como IWAN.

Este servicio simplifica en gran medida el proceso de establecer y mantener la

confianza en la red.

Path Trace Application: La inspección, interrogación y corrección de problemas de

red se basan en técnicas manuales de hoy, que pueden ser lentas e inexactas y también

muy costosas. Dada una descripción de cinco-tuplas, la aplicación Path Trace resuelve

este problema automatizando la inspección y visualización de la trayectoria tomada

por un flujo entre dos extremos en la red.

Identity Manager: es posible rastrear identidades de usuario y puntos finales

intercambiando información con el motor de servicios de identidad de Cisco (ISE). El

resultado es una implementación de políticas altamente sofisticada por usuario, que

puede mejorar las políticas de seguridad móviles (incluidas las políticas BYOD) en toda

la red empresarial.

Policy Manager: Para mejorar la seguridad, el controlador traduce la política

empresarial en una directiva a nivel de dispositivo de red. Puede aplicar políticas

abstraídas para determinados usuarios en diversas horas del día, a través de redes

cableadas e inalámbricas. Reúne análisis de red que ayudan a TI a iniciar la

implementación de políticas en toda la red empresarial.

Análisis ACL: El controlador acelera la gestión ACL. Consulta y analiza ACLs en cada

dispositivo de red. Esta función ayuda a TI a simplificar y acelerar la solución de

problemas identificando rápidamente las configuraciones erróneas de ACL.

Despliegue de QoS y gestión de cambios: Esta función le permite establecer y aplicar

rápidamente las políticas de prioridad de QoS, manteniendo la seguridad de que los

dispositivos de red se mantienen automáticamente en conformidad. Esta característica

ayuda a que el tráfico de las aplicaciones se comporte de forma consistente y de

acuerdo con los SLA de QoS.

298

Capítulo 11

Diseño de Centro de

Datos Empresariales

Multicapa

299

INTRODUCCIÓN

El diseño de cualquier red y, específicamente, de una red de centros de datos (DCN)

siempre debe estar impulsado por el requisito de las aplicaciones. Como resultado, el

diseño de las actuales redes de DC enfrenta desafíos constantes, como el rápido

crecimiento de las aplicaciones, las características de tráfico impredecibles, la movilidad

de la carga de trabajo, la optimización de los recursos y la seguridad de los datos críticos.

Por lo tanto, como arquitecto o diseñador de red, debe cubrir estos retos con un diseño de

red modular y escalable de centro de datos que cumpla con los requisitos de diseño de hoy

y ofrece la flexibilidad para crecer en el futuro con cualquier rediseño importante.

ESTUDIO DE CASO 1: CENTROS DE DATOS PEQUEÑOS

(CONEXIÓN DE SERVIDORES A UNA LAN EMPRESARIAL)

ABC Corp. es una pequeña empresa con aproximadamente 70 usuarios internos ubicados

en un edificio. Además, 15 usuarios remotos (basados en el hogar) están conectados a

través de Internet. Actualmente, la red que utiliza ABC Corp. se basa en la arquitectura de

núcleo / distribución colapsada, como se muestra en la Figura. Para satisfacer las

necesidades de los usuarios internos, ABC Corp. tiene que desplegar un pequeño grupo de

servidores montados en bastidor. Los servidores alojarán aplicaciones de correo

electrónico, uso compartido de archivos y bases de datos. La sala de servidores ya ha sido

instalada; sin embargo, los ingenieros de red de ABC Corp. deben decidir cómo se

conectarán los servidores a la LAN de la empresa.

Con base en la arquitectura LAN actual y en la escala de la red, para proporcionar

conectividad de red para los servidores e intergrarlo transparentemente a las capacidades

300

de seguridad de red, es decir, del firewall de la LAN existente, debe conectar los servidores

al switch de núcleo de red LAN. Este diseño ofrecerá un diseño simple y rentable que

cumpla con los requisitos de ABC Corp., siempre que haya suficientes puertos disponibles.

Además, idealmente debe agrupar los switches de núcleo colapsados con VSS, vPC o una

tecnología similar para lograr una solución sencilla y altamente tolerante a fallos facilitada

por conexiones de enlace ascendente redundantes usando el concepto de uso de

Multichassis EtherChannel (MEC), como se muestra en la Figura.

Como diseñador de redes, siempre debe considerar cualquier crecimiento futuro en su

diseño. Por ejemplo, cuando el número de servidores de ABC Corp. aumenta, los actuales

switches de núcleo colapsado pueden no proporcionar suficientes puertos. En este caso,

debe instalar switches adicionales de acceso a la sala de servidores entre los servidores y

los switches centrales de núcleo para resolver este problema, como se muestra en la

Figura. Por lo tanto, siempre debe preguntar acerca de los planes actuales y futuros antes

de proporcionar cualquier diseño.

301

Nota: Los conmutadores extensores del tejido (FEX) de Cisco proporcionan más puertos /

switches de acceso a la sala de servidores y estos actúan como tarjetas de línea remotas

por lo que no puede considerarse como una capa de red adicional en este diseño.

Cualquier conmutador con capacidades de puerto suficientes puede utilizarse como un

conmutador de sala de servidores. Sin embargo, para lograr la tolerancia de fallos entre

los servidores y los conmutadores de sala de servidores, debe utilizar conmutadores con

capacidades de clúster de conmutación (VSS, vPC, Stackwise) para permitir el uso del

modelo de conectividad MEC.

Nota El conmutador de sala de servidores y el conmutador de acceso de LAN del cliente

conectan dispositivos a la red. La diferencia entre los dos métodos que cambia el modelo

de conmutador es el requisito en el acceso LAN para Power over Ethernet (PoE). Aunque

los dispositivos compatibles con PoE no son típicos en la sala de servidores, el uso de

conmutadores compatibles con PoE ofrece un beneficio que vale la pena considerar: Los

ahorros iniciales de costes de un conmutador sin PoE pueden no valer los beneficios de

utilizar el mismo conmutador en otros módulos de su LAN local. La capacidad de utilizar

un único tipo de conmutador entre varios módulos puede reducir los costes operativos al

permitir una gestión y ahorro, y también ofrece una mayor posibilidad de reutilización a

medida que la organización crece. Dicho esto, algunos conmutadores de centros de datos

construidos específicamente, como la familia Cisco Nexus, ofrecen capacidades de oferta

diseñadas para redes de centros de datos. Para una pequeña red de centros de datos (sala

de servidores), puede considerar modelos de gama baja si se requiere alguna

característica de estos conmutadores.

302

ESTUDIO DE CASO 2: ARQUITECTURA DE RED DE DOS

CENTROS DE DATOS

La empresa ABC Corp. decidió expandir su negocio en el que un mayor nivel de

rendimiento del centro de datos, escalabilidad y disponibilidad de servicios de

aplicaciones es requerido por el negocio.

Se deben integrar múltiples plataformas y tecnologías de hardware para ofrecer los

niveles esperados de rendimiento y disponibilidad para los usuarios finales. Un centro de

datos escalable y de alto rendimiento requiere plataformas de conmutación diseñadas

para el centro de datos, como la familia Cisco Nexus.

Como usted conoce el estudio de caso precedente, las empresas más pequeñas con los

requisitos medianos del centro de datos a menudo usan switches de centro de datos como

switches de núcleo colapsado. Un solo par de conmutadores proporciona las capacidades

de centro de datos deseadas y de núcleo de LAN al mismo tiempop que ofrecen serviciosde

firewall, IPS / IDS y otros dispositivos tanto para la LAN corporativa como para el centro

de datos.

Este diseño tiene sus inconvenientes. Cuando aumenta el número de servidores, los

switches del núcleo colapsado de la LAN pueden no proporcionar suficientes puertos de

conmutación, y el firewall de LAN, IPS / IDS y otros dispositivos pueden no ser suficientes

para los requisitos del centro de datos. Por lo tanto, agregar una capa de conmutadores de

acceso / agregación de centro de datos entre el núcleo de LAN y los servidores resuelve

ese problema. Con este modelo de diseño, la agregación proporciona puertos y agregación

303

de ancho de banda. Además, si los conmutadores de acceso añadidos son conmutadores

Cisco Nexus, puede aumentar la capacidad del puertso de acceso a un número

significativamente mayor si se considera el uso de Cisco FEX.

Nota: Las conexiones hacia el norte conducen a una capa de nivel superior (es decir, en la

dirección del núcleo). Las conexiones hacia el sur llevan a una capa inferior (es decir, en la

dirección de los nodos finales). Los términos describen una típica topología de red en

capas que imita la orientación de un mapa típico, donde el norte está representado en la

parte superior del mapa.

Nota: Debe tener cuidado al aumentar el número de puertos de acceso porque al hacerlo

reducirá el acceso a la tasa de sobresuscripción del enlace ascendente, que debe

mantenerse lo más pequeño posible en el diseño del centro de datos. La sobreescripción

se produce cuando la capacidad de ingreso excede la capacidad de salida. Por ejemplo,

para los servidores conectados 48x 10G, el conmutador de acceso necesita al menos 480

Gbps de capacidad de puerto hacia la capa ascendente o de distribución para proporcionar

sobreescritura 1: 1 (1: 1 significa cero o sin suscripción). Sin embargo, si el conmutador de

acceso tiene sólo 2x 10G uplinks, en este caso la sobreescripción es 24: 1. Aunque no se

requiere que cada red proporcione un rendimiento de 1: 1, la sobreescripción debe

minimizarse en los DCN modernos a gran escala (por ejemplo, idealmente 4: 1 o 3: 1).

Tenga en cuenta que cuando se produce una sobreescripción, casi siempre se necesita

calidad de servicio (QoS) para proteger las aplicaciones importantes durante los períodos

de congestión.

ESTUDIO DE CASO 3: ARQUITECTURA DE RED DE TRES NIVELES

DE CENTROS DE DATOS

A medida que el centro de datos crece, aumenta el número de servidores y las conexiones

necesarias. Los conmutadores de agregación de centros de datos no proporcionan un

número suficiente de puertos y conectar cada servidor a un número limitado de

conmutadores de acceso y conmutadores de agregación de pares resulta una molestia.

Para solucionar el problema, la red necesita ser rediseñada usando una arquitectura que

soporta una escala mayor de conmutadores de acceso y agregación. En una arquitectura

de tres niveles, ocurre lo siguiente:

La capa de acceso aumenta el número de puertos disponibles, pero lo más

importante es que reduce el número de cables necesarios. Los servidores están

ahora conectados al conmutador de acceso más cercano.

304

Los conmutadores de acceso están conectados en dirección norte a conmutadores

de agregación con un par de cables de cobre o ópticos.

Los conmutadores de agregación también están conectados de la misma manera a

los conmutadores de núcleo, pero con esta arquitectura, el centro de datos puede

tener varios pares de conmutadores de agregación conectados a un par de

conmutadores centrales para soportar redes de centros de datos a gran escala.

Con esta arquitectura, los servicios y dispositivos están conectados a los

conmutadores de agregación.

Además, como diseñador de red, debe tener en cuenta algunos enfoques de diseño que se

pueden utilizar con esta arquitectura, entre los que se incluyen los siguientes:

Enrutamiento entre VLAN para decidir qué capa aplica la demarcación entre los

dominios de Capa 3 y Capa 2 en dicha arquitectura

Modelos de conectividad de conmutador de acceso de Top of rack (ToR) versus End

of rack (EoR)

Extensor de tejido de Cisco (FEX) en la capa de acceso

Disponibilidad y optimización del rendimiento

Las subsecciones siguientes cubren estos puntos con más detalle.

Enrutamiento Inter-VLAN del centro de datos

305

Con la arquitectura de red multicapa en el centros de datos, debe decidir qué capa

realizará el enrutamiento entre VLAN. Esta decisión dicta la elección de los conmutadores

(Capa 2 o Capa 3) en la capa de agregación. Además, la topología está dictada por el tipo de

carga de trabajo del centro de datos y los flujos de tráfico predominantes.

Considere que el punto de demarcación entre un dominio de Capa 3 y Capa 2 en la capa de

agregación de centro de datos (enrutamiento Inter-VLAN) se prefiere en centros de datos

con servidores que realizan tareas idénticas y normalmente se colocan detrás de

equilibradores de carga, como servicios web. Como se muestra en la Figura, los flujos de

tráfico se ejecutan principalmente entre los servidores y el núcleo de la red, mientras que

la comunicación entre los servidores es escasa. Dichos flujos de tráfico permiten reducir el

tamaño del dominio de Capa 2 y evitar los problemas que se producen en dominios

grandes de Capa 2. El enrutamiento entre VLAN en la capa de agregación requiere

switches de Capa 3.

Sin embargo, un centro de datos empresarial típico, que aloja servidores que ejecutan

máquinas virtuales, tiene requisitos diferentes. Por ejemplo, la migración activa de VM y

otros flujos de tráfico entre los servidores físicos prefieren dominios de Capa 2 más

grandes. Un modelo de diseño posible es que el enrutamiento de Inter-VLAN se puede

hacer en el núcleo, y la capa de agregación sólo requiere switches de Nivel 2, como se

muestra en la Figura. Sin embargo, este diseño introduce algunos retos en las redes a gran

escala, como la reducción del rendimiento debido al mayor dominio Broadcast en la capa

2.

306

Modelos de conectividad de conmutador de acceso de Top of rack

(ToR) versus End of rack (EoR)

Los centros de datos más grandes suelen tener filas múltiples de bastidores. El modelo

EoR describe una topología en la que todos los servidores en una fila se conectan al

conmutador de acceso que reside en el último bastidor en una fila. Los conmutadores de

acceso EoR son normalmente conmutadores modulares con un número suficiente de

puertos para proporcionar conectividad a cientos de servidores.

El diseño ToR describe una topología con un conmutador de acceso en la parte superior de

cada bastidor, con todos los servidores en un bastidor conectado a él. Los conmutadores

de acceso ToR son normalmente conmutadores con 24 o 48 puertos y una conexión de

fibra óptica a conmutadores de agregación.

307

Nota: EoR describe un diseño con conmutadores de acceso situados al final, al inicio o a la

mitad de la fila. Para un diseño redundante, un switch de fila se puede colocar al principio

y el otro al final de la fila. Sin embargo, la topología ToR puede tener el switch de acceso en

la parte superior, en la parte inferior o en el centro del bastidor. La topología redundante

normalmente consta de dos conmutadores por rack.

EoR requiere un número menor de conmutadores. EoR reduce la sobrecarga de gestión,

simplifica la topología STP y requiere menos puertos en la capa de agregación. Sin

embargo, en redes de gran escala, EoR puede requerir cableado de cobre extenso de

cientos de servidores al final de la fila y más infraestructura para el cableado. Esto se

traduce en más complejidad operativa.

Por el contrario, ToR contiene el cableado de cobre de los servidores en el rack,

reduciendo el cable y la infraestructura de patch cords y utilizando conexiones de fibra

con mayor capacidad. Además, la topología física ToR es más modular porque cada rack

presenta un módulo que puede actualizarse y cambiarse sin ningún efecto en los demás

bastidores. Sin embargo, ToR requiere un mayor número de conmutadores, aumentando

así la sobrecarga de gestión. Se requieren más puertos en la capa de agregación y la

topología STP gana complejidad.

Extensores de tela Cisco (FEX)

Los extensores de tela, también conocidos como extensores de puertos, siguen el concepto

ToR, pero resuelven algunas de sus deficiencias. Al igual que con los conmutadores de

acceso ToR, los FEX se montan típicamente en la parte superior de cada bastidor. Sin

embargo, los FEX no se comportan como conmutadores normales, sino como tarjetas de

línea del conmutador de agregación. Los FEX extienden el plano de datos del conmutador

de agregación a la parte superior de cada bastidor, mientras que obtienen un único plano

de control en su conmutador maestro, como se muestra en la Figura.

308

Debido a que múltiples FEX y conmutadores padres se comportan como un único

conmutador de agregación, el uso de FEX reduce el número de conmutadores gestionados

y elimina una capa en la topología STP. Los FEX actuales no pueden conmutar el tráfico

entre los puertos locales. Todo el tráfico se reenvía al conmutador padre. Por lo tanto, el

uso de FEX es ideal cuando la mayoría del tráfico fluye entre los servidores y el núcleo de

la red, y no entre los servidores que están conectados al mismo FEX.

Sin embargo, un diseño basado en FEX proporciona los beneficios de un diseño de ToR

físico y un diseño lógico de EoR al mismo tiempo. Como se muestra en la Figura, este

diseño reduce tanto el número de conexiones requeridas a la capa de agregación como de

núcleo y el número de conmutadores gestionados; También reduce el dominio STP.

309

Además, algunos de los modelos Cisco FEX (como el FEX-2232TM-E) le permiten ampliar

el alcance de 10G Ethernet / FCoE a una tarjeta de línea distribuida (ToR). Cuando se

requiere FCoE en el nivel de acceso del anfitrión, los modelos de conectividad del FEX al

conmutador principal ascendente (por ejemplo, la serie Nexus 5500) serán limitados. El

Nexus 2232 debe ser de un solo domicilio para el Nexus 5000 (directamente a N2K) para

asegurar el aislamiento SAN A y SAN B, como se muestra en la Figura.

Nota El protocolo de inicialización de FCoE (FIP) utiliza la VLAN nativa. Por lo tanto, todos

los enlaces FCoE deben ser troncalizados para llevar la VLAN FCoE y la VLAN nativa.

Además, la generación 2 (FIP habilitado) CNA son necesarios para las conexiones de host a

las interfaces de host de Cisco Nexus 2232 Fabric Extender.

310

Alta disponibilidad del centro de datos

Basándose únicamente en STP con esta arquitectura DC LAN jerárquica, típicamente

bloqueará algunas de las conexiones de Capa 2.

Como diseñador de red, primero debe preguntar, "¿Cómo se pueden poner las conexiones

bloqueadas en uso?" Hipotéticamente, una planificación cuidadosa de múltiples instancias

de STP puede considerarse como una de las posibles soluciones. Sin embargo,

prácticamente, es difícil mantener un equilibrio carga perfecto en el centro de datos.

Existe una mejor solución, que se basa en el agrupamiento de conexiones redundantes

entre dispositivos físicos con PortChannel para reducir o eliminar completamente el

número de bucles en la topología de Capa 2. Sin embargo, para agrupar los puertos en un

chasis diferente en un PortChannel con EchChannel multichassis (MEC), los dos

conmutadores de la misma capa deben agruparse en una unidad lógica. En una LAN

empresarial, puede lograr este agrupamiento mediante el apilado (VSS, StackWise) en una

única unidad lógica. Sin embargo, ninguna de estas dos tecnologías está disponible en los

conmutadores de centro de datos Cisco Nexus. En su lugar, los conmutadores de centro de

datos Cisco Nexus introducen la tecnología virtual vPC PortChannel.

Contrariamente a VSS, vPC no agrupa dos conmutadores en un switch lógico. VPC permite

que los enlaces físicamente conectados a dos switches Cisco Nexus aparezcan como un

solo PortChannel a un tercer dispositivo. A diferencia de spanning tree, vPC proporciona el

311

multipathing de capa 2 y el balanceo de carga sobre ambos enlaces ascendentes a dos

conmutadores diferentes. Esto ofrece verdaderos enlaces ascendentes activos / activos,

duplicando así el ancho de banda de red disponible, como se muestra en la Figura.

Cuando los extensores de tejido están conectados a conmutadores de centro de datos

enlazados con vPC, pueden existir diferentes topologías posibles para lograr redundancia

de acceso a la red. Como se muestra en la Figura, los extensores de tejido pueden ser de

doble sede cuando se conectan a conmutadores de centro de datos vinculados con vPC

mejorado, compatible con la serie Cisco Nexus 5500. Esto permite una topología FEX de

doble domicilio, donde cualquier FEX de doble domicilio reenvía el tráfico incluso si falla

uno de los conmutadores del centro de datos.

En la topología de FEX unidireccional, los extensores de tejido se conectan a un único

conmutador principal (padre), que no requiere vPC entre los conmutadores principales.

Sin embargo, para utilizar MEC entre los extensores de tejido y los servidores, los

conmutadores de centros de datos deben utilizar vPC. Con esta topología, el fallo del

conmutador del centro de datos también resulta en un fallo del extensor del tejido. No

habrá ningún tiempo de inactividad del servicio porque los servidores se mantienen

312

conectados al extensor de tejido del segundo conmutador de centro de datos (suponiendo

que el equipo de NIC correcto se despliega a nivel de servidor).

Además, las tecnologías Cisco vPC y VSS MEC ofrecen la flexibilidad de integrar pares de

nodos configurados como VSS y vPC, proporcionando una ruta de reenvío de extremo a

extremo (no bloqueada), como se muestra en la Figura. (Por ejemplo, puede que existan

conmutadores Catalyst de Cisco implementados con VSS donde la interoperabilidad vPC y

VSS ofrezca protección de inversión, en este caso, para el equipo de red existente).

Nota: aunque vPC elimina las limitaciones del bloqueo STP, STP debe habilitarse como un

mecanismo de protección si se produce alguna configuración errónea o incorrecta en la

red para evitar cualquier lazo 2 bucles que puede conducir a un apagón o rendimiento

degradado. La Figura muestra las configuraciones STP recomendadas en un entorno vPC.

Sin embargo, se recomienda encarecidamente que habilite STP como un mecanismo de

protección en caso de configuración errónea o incorrecta.

313

Equipos de controladores de interfaces de red

Para proporcionar redundancia, los servidores suelen estar conectados a uno o dos

conmutadores con dos conexiones redundantes. Como nodos finales, los servidores no

reenvían tramas y no ejecutan STP. Para utilizar conexiones duales, los servidores usan la

asociación de NIC. Los siguientes son los dos modelos principales de agrupación de NIC:

Equipo activo / pasivo de NIC: permite colocar varios adaptadores de red en un

equipo para evitar una pérdida de conectividad si se produce un corte de la

conexión activa. Las NIC activas / pasivas se pueden conectar a un solo conmutador

o a varios sin ningún requisito adicional en el conmutador. Sin embargo, debido a

que la NIC pasiva no está en uso, no ofrece ninguna agregación de ancho de banda.

Equipo activo / activo de NIC: permite colocar varios adaptadores de red en un

equipo. De esta manera, puede mejorar el ancho de banda mediante la agregación

de ancho de banda y evitar la pérdida de conectividad si se produce una

interrupción de una de las conexiones. El agrupamiento activo / activo de la NIC

requiere la configuración de PortChannel en el conmutador ascendente y la

configuración vPC o VSS MEC en los conmutadores ascendentes si el servidor está

conectado a dos conmutadores diferentes.

314

315

Capítulo 12

Nuevas Tendencias y

Técnicas en el Diseño

del Centro de Datos

Modernos

316

LA NECESIDAD DE UNA NUEVA ARQUITECTURA DE RED

Los centros de datos clásicos están estructurados con una arquitectura de tres niveles que

tiene núcleo, agregación y capas de acceso, o un núcleo colapsado de dos niveles que tiene

las funciones de agregación y núcleo combinadas en una capa. Los centros de datos más

pequeños pueden incluso aprovechar un solo par de conmutadores. Esta arquitectura

acompaña un patrón de tráfico norte-sur en el que los datos de los clientes vienen de la

WAN o Internet para ser procesados por un servidor en el centro de datos y luego es

empujado de vuelta fuera del centro de datos. Esto es común para aplicaciones como

servicios web, donde la mayoría de la comunicación es entre un cliente externo y un

servidor interno. El patrón de tráfico norte-sur permite la sobresubscripción del hardware

debido a que la mayoría del tráfico se canaliza hacia dentro y hacia fuera a través del

cuello de botella WAN o Internet de menor ancho de banda.

Basándose en las aplicaciones de los centros de datos y en los requisitos de servicio, la

forma tradicional de construir redes de árbol jerárquico o de niveles no es adecuada para

la naturaleza dinámica de las necesidades de computación y almacenamiento modernas.

Las siguientes tendencias informáticas configuran la necesidad de una nueva arquitectura

de red:

Cambiar los patrones de tráfico: el centro de datos se está desplazando de las

arquitecturas de aplicaciones tradicionales cliente/servidor a modelos en los que

se transfieren significativamente más datos de una máquina a otra. El resultado es

un cambio de los patrones de tráfico norte-sur a más tráfico este-oeste en el centro

de datos. El contenido de la empresa también debe ser accesible en cualquier

momento y desde cualquier lugar. Además, muchos departamentos de TI

corporativos muestran un gran interés en moverse a entornos públicos, privados o

híbridos en la nube.

La consumerización de la TI: Los usuarios exigen más flexibilidad para llevar sus

propios dispositivos (BYOD), de manera que los portátiles, tablets y teléfonos

inteligentes personales puedan utilizarse para acceder a la información

corporativa. Un resultado de esta tendencia es un mayor énfasis en la protección de

datos corporativos con políticas de seguridad y cumplimiento.

El aumento de los servicios en la nube: los servicios de nube pública disponibles

de compañías como Amazon.com, Microsoft y Google han dado a los departamentos

de TI corporativos un vistazo a TI de autoservicio y demuestran cómo pueden ser

ágiles las aplicaciones y los servicios. Las organizaciones ahora exigen los mismos

niveles de servicio de sus propios departamentos de TI. Sin embargo, a diferencia

de los entornos de nube pública, los entornos de nube privada deben cumplir con

estrictos requisitos de seguridad y cumplimiento, que no pueden ser sacrificados

por una mayor agilidad.

317

La “Big Data” significa más ancho de banda: las empresas están invirtiendo en

grandes aplicaciones de datos para facilitar una mejor toma de decisiones

empresariales. Sin embargo, estas aplicaciones requieren un procesamiento

paralelo masivo a través de cientos o miles de servidores. La demanda para

manejar enormes conjuntos de datos está colocando mayor estrés y carga en la red

y conduciendo la necesidad de una mayor capacidad.

LIMITACIONES DE LA TECNOLOGÍA DE RED ACTUAL

La Open Networking Foundation (ONF) es una organización dirigida al usuario y que está

dedicada a la promoción y adopción de redes definidas por software (SDN). La ONF

publicó un libro blanco titulado "Redes Definidas por Software: La Nueva Norma para las

Redes". Este documento de la ONF discute las significativas limitaciones de las actuales

tecnologías de redes y que deben superarse para satisfacer los requerimientos modernos

de TI. Estos desafíos se presentan en el contexto de un requisito tradicional, es decir,

proporcionar una conectividad estable, resiliente pero estática. Sin embargo, las

tendencias informáticas mencionadas anteriormente requieren que las redes apoyen el

despliegue rápido de aplicaciones. También requieren que la red se amplíe para acomodar

mayores cargas de trabajo con mayor agilidad, al mismo tiempo que se mantienen los

costos al mínimo. Por lo tanto, el enfoque tradicional tiene limitaciones sustanciales, como

las siguientes:

Complejidad que conduce al estancamiento: La abundancia de protocolos de red

y características definidas de forma aislada ha aumentado enormemente la

complejidad de la red. El documento de la ONF afirma que cada protocolo está

"resolviendo un problema específico y sin el beneficio de ninguna abstracción

fundamental". Además, las viejas tecnologías a menudo se reciclaban como

soluciones rápidas para hacer frente a los nuevos requerimientos empresariales.

Un ejemplo de este enfoque reciclado es el uso de VLANs en las redes actuales.

Inicialmente, el propósito de las VLAN era crear dominios de difusión más

pequeños. Hoy en día, las VLAN se utilizan como dominios de seguridad y de

políticas para el aislamiento. Este uso ha creado dependencias complejas que

aumentan los riesgos de seguridad y reducen la agilidad porque un cambio en la

política de seguridad requiere un cambio en el dominio de difusión y reenvío,

mientras que un cambio en las VLAN también puede afectar la política de

seguridad.

Políticas incoherentes: las políticas de seguridad y calidad de servicio (QoS) en

las redes actuales deben configurarse o secuenciarse manualmente a través de

cientos o miles de dispositivos de red. Este requisito hace que los cambios en las

políticas sean extremadamente complicados para que las organizaciones

318

implementen sin una inversión significativa en las habilidades de lenguaje de

secuencias de comandos o herramientas que pueden automatizar los cambios de

configuración. La configuración manual es propensa a errores y puede dar lugar a

muchas horas de resolución de problemas para descubrir qué línea de una lista de

control de acceso de seguridad o QoS se ha introducido incorrectamente para un

dispositivo determinado.

Escalabilidad limitada: A medida que cambian las cargas de trabajo de las

aplicaciones y aumenta la demanda de ancho de banda de la red, el departamento

de TI necesita estar satisfecho con una red estática sobre-suscrita o necesita crecer

con las demandas de la organización. Desafortunadamente, la mayoría de las redes

tradicionales están provisionadas estáticamente de tal manera que el aumento del

número de puntos finales, servicios o ancho de banda requiere una planificación y

un rediseño sustancial de la red. La virtualización del servidor y las

implementaciones de la nube privada están desafiando a los profesionales de redes

de TI a reevaluar su arquitectura. Algunos pueden optar por sobreprovisionar

masivamente la red para adaptarse a la naturaleza dinámica de las máquinas

virtuales, que se pueden implementar a petición e instanciarse en cualquier lugar

de la red, pero la mayoría necesita evaluar nuevas formas de diseñar la red.

Agregación de ancho de banda: Con la arquitectura clásica de tres niveles, el

tráfico este-oeste entre la carga de trabajo dentro del centro de datos que reside en

diferentes subredes o punto de entrega (POD) puede terminar atravesando el

acceso al centro de datos, la agregación y la capa de núcleo. Esto típicamente puede

conducir a un ancho de banda reducido a lo largo de la trayectoria; A medida que el

tráfico aumenta en la jerarquía, más agregación de ruta entre todos los flujos de

tráfico debe ser hecha. Además, esto conduce a una mayor latencia.

TÉCNICAS Y ARQUITECTURAS MODERNAS DE DISEÑO DE

CENTROS DE DATOS

Aquí se discute los diseños y protocolos fundamentales utilizados hoy para superar las

preocupaciones y limitaciones descritas en la sección anterior para el modelo de diseño

tradicional del centro de datos. Debe entender que cada diseño o protocolo discutido en

este capítulo no puede superar individualmente las preocupaciones de diseño y las

limitaciones del modelo de diseño tradicional, y cuando este es el caso, debe considerar

una combinación de estos elementos para lograr la meta deseada. Por ejemplo, es posible

que tenga que considerar una arquitectura de hoja de espina junto con un protocolo de

superposición como VXLAN para lograr una ágil y moderna red de centros de datos en la

que puede obtener movilidad de host y mantener el mismo direccionamiento IP sin

319

importar donde el host esté físicamente conectado a la red del centro de datos y sin

afectar a las limitaciones de escalabilidad del diseño extendido de las VLAN capa 2.

Diseño del centro de datos de Spine-Leaf

Las topologías de la hoja de la espina se basan en la arquitectura de la red de Clos. El

término se origina de Charles Clos en Bell Laboratories. En 1953, publicó un artículo que

describe una teoría matemática de una topología de red multitrayectos, no bloqueante, de

múltiples etapas para conmutar las llamadas telefónicas.

La hoja de la espina se despliega típicamente como dos capas: espinas (como una capa de

la agregación) y hojas (como una capa de acceso), como se muestra en la figura. Con la

arquitectura de columna vertebral-Hoja de espinas (Clos), cada hoja está a un salto de

cualquier otro switch hoja; por lo tanto, promueve conectividad de servidor a servidor con

alto ancho de banda, baja latencia y sin bloqueo.

Los switches de hoja proporcionan a los dispositivos acceso al tejido (la red de

conmutadores de espina y hoja) y normalmente se despliegan en la parte superior del

bastidor. Todos los dispositivos se conectan a los switches de hoja. Los dispositivos

pueden incluir servidores, servicios de Capa 4 a 7 (firewalls y equilibradores de carga) y

enrutadores WAN o Internet. Los conmutadores de hoja no se conectan a otros. Sin

embargo, cada hoja debe conectarse a cada espina en una malla completa. Algunos puertos

de la hoja se utilizarán para dispositivos finales (normalmente de 1 Gb o 10 Gb), y algunos

puertos se utilizarán para las conexiones de la columna vertebral (a 40 Gb o 100 Gb).

Los conmutadores de espina se conectan a todos los de hoja y normalmente se despliegan

en el extremo o en el centro de la fila. Los conmutadores de columna no se conectan a

320

otros de columna. Las espinas sirven como interconexiones de la columna vertebral para

los de hoja. Las espinas se conectan sólo a las hojas.

Todos los dispositivos conectados al tejido tienen un número igual de saltos unos de otros.

Esto proporciona latencia predecible y gran ancho de banda entre servidores. La figura

muestra un diseño típico de hoja de espina.

En esta arquitectura, los switches de la serie Cisco Nexus 9000 permiten a los operadores

de centros de datos de pequeñas y medianas redes comenzar con unos pocos

conmutadores e implementar un modelo de pago por crecimiento. Cuando se necesitan

más puertos de acceso, se pueden agregar más hojas. Cuando se necesita más ancho de

banda, se pueden añadir más espinas. En ambos casos, no habrá necesidad de hacer

ningún cambio en el diseño, cableado o direccionamiento de la infraestructura de

subyacente.

Además, si desea llevar este modelo de diseño al siguiente paso en la evolución del centro

de datos, debe considerar una tecnología de superposición de red virtual (también

conocida como superposición virtual). Con este enfoque, puede mantener la accesibilidad

de capa 2 entre servidores sin depender de STP y sus ineficiencias. La siguiente sección

cubre las superposiciones de red con más detalle.

Superposiciones de red

En una red de centros de datos moderna, uno de los enfoques comunes para superar

algunas de las limitaciones mencionadas anteriormente es utilizar protocolos de

superposición de redes. Esto se deriva principalmente de las necesidades de los centros de

datos de hoy en día, donde las aplicaciones multicapa necesitan comunicarse con otros

niveles de aplicación o servicios, sin importar dónde se encuentre la aplicación

físicamente dentro de la red del centro de datos.

En general, el concepto de superposición se refiere a la capacidad de encapsular paquetes

enviados por una aplicación o servicio junto con la ubicación del destino antes de enviarlo

a través de la red. Entonces, cuando el paquete llega al destino objetivo, será decapsulado

y entregado en su formato original, como por ejemplo con una etiqueta 802.1Q. La

encapsulación y decapsulación son facilitadas por un protocolo de superposición que

transforma la comunicación de la aplicación para ser más independiente de la ubicación,

separando la ubicación de la identidad y facilitando la creación de múltiples redes lógicas

separadas, como se muestra en la Figura. Los protocolos de superposición más comunes

utilizan hoy en día encapsulamiento MAC-in-MAC, como IETF Transparent

Interconnection de Lotes de enlaces (TRILL) y Cisco FabricPath. MAC-in-IP se puede

lograr utilizando NVGRE o Virtual Extensible LAN (VXLAN). Las secciones siguientes

describen Cisco FabricPath (FP) y VXLAN con más detalle.

321

Cisco Fabric Path

Normalmente, la conectividad de capa 2 es necesaria entre los conmutadores de centro de

datos. El uso de Spanning-Tree Protocol (STP) bloquea todas las conexiones redundantes.

Como resultado, los switches reenvían tramas basado en las entradas de la tabla MAC sólo

a través de los enlaces no bloqueados, lo que resulta en un flujo de tráfico subóptimo y

estresando más de lo necesario a las conexiones no bloqueadas y a los otros

conmutadores, lo que dará lugar a la utilización ineficientes de enlaces y ancho de banda.

Una de las tecnologías de superposición de redes para superar los problemas de STP en

dichos diseños es Cisco FabricPath (FP). La tecnología FabricPath de Cisco, soportada por

322

los conmutadores de centros de datos Cisco Nexus, es la implementación de TRILL por

parte de Cisco. Cisco FabricPath trae técnicas de enrutamiento desde la capa 3 para

resolver problemas de bucle de capa 2.

La conmutación Cisco FabricPath permite la creación de redes multitrayecto en la capa 2 y

encapsula toda la trama de la capa 2 con una nueva cabecera Cisco FabricPath. Los enlaces

de FabricPath son punto a punto. Los dispositivos encapsulan las tramas en el puerto de

borde de ingreso de la red Cisco FabricPath y desencapsulan las tramas en el puerto de

borde de salida de esta red. Esta nueva encapsulación permite que el núcleo de la red

Cisco FabricPath se oculte (a través de la tecnología de superposición) de la información

del estado de host, reduciendo los requisitos de escala de los dispositivos principales de

Cisco FabricPath.

Debido a que Cisco FabricPath empaqueta toda la trama Ethernet en una nueva

encapsulación, todos los nodos de la red Cisco FabricPath necesitan soportar Cisco

FabricPath para buscar y reenviar la trama a través del resto de la red. Cisco FabricPath

utiliza extensiones en el protocolo IS -IS para intercambiar información de localización y

accesibilidad unicast y multicast y para reenviar tráfico en la red utilizando encabezados

Cisco FabricPath. IS-IS forma la red de subyacente para el FabricPath y permite que el

tejido subyacente sea una red enrutada sin bloqueo con reenvío de ECMP. Debido a que IS-

IS es un protocolo de enrutamiento dinámico de estado de enlace, puede detectar cambios

en la topología de la red y calcular las rutas a todos los otros nodos de la red.

Además, el reenvío de FabricPath se realiza sólo dentro de un dominio FabricPath. Los

conmutadores FabricPath que se conectan a hosts o conmutadores clásicos se llaman

switches de borde. Los switches de borde encaminan las tramas hacia los otros

conmutadores FabricPath utilizando el enrutamiento FabricPath, y realiza la conmutación

clásica con los switches clásicos fuera del dominio FabricPath. Para evitar la necesidad de

STP entre el dominio FabricPath y el switch clásico, puede utilizar vPC con MEC. Puede

lograrlo utilizando una construcción de configuración llamada un conmutador emulado.

Las implementaciones de conmutadores emulados en FabricPath, donde dos switches de

borde FabricPath proporcionan un vPC a un dispositivo de terceros, se denominan vPC +.

323

LAN virtual extensible (VXLAN)

VXLAN es un método de encapsulación que extiende el tráfico de Capa 2 a través de una

capa 3 o una red basada en IP. VXLAN se basa en la multidifusión en el núcleo de la red.

Cisco, en asociación con otros proveedores líderes, propuso el estándar VXLAN al IETF

como una solución a los retos de la red de centros de datos planteados por la tecnología

VLAN tradicional. El estándar VXLAN proporciona una colocación elástica de la carga de

trabajo y una mayor escalabilidad de la segmentación de la capa 2 requerida por las

demandas actuales de la aplicación.

Como su nombre indica, VXLAN está diseñado para proporcionar los mismos servicios de

red Ethernet Layer 2 que VLAN hace hoy, pero con mayor flexibilidad y extensibilidad. En

comparación con VLAN, VXLAN ofrece los siguientes beneficios:

Colocación flexible de segmentos de múltiples segmentos en todo el centro de

datos: Ofrece una solución para extender los segmentos de la Capa 2 sobre la

infraestructura de red compartida subyacente para que la carga de trabajo del host

se pueda colocar en los pods físicos del centro de datos.

Mayor escalabilidad para abordar más segmentos de la capa 2: Las VLAN

utilizan un ID de VLAN de 12 bits para dirigir segmentos de capa 2, lo que resulta

en limitar la escalabilidad de sólo 4094 VLAN. VXLAN utiliza un identificador de

segmento de 24 bits conocido como el identificador de red VXLAN (VNID), que

permite que hasta 16 millones de segmentos VXLAN coexistan en el mismo

dominio administrativo.

Mejor utilización de las rutas de red disponibles en la infraestructura

subyacente: VLAN utiliza el protocolo Spanning-Tree para la prevención de bucle,

que no utiliza la mitad de los enlaces de red de una red al bloquear rutas

redundantes. Por el contrario, los paquetes VXLAN se transfieren a través de la red

subyacente basándose en el encabezado de Capa 3 y pueden aprovechar al máximo

el enrutamiento, balanceo de igual costo (ECMP) y los protocolos de agregación de

enlaces para usar todas las rutas disponibles.

VXLAN es un esquema de superposición de capa 2 sobre una red capa 3 y clasifica como

un protocolo de superposición MAC-en-IP; Específicamente, utiliza encapsulación MACen-UDP

para proporcionar un medio para extender segmentos de Capa 2 a través de la red

del centro de datos. VXLAN es una solución para un entorno multicapa flexible a gran

escala sobre una infraestructura física compartida. El protocolo de transporte a través de

la red de centros de datos físicos es IP más UDP.

324

VXLAN define un esquema de encapsulación MAC-en-UDP en el que la trama original tiene

un encabezado VXLAN agregó y se coloca en un paquete UDP-IP. Con esta encapsulación

MAC-en-UDP, VXLAN crea túneles capa 2 a través de una red capa 3.

VXLAN introduce un encabezado VXLAN de 8 bytes que consiste en un VNID de 24 bits y

algunos bits reservados. La cabecera VXLAN, junto con la trama Ethernet original, va en la

porción de datos UDP. El VNID de 24 bits se utiliza para identificar segmentos de capa 2 y

para mantener el aislamiento capa 2 entre los segmentos. Con todos los 24 bits en VNID,

VXLAN puede soportar 16 millones de segmentos LAN.

Nota Debido a la encapsulación MAC-a-UDP, VXLAN introduce una sobrecarga de 50 bytes

a las tramas originales. Por lo tanto, la unidad de transmisión máxima (MTU) en el red de

transporte debe incrementarse en 50 bytes. Si las superposiciones usan una MTU de 1500

bytes, la red de transporte debe configurar para alojar paquetes de 1550 bytes como

mínimo. En el red de transporte, se requiere soporte de tramas jumbo y las aplicaciones de

la superposición tienden a utilizar los tamaños de trama mayores de 1500 bytes.

Punto Final del Túnel VXLAN

VXLAN utiliza VXLAN tunnel endpoint (VTEP) para asignar los dispositivos finales a los

segmentos VXLAN y para realizar la encapsulación y desencapsulation VXLAN. Cada

función VTEP tiene dos interfaces: una es una interfaz de conmutador en el segmento de

LAN local para permitir la comunicación de punto final local a través del puenteo, y la otra

es una interfaz IP para la IP en la red de transporte, como muestra en la Figura.

La interfaz IP tiene una dirección IP única que identifica al dispositivo VTEP en la red IP de

transporte conocido como VLAN de infraestructura. El dispositivo VTEP utiliza esta

325

dirección IP para encapsular tramas Ethernet y transmite los paquetes encapsulados a la

red de transporte a través de la interfaz IP. Un dispositivo VTEP también descubre los

VTEP remotos para sus segmentos VXLAN y aprende las asignaciones de direcciones MAC

un VTEP a través de su interfaz IP.

Cada VTEP tiene dos interfaces:

Interfaz de LAN local

Interfaz con la red IP de transporte

La interfaz IP tiene una dirección IP única que identifica el VTEP en la red IP de transporte.

Los segmentos VXLAN son independientes de la topología de red subyacente; por el

contrario, la red IP subyacente entre VTEPs es independiente de la superposición de

VXLAN. Enruta los paquetes encapsulados basados en el encabezado de dirección IP

externa, que tiene el VTEP de inicio como la dirección IP de origen y el VTEP de

terminación como la dirección IP de destino.

Cada VTEP tiene dos tablas en las que se basa cuando las tramas deben encapsularse.

Cuando un trama entra en el VTEP en el lado de LAN, VTEP mira en el mapa de VLAN a

VXLAN para determinar en qué VXLAN el trama se encapsulará. VTEP busca en el mapa

MAC a VTEP y compara la dirección MAC del destino de la trama y su VXLAN para

determinar la dirección IP del VTEP remoto. El marco se encapsula en un túnel VXLAN sin

estado y se envía a través de la red de transporte IP a la dirección IP VTEP remota

utilizando UDP.

Si VTEP recibe una trama de difusión o una trama con una dirección MAC de destino que

no está presente en MAC en un mapa VTEP, VTEP inunda la trama en un grupo de

multidifusión IP. Cada VXLAN tiene un grupo de multidifusión IP asignado, y todos los

VTEPs con nodos en ese VXLAN se unen a ese grupo de multidifusión. Este

comportamiento es análogo al modelo Ethernet tradicional, pero limita la inundación sólo

a los VTEP que escuchan la IP multicast asignada.

326

Nota: Los dispositivos VTEP deben utilizar un puerto UDP de destino idéntico. Sin

embargo, algunos conmutadores introducen un nivel de entropía en el puerto UDP de

origen. Cuando la red de transporte utiliza un algoritmo de hashing ECMP o LACP que

toma el puerto de origen UDP como una entrada para hash, esto logra los mejores

resultados de carga compartida para el tráfico encapsulado VXLAN.

Descubrimiento de los VTEP Remotos y el Aprendizaje de

Direcciones de Inquilinos

El despliegue típico de VXLAN (como los conmutadores de la serie Nexus 9000 de Cisco en

modo no ACI) utiliza los mecanismos existentes de Capa 2 (inundación y aprendizaje de

direcciones MAC dinámicas) para realizar:

Transmisión de transporte, unicast desconocido y tráfico multicast (tráfico BUM).

Descubrimiento de los VTEP remotos.

Aprendizaje de las direcciones MAC del host remoto y asignaciones MAC-a-VTEP

para cada segmento VXLAN.

Para estos tipos de tráfico, la multidifusión IP reduce el alcance de inundación del

conjunto de hosts que participan en el segmento VXLAN. Cada segmento VXLAN, o VNID,

se asigna a un grupo de multidifusión IP en la red IP de transporte. Cada dispositivo VTEP

está configurado independientemente y se une a este grupo de multidifusión como un host

IP a través del protocolo IGMP. IGMP se une a las asociaciones y señalización de PIM a

través de la red de transporte para el grupo de multidifusión en particular. El árbol de

distribución multicast para este grupo se construye a través de la red de transporte

basado en las ubicaciones de los VTEP participantes.

327

Basado en el modelo de despliegue VXLAN anterior, utiliza los métodos clásicos de

inundación y aprendizaje del plano de datos de capa 2 para el descubrimiento remoto de

VTEP y el aprendizaje de direcciones de inquilinos. Por ejemplo, en el escenario mostrado

en la figura, el segmento VXLAN inquilino tiene VNID 10 y utiliza el grupo de multidifusión

239.1.1.1 sobre la red de transporte. Tiene tres VTEPs participantes en el centro de datos.

Suponga que no se ha realizado ningún aprendizaje de direcciones entre ubicaciones. El

dispositivo final A (con IP-A, MAC-A) inicia la comunicación IP con el dispositivo final B

(con IP-B, MAC-B).

La secuencia de pasos es la siguiente:

1. El dispositivo final A envía una solicitud ARP para la IP-B en la capa 2 de VXLAN.

2. VTEP-1 recibe la solicitud ARP. Todavía no tiene una asignación para IP-B.

3. VTEP-1 encapsula la solicitud ARP en un paquete de multidifusión IP y lo envía al

grupo de multidifusión VXLAN. El paquete de multidifusión encapsulado tiene la

dirección IP de VTEP-1 como la dirección IP de origen y la dirección de grupo de

multidifusión VXLAN como la dirección IP de destino.

El paquete IP multicast se distribuye a todos los miembros del árbol. VTEP-2 y

VTEP-3 reciben el paquete multicast encapsulado porque se han unido al grupo de

multidifusión VXLAN. Desencapsulan el paquete y comprueban su VNID en el

encabezado VXLAN. Si coincide con su VNID del segmento VXLAN configurado,

envían la solicitud ARP a su VXLAN local. También aprenden la dirección IP de

VTEP-1 desde el encabezado de dirección IP externa e inspeccionan el paquete

para aprender la dirección MAC del dispositivo final A, colocando esta asignación

en la tabla local.

4. El sistema final B recibe la petición ARP enviada por VTEP-2. Responde con su

propia dirección MAC (MAC-B) y aprende la asignación IP-A-a-MAC-A.

5. VTEP-2 recibe la respuesta ARP del dispositivo final B que tiene MAC-A como la

dirección MAC de destino. Ahora conoce el mapeo MAC-A-IP-1. Puede usar el túnel

unicast para reenviar la respuesta ARP a VTEP-1. En el paquete unicast

encapsulado, la dirección IP de origen es IP-2 y la dirección IP de destino es IP-1. La

respuesta ARP está encapsulada en la carga útil UDP.

6. VTEP-1 recibe la respuesta ARP encapsulada de VTEP-2. Se encapsula y reenvía la

respuesta ARP al dispositivo final A. También aprende la dirección IP de VTEP-2

desde el encabezado de dirección IP externa e inspecciona el paquete original para

aprender el mapeo MAC-B a IP-2.

7. Los paquetes IP subsiguientes entre los sistemas finales A y B son unicast

reenviados, basados en la información de mapeo en VTEP-1 y VTEP-2, utilizando el

túnel VXLAN entre ellos.

VTEP-1 puede opcionalmente realizar ARPs de proxy para solicitudes ARP posteriores

para IP-B y así reducir la inundación sobre la red de transporte.

328

Optimización del plano de control VXLAN

Los estándares IETF VXLAN iniciales (RFC 7348) definieron que un mecanismo de

inundación y aprendizaje basado en multidifusión sin un plano de control. Descansa en el

comportamiento de inundación y aprendizaje basado en datos para el descubrimiento de

pares de VXLAN de punto final remoto (VTEP) y el aprendizaje remoto de host final. La

emisión de superposición, la unicast desconocida y el tráfico de multidifusión se

encapsulan en paquetes de VXLAN multicast y se transportan a los conmutadores VTEP

remotos a través del reenvío de multidifusión. Las inundaciones en tal despliegue pueden

presentar un desafío para la escalabilidad de la solución. El requisito de habilitar las

capacidades de multidifusión en la red subyacente también presenta un desafío porque

algunas organizaciones no quieren habilitar la multidifusión en sus centros de datos o

WAN.

Para superar las limitaciones del mecanismo de inundación-y-aprender VXLAN según lo

definido en RFC 7348, las organizaciones pueden utilizar la red privada virtual de

Ethernet del protocolo MP-BGP (MP-BGP EVPN) como el plano de control para VXLAN. El

IETF ha definido MP-BGP EVPN como el plano de control basado en estándares para

superposiciones VXLAN. El plano de control MPP-BGP EVPN proporciona la distribución

de información basada en protocolos VTEP y la distribución de información de

accesibilidad de host final que permite diseños de red de superposición VXLAN escalables,

adecuados para nubes privadas y públicas. El plano de control MP-BGP EVPN introduce un

conjunto de características que reducen o eliminan las inundaciones de tráfico en la red de

superposición y permiten un despliegue óptimo tanto para el tráfico del oeste como el sur

del norte.

El plano de control MP-BGP EVPN ofrece los siguientes beneficios principales:

El protocolo EVPN MP-BGP se basa en los estándares de la industria, permitiendo la

interoperabilidad entre múltiples proveedores.

Permite el aprendizaje en plano de control de la información de accesibilidad de

capa 2 y capa 3 de host final, permitiendo a las organizaciones crear redes de

superposición VXLAN más robustas y escalables.

Utiliza la probada y madura tecnología MPN-BGP VPN para soportar las redes de

superposición VXLAN escalables y de arrendatario múltiple.

La familia de direcciones EVPN tiene información de accesibilidad tanto de Capa 2

como de Capa 3, proporcionando así puenteado y enrutamiento integrados en

redes de superposición VXLAN.

Minimiza la inundación de red a través de la distribución de rutas MAC / IP del host

basada en protocolo y la supresión de Protocolo de resolución de direcciones (ARP)

en los VTEP locales.

329

Proporciona un reenvío óptimo para el tráfico este-oeste y norte-sur y soporta la

movilidad de la carga de trabajo con la función anycast distribuida.

Proporciona descubrimiento y autenticación de pares VTEP, mitigando el riesgo de

VTEPs deshonestos en la red de superposición VXLAN.

Proporciona mecanismos para construir multihoming activo-activo en la Capa 2.

Nota: Aunque muchas de las funciones y diseño del MPP-BGP EVPN son independientes

de la plataforma, la serie Cisco Nexus 9000 es la primera plataforma de conmutación que

soporta este protocolo como un plano de control VXLAN cuando opera en modo autónomo

(no ACI).

Redes definidas por software

Las redes tradicionales consisten en varios dispositivos (por ejemplo, enrutadores,

conmutadores y más), cada uno equipado con su software y funcionalidad de red:

El plano de datos es responsable del reenvío de tramas o paquetes.

El plano de control es responsable de controlar las tablas de reenvío que utiliza el

plano de datos. El plano de control de los enrutadores y los switches ha

experimentado un enorme desarrollo en las últimas décadas, lo que da a la red

buenas capacidades, pero también aumenta la complejidad. Esta complejidad se ha

incrementado aún más con la introducción de soluciones y requisitos modernos

como la movilidad, la nube, la incorporación de su propio dispositivo (BYOD), los

requisitos de seguridad mejorados, etc.

El plano de control consume más recursos de hardware porque se ejecuta en la CPU,

mientras que el plano de datos se ejecuta en hardware dedicado. En base a ello, el plano de

control es la inteligencia del elemento de red, mientras que el plano de datos (también

conocido como el plano de reenvío) es responsable de recibir y enviar paquetes. La Tabla

compara el plano de control de red y el plano de datos.

Plano de

procesamiento

Donde

funciona

Qué tan rápido se

ejecutan estos

procesos

Tipo de Procesos Realizados

Controlar Switch CPU

(en el

software)

Miles de paquetes por

segundo

Protocolos de enrutamiento, Spanning-

Tree Protocol,

Avión ASIC de

hardware

dedicado

Millones o miles de

millones de paquetes

por segundo

SYSLOG, contabilidad de autorización

de autenticación, exportación de datos

de netflow, CLI, SNMP

330

Cómo SDN puede ayudar

Las nuevas tendencias y la evolución de las necesidades de las aplicaciones están

afectando directamente a la arquitectura y los modelos de diseño y las direcciones de las

redes actuales de centros de datos y empresas. Por lo tanto, SDN debe tener en cuenta los

nuevos requisitos tecnológicos, donde las arquitecturas de red necesitan soportar un

mayor nivel de escalabilidad y políticas más sofisticadas para hacer frente a estos cambios.

La capacidad de automatizar y empujar estas políticas de una manera simplificada y

centralizada es clave para proporcionar una solución manejable a una escala.

Varias encuestas de publicaciones sobre redes, además de los RFC informativos, como RFC

3535, enumeran los requisitos que los usuarios finales han asociado con SDN:

Capacidad para automatizar el aprovisionamiento y la gestión.

Flexibilidad en la utilización de recursos que permite el aprovisionamiento, la

modificación o la liberación de recursos fácilmente.

331

Seguridad mejorada que ofrece una inserción de servicios de seguridad más

flexible que va más allá de un simple concepto de seguridad perimetral en el borde

de la red.

Conciencia de la aplicación en la administración de la red para permitir a las

aplicaciones interactuar fácilmente con la red o la administración de la red para

adquirir los recursos necesarios de la red.

Mayor escalabilidad. La escalabilidad de los recursos físicos debe permitir

modificaciones sin fisuras en la infraestructura subyacente sin necesidad de una

administración de infraestructura compleja.

Necesidad de que las redes se configuren como un todo con la capacidad de

implementar políticas de toda la red.

Apoyo a la creación y al movimiento dinámico de máquinas virtuales. La movilidad

de recursos permite que los recursos provistos sean móviles internamente o

incluso puedan moverse a ubicaciones externas (por ejemplo, nube).

Apoyo a la creación de una nube privada o híbrida.

Necesidad de que las redes se configuren como un todo.

Necesidad de configuración basada en texto para un control de revisión

simplificado

Gestión de toda la red necesaria para permitir que una aplicación administre

servicios de extremo a extremo. Esto significa una necesidad de herramientas de

administración de red más avanzadas que SNMP (Simple Network Management

Protocol) y una interfaz de línea de comandos (CLI).

Abstracción de dispositivos y tecnologías de red que permiten a los desarrolladores

de software crear soluciones que se integran con la gestión de red sin necesidad de

conocer en profundidad la topología de red subyacente y las tecnologías que se

utilizan en ella.

Según la ONF, los aspectos más importantes de SDN son "los operadores y

administradores de red" que pueden "configurar mediante programación esta abstracción

simplificada de red en lugar de tener que codificar manualmente decenas de miles de

líneas de configuración dispersas entre miles de dispositivos. Además, aprovechando la

inteligencia centralizada del controlador SDN, las TI pueden alterar el comportamiento de

la red en tiempo real e implementar nuevas aplicaciones y servicios de red en cuestión de

horas o días”.

Nota: OpenFlow es el estándar ONF; sin embargo, no es necesario para una solución SDN.

Criterios de selección de las soluciones SDN

Esta sección resalta los principales factores que usted, como diseñador de red, debe

considerar al seleccionar o evaluar una solución SDN. Deben tenerse en cuenta muchos

factores al seleccionar cualquier solución tecnológica; sin embargo, para SDN, debe

considerar los siguientes puntos mínimos:

332

Control centralizado basado en políticas: Una de las principales promesas y

beneficios de un concepto de SDN es el aprovisionamiento centralizado y la

programación de red, donde un administrador de red puede definir y empujar

configuraciones, políticas y más del controlador SDN sin necesidad de configurar

cada uno de los dispositivos en la ruta de transferencia de datos. Dicho esto, es

fundamental entender que esto no significa que usted debe tener separación entre

ellos. En realidad, algunos protocolos y soluciones tecnológicas logran la visión de

SDN sin quitar la inteligencia del componente de red.

Características del controlador SDN: el controlador SDN es un elemento clave

vital de la arquitectura SDN y podría haber una variedad de controladores SDN a

considerar al seleccionar su solución SDN. Como regla simple, si considera un

controlador o controlador propietario que sólo admite un modelo de política SDN

limitado y un proveedor (no con capacidad para varios proveedores), estará

limitado con la flexibilidad y las capacidades de esta solución SDN. En otras

palabras, necesita un controlador SDN que pueda interactuar e integrarse con

diferentes vendedores, así como proporcionar la capacidad de crear y empujar

políticas sofisticadas centralmente que se alineen con las necesidades de las

aplicaciones y las políticas de negocio. Por ejemplo, Cisco ACI permite a los

operadores de red producir políticas complejas utilizando una interfaz gráfica de

usuario simplificada (GUI) y puede ser empujada posteriormente a los

conmutadores de centro de datos. Además, desde un punto de vista de

interoperabilidad de varios proveedores, actualmente varios socios de ecosistemas

se han convertido en compatibles con ACI, incluyendo F5, Citrix, Check Point y

otros.

Capacidad para integrarse con herramientas de automatización: En los

centros de datos virtualizados de hoy en día basados en la nube y multitenencia, la

automatización es uno de los elementos clave que una solución SDN debe soportar.

La integración entre el controlador SDN y las herramientas de automatización de la

nube significa que los operadores del centro de datos podrán instruir componentes

de infraestructura individuales (switches, servidores, firewalls, etc.) para alinearse

con otras aplicaciones y necesidades de servicio de una manera automatizada. Por

ejemplo, Cisco ha desarrollado un plug-in de código abierto para OpenStack

Neutron que permite a los inquilinos de OpenStack configurar y administrar de

forma transparente una red basada en el Cisco ACI. Este plug-in, Cisco Application

Policy Infrastructure Controller (APIC), traduce automáticamente los comandos

OpenStack Neutron API para redes, subredes, enrutadores, etc., en un perfil de red

de aplicaciones ACI.

Flexibilidad para integrarse con los servicios de seguridad: Una de las

principales preocupaciones asociadas con la adopción de una solución SDN es la

seguridad. Teniendo en cuenta una solución SDN y controlador que ofrecen la

flexibilidad de integrarse con diversos tipos de servicios de seguridad de red como

firewalls e IPS (tanto físicos como virtuales) de diferentes proveedores, ayudará en

333

gran medida a mantener los niveles actuales de seguridad con enfoques de

aprovisionamiento y administración más optimizados y automatizados.

Requisitos SDN

SDN define un conjunto de requisitos que deben cumplirse para proporcionar los

beneficios prometidos:

El conocimiento de la aplicación en la gestión de red permite a las aplicaciones

interactuar fácilmente con la red o la administración de red para adquirir los

recursos necesarios.

Se requiere una administración de toda la red para permitir que una aplicación

administre servicios de extremo a extremo.

La abstracción de dispositivos y tecnologías de red permite a los desarrolladores de

software crear soluciones que se integren con la gestión de red sin tener un

conocimiento profundo de la topología de red subyacente y las tecnologías que se

utilizan en ella.

La flexibilidad de la utilización de recursos permite el aprovisionamiento, la

modificación o la liberación de recursos fácilmente.

La movilidad de los recursos permite que los recursos provistos sean móviles

internamente o incluso puedan moverse a ubicaciones externas (por ejemplo, en la

nube).

La escalabilidad de los recursos físicos debe permitir modificaciones sin fisuras en

la infraestructura subyacente sin necesidad de una administración de

infraestructura compleja.

Desafíos SDN

En general, uno de los principales problemas con SDN hoy en día es que no es lo

suficientemente maduro en comparación con las tecnologías existentes utilizadas en

entornos empresariales. Los enrutadores y conmutadores actuales cuentan con funciones

que permiten una comunicación eficiente y segura. El entorno SDN no puede garantizar

niveles similares de servicios de red mediante el uso de controladores y aplicaciones SDN

disponibles. Otro aspecto importante en el enfoque SDN requiere el uso de conmutadores

"mudos" que soportan OpenFlow y esperan que el controlador le diga qué hacer. Estos

switches, también llamados de caja blanca, son hardware genérico con funciones de

control y administración reducidas en comparación con los switches estándar.

Aunque SDN, superposiciones virtuales basadas en software y OpenFlow presentan

soluciones interesantes tanto para cargas de trabajo tradicionales como emergentes. Hoy

en día, sólo un pequeño número de centros de datos han adoptado superposiciones de

334

software y OpenFlow en sus entornos de producción. Esta falta de adopción puede

atribuirse a un nuevo conjunto de desafíos, entre ellos los siguientes:

■ Nuevas complejidades operativas: Las superposiciones virtuales basadas en

software son difíciles de administrar y solucionar. El enfoque de superposición

virtual basado en software no puede abordar la complejidad de la gestión de la

infraestructura física subyacente. El problema fundamental es que tienen poca o

ninguna relación con la infraestructura física subyacente. Por ejemplo, si hay

alguna caída en la red subyacente, esto no se puede rastrear fácilmente al servicio o

la aplicación afectada. Además, la superposición virtual basada en software puede

ser gestionada por un equipo diferente, que no está equipado para solucionar

problemas de conectividad de extremo a extremo de la red, lo que lleva a apuntar

con dedo a través de los departamentos de operaciones de TI y, posiblemente, los

proveedores. Este inconveniente es potencialmente más severo en las redes

tradicionales, en las que la flexibilidad es limitada, pero al menos dichas redes

tienen predictibilidad y puntos de fallo deterministas para los que un solo grupo de

operaciones de TI se apropia.

El protocolo OpenFlow es demasiado primitivo y concreto para el centro de datos:

OpenFlow en un conmutador de red aplica una función de coincidencia en el

paquete entrante (normalmente basado en un atributo de campo de red existente,

como una dirección MAC de origen o una dirección IP de destino), pero

normalmente implica reenviar el paquete a través de un puerto físico o lógico dado.

Para la mayoría de los casos de uso en los centros de datos, este control detallado

no es necesario, ya que el ancho de banda (y, por lo tanto, las rutas) en el centro de

datos suele ser abundante. Por lo tanto, las decisiones de ruta detalladas basadas

en los parámetros de encabezado de red pueden no ser necesarias y pueden

incurrir en gastos innecesarios de gestión.

Además, el protocolo OpenFlow asume una arquitectura de hardware particular

que utiliza una serie de consultas de tabla genéricas que generan acciones que se

aplican al paquete. Esta vista específica de la arquitectura de hardware subyacente

limita la escalabilidad y la portabilidad. Un mayor nivel de abstracción permite que

diferentes arquitecturas de hardware específicas brinden beneficios específicos al

tiempo que cumplen con los requisitos de las API.

Silicio comercial no está optimizado para OpenFlow: La mayoría del silicio

comercial disponible en el mercado hoy en día se ha optimizado para las cargas de

trabajo generales del centro de datos. Típicamente, tales despliegues imponen

asignación de una gran cantidad de memoria a las tablas de reenvío para realizar

coincidencias de prefijo más largo y adyacencia, el protocolo de resolución de

direcciones (ARP) y consultas de enlace de direcciones MAC e IP; Y una cantidad

finita de memoria a las ACL, típicamente usando la memoria ternaria de

direcciones de contenido (TCAM) que está optimizada para enmascarar, emparejar

paquetes y conjuntos de acciones. Las tablas OpenFlow utilizan la última forma de

memoria en los switches. Desafortunadamente, la memoria de reenvío no es

335

fácilmente cambiable con la memoria ACL, por lo que la cantidad total de memoria

disponible para instalar las entradas de flujo en el moderno silicio actual es algo

limitada. Como se mencionó anteriormente, si se producen errores, los paquetes

pueden caer inesperadamente o reenviarse al controlador SDN para su

procesamiento posterior.

Desafíos de seguridad: cualquier persona con acceso a los servidores que alojan el

software de control puede controlar potencialmente toda la red. Varias funciones

de seguridad que normalmente se implementan en redes empresariales no encajan

en un entorno basado en controlador. El control de acceso administrativo que

tradicionalmente realiza cada dispositivo individual ya no escalará porque realiza

transacciones a granel a través de un controlador, que a su vez puede ejecutar

muchos comandos en varios dispositivos.

Además, el modelo tradicional AAA es reemplazado por RBAC en los controladores

centrales, lo que permite un control de acceso granular mediante la asignación de grupos

de usuarios a los roles, que a su vez define los privilegios en el sistema central (no en los

dispositivos individuales). Además, las empresas también organizan internamente sus

departamentos de TI en los llamados silos, como los departamentos de red, servidores,

almacenamiento y seguridad. Estos departamentos tradicionalmente han exhibido un

nivel de independencia que les permitió construir sus propios sistemas para gestionar su

parte del entorno de TI. Con SDN, usted quiere poder tener una administración de

servicios completos de extremo a extremo, que toca todos los aspectos del entorno:

servidores, almacenamiento, red, etc.

En consecuencia, aunque una arquitectura SDN típica basada en OpenFlow puede traer

varios beneficios a los operadores de centros de datos, puede introducir un nuevo

conjunto de limitaciones porque carece de escalabilidad, visibilidad y seguridad y está

asociada con la complejidad y las superposiciones disjuntas cuando se utilizan en redes de

centros de datos de gran escala. Por lo tanto, Cisco introdujo un nuevo enfoque y

arquitectura que se basa en el concepto SDN con más énfasis en la parte más importante

en el centro de datos: es una aplicación denominada Application Centric Infrastructure

(ACI).

Dirección de SDN no tradicional

Cuando diseña un entorno de red de empresa o centro de datos utilizando los principios

de SDN, debe considerar las siguientes direcciones de diseño:

Reutilizar la infraestructura existente (protección de la inversión).

Reutilizar tecnologías existentes (maduras) en lugar de aumentar los riesgos con

OpenFlow.

336

Utilice la red de superposición para habilitar la conectividad de extremo a extremo

basada en aplicaciones (por ejemplo, VLAN, VXLAN, Cisco WAN Inteligente

[IWAN]).

Utilizar un orquestador para habilitar la programación abierta (por ejemplo,

transferencia de estado representacional [REST]) y proporcionar abstracción de

dispositivos de red y topologías (simplificación del suministro de servicios

mediante el uso de API abiertas).

Elija los productos Cisco adecuados y el controlador de redes definidas por

software (SDN) para optimizar la gestión del entorno de destino:

Cisco Application Policy Infrastructure Controller (Cisco APIC) para el centro de

datos

Módulo empresarial de controlador de infraestructura de aplicaciones de Cisco

(Cisco APIC-EM) para WAN y acceso.

Nota REST es un estilo de arquitectura para diseñar aplicaciones en red. La idea es que, en

lugar de utilizar mecanismos complejos como CORBA, Remote Procedure Call (RPC) o

Simple Object Access Protocol (SOAP) para conectar entre máquinas, se usa HTTP simple

para realizar llamadas entre Máquinas.

CENTRO DE DATOS DE MÚLTIPLES TENENCIAS

La virtualización de los recursos de cálculo y almacenamiento agrega una capa de

abstracción, unificando los recursos del centro de datos en una única nube de recursos y

permitiendo el intercambio de recursos tanto dentro como fuera de la organización. Sin

embargo, la distribución de recursos físicos entre diferentes entidades resulta en riesgos

de seguridad y sobreutilización de recursos. El aislamiento lógico de recursos virtuales

compartidos se llama multitenencia. En este entorno, los recursos de los centros de datos

y las rutas de tráfico deberían separarse lógicamente en varios inquilinos para lograr una

distribución escalonada de la carga de trabajo y satisfacer las demandas de seguridad.

Un inquilino es una comunidad de usuarios con algún nivel de afinidad compartida. Un

inquilino puede ser un cliente en una nube IaaS. Dentro de una empresa, un inquilino

puede ser una unidad de negocio, departamento o grupo de trabajo. O cuando un centro

de datos aloja una aplicación de varias capas, un inquilino podría ser una capa de

aplicación única (por ejemplo, una capa web, de aplicación o de base de datos). El

despliegue de múltiples inquilinos en una infraestructura compartida y común optimiza la

utilización de los recursos a menor costo, pero requiere diseños que aborden la

segregación segura de inquilinos para garantizar el aislamiento de la ruta de extremo a

extremo y cumplir con los requisitos de los inquilinos.

337

Asegurar la separación del inquilino

Un centro de datos de multitenencia separa múltiples recursos: red, computación,

almacenamiento, y aplicación. La separación de la red se logra con el uso de diferentes

técnicas de aislamiento de rutas para dividir lógicamente una infraestructura compartida

en múltiples redes virtuales (por inquilino). El aislamiento de rutas se implementa de

extremo a extremo entre las múltiples capas jerárquicas de la infraestructura e incluye lo

siguiente:

Separación de la capa de red 3 (capas de núcleo / agregación): VRF-Lite

implementado en las capas de núcleo y agregación proporciona aislamiento por

inquilino en la capa 3, con tablas de enrutamiento y reenvío específicas por

inquilino garantizando que no se permitirá tráfico inter inquilino dentro del centro

de datos, A menos que esté explícitamente configurado.

Separación de la capa de red 2 (acceso, acceso virtual): Las VLAN proporcionan

aislamiento e identificación del tráfico de inquilinos a través del dominio de Capa 2

y, generalmente, a través de los enlaces compartidos a través de la infraestructura.

Separación de servicios de red (núcleo de servicios, cálculo): En un dispositivo

físico o en un módulo de servicio, los contextos o zonas dedicados proporcionan los

medios para la seguridad virtualizada, el equilibrio de carga, NAT y servicios de

descarga SSL y la aplicación de políticas únicas por inquilino al nivel de

granularidad de VLAN. De manera similar, los dispositivos virtuales dedicados

proporcionan servicios únicos por inquilino dentro de la capa de cálculo de la

infraestructura a nivel de granularidad de la máquina virtual.

338

Separación de la capa 3 con VRF-Lite

La separación de inquilino en la capa 2 se realiza mediante VLAN. El enrutamiento y

reenvío virtuales (VRF) consigue una separación similar en la capa 3. VRF es una

tecnología que permite que un enrutador tenga varias tablas de enrutamiento

independientes. Las interfaces se asignan a una determinada VRF para formar una ruta de

red aislada.

Un beneficio secundario de las instancias separadas de enrutamiento y reenvío es el

soporte para la superposición de direcciones IP. El espacio de direcciones IP superpuestas

es común en una nube pública, en una fusión o en otras situaciones que involucran

transiciones de direccionamiento IP en empresas privadas.

Los VRFs se usan comúnmente en las redes de proveedores de servicios en combinación

con el protocolo MPLS, donde los VRFs proporcionan enrutamiento y reenvío de

aislamiento, y MPLS proporciona aislamiento de tráfico en las conexiones. Sin embargo,

los VRF pueden utilizarse sin MPLS, con aislamiento de tráfico proporcionado por

conexiones asignadas por VRF o IP VPN. La implementación de VRF sin el MPLS se llama

VRF-Lite.

Virtualización y separación a nivel de dispositivo

339

Los conmutadores Cisco Nexus introducen soporte para contextos de dispositivos

virtuales (VDCs). Un VDC permite virtualizar los conmutadores a nivel de dispositivo. Cada

VDC configurado se presenta como un dispositivo único, expandiendo aún más la

separación de inquilinos no sólo en los planos de datos y de control, sino también en el

plano de gestión. Un VDC se ejecuta como una entidad lógica independiente dentro del

conmutador, manteniendo su propio conjunto único de procesos de software en ejecución,

teniendo su propia configuración y siendo gestionado por un administrador separado.

Cada VDC contiene su propio conjunto único e independiente de VLAN y VRF. Los puertos

físicos se pueden asignar a un VDC específico, permitiendo así que el plano de datos de

hardware sea virtualizado también. Dentro de cada VDC, un dominio de gestión

independiente puede gestionar el VDC propiamente dicho, permitiendo así que el propio

plano de gestión también sea virtualizado.

Microsegmentación con redes de superposición

Los modelos clásicos de seguridad son difíciles de adaptar a los requerimientos de

aplicación de múltiples aplicaciones. Los servicios públicos y privados no están sellados

entre sí. Las aplicaciones empresariales internas pueden necesitar acceso a aplicaciones y

bases de datos de comercio electrónico. Algunos flujos de aplicaciones pueden necesitar

extenderse fuera del inquilino de la nube privada. Los niveles de aplicación se pueden

distribuir a través de los límites de la capa 2 del centro de datos.

En centros de datos modernos, puede resolver estos problemas con redes de

superposición. Los servicios que necesitan comunicación directa se colocan en un VXLAN

común, proporcionando una conectividad de capa 2 independiente de la ubicación física o

de la red subyacente de la capa 3. La red superpuesta permite a los servicios comunicarse

libremente a través de los límites de la capa 2, mientras que su comunicación está aislada

de otros servicios.

340

341

Capítulo 13

Infraestructura

Centrada en la

Aplicación de Cisco

(ACI)

342

El Cisco Application Centric Infrastructure (ACI) ofrece flexibilidad de software con la

escalabilidad del rendimiento del hardware que proporciona una red de transporte

robusta orientado a las cargas de trabajo dinámicas actuales. El ACI está construido sobre

un tejido de red que combina protocolos con nuevas innovaciones para crear una

arquitectura altamente flexible, escalable y resistente de enlaces de baja latencia y de alto

ancho de banda. Estos beneficios se consiguen mediante la integración de entornos físicos

y virtuales bajo un único modelo de políticas para redes, servidores, almacenamiento,

servicios y seguridad.

CARACTERÍSTICAS DEL ACI

El ACI en el centro de datos es una arquitectura holística basada en políticas de redes

definidas por software (SDN). Las principales características del ACI incluyen:

Automatización simplificada mediante un modelo de políticas orientada a lass

aplicaciones

Velocidad de aplicación. Cualquier carga de trabajo en cualquier sitio

Visibilidad centralizada con monitoreo de la salud en tiempo real

Flexibilidad del software abierto para los equipos de DevOps y en la integración de

socios en el ecosistema

Protección de la inversión mediante la integración con la infraestructura de tejido

existente (por ejemplo, Nexus 7000)

Rendimiento escalable y multitenencia en hardware

A través de Cisco ACI, los clientes están reduciendo los tiempos de implementación de

aplicaciones de semanas a minutos. También mejora drásticamente la alineación de TI con

los objetivos de negocio y los requisitos de política. Lo que impulsa la velocidad y las

eficiencias de ACI es el modelo de funcionamiento basado en políticas común que el ACI

introduce en los elementos de red y de seguridad compatibles con este modelo. Este

modelo se facilita mediante el aprovechamiento de una solución basada en políticas. Por lo

tanto, ACI puede mejorar los modernos modelos de redes de centros de datos, superar las

limitaciones de las estructuras de los centros de datos y reducir considerablemente la

complejidad operacional y los costos del centro de datos (gastos de capital, gastos

operativos, tiempo de aprovisionamiento, etc.).

343

CÓMO EL CISCO ACI SOLUCIONA LAS LIMITACIONES DE RED

ACTUALES

El ACI de Cisco corrige las limitaciones actuales de la red de la siguiente manera:

Elimina la complejidad que conduce a la estasis: El Cisco ACI elimina la complejidad

de la red. Se establece para desacoplar la política de reenvío permitiendo que el

enrutamiento y la conmutación de la red se distribuyan por completo en toda la

estructura. El reenvío de paquetes ACI a través del tejido utiliza una combinación

de silicio comercial y personalizado para ofrecer puentes y enrutamiento Virtual

Extensible LAN (VXLAN) basados en estándares sin penalización ni impacto

negativo en el usuario o la aplicación.

Además, Cisco ACI puede aplicar la directiva sin necesidad de derivar esta

información de la información de red (como direcciones IP). Para ello, se rellena

cada trama VXLAN con un identificador de 16 bits para identificar de forma

exclusiva el grupo de origen del paquete, tal como se especifica en el borrador de

IETF (VXLAN Internet Engineering Task Force). Este enfoque ofrece una

flexibilidad excepcional para los usuarios finales, lo que permite a los usuarios

modificar las políticas de red con poco conocimiento de la misma y ningún impacto

negativo en el reenvío de la red.

El ACI de Cisco simplifica aún más las políticas mediante la introducción de un

modelo de abstracción -una directiva basada en grupos- de modo que los usuarios

finales puedan definir conectividad utilizando construcciones abstraídas de alto

nivel en lugar de semántica concreta de redes. Este modelo permite a los usuarios

finales de ACI definir reglas de política sin conocimientos de redes, abriendo el

camino para que los administradores de aplicaciones y desarrolladores interactúen

directamente con las políticas de ACI para expresar su intención sin necesidad de

involucrar a los administradores de redes de TI.

Asegura políticas coherentes: uno de los mayores retos en la administración de las

políticas de red en una gran red es el requisito de tocar un gran número de

dispositivos y asegurarse de que la configuración de la política permanezca

constante. Cisco ACI soluciona este desafío descargando esta tarea al controlador

de infraestructura de políticas de aplicaciones de Cisco (APIC), que es la autoridad

central de políticas y el punto central de administración para el ACI de Cisco y los

servicios físicos y virtuales asociados. El usuario final sólo tiene que especificar en

el Cisco APIC la intención deseada de la política basada en grupos y este distribuye

la política a todos los nodos del tejido ACI.

El APIC utiliza una variante de la teoría de la promesa, con una separación formal

total entre el modelo lógico abstracto y el modelo concreto, y sin ninguna

configuración realizada en entidades concretas. Las entidades concretas se

configuran implícitamente como un efecto secundario de la implementación del

344

modelo lógico. Esta implementación de la teoría de la promesa proporciona

consistencia de políticas en toda la red a escala.

Proporciona la habilidad de escalar: ACI está diseñado para escalar de forma

transparente durante toda su implementación, soportando cambios en la

conectividad, el ancho de banda, los inquilinos y las políticas. La topología de

espina y hoja del tejido Cisco ACI soporta un enfoque de diseño escalable. Si se

requiere conectividad física adicional, puede agregar nodos de hoja conectándolos

a las espinas. De forma similar, si se requiere un ancho de banda o redundancia

adicional, puede introducir nodos adicionales en la columna vertebral. Este modelo

de despliegue escala hacia afuera también permite a los usuarios finales comenzar

a escala pequeña y posterior a entornos extremadamente grandes, reduciendo así

el gasto de capital inicial requerido para implementar un tejido escalable. Sin

embargo, la adición de nuevos dispositivos no significa un mayor número de

puntos de gestión. Después de registrar los nuevos dispositivos en el tejido Cisco

ACI a través del Cisco APIC, el usuario final puede administrar todo el tejido,

incluidos los nuevos dispositivos, desde el Cisco APIC central. La introducción de

los nuevos dispositivos no requiere intervención del administrador.

Los inquilinos y las políticas también utilizan un enfoque de escala hacia fuera. Las

directivas se almacenan centralmente en el tejido y se procesan en los nodos de

tejido según sea necesario. El repositorio de políticas de Cisco APIC en sí mismo es

una base de datos en clúster escalable. Puede aumentar de 3 a más de 31 nodos en

un solo cluster, dependiendo de la escala de inquilinos y políticas requeridas.

Incluso con nodos de clúster adicionales, todos los nodos se consideran activos y

las directivas se pueden administrar en cualquier miembro del clúster.

Es independiente del proveedor: un despliegue completo de Cisco ACI incluirá

probablemente servicios de Capa 4 a 7, redes virtuales, computación, recursos de

almacenamiento, enrutadores WAN y servicios de orquestación hacia el norte. Una

de las principales ventajas de Cisco ACI es su apertura, con sus APIs publicadas,

paquetes de dispositivos de capa 4 a 7 y el uso del protocolo OpFlex abierto. Con

estas API abiertas, complementos y protocolos, los usuarios finales pueden agregar

funciones de forma incremental a sus soluciones sin necesidad de esperar a que un

solo proveedor introduzca nuevas capacidades.

COMPONENTES DE ARQUITECTURA DE CISCO ACI

La arquitectura Cisco ACI es una combinación de alto rendimiento de hardware e

innovación de software e inteligencia integrada con dos conceptos importantes de las

soluciones SDN: superposiciones y control centralizado. Sin embargo, el ACI utiliza

diferentes enfoques y ofrece capacidades que van más allá de la típica oferta SDN, o lo que

345

se conoce como SDN basado en OpenFlow. La arquitectura de Cisco ACI Solution consiste

en:

Administración de políticas centralizada denominada Controlador de

infraestructura de políticas de aplicaciones de Cisco (APIC)

El nuevo hardware de alto rendimiento Cisco ACI con innovaciones de software y

hardware

Un conmutador virtual de aplicación de Cisco (AVS) para el borde de la red virtual

Infraestructura física y virtual integrada

Un ecosistema abierto de proveedores de red, almacenamiento, administración y

orquestación

Cisco Application Policy Infrastructure Controller (APIC)

En general, los modernos operadores de centros de datos y el personal de TI necesitan

políticas coherentes en toda la red. Sin embargo, uno de los principales desafíos en el

manejo de políticas en las redes existentes es el número de dispositivos a los cuales las

políticas deben aplicarse, junto con la necesidad de garantizar la coherencia. El

controlador de infraestructura de directivas de aplicaciones de Cisco (APIC) soluciona este

problema.

La arquitectura de Red Abierta (ONE) de Cisco usa el APIC en el Centro de datos en cual es

un componente clave de ACI para simplificar y dinamizar la gestión de las aplicaciones

alojadas en el centro de datos. El Cisco APIC proporciona un enfoque abierto y

programable para la creación de redes a través de API abiertos para la gestión y la

seguridad basadas en políticas. Los operadores de centros de datos pueden utilizar las

llamadas basadas en la transferencia de estado representativo (REST) (a través de XML o

JavaScript Object Notation [JSON]) para proporcionar, administrar, supervisar o

solucionar problemas del sistema.

346

Este enfoque automatiza y unifica las aplicaciones, la red, la nube y los equipos de

seguridad en la definición de requisitos de aplicación que evitan la complejidad de lo que

normalmente ha sido un aburrido manual y aislado entre los diferentes equipos de TI.

Para la arquitectura, Cisco APIC es un sistema distribuido implementado como un grupo

de controladores. Proporciona un único punto de control, un API central, un repositorio

central para datos globales y un repositorio para datos de políticas basadas en grupos

para Cisco ACI.

El Cisco APIC se comunica con el tejido Cisco ACI para distribuir las políticas a los puntos

de unión y para proporcionar varias funciones administrativas críticas al tejido. Sin

embargo, el APIC de Cisco no está directamente involucrado en el reenvío en los planos de

datos, por lo que un fallo o desconexión completa de todos los elementos APIC de Cisco en

un clúster no producirá ninguna pérdida de capacidades de reenvío, aumentando la

confiabilidad general del sistema.

Además, Cisco APIC también proporciona soporte nativo completo a la multitenencia, por

lo que múltiples grupos interesados (internos o externos a la organización) pueden

compartir el Cisco ACI de forma segura, pero todavía se le permite el acceso a recursos

compartidos si es necesario. El APIC de Cisco también tiene un soporte completo y

detallado para el control de acceso basado en roles (RBAC, por sus siglas en inglés) hasta

cada objeto administrado en el sistema, por lo que se pueden otorgar privilegios (lectura,

escritura o ambos) por rol en todo el tejido.

Las principales características de Cisco APIC incluyen

Políticas de red centradas en la aplicación

Provisionamiento declarativo basado en modelos de datos

Aplicación, supervisión de topología y solución de problemas

Integración de terceros (servicios de Capa 4 a 7, almacenamiento, computación,

WAN)

Manejo de imágen (columna y hoja)

Inventario y configuración de Cisco ACI

Implementación en un marco distribuido a través de un conjunto de dispositivos

El APIC administra y automatiza los componentes de reenvío subyacentes y los

dispositivos de servicio de Capa 4-Capa 7. Utilizando la visibilidad APIC tanto en la

infraestructura virtual y física como en el conocimiento extremo a extremo de la

aplicación basada en el perfil de la aplicación, la APIC puede calcular una puntuación de

salud de la aplicación. Esta puntuación de salud representa la salud de la red de la

aplicación a través de recursos físicos y virtuales, incluidos los dispositivos de Capa 4-

Capa 7. Incluye jitter, latencia, congestión, fallos, descarte de paquetes, etc.

347

El puntaje de salud proporciona mayor visibilidad en los niveles de aplicación y de

inquilinos. La puntuación de salud puede crear más valor cuando se utiliza para activar

eventos automatizados en umbrales específicos. Esto permite que la red responda

automáticamente a la salud de la aplicación, realizando cambios antes de que los usuarios

se vean afectados.

Enfoque APIC dentro de la arquitectura ACI

La política APIC utiliza un enfoque orientado a objetos basado en la teoría de la promesa.

La teoría de la promesa se basa en el control declarativo y escalable de los objetos

inteligentes, en comparación con los modelos imperativos legados, que pueden

considerarse como una gestión de peso pesado y de arriba hacia abajo.

Como se muestra en la Figura, el controlador de políticas indica a los dispositivos de red

qué necesita habilitarse o configurarse para satisfacer el requisito de una aplicación; sin

embargo, no le dice al dispositivo cómo hacerlo, y el dispositivo puede hacerlo utilizando

sus propias características y capacidades para lograr el mismo resultado final.

El APIC empuja centralmente las políticas a la infraestructura subyacente utilizando un

protocolo de política extensible diseñado para intercambiar la política abstracta entre un

controlador de red y un conjunto de dispositivos inteligentes capaces de generar una

política denominada OpFlex. A diferencia de OpenFlow, que es una tecnología impulsada

por agentes y que sólo permite a operadores de red administrar elementos específicos con

348

el controlador OpenFlow, OpFlex está diseñado para funcionar como parte de un sistema

de control declarativo. Por lo tanto, ofrece la flexibilidad a los operadores de centros de

datos para empujar políticas a varios elementos de infraestructura de red, ya sean

virtuales, físicos o de Capa 4-7, y las políticas abstractas pueden ser compartidas bajo

demanda.

El Tejido de ACI

Como se comentó anteriormente, las cargas de trabajo continúan evolucionando, y el

tráfico se está volviendo cada vez más este - oeste. Las redes necesitan responder con

mayor rapidez a las cargas de trabajo dinámicas virtualizadas y basadas en la nube para

acomodar el crecimiento del tráfico a medida que los conjuntos de datos se hacen más

grandes.

La arquitectura del tejido ACI de Cisco está diseñada con base en uno de los modelos de

diseño de red más eficientes y escalables: una gráfica bipartita de espina y hoja o

arquitectura Clos, en la que cada hoja está conectada a cada columna a través de enlaces

40/100 Gigabit y viceversa. Además, con esta arquitectura, cada nodo de hoja está a un

salto de distancia de cualquier otro nodo de hoja a través del tejido. Como se comentó en

el capítulo anterior, la belleza de esta arquitectura es que la conectividad de malla

completa no es necesaria, sin embargo, puede ofrecer un camino de reenvío óptimo entre

349

cualquier par de puntos finales con un número mínimo de saltos/latencia combinado con

la distribución de carga ECMP. En otras palabras, los nodos de la columna vertebral no se

conectan entre sí, y los nodos de hojas no se conectan entre sí, como se muestra en la

Figura anterior.

Para reducir la probabilidad de que se formen puntos calientes de actividad en el tejido,

todos los dispositivos (independientemente de sus funciones) se conectan a los nodos de

hoja. De esta manera, el tejido puede simplemente escalar el número de dispositivos

conectados, añadiendo más nodos de hoja. Si se necesita incrementar la cantidad de ancho

de banda transversal que está sirviendo el tejido, el administrador simplemente tiene que

añadir nodos de espina. Esta flexibilidad permite que la tela empiece como un entorno

pequeño, pero gradualmente crezca hasta un ambiente mucho más grande si surge la

necesidad. El tejido también se construye utilizando interfaces IP enrutadas basadas en

estándares, ofreciendo mayor estabilidad en implementaciones de mayor escala.

Actualmente, el tejido típico de espina y hoja consta de dos capas de dispositivos de la

serie Cisco Nexus 9000:

Los conmutadores de columna: Los switches de alto rendimiento de nivel superior

interconectan todos los dispositivos de hoja; por lo tanto, los dispositivos de

columna vertebral constituyen la columna vertebral del tejido y proporcionan la

función de base de datos de mapeo. El hardware utilizado para la columna

vertebral está diseñado específicamente para proporcionar esta función a gran

escala. La base de datos de mapeo se almacena de forma redundante dentro de

cada columna vertebral y se replica entre los conmutadores de columna para que,

si una columna desaparece, el tráfico continúa. Los conmutadores modulares de

columna tienen una mayor capacidad de almacenamiento de bases de datos de

mapeo; De hecho, la base de datos de asignación se comparte entre las tarjetas del

tejido, por lo que a más tarjetas, más se puede almacenar. El uso de más tarjetas

también depende de la capacidad de reenvío que desee dar a las tarjetas de línea.

Como se mencionó anteriormente, no se permite ni requiere enlace directo entre

los conmutadores de columna.

Conmutadores de hoja: Los switches de nivel inferior conectan todos los servidores

u otras partes de la red al tejido. De hecho, los dispositivos de hoja pueden

conectarse a cualquier dispositivo, y son el lugar en el que se aplican las políticas.

Los dispositivos de hoja también proporcionan la capacidad de enrutamiento y

conmutación a las infraestructuras de red externas (campus, WAN, conectividad a

una nube de red privada virtual [MPLS VPN] de conmutación de etiquetas

multiprotocolo y así sucesivamente). En este caso, a veces se denominan

dispositivos de hoja de borde. Además, los conmutadores de hoja pueden ser el

punto de conexión para cargas de trabajo y para la hoja de borde y así

proporcionar conectividad a la WAN o a una nube MPLS VPN.

Los conmutadores Nexus deben ejecutar el modo de tejido ACI. Alternativamente, pueden

ejecutarse en un modo NX-OS estándar. En este caso, se consideran como cualquier otro

350

tipo de dispositivo individual. (Como se mencionó en el capítulo anterior, puede ejecutar

BGP-EVPN como el plano de control para el VXLAN en este modo, sin embargo, no

obtendrá la visibilidad de capacidades y aplicaciones que tiene con el modo ACI).

APIC es un dispositivo físico que está conectado a la capa de hoja y es responsable del

arranque inicial del tejido (por lo tanto, el requisito de ser un dispositivo físico porque el

entorno virtual depende de la disponibilidad del tejido). Cisco APIC es un controlador

físicamente distribuido, pero lógicamente centralizado que proporciona DHCP,

configuración de arranque y administración de imágenes al tejido para el inicio

automático y actualizaciones.

El software Cisco Nexus ACI está incluido en una imagen IOS, que se puede instalar en el

servidor de dispositivos APIC de Cisco a través de la consola. La IOS del Software Cisco

Nexus ACI contiene la imagen Cisco APIC, la imagen de firmware para el nodo hoja, la

imagen de firmware para el nodo espina, las políticas de infraestructura del tejido

predeterminadas y los protocolos que se requieren para la operación.

El tamaño mínimo recomendado tiene los siguientes requisitos:

Tres o más controladores Cisco APIC que están conectados de forma dual a

diferentes conmutadores de hoja para una máxima resiliencia. Tenga en cuenta que

el tejido es manejable incluso con sólo un controlador y operativo sin un

controlador.

Al menos dos dispositivos de columna vertebral para la resiliencia y también el

equilibrio de carga. La espina dorsal puede escalar fácilmente agregando

conmutadores adicionales.

Al menos dos dispositivos de hoja para la resiliencia y también balanceo de carga.

Las hojas pueden escalar fácilmente agregando los conmutadores adicionales de

351

hoja. Cada hoja debe estar conectada a todos los dispositivos de la columna

vertebral.

El tejido Cisco ACI es una arquitectura de hojas y espinas altamente escalable,

multicamino y de alto rendimiento que proporciona una superposición VXLAN para el

espacio del inquilino - la red que usan las aplicaciones de negocios, los departamentos y

los clientes. El tejido Cisco ACI también implementa el concepto de espacio de

infraestructura, que está aislado de forma segura en el tejido. Este es también el lugar

donde se realizan todos los descubrimientos de topología, gestión de trama y

direccionamiento de infraestructura.

SUPERPOSICIONES DE VIRTUALIZACIÓN DE RED ACI

El tejido ACI de Cisco está basado en IP e implementa una superposición integrada,

permitiendo que cualquier subred se coloque en cualquier parte del tejido y admita un

dominio de movilidad en toda la estructura para las cargas de trabajo virtualizadas. El

protocolo Spanning Tree (STP) no es necesario en los switches Cisco ACI de espina y hoja.

Para lograr esto, la solución de red Cisco ACI utiliza una superposición basada en VXLAN

para virtualizar la infraestructura física. Esta superposición, como la mayoría de las

superposiciones, requiere que la ruta de datos en el borde de la red trace desde la

dirección del punto final del inquilino en el paquete, su identificador, hasta la ubicación

del punto final, su localizador. Esta asignación se produce en el punto final del túnel (TEP).

Debido a que las redes de superposición son "virtuales" por naturaleza, son ágiles,

dinámicas y adecuadas para la automatización y el control de software. En un entorno ACI,

VXLAN se utiliza para encapsular el tráfico dentro del tejido. En otras palabras, cada

conmutador de hoja actúa como punto final del túnel de hardware VXLAN (VTEP).

Además, como se comentó en el capítulo anterior, VXLAN es un tipo de encapsulación

MAC-in-IP que requiere una red de transporte de capa subyacente-encaminada para

establecer la conectividad entre los VTEP. El tejido ACI está diseñado para proporcionar

una topología de experiencia de operación sin contacto con autodescubrimiento,

configuración automatizada y direccionamiento de infraestructura utilizando protocolos

estándar de la industria incluyendo IS-IS para facilitar el establecimiento de la

conectividad de superposición entre el VTEPs.

352

El tejido Cisco ACI desacopla la dirección del punto final del inquilino, su identificador,

desde la ubicación de ese punto extremo, que está definido por su localizador o la

dirección del punto final de terminación VXLAN.

El reenvío dentro del tejido es entre VTEPs y un formato de extensor de cabecera VXLAN

denominado encabezado de directiva VXLAN. El VTEP mapea la dirección MAC o IP

interna del inquilino a una ubicación que utiliza una base de datos de asignación

distribuida. El ACI admite la semántica completa de reenvío de Capa 2 y Capa 3; No se

requieren cambios en las aplicaciones o en las pilas IP de punto final. Los ID de VLAN

tendrán importancia local sólo en el nivel de conmutación de hoja, ya que el conmutador

de hoja de ingreso intercambia la VLAN externa, VXLAN y Virtualización de red mediante

etiquetas de encapsulación de enrutamiento genérico (NVGRE) con una etiqueta VXLAN

interna; Y esta etiqueta se intercambiará con la etiqueta respectiva en el conmutador de

hoja saliente.

353

En el tejido ACI, se han añadido algunas extensiones al encabezado VXLAN para permitir la

segmentación de grupos de puntos finales (EPG) y la gestión de las reglas de filtrado. Estas

extensiones también admiten las técnicas de balance de carga mejoradas en el tejido.

El encabezado VXLAN mejorado (eVXLAN) proporciona un mecanismo de etiquetado para

identificar las propiedades asociadas con las tramas enviadas a través de un tejido

compatible con ACI. Es una extensión del Localizador capa 2/Protocolo de Separación de

Identificación (LISP) con el grupo de políticas adicionales, la métrica de la ruta de carga y

la ruta, el contador y el puerto de ingreso y la información encapsulación. El encabezado

eVXLAN no está asociado con un segmento capa 2 o un dominio capa 3 específico, sino que

proporciona un mecanismo de marcado multifunción utilizado en el tejido habilitado para

la red ACI.

354

Con este enfoque de reenvío, ACI proporciona la estandarización del encapsulamiento

"multi-hypervisor", lo que facilita un transporte uniforme y unificado para diferentes

proveedores de hipervisor y tecnologías de superposición, ya sean basados en redes

VLAN, VXLAN o NVGRE para nodos virtuales y físicos. Como se muestra en la Figura, ACI

simplifica la implementación de aprovisionamiento de red para soportar el multihypervisor

y permite a los operadores de centros de datos elegir un proveedor de

hipervisor sin restricciones.

Nota: si se requiere una asignación de VLAN en el nivel de conmutación del puerto hoja, la

administración de red normalmente no necesita configuración manual. El administrador

sólo debe definir una directiva de acceso (especificando los atributos de acceso básicos,

como el tipo de puerto y el rango de agrupación VLAN). El resto será parte del proceso de

aprovisionamiento del perfil de red de aplicaciones (ANP).

355

A diferencia del despliegue de los conmutadores de la serie Nexus 9000 en modo no ACI,

que utilizan BGP-EVPN como plano de control para el VXLAN, en el modo ACI, el plano de

control y el reenvío se basan en un concepto denominado Mapeo de la base de datos. Una

base de datos de mapeo ofrece una mayor visibilidad de las ubicaciones y direcciones de

host en toda el tejido. La base de datos de mapeo en ACI es mantenida por el tejido que

contiene la asignación para cada extremo conectado a la red (identificador) y la dirección

del punto final del túnel que se encuentra detrás (localizador). La dirección del punto final

es tanto la dirección MAC como la dirección IP del punto final más la red lógica en la que

reside (la instancia VRF). La base de datos de mapeo en la columna vertebral se replica

por redundancia y se sincroniza en todas las espinas. Normalmente, cuando un

conmutador de hoja de ingreso transfiere un paquete, comprueba primero su caché local

de la base de datos de asignación. Si no encuentra la dirección del punto final que está

buscando, encapsulará el paquete en la función proxy que reside en el conmutador de

columna vertebral y lo reenviará como unidifusión para buscar la dirección requerida. O,

puede ser una dirección externa y alcanzable a través de una hoja de la frontera. Con este

enfoque, las tablas de cada hoja deben contener la siguiente información:

La tabla de estaciones locales (LST) debe contener las direcciones IP y MAC de los

hosts conectados localmente.

La tabla de estaciones globales (GST) debe contener la información sobre las

direcciones IP y MAC de los hosts remotos con los que los hosts locales tienen una

conversación activa.

PRINCIPIOS DE DISEÑO DE APLICACIONES CON EL MODELO

DE POLÍTICAS DE CISCO ACI

Las aplicaciones influyen en los negocios. Incluyen portales web que generan ingresos,

sistemas de recursos humanos (HR) que ayudan a nuevos empleados, sistemas de imagen

que apoyan la atención al paciente, etc. Mientras que el grupo de aplicaciones utilizado

difiere entre la industria y entre las empresas dentro de una industria, una cosa

permanece constante: una aplicación no es un proceso aislado que se ejecuta en una

máquina virtual (VM). Las aplicaciones son ecosistemas de componentes interconectados:

algunos físicos, algunos virtuales, algunos legados y otros nuevos.

Estos ecosistemas de aplicación son interconexiones complejas de componentes y niveles,

cuyo resultado final promueve el valor comercial. Por ejemplo, cuando un usuario intenta

acceder a una determinada aplicación a través de un cliente ligero (utilizando la

infraestructura de escritorio virtual o VDI), el proceso de introducir las credenciales de

inicio de sesión para recibir la interfaz de la aplicación deseada podría completarse en

unos segundos. En el extremo posterior, una instancia de aplicación virtualizada y VDI

356

pasará las credenciales del usuario a un sistema de autorización. Una vez que el usuario

está autorizado como usuario válido, la información se pasa al sistema de aplicaciones

virtualizado junto con la solicitud de acceso para iniciar la sesión de aplicación. A

continuación, recupera los datos pertinentes del almacén de datos, como un dispositivo de

almacenamiento del sistema de archivos de red (NFS). Por último, esta información se

formatea y se compila a través de una capa de presentación y se presenta de nuevo al

usuario a través de dispositivos cliente ligero.

Esta interacción para proporcionar una experiencia de inicio de sesión única al usuario

requiere varios niveles y componentes repartidos entre las redes de centro de datos frontend

y back-end. Estos componentes de aplicación pueden existir en capas virtuales o

físicas y las transacciones están sujetas a varios servicios de red, incluidas las

comprobaciones de seguridad y cumplimiento.

De hecho, las aplicaciones no son tan simples como el software que se ejecuta en una VM.

Las complejidades dentro de la conectividad de la aplicación van mucho más allá del

alcance de lo que se muestra en la Figura cuando se agregan puertos TCP / UDP,

encadenamiento de servicios y más. Este ecosistema completo es lo que proporciona el

resultado final deseado al usuario o sistema que utiliza la aplicación.

357

Dicho esto, las redes de hoy en día en su mayoría no tratan las solicitudes en la forma en

que están estructuradas. En cambio, las redes actuales casi siempre agrupan las

aplicaciones mediante LAN virtual (VLAN) y subred y aplican conectividad y política

basadas en esas construcciones. Esto lleva a restricciones sobre cómo se pueden agrupar

las aplicaciones y cómo se puede aplicar la política a esas aplicaciones. Con este enfoque

tradicional, es como si tuvieras una desconexión o una traducción ineficiente entre el

idioma de una aplicación y el idioma de la red.

Normalmente, una o más aplicaciones se agrupan en VLAN y, a continuación, las subredes

IP se asignan a esas VLAN. Desde allí, la conectividad a través del enrutamiento se

configura y los servicios de red se aplican al direccionamiento de subred. Por lo tanto, las

configuraciones manuales, el proceso y las construcciones acopladas de este modelo de

diseño conducen a un despliegue más lento, mayores tasas de error de configuración y

auditoría reducida. En consecuencia, esto crea un impacto significativo en los negocios con

la metodología actual.

358

Por otro lado, la Figura ilustra cómo el ACI de Cisco calculó la brecha entre los lenguajes de

la aplicación y de la red con el modelo basado en políticas que está habilitado

principalmente por Cisco APIC. En este enfoque, la aplicación escalonada tradicional

puede ahora desplegarse sin esfuerzo en el tejido ACI simplemente definiendo los objetos

y los requisitos de comunicación entre ellos.

Los siguientes son los principios principales para crear políticas de aplicación y

comunicaciones con el modelo de diseño de centros de datos basados en políticas de ACI:

Perfil de la red de aplicaciones (ANP): este perfil contiene toda la política de la

aplicación. De hecho, los ANP están diseñados para ser modelados de una manera

lógica que coincida con la forma en que se diseñan y despliegan las aplicaciones

(superando la desconexión entre el lenguaje de la aplicación y el lenguaje de red).

Grupos de puntos finales (EPG): una política consta de varios grupos de puntos

finales, que normalmente son uno o más servidores del mismo segmento.

Contratos: Los contratos de política definen los requisitos de comunicación entre

EPG.

359

¿Qué es un grupo de puntos finales en Cisco ACI?

Los grupos de puntos finales (EPG) son colecciones de puntos finales similares que

representan un nivel de aplicación o conjunto de servicios. Proporcionan un agrupamiento

lógico para objetos que requieren políticas similares. Por ejemplo, un EPG podría ser un

grupo de componentes que componen el nivel web de una aplicación. Los puntos finales se

definen mediante NIC, vNIC, direcciones MAC, direcciones IP, nombres DNS y etiquetas de

VM con extensibilidad para futuros métodos de identificación de componentes de

aplicación. Por ejemplo, la Figura muestra una EPG que contiene servicios web (HTTP y

HTTPS) definidos independientemente de su subred IP (diferentes subredes IP bajo una

sola EPG). En este ejemplo, independientemente de las subredes independientes, la

directiva se aplica a los servicios HTTPS y HTTP dentro de este EPG. Esto ayuda a los

operadores de centros de datos a separar el direccionamiento de las aplicaciones de su

mapeo y aplicación de políticas a través del tejido ACI.

360

Los EPGs están diseñados para ofrecer flexibilidad, permitiéndoles personalizarlos con

uno o más modelos de implementación que un cliente determinado puede elegir. Los EPGs

se utilizan para definir dónde se aplica la política. Dentro del tejido Cisco ACI, la política se

aplica entre EPG, por lo tanto, la definición de cómo EPGs se comunican entre sí. Además,

las EPG y las políticas asociadas están diseñadas para ser extensibles en el futuro a la

aplicación de políticas dentro de una propia EPG.

La implementación de EPG dentro del tejido proporciona varios beneficios. Los EPG

actúan como un único punto de aplicación de políticas para un grupo de objetos

contenidos. Esto simplifica la configuración de estas políticas y garantiza que sea

coherente. Se aplica una política adicional basada no en la subred, sino en la EPG misma.

Esto significa que los cambios de dirección IP en el punto final en sí no cambian

necesariamente su política, como suele ser el caso en las redes tradicionales (la excepción

aquí es un punto final definido por su IP). Alternativamente, mover un punto final a otro

EPG aplicaría la nueva política al switch de hoja al que está conectado el punto final y

definirá un nuevo comportamiento para ese punto extremo basado en el nuevo EPG.4

Diseño de EPGs

Los EPG proporcionan un nuevo modelo para asignar aplicaciones a una red. En lugar de

usar construcciones de reenvío como direccionamiento o VLAN para aplicar conectividad

y política, las EPG utilizan un grupo de puntos finales de aplicación. Los EPG actúan como

un contenedor para colecciones de aplicaciones o para componentes y niveles de

aplicación que se pueden utilizar para aplicar la lógica de reenvío y de políticas. Permiten

separar la política de red, la seguridad y el reenvío del direccionamiento y, en su lugar,

aplicarlo a los límites de las aplicaciones lógicas.

En cualquier implementación ACI típica, los grupos de punto final requieren los siguientes

componentes:

Colección de servidores

Contratos (suministrados y consumidos): un contrato define qué protocolo y

puerto de nivel 4 se permite (todo lo demás se deniega)

Dominio de puenteo

Red

Los contratos definen las reglas y políticas de permisos, denegaciones y QoS de entrada y

salida, como el redireccionamiento. Los contratos permiten definiciones sencillas y

complejas de la forma en que un EPG se comunica con otros EPG, dependiendo de los

requisitos del entorno. Aunque los contratos se aplican entre EPGs, están conectados a

EPGs usando relaciones proveedor-consumidor. Esencialmente, una EPG proporciona un

contrato y otros EPG consumen ese contrato. Además, este modelo de política permite la

aplicación unidireccional y bidireccional de políticas.

361

En otras palabras, para construir un diseño con el enfoque basado en políticas de Cisco

ACI, debe hacer lo siguiente:

Identificar y agrupar puntos finales. En el modelo Cisco ACI, esto se logra utilizando

EPG.

Determinar la forma en que estos puntos finales agrupados se comunican entre sí.

En Cisco ACI, esto se logra creando políticas y asociándolas con contratos como

puntos de conexión entre EPG.

Después de definir objetos tales como EPGs y contratos, el operador del centro de datos

puede definir el perfil de red de aplicación que debe ser empujado por el ACI APIC y

provisto por los conmutadores de tejido ACI, como se ilustra en la Figura. Con este

enfoque, los operadores de red no necesitan preocuparse por definir y aplicar

configuraciones manualmente complejas como VLANs y ACLs.

362

Nota: Como se comentó anteriormente, el grupo de origen eVXLAN se utiliza como

etiqueta/etiqueta para identificar el punto final específico para cada función de aplicación

(EPG), en la que permite al ACI mapear la configuración de políticas al nivel de paquetes

ya las instalaciones. Al hacerlo, logra lo siguiente:

Aplicación de políticas entre un nivel de aplicación de entrada o de origen (EPG) y

un nivel de aplicación de salida o destino (EPG)

Política que puede aplicarse en la fuente o el destino

Políticas de acceso de tela ACI

El operador de la red del centro de datos necesita proporcionar una configuración básica

para los conmutadores de hoja para especificar parámetros relacionados con el acceso

tales como agrupaciones de VLAN, qué conmutadores de hoja y puertos necesitan ser

utilizados y cómo deben configurarse - conectividad externa, troncal o vPC). También, se

pueden configurar otros parámetros de acceso, incluyendo velocidad de puerto, LLDP,

CDP y control de tormentas.

Por otro lado, la filosofía subyacente del Cisco ACI es que el administrador de

infraestructura puede clasificar los servidores según sus requerimientos. Por ejemplo, los

servidores virtualizados con hipervisores pueden conectarse a una red de 10 Gigabit

363

Ethernet, los servidores no virtualizados pueden conectarse a una Ethernet de 1 Gigabit,

etc.

Cisco ACI proporciona una manera de mantener el nivel prometido de abstracción al

definir la conexión de los servidores o cualquier entidad externa al tejido. Al mismo

tiempo, desmitifica las configuraciones de los puertos físicos para los centros de datos

pequeños y grandes. El administrador de infraestructuras prepara una plantilla de

configuraciones para los servidores conectados con agrupaciones activo/pasivo,

PortChannels y vPCs y agrupa todas las configuraciones de los puertos en un grupo de

políticas. A continuación, el administrador crea objetos que seleccionan interfaces del

tejido en intervalos que comparten la misma configuración de grupo de políticas.

Con este enfoque, el operador o administrador de red del DC puede definir las directivas y

plantillas necesarias una vez para proporcionar las VLAN y las políticas de interfaz

deseadas en los nodos y puertos de hojas.

Además, puede crear políticas que se apliquen no sólo a un conmutador a la vez, sino a

varios conmutadores. Esta capacidad es muy útil para la configuración de vPCs.

Desde el punto de vista de la operación en red, la principal ventaja de este enfoque es que

puede aplicar configuraciones de manera más lógica. Por ejemplo, si desea agregar un

puerto al conjunto de servidores físicos, sólo tiene que agregar una interfaz al perfil de

interfaz. Si desea cambiar la configuración del puerto físico, sólo tiene que realizar ese

cambio en el grupo de políticas de interfaz. Si desea agregar una VLAN al rango,

simplemente podría modificar el dominio físico.

364

Bloques de construcción de un inquilino en el Cisco ACI

Aunque el uso exacto y la definición de un inquilino en las redes de centros de datos

modernas puede variar de una solución a otra, su concepto general sigue siendo el mismo.

Un inquilino es una entidad física o física que reside en una red de centros de datos para

servir a un determinado grupo de usuarios (como un inquilino de un equipo de marketing,

un inquilino invitado, un inquilino de investigación y desarrollo). En una red de centros de

datos multitenientes moderna, varios inquilinos normalmente utilizan la misma

infraestructura subyacente con separaciones lógicas en capas más altas (Capas 2 a 7).

En el Cisco ACI, un inquilino es un contenedor lógico o una carpeta para directivas de

aplicación. Puede representar un inquilino real, una organización o un dominio, o

simplemente puede usarse para la conveniencia de organizar la información. En Cisco ACI,

normalmente todas las configuraciones de aplicaciones forman parte de un inquilino

porque representa una unidad de aislamiento de una perspectiva de política y no

representa una red privada. Dentro de un inquilino, puede definir una o más redes de

Capa 3 (instancias VRF / contextos), uno o más dominios de puente por red y EPG para

dividir los dominios de puente.

Los dominios de puente identifican las propiedades que influyen en el comportamiento de

reenvío. De hecho, un dominio de puente es un contenedor para subredes que puede

actuar como un dominio de difusión o inundación si la difusión o inundación está

habilitada. El dominio de puente no es una VLAN, aunque puede actuar de forma similar a

una VLAN. Deberías pensar en ello como un switch distribuido, que, en una hoja, puede ser

traducido localmente como una VLAN con significado local. Siempre que crea un EPG,

necesita hacer referencia a un dominio de puente.

Las relaciones entre los distintos objetos son las siguientes:

El EPG apunta a un dominio de puente BD.

El dominio del puente apunta a una red de Capa 3 (BD puede definirse como Capa 2

donde no se habilita ningún enrutamiento o como BD enrutada donde Capa 3 está

habilitada junto con una capacidad de puerta de enlace generalizada).

Los EPG se agrupan en perfiles de red de aplicaciones y los perfiles de aplicación

pueden abarcar varios dominios de puente. Al agrupar los EPG en perfiles de

aplicaciones, el administrador hace que la red sea consciente de la relación entre

los componentes de la aplicación.

365

Los dominios de puente y las instancias de enrutamiento para mover paquetes IP a través

del tejido proporcionan la infraestructura de transporte para las cargas de trabajo

definidas en los EPG. La relación entre EPGs a través de contratos puede abarcar perfiles

de aplicación e incluso inquilinos.

366

Nota Cisco ACI ofrece la capacidad de insertar las funciones de Capa 4 a Capa 7 usando un

enfoque denominado gráfico de servicio. La industria normalmente se refiere a la

capacidad de agregar dispositivos de Capa 4 a Capa 7 en la ruta entre puntos finales como

inserción de servicio. La tecnología gráfica de servicio de Cisco ACI puede considerarse un

superconjunto de la inserción de servicios. Una de varias innovaciones en el área de

inserción de servicios es que Cisco ACI le permite concatenar funciones ofrecidas por

dispositivos individuales de Capa 4 a Capa 7 en lugar de simplemente conectar cajas

discretas en secuencia. Un gráfico de servicios es una variación del concepto de un

contrato.

Construcción del diseño de aplicaciones con Cisco ACI

Una de las principales filosofías del Cisco ACI es transformar el diseño de red de trabajo

del centro de datos para que sea impulsado por políticas. El objetivo es centrarse en las

necesidades de las aplicaciones y en las políticas comerciales que no son relevantes para el

dispositivo o la ubicación de la aplicación dentro del tejido ACI (no importa dónde esté

conectado, qué IP o VLAN se utiliza). Esta capacidad está activada principalmente por el

concepto de perfiles de la aplicación (ANP) y sus subcomponentes (EPG, BD, contratos,

inserción de servicios), como se ilustra en la Figura. La simplicidad del modelado del perfil

de aplicación requiere sólo un conjunto relativamente pequeño de datos que describen

aplicaciones existentes o nuevas. A continuación, se puede modelar e implementar un

diseño optimizado utilizando los perfiles de red de la aplicación Cisco Application Policy

Infrastructure Controller.

367

Sin embargo, a menudo no hay documentación relativa a un conjunto existente

(potencialmente grande) de aplicaciones que están en producción. La falta de dicha

información puede impedir el diseño adecuado de una aplicación equivalente utilizando

Cisco APIC.

Por lo tanto, como diseñador de red, necesita la siguiente información para diseñar un

perfil de aplicación en Cisco APIC:

Arquitectura de la aplicación

Direccionamiento y enrutamiento

Funcionalidad de seguridad (por ejemplo, protocolos y puertos utilizados)

Esto significa que un análisis exhaustivo del entorno existente debe preceder a otros pasos

de diseño de aplicación para proporcionar un conjunto confiable de información que

describe las aplicaciones migradas. Puede completar este análisis utilizando cualquiera de

varias formas, como inspeccionar configuraciones en ejecución de dispositivos para

determinar aplicaciones, dispositivos, relaciones, reglas de conectividad, etc.

Interacción de ACI con conexiones y redes externas de capa 2

Para crear una red básica de Capa 2 en el ACI, sin ningún enrutamiento de Capa 3,

simplemente necesita comenzar con los conceptos básicos. En primer lugar, considere la

posibilidad de crear uno o más dominios de puente y EPG. A continuación, puede decidir si

368

desea configurar los dominios de puente para el modo de proxy de hardware o para el

modo de inundación y aprendizaje basados en la comunicación.

Nota Al crear cualquier configuración o diseño en el ACI de Cisco, para que los objetos se

instancien y, como resultado, se programen en el hardware, deben cumplir los requisitos

del modelo de objetos. En otras palabras, si falta una referencia, el objeto no será

instanciado.

En el modelo de objeto ACI de Cisco, el dominio de puente es un elemento secundario de la

instancia de VRF. Por lo tanto, incluso si necesita una red de capa 2, todavía necesita crear

una instancia de VRF y asociar el dominio de puente con esa instancia de VRF.

Dicho esto, este enfoque no significa que la configuración consume recursos de hardware

VRF. De hecho, si no habilita el enrutamiento, no se asignarán recursos de VRF en

hardware.

Los siguientes pasos son necesarios para crear una red de capa 2 simple en el Cisco ACI:

1. Cree una instancia de VRF.

2. Cree un dominio de puente (sin habilitar enrutamiento de unidifusión) y asocie el

dominio de puente con la instancia de VRF. Además, el dominio de puente no debe

proporcionarse con una dirección IP de subred (dirección IP SVI).

3. Configure el dominio de puente para la conmutación optimizada (también llamada

modo de proxy de hardware, es decir, utilizando la base de datos de asignación) o

el comportamiento tradicional de inundación y aprendizaje (si hay hosts

silenciosos).

4. Cree un EPG y asegúrese de que tienen una relación con un dominio de puente.

(Los EPG y el dominio del puente no tienen una relación uno a uno, puede tener

múltiples EPG en el mismo dominio del puente).

5. Crear contratos entre EPGs según sea necesario. Si desea que todos los EPG puedan

hablar entre sí sin filtrar, puede configurar la instancia de VRF como no aplicada.

6. Cree políticas de acceso y de conmutador (perfiles) para asignar los parámetros y

las VLAN deseados a los conmutadores y puertos de hoja de acceso.

Nota Al extender un dominio puenteado de Capa 2 a un dominio de Capa 2 externo en

escenarios de migración en los que la puerta de enlace predeterminada de Capa 3 todavía

puede residir en la red externa, debe considerar los siguientes parámetros al crear el

dominio de puente BD en ACI:

Habilitar la inundación de la unidifusión desconocida de Capa 2.

Habilitar la inundación de ARP.

Deshabilitar el enrutamiento unidireccional (se puede habilitar más adelante

cuando se completa la migración y los extremos usarán el ACI para la puerta de

enlace predeterminada de Nivel 3).

369

Las siguientes secciones cubren cómo extender un dominio de Capa 2 creado utilizando

los pasos anteriores fuera del tejido ACI que pueden ser necesarios para lograr cualquiera

o todos los siguientes requisitos de conectividad:

1. Conecte la carga de trabajo física a ACI.

2. Conecte las plataformas de hipervisor que funcionan sin integración con APIC.

3. Conecte la red heredada a ACI (podría ser una red basada en STP o vPC).

4. Extender un BD / EPG para admitir la Interconexión del Centro de Datos de Capa 2

(DCI).

Conexión de ACI al dominio de la capa externa 2

Esta sección cubre los dos métodos principales para extender el dominio de inundación de

Capa 2 del tejido ACI a una red externa tal como una red heredada existente durante la

fase de migración o para soportar un DCI de interconexión de centro de datos de Capa 2

utilizando VLAN peering.

Ampliación de la EPG existente

Para ampliar una EPG existente, debe asignar manualmente un puerto a una VLAN. A su

vez, se asigna a una EPG, para extender una EPG existente más allá del tejido ACI bajo el

mismo dominio de puente y el único grupo de políticas (EPG).

370

Conexión externa de capa 2 (L2Out)

La opción L2Out también proporciona la extensión de Capa 2 desde el tejido ACI a una red

puente externa. A diferencia de la opción anterior, esta opción está diseñada

específicamente para proporcionar conectividad a redes puenteadas externas. El operador

de red necesita definir un grupo de terminales externo separado bajo la "red puente

externa". Entonces se puede definir un contrato para permitir la comunicación entre el

EPG interno (cualquier EPG definido en el perfil de aplicación que necesite utilizar la capa

externa 2 exterior Conexión) y la EPG externa.

Nota Aunque ambas opciones descritas aquí usan el mismo dominio de puente para

conectar entidades externas de Capa 2 como puntos de extremo conectados directamente,

la opción L2Out coloca puntos de extremo externos bajo EPGs externos, que ofrecen un

control de políticas más granular porque se aplicarán políticas entre el EPG interno y el

externo. Además, la inundación entre los dos dominios se contendrá porque la capa 2 de

inundación no está permitido, por defecto, entre diferentes EPGs en el Cisco ACI.

Integración ACI con LAN de capa basada en STP

Aunque el tejido Cisco ACI no ejecuta el protocolo Spanning-Tree de forma nativa, envía

BPDU entre puertos dentro de un EPG. Por ejemplo, en los escenarios ilustrados en la

Figura, los conmutadores A y B están conectados a un puerto diferente en un interruptor

de hoja ACI diferente; Sin embargo, estos puertos residen en el mismo EPG de la capa

externa 2 fuera del EPG. En este escenario, el tejido ACI inunda las tramas BPDU dentro

del mismo EPG. Con este comportamiento, los conmutadores A y B actuarán como si

371

estuvieran conectados directamente entre sí (el ACI aparecerá como un transporte de

capa 2). Como resultado, el segmento entre el conmutador B y el tejido ACI está

bloqueado. Esto significa que los dispositivos externos pueden aprovechar STP / BPDU

para evitar cualquier posible bucle capa 2. Además, ACI ofrece otros mecanismos de

protección contra bucles externos, como los siguientes:

El protocolo de detección de capa de enlace (LLDP) detecta los cables de bucle

directo entre dos conmutadores de la misma estructura.

MCP (Mis-Cabling Protocol) es un nuevo paquete de bucle de nivel de enlace que

detecta un bucle de reenvío externo de Capa 2.

Además, con este comportamiento, habrá solo reenvío de hardware y no habrá interacción

con la CPU en los conmutadores de hoja o de columna para las tramas BPDU estándar.

Esto protege la CPU contra cualquier inundación de capa 2 que se produzca externamente.

ENRUTAMIENTO ACI

La tela ACI desacopla la dirección del punto final del inquilino, su "identificador", desde la

ubicación de ese punto extremo que está definido por su "localizador" o dirección VTEP.

Por lo tanto, el reenvío dentro del tejido es entre VTEPs y los VTEPs realizan la asignación

interna de MAC o dirección IP de inquilino a la ubicación utilizando el concepto de base de

datos de mapeo distribuido.

372

Esta capacidad permite que el tejido ACI admita la semántica completa de reenvío de Capa

2 y Capa 3, donde no se requieren cambios en las aplicaciones ni en las pilas IP de punto

final.

Puerta de acceso predeterminada de capa 1 de primer nivel en

ACI

Con el ACI, los operadores de red y los diseñadores no necesitan preocuparse por

considerar protocolos adicionales para proporcionar servicios de puerta de enlace de

nivel 3 como HSRP porque el Cisco ACI ofrece lo que se conoce como "Pervasive SVI", que

proporciona una distribución de puerta enlace predeterminada. Esta puerta de enlace de

Anycast es global a través del tejido y configurada en la parte superior de los

conmutadores de hoja de rack (ToR) donde quiera que esté presente el dominio de puente

de un inquilino. Además, las direcciones de puerta de enlace por defecto de subred están

programadas en todas las hojas con puntos finales presentes para la subred IP del

inquilino específico. Esto no sólo ayuda a reducir el diseño y la complejidad de la

operación, sino que también ayuda en gran medida a optimizar el reenvío de tráfico a

través del tejido ACI. Cuando un paquete necesita ser enrutado a otra hoja o red externa,

no tiene que abarcar la red para alcanzar su puerta de enlace predeterminada que podría

residir en otra hoja.

Dicho esto, el ACI sigue soportando la puerta externa, que se utiliza comúnmente cuando

el tejido se implementa para proporcionar transporte de capa 2 sólo a un inquilino

373

específico o si las normas de seguridad de la organización requieren que la puerta de

enlace predeterminada sea un firewall.

Hojas de la frontera

Las hojas fronterizas son nodos de hoja ACI que proporcionan conexiones de capa 3 al

exterior (Una red externa puede ser una red enrutada de Capa 3 como WAN/Internet o

capa 2 como Data Center Interconnect). Cualquier nodo hoja ACI se puede utilizar como un

nodo hoja frontera. No hay limitación al número de conmutadores de hoja que puede

utilizar como hojas de borde. El número depende de la escala de red, el número de

conexiones externas y redundantes, y así sucesivamente. La hoja de la frontera también se

puede utilizar para conectarse a computación, almacenamiento IP y dispositivos de

servicio. En los escenarios de diseño a gran escala, puede preferirse que los conmutadores

de hoja de borde separados de las hojas se conecten a los aparatos de computación y de

servicio por razones de escalabilidad. En este caso, estas hojas fronterizas se denominan

hojas de servicio para distinguirlas de las hojas fronterizas que conectan el ACI a la red

externa. Tanto los nodos hoja de servicio como los nodos hoja de borde realizan la misma

función, que proporciona conectividad a nodos o redes externas.

374

Nota Al igual que cualquier nodo de red típico, los conmutadores de hoja de borde

admiten los siguientes tipos de interfaz para conectarse a redes externas:

Interfaz de capa 3 (enrutado): Se utiliza cuando se conecta a dispositivos

externos dedicados por inquilino / VRF.

Subinterfaz con etiquetado 802.1Q: Se utiliza cuando se conecta a dispositivos

externos compartidos a través de inquilinos / VRF (VRF-Lite).

Interfaz virtual conmutada (SVI): se utiliza cuando se conecta a dispositivos que

requieren una conectividad de capa 2 entre dispositivos. Se utiliza cuando se

requieren conexiones de Capa 3 y Capa 2 en la misma interfaz.

375

Propagación de ruta dentro de la Tela ACI

Dentro del tejido ACI, se utiliza Multiprotocolo BGP (MP-BGP) entre los conmutadores

hoja y espina para propagar rutas externas dentro del tejido ACI. Además, la tecnología de

reflector de ruta BGP está habilitada en los conmutadores de columna para soportar un

gran número de conmutadores de hoja dentro de un solo tejido. Con esta arquitectura,

todos los conmutadores de hojas y espinas están en un único sistema autónomo BGP (AS).

El uso de MP-BGP facilita la propagación de rutas de diferentes redes de inquilinos sin

agregar complejidad de plano de control (no se requieren instancias de enrutamiento

diferentes a través del tejido ACI). En consecuencia, cuando el nodo de hoja de frontera

aprende las rutas externas, puede redistribuir las rutas externas de un VRF dado a una

familia de direcciones MP BGP VPN versión 4 (o VPN versión 6). Con la familia de

direcciones VPN versión 4, MP-BGP mantiene una tabla de enrutamiento BGP separada

para cada VRF. Dentro de MP-BGP, la hoja de la frontera anuncia las rutas a un

conmutador de la espina dorsal, que es un reflector de la ruta de BGP. Las rutas se

propagan entonces a todas las hojas donde se instancian los VRF (o red privada en la

terminología de la GUI de APIC).

Nota Las versiones recientes de Cisco ACI admiten el tejido ACI para que actúe como una

red de tránsito entre diferentes conexiones L3Out, pero es posible que necesite configurar

376

una "política de control de rutas de exportación" para el prefijo de tránsito para permitir

que el tejido ACI lo anuncie a través de Otra conexión L3Out.

Nota MP-BGP no está habilitado, por defecto, en el tejido ACI. Para un escenario de

despliegue en el que se utiliza el tejido ACI como tejido de capa 2 o no se necesita una

conexión externa de capa 3, MP-BGP no es necesario. Para habilitar MP-BGP, configure la

política BGP en el APIC para especificar el BGP ASN y especifique los nodos de espina

como reflectores de ruta BGP. Después de configurar estos dos, el APIC se hará cargo del

resto, como la configuración de IBGP peering entre la hoja y la columna vertebral, y la

especificación de hojas como clientes del reflector de ruta. También generará

automáticamente la configuración requerida para la redistribución de rutas en la hoja de

borde.

Conexión de los dominios de la capa ACI a la capa externa 3

ACI le permite definir una conexión L2Out para proporcionar conectividad con una red

externa usando una interconexión de Nivel 2. En este caso, debe definir un EGP externo

separado para el L2Out y, a continuación, definir un contrato entre cualquier EPG interno

y este EPG externo que requiera la comunicación a través de esta conexión. De manera

similar, la conexión externa de Capa 3 (también conocida como Capa 3 de salida o L3Out)

usa la misma lógica. Sin embargo, se utiliza para proporcionar la conectividad de Capa 3

(enrutada), donde típicamente necesitará tener más configuraciones como una dirección

IP de interfaz (física o SVI) y definir el protocolo de enrutamiento utilizado con el par

externo y sus atributos.

Nota Antes de configurar cualquier conexión enrutada externa de Capa 3, asegúrese de

que el enrutamiento y el MP-BGP estén habilitados. Además, asegúrese de que las políticas

de acceso requeridas se configuran y se aplican al nodo/interfaz de hoja orientada, en el

que puede especificar las ID de VLAN si desea definir SVI de capa 3, . Habilitar MP-BGP en

Cisco ACI es tan simple como seleccionar las espinas que funcionarán como reflectores de

ruta BGP y configurar el número de sistema autónomo (ASN).

De hecho, crear L3Out es una tarea sencilla siempre y cuando entienda los objetos

necesarios y la lógica de construcción de políticas. Para crear un L3Out externo, debe

considerar la siguiente lógica:

1. Crear redes enrutadas externas.

2. Agregar / seleccionar un nodo de hoja de borde de capa 3 para la conexión externa

de capa 3.

3. Agregar / seleccionar un perfil de interfaz de capa 3 para la conexión externa de

capa 3.

377

4. Repetir los pasos 2 y 3 si necesita agregar nodos / interfaces de hojas adicionales.

5. Configurar una EPG externa. El tejido ACI asigna los puntos finales / rutas externos

de la capa 3 al EPG externo mediante el prefijo IP y la máscara. Se puede admitir

uno o más EPG externos para cada conexión externa de Capa 3, dependiendo de si

el usuario desea aplicar una política diferente para diferentes grupos de puntos

finales externos. Puede tratar todos los extremos externos por igual y crear sólo

una EPG externa.

6. Configure un contrato entre el EPG externo y el interno. El modelo de política ACI

requiere un contrato entre los EPG externos e internos. Sin esto, toda la

conectividad con el exterior será bloqueada, incluso si las rutas externas se

aprenden correctamente. Esto es parte del modelo de seguridad de ACI.

Nota Para que una subred en un dominio de puente se anuncie al exterior, asegúrese de

que la configuración siguiente esté establecida: la subred debe estar configurada bajo el

dominio de puente y la EPG y marcada como anunciada externamente (o pública).

Además, debe marcar la subred como compartida si necesita filtrarla a otros VRF.

Integración y migración a las opciones de conectividad ACI

ACI proporciona la flexibilidad para que los entornos existentes del centro de datos se

integren o migren al nuevo tejido utilizando cualquiera de las siguientes opciones

(consulte la Figura):

Migración de hosts ala nuevo tejido

Migración de extensores de tela (FEX) al tejido ACI

Migración de los conmutadores agregadores Cisco Nexus 5x00 y FEX dependientes

a la estructura ACI

La interconexión de todo el centro de datos existente con el tejido ACI (utilizando

L3Out, L2Out o ambos depende de los requisitos de la aplicación y del enfoque de

migración).

378

379

380

Capítulo 14

Conexiones en el

Centro de Datos

381

La comunicación de servidor a servidor, los clústeres de alta disponibilidad, la conexión en

red y la seguridad pueden requerir la conectividad de Capa 2 mantenida a través de

diferentes conmutadores de capa de acceso. En muchos casos, la funcionalidad de la capa

2 debe extenderse más allá de un único centro de datos, particularmente cuando el marco

de un campus se extiende más allá de su geografía original, abarcando múltiples centros

de datos de larga distancia. Cisco recomienda aislar y reducir las redes de capa 2 a su

diámetro más pequeño, limitado a la capa de acceso.

Los flujos de tráfico entre el centro de datos y los dispositivos externos y la comunicación

entre servicios y aplicaciones dentro de un centro de datos determinan el diseño de la red

del centro de datos, específicamente el Data Center Interconnect (DCI).

FLUJOS DE TRÁFICO DEL CENTRO DE DATOS

Esta sección cubre las diferentes direcciones y tipos de flujos de tráfico en un centro de

datos.

Direcciones del flujo de tráfico

El tráfico del centro de datos fluye en tres direcciones (ver Figura 14-1):

Tráfico Norte-Sur: este tráfico entra o sale del centro de datos y normalmente

fluye entre los clientes que se encuentran fuera del centro de datos y los servidores

en el centro de datos.

382

Tráfico Este-Oeste: este tráfico fluye entre los servidores o dispositivos en el

centro de datos y no sale del centro de datos.

Tráfico entre DC: este tráfico fluye entre múltiples centros de datos a través del

ICD.

Nota Los términos Norte-Sur y Este-Oeste describen las direcciones de flujo de tráfico

basadas en un esquema de topología de red en el que el núcleo está situado en la parte

superior (norte) y los servidores en la parte inferior (sur). Además, el tráfico este-oeste

puede abarcar el ICD entre dos centros de datos.

A diferencia de una red de campus, en un típico centro de datos el volumen dominante

atraviesa en dirección este-oeste. El índice Global Cloud de Cisco estima que el 76% del

tráfico global de los centros de datos atraviesa este-oeste, el 17% atraviesa el norte-sur y

el 7% atraviesa los centros de datos.

El volumen y la dirección del tráfico dictan no sólo la sobresuscripción de una topología de

centro de datos, sino también la posición de un borde de Capa 2 o Capa 3. El fuerte tráfico

norte-sur prefiere un pequeño dominio de Nivel 2 con enrutamiento Inter-VLAN en la

capa de agregación. Sin embargo, el tráfico este-oeste predominante aboga por un gran

dominio de Capa 2 con enrutamiento Inter-VLAN en la capa central.

Nota Como sabrá del capítulo anterior, con el Cisco ACI, tendrá un enrutamiento entre

VLAN más optimizado para los flujos de tráfico inter e intra-DC utilizando el concepto de

una pasarela predeterminada distribuida (Anycast).

Tipos de flujo de tráfico

El tráfico cliente-servidor suele ser el tráfico norte-sur que entra o sale del centro de datos

y fluye entre los clientes que se encuentran fuera del centro de datos y los servidores en el

centro de datos. Sin embargo, el uso de cortafuegos y equilibradores de carga añade un

componente del tráfico este-oeste entre los dispositivos y servidores, como se muestra en

la Figura 14-2. Debe planificar cuidadosamente la sobresuscripción de enlaces entre las

capas núcleo y de agregación para proporcionar suficiente ancho de banda para varios

servidores.

383

El tráfico servidor-servidor suele ser el tráfico este-oeste, que nunca sale del centro de

datos o que a veces está limitado a un solo dominio de la capa 2. Puede fluir directamente

de servidor a servidor, o si hay demandas de seguridad y escalabilidad, los aparatos tales

como firewalls y equilibradores de carga se pueden interponer. El tráfico típico de

servidor-servidor sigue:

384

Migración de la máquina virtual (VM)

Comunicación entre el servidor de aplicaciones y la base de datos (aplicaciones de

nivel)

Replicaciones de estado y de transacciones entre servidores del mismo clúster, etc.

Cuando el tráfico servidor-servidor fluye entre servidores en diferentes centros de datos,

atraviesa el DCI. Debe adaptar cuidadosamente el tráfico Inter-DCI porque la capacidad

del enlace DCI suele tener magnitudes inferiores a la capacidad disponible en el centro de

datos.

El tercer tipo de tráfico en los centros de datos modernos es el tráfico de almacenamiento.

NFS, iSCSI, FCoE y otros protocolos de almacenamiento utilizan la red existente del centro

de datos para su tráfico. Hay tres tipos de tráfico de almacenamiento: tráfico de

almacenamiento de servidor, replicación síncrona entre Arrays de almacenamiento y

replicación asíncrona entre matrices de almacenamiento. El tráfico de almacenamiento del

servidor y la replicación síncrona requieren una baja latencia y pueden requerir

mecanismos adicionales como Ethernet sin pérdida o trama Jumbo. Por lo tanto, se

mantienen típicamente dentro de un dominio de la Capa 2, no transitan ningún otro

aparato, y se consideran tráfico de este-oeste, como se muestra en la Figura 14-4.

Nota Ethernet estándar es un medio de mejor esfuerzo, lo que significa que carece de

cualquier forma de control de flujo. Si se producen congestión o colisiones, Ethernet

descarta los paquetes. Un conjunto de tecnologías de red, entre ellas IEEE Data Center

Bridging, permite que los tejidos Ethernet soporten la transmisión sin pérdidas,

haciéndolos adecuados para transportar todo tipo de tráfico SAN.

Cuando se requiere la replicación de almacenamiento entre centros de datos desplazados,

el tráfico de almacenamiento tiene que recorrer el ICD. A menos que los centros de datos

estén convenientemente juntos (100-200 km), la capacidad, la latencia y la confiabilidad

del DCI no son adecuadas para la replicación sincrónica; Por lo tanto, la replicación

asíncrona es más comúnmente utilizada en DCI.

385

Con la replicación síncrona, todos los datos comprometidos en la primera matriz de

almacenamiento se sincronizan con la segunda matriz de almacenamiento, antes de que el

servidor obtenga un reconocimiento de que se han confirmado los datos. Con la

replicación asíncrona, los compromisos en la primera matriz de almacenamiento se

colocan en la cola y se envían a la segunda matriz de almacenamiento cuando es posible,

dando como resultado una pérdida de datos potencial si falla la primera matriz de

almacenamiento.

Nota Durante la planificación de la replicación de almacenamiento a través de un ICD, los

arquitectos de red deben considerar dos factores importantes:

Recover and Point Objective (RPO): Es la cantidad de pérdida de datos que se

considera aceptable, definida por la aplicación, si ocurre una interrupción. RPO

puede variar desde cero pérdida de datos hasta minutos u horas de pérdida de

datos, dependiendo de la criticidad de la aplicación o datos. Por ejemplo, la

replicación de datos síncronos es capaz de ofrecer RPO de pérdida de datos de baja

a cero; Sin embargo, puede ser una opción costosa con limitaciones de distancia

debido a sus requerimientos de alto ancho de banda y baja latencia.

Objetivo de tiempo de recuperación (RTO): es la cantidad de tiempo que se

necesita para recuperar los procesos de negocio críticos para los usuarios desde la

interrupción inicial, que van desde cero a muchos minutos u horas.

Idealmente, el nivel de criticidad de una aplicación de negocio debe definir la RPO

aceptable y la meta RTO si se produce una interrupción planificada o no planificada.

LA NECESIDAD DE ICD

Las empresas de hoy en día dependen en gran medida de la tecnología para facilitar el

logro de sus objetivos de negocio. Por lo tanto, la disponibilidad de aplicaciones críticas de

negocio y soluciones tecnológicas es clave para que cualquier negocio continúe su

operación y tenga éxito. En consecuencia, la continuidad del negocio es un requisito

fundamental para los negocios de hoy. La continuidad de negocio (BC), también conocida

como planificación de continuidad de negocio (BCP), tiene como objetivo construir un

plan estándar para mantener intactas las operaciones del negocio durante y después de

cualquier escenario de falla. El BCP es un requisito fundamental para algunas

organizaciones que no pueden tolerar ninguna interrupción del servicio, como la atención

médica, los servicios financieros y los minoristas en línea. Típicamente, esto es impulsado

por un costo enorme causado por cualquier interrupción simple o por los servicios

proporcionados críticos, tales como servicios de cuidado médico, que no pueden aceptar

386

ningún tiempo de inactividad. La recuperación de desastres es uno de los mecanismos que

ayuda a lograr BC por tener un componente redundante que se puede utilizar en

escenarios de fallo, como la recuperación de un servidor fallido que utiliza un servidor

redundante que se puede ubicar en la misma ubicación física o en una ubicación diferente.

El despliegue de centros de datos geográficamente dispersos permite al diseñador del

centro de datos implementar mecanismos efectivos de prevención y recuperación de

desastres que aumentan la disponibilidad de las aplicaciones. La dispersión geográfica

también permite optimizar la respuesta de la aplicación a través de una mejor colocación

de la instalación y la movilidad de las cargas de trabajo a través de los centros de datos

para evitar hotspots de la demanda y utiliza completamente la capacidad disponible.

Para habilitar todos los beneficios de los centros de datos dispersos geográficamente,

pueden ser necesarios diferentes tipos de comunicación entre los centros de datos:

La VM típica y la movilidad de direcciones IP requieren la Capa 2 DCI. Sin embargo,

este objetivo también es alcanzable sobre la capa 3 DCI utilizando tecnologías

avanzadas como LISP.

La replicación de transacciones de un clúster de bases de datos o de la

sincronización de aplicaciones de un clúster de aplicaciones requiere una

comunicación de capa 3 a través de un DCI (algunas aplicaciones heredadas pueden

necesitar la capa 2).

Los requisitos de replicación de almacenamiento varían en función del protocolo

de almacenamiento utilizado. FC requiere Capa 1 DCI (fibra óptica), FCoE Capa 2

DCI, iSCSI Capa 3 DCI, y así sucesivamente.

387

MOVILIDAD DE DIRECCIONES IP

Como se mencionó anteriormente, la capa 2 DCI permite movilidad simple de direcciones

IP y VM. Sin embargo, algunas implicaciones con este diseño deben ser consideradas. Por

ejemplo, vea el servidor virtual en el centro de datos del sitio A con la IP pública

203.0.113.100. El tráfico deja la VLAN local a través de la pasarela 203.0.113.1 y se envía a

través de la capa central y sale a Internet.

Cuando la VM se migra al centro de datos del sitio B, mantiene su dirección IP y sigue

perteneciendo a la misma VLAN. Su gateway, sin embargo, permanece en el Sitio A y la red

IP a la que pertenece aún se anuncia en Internet desde el Sitio A. El tráfico de VLAN es así

reenviado desde el Sitio B a través de la Capa 2 DCI al Sitio A y luego redireccionado a

Internet, Como se muestra en la Figura 14-7.

388

Como diseñador de red que propone un diseño como éste, debe preguntarse: "¿Qué sucede

cuando falla el DCI?" La puerta de enlace predeterminada de VM está ahora inaccesible.

Aunque se podría solucionar este problema utilizando FHRP con puertas de enlace

predeterminadas en ambos sitios, todavía hay una cuestión de tráfico de devolución

porque el BGP todavía anuncia la subred desde el sitio A. Algunos de los servidores de la

misma subred todavía podrían estar ejecutándose en el sitio A, Como se muestra en la

Figura, por lo que la publicidad BGP de la misma red desde el Sitio B no es una solución y

puede causar el problema del cerebro dividido. Esto ocurre cuando los servidores de

diferentes centros de datos sirven el contenido a diferentes partes de Internet sin

sincronización entre sí mientras el DCI está inactivo. El cerebro partido puede conducir a

la inconsistencia del estado ya la corrupción de los datos.

389

Otro problema se produce con la migración de VM. La Figura 14-9 muestra dos máquinas

virtuales que tienen sus puertas de enlace predeterminadas en otro centro de datos.

Cuando una VM en el Sitio B se comunica con una VM en el Sitio A, su tráfico va desde el

Sitio B a través del DCI al Sitio A, hasta su puerta de enlace predeterminada. La puerta de

enlace predeterminada reenvía el tráfico a través del DCI al sitio B basado en la entrada de

la tabla de enrutamiento. La puerta de enlace predeterminada de VLAN 20 en el sitio B

acepta el tráfico y, en base a su tabla de memoria de direcciones de contenido (CAM), la

envía a través de la VLAN 20 de vuelta al servidor ubicado en el sitio A.

390

En este peor de los casos, el tráfico debe recorrer el DCI tres veces antes de llegar a su

destino de acogida; Este efecto se denomina trombón de tráfico, que ocurre cuando un

flujo de tráfico único atraviesa el DCI. Si tiene un gran volumen de tráfico que atraviesa el

DCI que interconecta dos centros de datos ubicados en diferentes ubicaciones geográficas,

esto puede reducir el rendimiento de la aplicación y, en última instancia, afectará la

experiencia del usuario.

La cuestión de la movilidad IP no es fácilmente solucionable porque la dirección IP

expresa dos elementos de información en una sola dirección: la identidad del dispositivo y

la posición del dispositivo en la red. Existen varias iniciativas que separan esas dos piezas

de información en dos espacios de direccionamiento separados -por ejemplo, la

sensibilización a la movilidad LISP IP/host-level, como se ilustra en la Figura.

Los pasos mostrados en la Figura 14-10 se resumen aquí:

391

1. El enrutador de Ingreso de túnel (ITR) consulta el directorio para obtener el RLOC

(Ruta de localización) para el ID de punto final de destino (EID).

2. El ITR IP-en-IP encapsula el tráfico para enviarlo a la dirección RLOC.

3. Los enrutadores de salida del túnel (ETR) reciben y decapsulan el tráfico.

Hasta el paso 3, el tráfico se dirige al DC local (hogar) donde se encuentra el VM /

host; Los pasos siguientes describen el manejo del tráfico cuando una VM se

desplaza al DC secundario (remoto).

4. La VM con IP 10.10.10.1 se mueve a la segunda DC (DC B).

5. El ETR actualiza el DB de mapeo o el RLOC para mapear el host VM IP / 23

10.10.10.1/32 para apuntar a nodos / xTR C y D en DC B.

6. Las nuevas sesiones destinadas al host con IP 10.10.10.1 serán encaminadas a DC

B.

7. Los ETRs reciben y decapsulan el tráfico.

Usted debe centrarse no sólo en la optimización del flujo de tráfico de entrada, pero para

la dirección de salida de tráfico, también es necesario lograr la localización FHRP. Por

ejemplo, es necesario filtrar los mensajes HSRP a través del DCI de capa 2 para garantizar

el enrutamiento simétrico de los flujos de tráfico entrante y saliente después de la

migración de VM o de host.) Por lo tanto, en este escenario, las direcciones MAC (vMAC)

(VIP, por sus siglas en inglés) en ambos centros de datos debería ser consistente, ya que la

carga de trabajo móvil probablemente continuará enviando paquetes a la misma dirección

IP GW después de completar el evento de movilidad en vivo. La coherencia MAC virtual se

392

logra generalmente en el modo de subred extendido configurando el mismo grupo de

HSRP asociado con la misma subred en sitios separados del centro de datos. Además,

normalmente se configura el filtrado HSRP, aprovechando ACL para desactivar Hellos y

evitar el intercambio a través de la conexión de extensión LAN.

Nota Con LISP, los sitios remotos o la puerta de enlace de borde que interactúan con sitios

que no son LISP (también conocidos como enrutadores de túnel Proxy) deben tener la

capacidad LISP para que LISP funcione como se esperaba.

Estirar el clúster de servidores de alta disponibilidad con movilidad de VM a través de

múltiples centros de datos podría no ser una buena idea debido al aumento de los

dominios de inundación de capa 2. Debe utilizar un segundo centro de datos como un DRC

en su lugar. Sin embargo, esto no siempre es una elección de ingeniero de red. Por

ejemplo:

Las aplicaciones que requieren la conectividad de Capa 2 seguirán necesitando una

extensión de LAN (agrupación de Capa 2, etc.).

El tráfico de las aplicaciones heredadas puede no ser enrutable, por lo que todavía

necesitará utilizar la LAN para extenderse a través de las DC.

Además, debe comprender que al considerar la movilidad de IP o de host con LAN

extendida sobre DCI (Layer 2 DCI), se presentan los siguientes desafíos para el tráfico de

entrada:

Las subredes se distribuyen por las ubicaciones.

La información de subred en las tablas de enrutamiento no es lo suficientemente

específica.

El enrutamiento no sabe si un servidor se ha movido entre ubicaciones.

El tráfico puede ser enviado a la ubicación en la que la aplicación no está

disponible.

Para mitigar o superar los desafíos, considere una de las siguientes opciones para el ICD

cuando sea posible:

DCI de capa 3 con redirección de DNS (esta opción funciona para aplicaciones que

se pueden llamar por nombre)

Capa 2 o Capa 3 DCI con LISP (enrutamiento basado en host)

Anuncio de DCI de Capa 3 con las rutas de Anycast (este concepto se trata más

adelante en la sección "Capa 3 DCI")

ESTUDIO DE CASO: DARK FIBER DCI

393

La fibra oscura puede considerarse un tipo de servicio de Capa 1. Es popular entre muchos

clientes hoy en día, ya que permite el transporte de varios tipos de tráfico, Ethernet nativo,

IP y MPLS, incluido el tráfico SAN. Tiende a ser caro, especialmente a medida que aumenta

el número de sitios. La fibra oscura se utiliza comúnmente para construir redes de

multiplexores de división de longitud de onda (el más comúnmente Dense Wavelength

Division Multiplexer Device, o DWDM), que abarca la capa 2 Ethernet a través de

distancias de MAN hasta 100 km, proporcionando la capa 2 DCI.

Nota El término fibra oscura se refiere a la capacidad de fibra que se instala pero no se usa

(es decir, no se ilumina); Por lo tanto, está disponible para arrendamiento.

Nota WDM es una tecnología que multiplexa una serie de señales portadoras ópticas sobre

una única fibra óptica utilizando diferentes longitudes de onda de luz láser. WDM

proporciona la capa de medios para iniciar las diversas capas físicas punto a punto

(construidas a partir de cada longitud de onda disponible del enlace óptico). Hay dos tipos

comunes de WDM:

CWDM: El multiplexado por división de longitud de onda gruesa se puede utilizar

con sistemas WDM que necesitan menos de ocho longitudes de onda activas por

fibra.

DWDM: El multiplexado de división de longitud de onda densa se puede utilizar

con sistemas WDM con más de ocho longitudes de onda activas por fibra. Puede

proporcionar hasta 96 longitudes de onda DWDM sobre un solo par de fibras.

En este estudio de caso, su empresa tiene dos centros de datos. Es necesario establecer un

ICD punto a punto. Un enlace DWDM de fibra oscura está disponible entre los dos sitios, lo

que le permite iniciar múltiples conexiones de capa 2. Como diseñador de la red, usted

necesita pensar primero acerca de la siguiente pregunta: "¿Qué capa (s) de centro de datos

se debe colocar la interconexión de CC y cómo?" (Vea la Figura 14-11).

394

Aunque puede utilizar los conmutadores de acceso o de capa de agregación para extender

su LAN entre dos sitios, se recomienda interconectar los centros de datos sobre una fibra

oscura utilizando las capas de agregación de cada DC.

Para lograrlo, debe conectar un conmutador de agregación en el sitio A con el conmutador

de agregación en el sitio B y el otro conmutador de agregación en el sitio A con otro

conmutador de agregación en el sitio B. Para excluir cualquier bucle de capa 2, agrupe los

dos enlaces en un Multichassis EtherChannel (MEC) y unirse a los conmutadores de

agregación en ambos sitios con vPC / VSS. Este enfoque soporta una red de capa 2

totalmente redundante de extremo a extremo sin necesidad de STP, como se ilustra en la

figura. Sin embargo, debe mantener STP habilitado como último recurso en caso de

errores de software o cable o cable.

395

Ahora suponga que el número de centros de datos que necesita para interconectar

aumenta. Cuatro centros de datos remotos están interconectados utilizando un anillo

DWDM. DWDM proporciona la capa de medios para iniciar las diversas capas físicas punto

a punto. ¿Cómo conectará los cuatro centros de datos con una topología de capa 2 sin

bucles?

Una topología de estrella lógica ofrece una interconexión escalable y sin bucles para todos

los centros de datos. En este modelo de diseño, debe establecer un núcleo de capa 2 con

conmutadores redundantes agrupados mediante vPC / VSS para permitir MEC entre la

capa de agregación de cada DC y el nuevo núcleo de capa 2, como se muestra en la figura.

Sin embargo, el núcleo de la capa 2 debe colocarse en uno de los sitios existentes. ¿Dónde

396

ubicarás los switches redundantes de la capa 2 para lograr la mejor escalabilidad,

redundancia y menor latencia?

Nota Si está utilizando la arquitectura Clos en su DC, debe utilizar los nodos hoja de borde

para conectar los enlaces DCI.

Un punto crucial de la arquitectura es que usted separa los switches físicos que

comprenden el núcleo de la capa 2 en sitios remotos diferentes, ofreciendo así alta

disponibilidad. En consecuencia, es necesario establecer una conexión lógica punto a

punto entre los switches de núcleo de capa 2 que utilizan DWDM y agruparlos con vPC /

VSS, como se muestra en la figura 14-15.

397

Las conexiones lógicas punto a punto se establecen para producir una topología de estrella

virtual con el núcleo de capa 2 como el concentrador y la agregación de pares como los

radios. Uno de los conmutadores de agregación en el sitio A está conectado al conmutador

del núcleo A de la capa 2 utilizando el enlace local. El otro conmutador de agregación en el

sitio A está conectado al conmutador de núcleo B de capa 2 en el sitio B, utilizando uno de

los vínculos punto a punto DWDM disponibles creados entre los sitios A y B. Los sitios B, C

y D están configurados en una manera similar.

La aplicación de esta misma metodología de interconexión a todos los sitios produce un

diseño altamente flexible. La única limitación es el número máximo de enlaces

ascendentes disponibles desde el núcleo de Capa 2 y el número máximo de longitudes de

onda disponibles desde el anillo DWDM. Además, cuanto más se extienda un dominio de

capa 2, mayor será el dominio de inundación en diferentes ubicaciones de CC, lo que

puede conducir a un mayor grado de inestabilidad (tormentas de capa 2) y un

enrutamiento subóptimo.

PSEUDOWIRE DCI

La fibra oscura es un modelo de conectividad costoso, puede no estar disponible en el sitio

(limitación de la distribución geográfica) y tiene sus límites de rango (escalabilidad). Los

proveedores de servicios actuales (como Carrier Ethernet) suelen ofrecer un servicio

398

menos costoso: pseudowires. Pseudowire es una emulación de una conexión punto a

punto a través de una red de conmutación de paquetes. Ethernet sobre MPLS (EoMPLS) es

un servicio pseudowire típico de proveedor de servicios que ofrece una conexión Ethernet

punto a punto. Cualquier tráfico de nivel 2 de entrada en una ubicación será transportado

y entregado a la ubicación remota como está, ya sea datos o un paquete de control.

Cuando se interconectan dos centros de datos, la mejor práctica es agrupar dos

pseudowires Ethernet y deshabilitar STP entre las ubicaciones para contener cambios de

topología STP dentro de la ubicación.

Servicio de LAN privada virtual DCI

El Servicio de Red Privada Virtual (VPLS) es una clase de VPN que soporta la conexión de

múltiples sitios en un solo dominio puenteado a través de una red IP o MPLS

administrada. VPLS presenta una interfaz Ethernet a los clientes, mientras que la red de

proveedores de servicios actúa como una LAN conmutada.

Debido a que el par de conmutadores VSS / vPC ahora se conecta a la red VPLS que emula

un puente Ethernet IEEE, el uso de EtherChannel ya no es posible. Los bucles de capa 2 en

la red necesitan ser resueltos con el uso de STP. La introducción de STP en DCI no sólo

bloquea algunos de los enlaces redundantes, sino que también extiende el dominio STP a

través del DCI. Esta acción es indeseable porque inunda BPDUs a través de DCI, lo que

resulta en puente de reenvío flush table en el sitio B cuando los cambios de topología

ocurren en el sitio A, y así sucesivamente.

Advanced VPLS (A-VPLS) es la mejora de Cisco de la solución VPN VPLS de capa 2

existente. Extiende el concepto MEC a la red VPLS, permitiendo el uso de MEC en enlaces

redundantes a través de la red VPLS, siempre y cuando los switches en el sitio del cliente

399

estén en VSS / vPC. La Figura muestra los modelos clásicos de conectividad VPLS y A-VPLS

desde una perspectiva DCI. La característica VPN A-VPLS de Cisco Layer 2 introduce las

siguientes mejoras en VPLS:

Capacidad para balancear la carga del tráfico a través de múltiples interfaces de

núcleo utilizando ECMP (multipathing de coste igual), mientras que el VPLS típico

no puede soportar circuitos / rutas de conexión activos / activos

Mejoras en la interfaz de línea de comandos (CLI) para facilitar la configuración de

la función L2VPN A-VPLS

Compatibilidad con switches redundantes Cisco Data Center Interconnect (DCI) y

proveedores

Modelos de implementación DCI de capa 2 gestionados por el

cliente

Las secciones anteriores cubrieron las diferentes opciones posibles de DCI basadas en

L2VPN, incluyendo pseudowire y VPLS. El modelo cubierto en estas secciones se basa en el

hecho de que el proveedor de servicios (por ejemplo, Carrier Ethernet) es responsable de

aprovisionar el modelo de conectividad de Capa 2 requerido al cliente con fines de DCI, ya

sea punto a punto o multipunto, A-multipunto. Sin embargo, en algunos escenarios, los

clientes empresariales tienen su propia red enrutada WAN / MAN administrada y

necesitan superponer una tecnología DCI de capa 2 utilizando cualquiera de las

tecnologías discutidas en este capítulo. La Figura muestra estos dos modelos de

aprovisionamiento diferentes.

400

Cualquier transporte sobre MPLS sobre GRE

Cuando los proveedores de servicios no proporcionan servicios VPN de Nivel 2 o cuando

DCI necesita establecerse sobre un núcleo de empresa IP existente, EoMPLS y VPLS no se

pueden utilizar de forma nativa. Debe crear una superposición para interconectar

lógicamente los dispositivos empresariales en los diferentes centros de datos y habilitar

MPLS dentro de la superposición / túnel. Por lo general, lograr este resultado mediante el

uso de túneles GRE. El tráfico de EoMPLS o VPLS se encapsula en un túnel GRE,

permitiendo que el tráfico de Nivel 2 fluya sobre un núcleo IP existente. La solución se

llama "cualquier transporte sobre MPLS sobre GRE" (AToMoGRE).

El diseño resultante es idéntico al despliegue sobre la red MPLS del proveedor de

servicios. Este enfoque permite a la empresa construir EoMPLS punto a punto a través de

conexiones entre dos sitios, mientras que estas conexiones se están transportando sobre

el núcleo IP existente, como se ilustra en la Figura 14-19. MPLS no necesita ser desplegado

en la red principal.

401

Si el requisito de la empresa quiere interconectar múltiples sitios de una manera

multipunto, VPLS es la tecnología recomendada. Al igual que EoMPLS, puede ser

transportado por IP utilizando un túnel GRE.

Cuando se interconectan dos centros de datos, la mejor práctica es agrupar dos

pseudowires Ethernet y deshabilitar STP entre las ubicaciones para contener cambios de

topología STP dentro de la ubicación.

Nota También puede crear túneles de capa 2 punto a punto sobre redes IP nativas

mediante L2TPv3.

Implementación de DCI de capa 2 gestionada por el cliente

A diferencia de AToMoGRE, en algunos escenarios, el cliente empresarial posee el núcleo

WAN / MAN; por lo tanto, es posible habilitar MPLS (si aún no está habilitado) para poder

superponer una tecnología VPN de nivel 2 encima de ella, como pseudowire punto a

punto, VPLS multipunto o A-VPLS. Como aprendiste antes en el "Estudio de caso: Dark

Fiber DCI ", debe casi siempre desplegar fibra oscura DCI en la capa de agregación DC. Por

el contrario, desde una vista de punto de diseño, las tecnologías DCI mencionadas

anteriormente, tales como AToMoGRE, pseudowire y A-VPLS, pueden tener diferentes

modelos de despliegue posibles en los que se puede aplicar la configuración real de DCI

relevante. (Cada modelo utiliza una capa de DC diferente, y cada uno tiene su propio caso

de uso.En otras palabras, no hay una sola mejor práctica que siempre se debe utilizar.) Los

siguientes son los modelos de implementación más comunes:

402

Modelo de despliegue de capa principal: Las instancias pseudowire, VPLS o A-

VPLS se pueden iniciar desde la capa central. Es necesario conectar un enlace

adicional desde la agregación a la capa central, y este enlace debe configurarse

como un enlace troncal. Sólo las VLAN que necesitan ser transportadas a través del

dominio de Capa 3 deben ser permitidas; Todas las demás VLAN deben ser

rechazadas, como se muestra en la Figura 14-20.

Modelo de implementación de capa de agregación: la mayoría de las redes

inician sus límites de capa 3 y capa 2 de la capa de agregación. Con este modelo,

casi nunca tendrá que considerar la posibilidad de agregar ningún enlace adicional

para las VLAN que necesitan ser extendidas sobre el DCI, como se muestra en la

Figura 14-21. Sin embargo, debe asegurarse de que el hardware y el software de la

capa de agregación admiten la tecnología DCI utilizada, como A-VPLS.

403

Nota Si ningún requisito específico o restricción de diseño impone el uso de cualquier otro

modelo de implementación, debe considerar el modelo de implementación de la capa de

agregación debido a su simplicidad en comparación con los otros modelos.

Modelo de despliegue de capa de DCI independiente: se puede crear una capa

independiente para extender el dominio de Capa 2. Este tipo de configuración es

útil en redes de plataforma mixta o redes grandes con múltiples conmutadores de

capa de agregación, como se muestra en la Figura.

Advertencias de la capa 2 DCI

Los mecanismos existentes para la extensión de la conectividad de Capa 2 son menos que

óptimos al abordar los requisitos de conectividad e independencia y presentan muchos

desafíos y limitaciones.

Los siguientes son algunos de los desafíos:

Aprendizaje e inundación de planos de datos: La extensión de dominios de Capa

2 a través de múltiples centros de datos puede hacer que los centros de datos

compartan fallos que normalmente se habrían aislado al interconectar centros de

datos a través de una red IP. Estas fallas se propagan libremente sobre el dominio

de inundación de capa 2 abierto.

El direccionamiento de capa 2 es plano y no jerárquico: las direcciones MAC

identifican hosts; No apuntan a su ubicación. Hace que la solución de problemas de

las grandes topologías de la capa 2 sea un desafío. El direccionamiento de capa 2 no

se puede minimizar, lo que resulta en un crecimiento no controlado de la tabla de

direcciones para todos los dispositivos del dominio de capa 2.

404

Árbol de expansión a través del DCI: si un sitio de cliente es multihomed, STP

debe estar ejecutándose en el núcleo de DCI para evitar bucles de capa 2. Los

enlaces redundantes se bloquean y su ancho de banda se pierde.

Multicast: no hay soporte de replicación de multidifusión nativa. Cuando DCI

consiste en pseudowires múltiples, las tramas multicast se inundan a través de

todos los pseudowires.

Operaciones complejas: Las VPN de Capa 2 pueden proporcionar una

conectividad de Capa 2 extendida entre centros de datos, pero que normalmente

implicará una mezcla de protocolos complejos, aprovisionamiento distribuido y un

modelo de escalado jerárquico operacionalmente intensivo. Un simple protocolo de

superposición con capacidades integradas y provisión de punto a cloud es crucial

para reducir el costo de proporcionar esta conectividad.

Por lo tanto, en general, como arquitecto de red, debe evitar considerar una extensión de

LAN a menos que sea imprescindible para ciertas aplicaciones empresariales críticas. En

este caso, también puede buscar tecnologías avanzadas que optimicen el comportamiento

de la capa 2 DCI, como Overlay Transport Virtualization (OTV). De lo contrario, siempre

debe tratar de utilizar la capa 3 DCI.

DCI de virtualización de transporte superpuesto

Las soluciones AToMoGRE requieren el establecimiento de capas intermedias: MPLS. OTV

es una funcionalidad basada en IP que ha sido diseñada desde cero para proporcionar

capacidades de extensión de Capa 2 sobre cualquier infraestructura de transporte: Capa 2,

Capa 3, MPLS, etc.

Como se muestra en la Figura, el único requisito de la infraestructura de transporte es

proporcionar conectividad IP entre sitios de centros de datos remotos. Además, OTV

proporciona una superposición que permite la conectividad de Capa 2 entre distintos

dominios de Capa 2, manteniendo estos dominios independientes y preservando los

beneficios de aislamiento de fallas, resiliencia y equilibrio de carga de una interconexión

basada en IP.

405

Las tramas Ethernet están encapsuladas directamente en los paquetes IP. No se requieren

capas intermedias.

OTV introduce el concepto de encapsulación dinámica para los flujos de capa 2 que

necesitan ser enviados a ubicaciones remotas. Cada trama Ethernet se encapsula

individualmente en un paquete IP y se entrega a través de la red de transporte. La

encapsulación dinámica elimina la necesidad de establecer pseudowires entre centros de

datos.

Además, OTV introduce el concepto de "enrutamiento MAC". Se usa un protocolo de plano

de control para intercambiar información de accesibilidad MAC entre dispositivos de red

que proporcionan funcionalidad de extensión LAN. Este es un cambio significativo de la

conmutación de capa 2 que aprovecha el aprendizaje de plano de datos, y se justifica por la

necesidad de limitar la inundación de la capa 2 de tráfico a través de la infraestructura de

transporte. Si se desconoce la información de la dirección MAC de destino, el tráfico se

pierde (no se inunda), evitando el desperdicio de un precioso ancho de banda a través de

la WAN.

Los siguientes son los elementos principales que construyen el DCI basado en OTV (ver

Figura14-24):

406

El dispositivo de borde es responsable de realizar toda la funcionalidad OTV.

Las interfaces internas son aquellas interfaces de los dispositivos de borde que se

enfrentan al sitio y llevan al menos una de las VLAN extendidas a través de OTV.

La interfaz de unión es una de las interfaces de enlace ascendente del dispositivo de

borde. Es una interfaz enrutada punto a punto y puede ser una sola interfaz física,

así como un canal de puerto (que tiene una mayor elasticidad).

La interfaz de superposición es una nueva interfaz virtual donde se coloca toda la

configuración OTV; Encapsula las tramas de capa 2 del sitio en unicast IP o

paquetes de multidifusión que se envían a los otros sitios.

La encapsulación de OTV se realiza en dispositivos de borde OTV, que están situados en el

borde del dominio de Capa 2. Cuando el dispositivo de borde OTV en el Sitio A aprende

una nueva dirección MAC en su interfaz interna, a través del aprendizaje tradicional de

Ethernet MAC, el dispositivo de borde OTV crea entonces un mensaje de actualización de

OTV que contiene la información sobre la dirección MAC.

A continuación, envía ese mensaje a través de la red IP a todos los otros dispositivos de

borde OTV. La información de accesibilidad MAC se importa en el CAM del dispositivo de

borde OTV. La única diferencia con una entrada CAM tradicional es que en lugar de

asociarse con una interfaz física, las entradas OTV se refieren a la dirección IP del

dispositivo de borde OTV de origen.

Cuando se recibe una trama de Capa 2 en el dispositivo de borde OTV, se realiza una

búsqueda de Capa 2. Si la información MAC en CAM señala una dirección IP del dispositivo

de borde OTV remoto, en lugar de una interfaz física, la trama Ethernet se encapsula en un

paquete IP y se envía a través de la red IP al dispositivo de borde OTV remoto.

Los siguientes pasos resumen el flujo de tráfico entre dos servidores ubicados en el mismo

segmento LAN a través de dos centros de datos que utilizan OTV como solución DCI. La

407

trama pasa del servidor 1 (MAC 1) en el sitio A al servidor 3 (MAC 3) en el sitio B (consulte

la figura).

1. El servidor 1 envía una trama al servidor 3.

2. La trama capa 2 llega al dispositivo de borde OTV del sitio. Se lleva a cabo una

búsqueda clásica de nivel 2 en la dirección MAC de destino. La dirección MAC de

destino, MAC 3, se puede acceder a través de una dirección IP, lo que indica que

MAC 3 no es un MAC local. El MAC 3 es, de hecho, accesible a través del IP B, que es

la dirección IP de la interfaz de unión del dispositivo de borde OTV en el sitio B.

3. El MAC 3 es accesible a través de IP B. El dispositivo de borde encapsula entonces

el cuadro original en un paquete IP donde IP_SA es IP A y IP_DA es IP B.

4. El paquete encapsulado ahora se pasa al núcleo, que lo entregará a su destino: el

dispositivo de borde OTV en el Sitio B asociado con la dirección IP IP B.

5. El dispositivo de borde OTV en el sitio B con dirección IP B recibe y decapsula el

paquete. Ahora tiene la trama de capa 2 original.

6. Otra búsqueda clásica de la capa 2 se realiza entonces en la trama. MAC 3 es ahora

accesible a través de una interfaz física. En realidad, es un MAC local.

7. La trama de capa 2 se entrega a su servidor de destino.

Nota El protocolo de enrutamiento utilizado para implementar el plano de control OTV es

IS-IS. Se seleccionó porque es un protocolo basado en estándares, diseñado originalmente

con la capacidad de llevar información de direcciones MAC.

OTV proporciona una capacidad integrada multihoming nativa con detección automática,

crítica para aumentar la alta disponibilidad de la solución global. Dos o más dispositivos se

pueden aprovechar en cada centro de datos para proporcionar funcionalidad de extensión

408

de LAN sin correr el riesgo de crear un bucle de extremo a extremo. OTV no requiere STP

extendido a través del ICD.

OTV también proporciona otras optimizaciones. Los dispositivos de borde OTV escuchan

respuestas ARP y señalan enlaces IP a MAC a nodos remotos, reduciendo así las emisiones

ARP. OTV utiliza la multidifusión de IP nativa para ayudar a asegurar una replicación

óptima del tráfico de multidifusión, difusión y señalización.

Nota OTV es actualmente compatible con los routers Cisco Nexus 7000 y Cisco ASR 1000.

Nota Como se muestra en la Figura 14-26, considerar LISP junto con OTV le ayudará a

lograr la localización de entrada y salida con movilidad IP / VM y evitar las limitaciones

estándar de LAN extendida sobre una capa DCI.

409

Overlay Networking DCI

Los protocolos de red de superposición, como VXLAN, están diseñados para abarcar redes

de Capa 2 a través de la red IP subyacente. ¿Pueden utilizarse para proporcionar la ICD de

capa 2?

VXLAN fue diseñado para resolver un problema diferente. Fue diseñado para funcionar

dentro de un solo centro de datos. VXLAN carece del plano de control y se basa en las

direcciones de plano de datos estándar de Capa 2 que aprenden con una inundación

unicast, extendiendo el dominio de falla de Capa 2 a través de múltiples centros de datos.

Debido a la encapsulación MAC-in-IP, VXLAN requiere una MTU de 1600 bytes para

acomodar el encabezado adicional de 24 bits. Mientras que las tramas jumbo son

fácilmente compatibles dentro de un centro de datos, no siempre es el caso en las

conexiones IP entre los centros de datos.

Nota VXLAN no es una tecnología DCI en su estado actual. Debe utilizar otras tecnologías,

como OTV.

Capa 3 DCI

Una interconexión de centro de datos basada en la capa 3 ofrece un diseño más simple y

más predecible en comparación con el ICD de capa 2. Sin embargo, tal como se trató

anteriormente en este capítulo, la elección del diseño siempre debe derivarse de los

requisitos de la capa superior, como las aplicaciones para lograr los objetivos de BC

deseados. Por lo tanto, si la extensión de la capa 2 entre los centros de datos no es un

requisito desde un punto de vista técnico, debe considerar el ICD en ruta o de capa 3 en

este caso porque el enrutado DCI ayudará a evitar varias complejidades de diseño y

operaciones Asociado con el DCI de Capa 2 (como se discutió anteriormente en este

capítulo). Por ejemplo, con el modelo DCI de Capa 3, los dominios de fallo estarán

contenidos dentro de cada sitio (siguiendo el principio de aislamiento de fallas). A su vez,

el modelo proporcionará una solución DCI más estable y fiable. Las siguientes son las

opciones comunes posibles para anunciar las redes de centros de datos cuando se utiliza

DCI de capa 3 (vea la Figura 14-28):

410

Opción 1: Cada sitio tiene su propio rango de IP (un rango completo o dividido). Al

mismo tiempo, cada sitio anuncia el rango de IP del otro sitio (como un resumen de

los rangos de IP de ambos sitios, si esta información es resumible) para fines de

conmutación por error.

Opción 2: Cada sitio tiene su propio rango de IP, y cada DC / sitio sólo se requiere

para proporcionar conectividad a sus recursos locales. (Si un DC falla, no será

accesible a través del DCI, y el ICD aquí se utiliza principalmente para

comunicaciones de servicios internos y de sistemas, como replicación, migración,

etc.).

Opción 3: Cada sitio tiene el mismo rango de IP o un rango de IP diferente (con

NAT en el borde); Sin embargo, el rango de IP anunciado es el mismo de cada sitio.

Este modelo también se conoce como el modelo "Anycast". Con este enfoque, los

sitios de DC funcionarán en modo activo activo y la distribución de carga a través

de los centros de datos se basará en la ubicación geográfica de las fuentes de tráfico

porque el tráfico de la ruta de Internet se mueve de la fuente al DC Sitio (por

ejemplo, la ruta con el número más bajo de saltos). Con este modelo, los usuarios

que intenten acceder a los servicios de DC serán encaminados al sitio DC más

cercano y automáticamente encaminados al siguiente sitio más cercano en caso de

un fallo de CC.

Sin embargo, el enfoque que debe elegir debe basarse en los negocios, las aplicaciones y

los requisitos funcionales de los DC interconectados.

Por ejemplo, la Figura muestra una organización que utiliza el DCI de Capa 3 (utilizando el

modelo de diseño de Opción 2, descrito anteriormente). En este escenario, la selección de

sitio / DC es realizada por primera vez por el selector de sitios global (GSS). Esto se logra

comúnmente basado en DNS en el que el servicio principal o la aplicación se accede a

través del GSS utilizando un solo nombre / URL como www.example.com, y cada sitio

tiene su propio equilibrador de carga local con su propia dirección IP virtual (VIP) Que

apunta a los recursos locales del sitio / DC. Con este enfoque, esta organización puede

lograr centros de datos activos-activos interconectados. Como se describió anteriormente,

411

con este modelo de diseño (opción 2), el DCI se utiliza únicamente para comunicaciones

de servicios de centro de datos, como la replicación de datos. En caso de cualquier fallo en

el sitio DC, el GSS dirigirá todo el tráfico al sitio DC restante solamente.

Nota La funcionalidad de GSS puede ser proporcionada por el ISP o por el cliente.

412

Capítulo 15

Descripción General de

QoS

413

VISIÓN GENERAL DE QOS

QoS es un elemento crucial de cualquier política administrativa que requiere cómo

manejar el tráfico de aplicaciones en una red. El objetivo fundamental de QoS es gestionar

contención para recursos de red y maximizar la experiencia de usuario final de una sesión.

Dado que no todos los paquetes son iguales, no deben ser tratados por igual.

En cualquier red en la que las aplicaciones en red requieren niveles de servicio

diferenciados, el tráfico debe clasificarse en diferentes clases sobre las que se aplica la

QoS. La clasificación y el marcado son dos funciones fundamentales de cualquier

implementación exitosa de QoS. Traffic Policing y Traffic Shaping son dos técnicas de QoS

que pueden limitar la cantidad de ancho de banda que una aplicación, usuario o clase de

tráfico específico puede usar en un enlace. Puede utilizar mecanismos de prevención de

congestión para reducir sus efectos negativos, penalizando los flujos de tráfico más

agresivos cuando las colas de software empiezan a llenarse. Sin embargo, las técnicas de

gestión de la congestión pueden proporcionarle un medio eficaz para gestionar colas de

software y asignar el ancho de banda necesario a aplicaciones específicas cuando existe

congestión.

IntServ versus DiffServ

Existen dos modelos diferentes para abordar QoS en una red. El modelo de servicios

integrados (IntServ) se introdujo para complementar el mejor esfuerzo de entrega,

dejando de lado un poco de ancho de banda para las aplicaciones que requieren garantías

de ancho de banda y el retraso. IntServ espera que las aplicaciones indiquen sus

necesidades a la red. Se agregó el modelo de servicios diferenciados (DiffServ) para

proporcionar una mayor escalabilidad para abordar los requisitos de QoS para paquetes

IP.

Algunas aplicaciones, como la videoconferencia de alta definición, requieren un ancho de

banda dedicado y constante para proporcionar una experiencia suficiente para los

usuarios. IntServ se introdujo para garantizar el comportamiento predecible de la red para

estos tipos de aplicaciones. Debido a que IntServ reserva el ancho de banda a través de

una red, ningún otro tráfico puede utilizar el ancho de banda reservado.

IntServ proporciona garantías de QoS duras, tales como ancho de banda, retraso y tasas de

pérdida de paquetes de extremo a extremo. Estas garantías garantizan niveles de servicio

tanto previsibles como garantizados para las aplicaciones. No habrá ningún efecto en el

tráfico cuando se hagan garantías porque los requisitos de QoS se negocian al establecer la

conexión y el Control de Admisión de Conexión (CAC) garantiza que ningún nuevo tráfico

414

violará las garantías existentes. Estas garantías requieren un enfoque de QoS de extremo a

extremo, que introduce tanto complejidad como escalabilidad. Debido a que cada nodo

necesita construir y mantener el estado por flujo, en redes de gran escala con miles o

millones de flujos, esto introduce la complejidad del plano de control y añade una

sobrecarga adicional en los dispositivos de red a lo largo de la ruta de flujo.

DiffServ fue diseñado para superar las limitaciones de los modelos IntServ. DiffServ ofrece

un modelo de QoS "casi garantizado" rentable y escalable. Con el modelo DiffServ, los

mecanismos de QoS se utilizan sin señalización previa, y las características de QoS (por

ejemplo, ancho de banda y retardo) se gestionan de forma salto a salto con políticas

establecidas independientes en cada dispositivo de la red. Este enfoque no se considera

una estrategia de QoS de extremo a extremo porque las garantías de extremo a extremo no

se pueden aplicar. Es importante notar, sin embargo, que DiffServ es un enfoque más

escalable para implementar QoS porque cientos o potencialmente miles de aplicaciones

pueden ser asignadas en un conjunto más pequeño de clases sobre las cuales se pueden

implementar conjuntos similares de comportamientos QoS. Aunque los mecanismos QoS

en este enfoque se aplican sobre una base salto a salto, aplicar uniformemente una política

global a cada clase de tráfico consistente proporciona flexibilidad y escalabilidad.

Con DiffServ, el tráfico de red se divide en clases que se basan en requisitos comerciales. A

cada clase se le puede asignar un nivel de servicio diferente. A medida que los paquetes

atraviesan una red, cada uno de los dispositivos de red identifica la clase de paquete y los

servicios de los paquetes de acuerdo con esta clase. Puede elegir muchos niveles de

servicio con DiffServ. Ejemplos de implementación de diferentes niveles de servicio

incluyen el tráfico de voz de los teléfonos IP que reciben un trato preferente sobre el resto

del tráfico de aplicaciones y el correo electrónico recibe el mejor servicio. No comercial, o

carroñero, el tráfico puede ser dado un mal servicio o bloqueado por completo.

DiffServ funciona como un servicio de entrega de paquetes. Usted solicita (y paga) un nivel

de servicio cuando envía su paquete. A lo largo del proceso de entrega de paquetes, el

nivel de servicio es reconocido, y su paquete se da tratamiento preferencial o normal,

dependiendo de lo que usted pidió.

DiffServ, como se ha señalado, es altamente escalable y ofrece muchos niveles diferentes

de configuración de servicio de calidad; Sin embargo, tiene los siguientes inconvenientes:

No se puede garantizar una calidad absoluta del servicio.

Se requiere un conjunto de mecanismos complejos para trabajar en conjunto en

toda la red.

Tabla 15-1 Características de IntServ versus DiffServ

415

Servicios integrados (IntServ)

IntServ es similar a un servicio privado de

mensajería.

Servicios Diferenciados (DiffServ)

DiffServ es similar a un servicio de entrega de paquetes.

Una aplicación envía un mensaje a la red.

La clasificación identifica el tráfico de la red.

Garantiza un comportamiento predecible

de la red.

La política de QoS de la red impone un tratamiento

diferenciado de las clases de tráfico.

Ningún otro tráfico puede utilizar el ancho

de banda reservado.

El usuario define el nivel de servicio para cada clase de

tráfico.

CLASIFICACIÓN Y MARCADO

Esta sección define y explica la necesidad y el diseño de la clasificación y comercialización

de la QoS. También se analizan diferentes clasificaciones y mecanismos de marcado y

consideraciones de diseño de cada uno.

Clasificaciones y herramientas de marcado

La clasificación de paquetes utiliza un descriptor de tráfico para categorizar un paquete

dentro de un grupo específico al momento de definir este paquete. La marcación está

relacionada con la clasificación y permite que los dispositivos de red aprovechen un

descriptor de tráfico específico para clasificar un paquete o una trama.

Los descriptores de tráfico comúnmente utilizados incluyen

Clase de servicio (CoS)

Interfaz entrante

Prioridad IP

Punto de código de servicios diferenciados (DSCP)

Dirección de origen

Dirección de destino

416

Aplicación

MPLS EXP bits

Una vez que el paquete ha sido definido o clasificado, el paquete es entonces accesible

para el manejo de QoS en la red. La clasificación de paquetes crea una oportunidad para

que divida el tráfico de la red en varios niveles de prioridad o clases de servicio. Cuando se

utilizan descriptores de tráfico para clasificar el tráfico, la fuente acepta adherirse a los

términos contratados y la red promete un nivel específico de QoS. Los diferentes

mecanismos de QoS, como Traffic Policy, Traffic Shaping y técnicas de colas, utiliza el

descriptor de tráfico del paquete (es decir, la clasificación del paquete) para asegurar el

cumplimiento del acuerdo definido.

La clasificación y el marcado siempre deben tener lugar en el borde de la red,

normalmente en el armario de cableado, en los teléfonos IP o en los puntos finales de la

red. Se recomienda que la clasificación ocurra tan cerca de la fuente del tráfico como sea

posible para asegurar que los flujos de tráfico reciban el tratamiento deseado desde su

punto de entrada a la red hasta el punto de destino o salida (salto a salto).

El concepto de confianza es clave para desplegar QoS. Cuando un dispositivo final como

una estación de trabajo o un teléfono IP marca un paquete con un valor CoS o DSCP, un

conmutador o enrutador tiene la opción de aceptar o no los valores desde el dispositivo

final. Si el conmutador o enrutador opta por aceptar los valores, el conmutador o

enrutador confía en el dispositivo final. Si el conmutador o enrutador confía en el

dispositivo final, no necesita realizar ninguna reclasificación de paquetes desde el

dispositivo al entrar en la interfaz. Si el conmutador o enrutador no confía en el

dispositivo, debe realizar una reclasificación para determinar el valor de QoS apropiado

para los paquetes procedentes del dispositivo a través de la interfaz. Los conmutadores y

enrutadores generalmente están configurados para no confiar en los dispositivos finales y

deben configurarse específicamente para confiar en los paquetes que provienen de una

interfaz.

Marcar un paquete o una trama con su clasificación permite a los dispositivos de red

distinguir fácilmente el paquete marcado o la trama como pertenecientes a una clase

específica. Después de que los paquetes o las tramas se identifican como pertenecientes a

417

una clase específica, otros mecanismos QoS pueden usar estas marcas para aplicar de

manera uniforme las directivas QoS. Las siguientes secciones exploran la clasificación y el

marcado con más detalle.

Marcado de la capa 2: IEEE 802.1Q / p Clase de servicio

Las opciones de clasificación y marcado de paquetes que están disponibles en la capa de

enlace de datos dependen de la tecnología de capa 2. Cada tecnología de capa 2 tiene su

propio mecanismo para su clasificación y marcado. Para que la marcación persista más

allá de la red de la capa 2, debe producirse la traducción del campo correspondiente.

El estándar 802.1Q es una especificación IEEE para implementar VLANs en redes

conmutadas de Nivel 2. Como se muestra en la Figura, la especificación 802.1Q define dos

campos de 2 bytes, Tag Protocol Identifier (TPID) y Tag Control Information (TCI), que se

insertan dentro de una trama Ethernet después del campo Source Address (SA).

El campo TPID está actualmente fijo y se le asigna el valor 0x8100. El campo TCI se

compone de tres campos:

Bits de prioridad de usuario (3 bits): El estándar IEEE 802.1p define las

especificaciones de este campo de 3 bits. Estos bits pueden marcar paquetes como

pertenecientes a un CoS específico. Las marcas de CoS utilizan los tres bits de

prioridad de usuario 802.1p y permiten marcar una trama Ethernet de Capa 2 con

ocho niveles de prioridad (valores 0-7). Los 3 bits permiten una correspondencia

directa con los valores de tipo de servicio (ToS) IPv4 (prioridad IP). La

especificación 802.1p define estas definiciones estándar para cada CoS:

o CoS 7 (111): red

o CoS 6 (110): Internet

o CoS 5 (101): crítica

o CoS 4 (100): interrumpir el flash

o CoS 3 (011): flash

o CoS 2 (010): inmediato

418

o CoS 1 (001): prioridad

o CoS 0 (000): rutina

Una desventaja de usar el marcado de CoS es que las tramas pierden sus marcas de

CoS cuando transitan un enlace no 802.1Q o no 802.1p. Los enlaces no 802.1Q /

802.1p incluyen cualquier tipo de enlace WAN no Ethernet. Al diseñar QoS de

extremo a extremo, debe considerar un mecanismo de marcado más permanente

para el tránsito de red, como la marca IP DSCP de capa 3. Este objetivo suele

llevarse a cabo mediante la traducción de una marca CoS en otro marcador o

simplemente con un mecanismo de marcado diferente para empezar.

CFI (1 bit): Este bit indica si el orden de los bits es canónico o no canónico. El bit

Canonical Format Indicator (CFI) se utiliza para la compatibilidad entre redes

Ethernet y Token Ring.

Identificador de VLAN o ID de VLAN (12 bits): El campo ID de VLAN es un campo

de 12 bits que define la VLAN utilizada por 802.1Q. Debido a que el campo es 12

bits restringe el número de VLANs que son compatibles con 802.1Q a 4096.

Nota Enlaces capa 2 anteriores como ATM y frame relay, llevan marcas QoS en sus

encabezados.

Marcado de la capa 3: Tipo de servicio IP

Los medios de capa de enlace cambian a menudo cuando un paquete viaja desde su origen

hasta su destino. Como se indicó en la sección anterior, el campo CoS no existe en una

trama Ethernet estándar y, por lo tanto, las marcas CoS en la capa de enlace no se

conservan a medida que los paquetes atraviesan redes no troncalizadas o no Ethernet. El

uso de marcas en la capa 3 proporciona un marcador más permanente que se conserva de

la fuente al destino. En la capa 3, los paquetes IP se clasifican comúnmente según la

dirección IP de origen o destino, la longitud del paquete o el contenido del byte ToS.

419

La precedencia IP utiliza tres bits de precedencia en el campo ToS del encabezado IPv4

para especificar la clase de servicio para cada paquete. Los valores de prioridad IP varían

de 0 a 7 y permiten dividir el tráfico en hasta seis clases de servicio utilizables. Es

importante tener en cuenta que los valores 6 y 7 están reservados para el uso interno de la

red.

El nuevo modelo DiffServ reemplaza y es compatible con la precedencia IP. Esto ha dado

como resultado que la precedencia de la IP sea prácticamente obsoleta. DiffServ redefine

el byte ToS como el campo DiffServ y utiliza seis bits de priorización que permiten la

clasificación de hasta 64 valores (0 a 63), de los cuales 32 son de uso común. Un valor

DiffServ se denomina valor DSCP.

Con DiffServ, la clasificación de paquetes categoriza el tráfico de red en múltiples niveles

de prioridad o clases de servicio. La clasificación de paquetes utiliza el descriptor de

tráfico DSCP para categorizar un paquete dentro de un grupo específico al momento de

definir este paquete. Una vez que el paquete ha sido definido (clasificado), el paquete es

entonces accesible para el manejo de QoS en la red.

Los primeros 6 bits del byte ToS se utilizan para el marcado mientras que los 2 últimos

bits están reservados para el control de flujo y la notificación de congestión explícita

(ECN).

ECN permite la notificación de extremo a extremo de congestión de la red sin descartar

paquetes. ECN es una característica opcional que se puede utilizar entre dos puntos finales

habilitados con ECN cuando la infraestructura de red subyacente también admite esta

capacidad. Cuando ECN se negocia con éxito, un enrutador habilitado con ECN puede

establecer una marca en el encabezado IP en lugar de descartar un paquete para señalar la

congestión inminente. El receptor del paquete hace eco de la indicación de congestión al

remitente, lo que reduce su velocidad de transmisión como si detectara un paquete

abandonado. Debido a que la marcación ECN en los enrutadores depende de alguna forma

de gestión de colas activa, los enrutadores deben configurarse con una disciplina de cola

adecuada para realizar la marcación ECN. Los enrutadores Cisco IOS realizan marcado

ECN si se configuran con la disciplina de colas de detección temprana aleatoria ponderada

(WRED).

Marcado de la capa 3: Comportamiento de DSCP por salto

Comúnmente, diferentes valores de comportamiento por salto (PHB) se utilizan en las

redes de hoy, y se basan en los valores DSCP de los paquetes IP. La Tabla 15-2 proporciona

un desglose de PHB e incluye el uso asociado, así como ajustes de bits DSCP.

420

Tabla 15-2 IETF Definiciones de PHB

PHB Utilizar Configuración del bit

DSCP

Defecto (default) Se utiliza para el servicio de mejor esfuerzo Bits 5 a 7 de DSCP = 000

EF Se utiliza para el servicio de baja demora Bits 5 a 7 de DSCP = 101

AF

Se utiliza para garantizar el servicio de ancho de

banda

Los bits 5 a 7 de DSCP =

001, 010, 011 o 100

Selector de clase

(Class Selector)

Se utiliza para la compatibilidad con dispositivos

no compatibles con DiffServ (dispositivos RFC

1812)

Bits 2 a 4 de DSCP = 000

El EF tiene la intención de proporcionar una tasa de ancho de banda garantizada con el

menor retardo posible. Esto se logra proporcionando un reenvío prioritario. El reenvío de

prioridades da como resultado este PHB que controla el exceso de ancho de banda para

que otras clases que no estén usando este PHB no estén privadas del mismo.

Los paquetes que requieren EF PHB deben marcarse con un valor binario DSCP de

101110, o 46, como se muestra en la Figura; Los dispositivos que no cumplen con DiffServ

considerarán el valor EF DSCP como prioridad IP 5. Esta precedencia es la prioridad IP

más alta definida por el usuario y suele utilizarse para tráfico sensible al retardo, como

VoIP.

421

El AF define un método mediante el cual se pueden dar diferentes garantías de reenvío a

los paquetes. Cuatro clases AF definidas están representadas por los valores aaa 001, 010,

011 y 100, como se muestra en la Figura. Cada clase debe ser tratada independientemente

y debe haber asignado el ancho de banda que se basa en la política QoS.

La probabilidad de descarte de AF indica las prioridades de descarte del tráfico dentro de

las clases de AF. A cada clase AF se le asigna una prioridad IP y tiene tres probabilidades

de descarte: baja, media y alta. La figura proporciona una mirada a la relación entre la

probabilidad de caída y los valores de AF.

AFxy definido en RFC 2597 es un AF en el que el valor x corresponde a los valores de

prioridad IP 1 a 4 y el valor y corresponde al valor de preferencia de descarte 1, 2 o 3. Es

posible calcular el valor de DSCP para un AF multiplicando el valor de la precedencia IP

por 8, multiplicando la preferencia de descarte por 2 y añadiendo estos valores juntos. Por

ejemplo, el valor de DSCP para AF23 sería igual a ((2 * 8) + (3 * 2)) = 22.

Tabla 15-3 Probabilidad de caída del DSCP

DESCARTE AF1X AF2X AF3X AF4X

422

BAJO

AF11 = DSCP 10 o

001010

AF21 = DSCP 18 o

010010

AF31 = DSCP 26 o

011010

AF41 = DSCP 34 o

100010

MEDIO

AF12 = DSCP 12 o

001100

AF22 = DSCP 20 o

010100

AF32 = DSCP 28 o

011100

AF42 = DSCP 36 o

100100

ALTO

AF13 = DSCP 14 o

001110

AF23 = DSCP 22 o

010110

AF33 = DSCP 30 ó

011110

AF43 = DSCP 38 o

100110

Tabla 15-4 Cálculo de probabilidades de caída de DSCP

Soltar AF1x AF2x AF3x AF4x

Bajo AF11 = ((1 * 8) + (1 *

2)) = 10

AF21 = ((2 * 8) + (1 *

2)) = 18

AF31 = ((3 * 8) + (1 *

2)) = 26

AF41 = ((4 * 8) + (1 *

2)) = 34

Medio AF12 = ((1 * 8) + (2 *

2)) = 12

AF22 = ((2 * 8) + (2 *

2)) = 20

AF32 = ((3 * 8) + (2 *

2)) = 28

AF42 = ((4 * 8) + (2 *

2)) = 36

Alto AF13 = ((1 * 8) + (3 *

2)) = 14

AF23 = ((2 * 8) + (3 *

2)) = 22

AF33 = ((3 * 8) + (3 *

2)) = 30

AF43 = ((4 * 8) + (3 *

2)) = 38

Como se ha indicado anteriormente, originalmente el campo DS se denominó campo ToS, y

los primeros 3 bits del campo (bits 5 a 7) definieron un valor de precedencia IP de

paquete. A un paquete se le podría asignar una de las seis prioridades basadas en el valor

de precedencia IP. Como se señala en la RFC 791, IP precedencia 5 (101) fue la más alta

prioridad que podría ser asignado.

RFC 2474 reemplazó el campo ToS con el campo DS. El selector de clases PHB y el rango

de ocho valores se definieron para proporcionar compatibilidad hacia atrás para DSCP con

prioridad IP basada en ToS. RFC 1812 simplemente da prioridad a los paquetes de

acuerdo con el valor de precedencia, esencialmente el mapeo de precedencia de IP a DSCP.

423

El PHB se define como la probabilidad de reenvío oportuno. Los paquetes con mayor

prioridad de IP deben ser enviados en promedio en menos tiempo que los paquetes con

menor prioridad de IP durante un período de congestión de interfaz.

Los últimos 3 bits del DSCP, bits 2-4, establecidos en 0, identifican un selector de clases

PHB. Puede calcular el valor de DSCP para un CS PHB multiplicando el número de clase

por 8. Por ejemplo, el valor de DSCP para CS3 sería igual a (3 * 8) = 24.

Tabla 15-5 Cartografía DSP a IP Precedencia

Valor DSCP DS Binario DS Decimal Precedencia IP

CS0 000 000 0 0

CS1 001 000 8 1

AF11 001 010 10 1

AF12 001 100 12 1

AF13 001 110 14 1

CS2 010 000 16 2

AF21 010 010 18 2

AF22 010 100 20 2

AF23 010 110 22 2

CS3 011 000 24 3

AF31 011 010 26 3

AF32 011 100 28 3

AF33 011 110 30 3

CS4 100 000 32 4

AF41 100 010 34 4

AF42 100 100 36 4

AF43 100 110 38 4

CS5 101 000 40 5

EF 101 110 46 5

CS6 110 000 48 6

CS7 111 000 56 7

424

Capa 2.5 Marcado: MPLS Experimental Bits

La marcación en un entorno MPLS se sitúa entre la capa 2 y la 3 y requiere un tipo

diferente de descriptor. El campo MPLS EXP es un campo de 3 bits en el encabezado MPLS

que puede utilizar para definir el tratamiento QoS y el comportamiento por salto que un

nodo debe dar a un paquete.

Como se ha indicado anteriormente, cuando un cliente transmite paquetes IP de un sitio a

otro, el campo de prioridad de IP especifica la clase de servicio. El paquete recibe el

tratamiento deseado, como ancho de banda garantizado o latencia basado en la marca de

precedencia de IP. Si la red del proveedor de servicios es una red MPLS, los bits de

precedencia IP se copian en el campo MPLS EXP en el borde de la red. En muchos casos y

dependiendo de la oferta de servicio, el proveedor de servicios puede querer establecer

QoS para un paquete MPLS a un valor diferente.

El campo MPLS EXP permite al proveedor de servicios proporcionar QoS sin sobrescribir

el valor en el campo de prioridad IP del cliente. El encabezado IP sigue estando disponible

para el uso de los clientes y no se requiere que la marcación de paquetes IP cambie a

medida que el paquete viaja a través de la red MPLS. La Figura proporciona un desglose

visual del encabezado MPLS y específicamente del campo MPLS EXP.

Los siguientes son algunos datos básicos importantes sobre las marcas de QoS de MPLS:

MPLS utiliza un campo de etiquetas de 32 bits denominado encabezado de calzo

que se inserta entre los encabezados de Capa 2 y Capa 3 en modo de marco.

El campo MPLS EXP de 3 bits se utiliza para el marcado QoS y admite hasta ocho

clases de servicio.

El campo de precedencia IP o DSCP no está directamente visible para los

conmutadores de etiquetas MPLS.

De forma predeterminada, el software Cisco IOS copia los tres bits más

significativos del DSCP o la prioridad IP del paquete IP al campo EXP.

El campo MPLS EXP de 3 bits se conserva en toda la red MPLS.

425

Mapeo de marcas QoS entre capas OSI

A diferencia de los encabezados de capa de enlace de datos, los encabezados IP se

conservan de extremo a extremo cuando los paquetes IP se transportan a través de una

red. Puede suponer que esto significa que la capa IP es el lugar más lógico para marcar los

paquetes de QoS de extremo a extremo. Marcando el tráfico estrictamente en el IP no

siempre es práctico dado que algunos dispositivos de borde pueden marcar tramas

solamente en la capa de enlace de datos y muchos otros dispositivos de red operan

solamente en la capa 2. Con diferentes mecanismos de marcado soportados de la capa 2 a

la capa 3, la capacidad de mapear el marcado QoS entre las capas es esencial para asegurar

la interoperabilidad y proporcionar una verdadera QoS de extremo a extremo.

Las redes empresariales frecuentemente están compuestas de sitios con una LAN

conmutada. La provisión de QoS de extremo a extremo a través de este tipo de entorno

requiere que las marcas de CoS que se establezcan en el borde de la LAN se mapeen en

marcas de QoS tales como precedencia de IP o DSCP para tránsito a través de los

enrutadores de campus o WAN. Los enrutadores de Campus y WAN también pueden

asignar las marcas QoS a los nuevos encabezados de enlace de datos para el tránsito a

través de la LAN conmutada. De esta manera, la QoS puede ser preservada y aplicada

uniformemente en toda la empresa.

Los proveedores de servicios que ofrecen servicios IP suelen tener el requisito de

proporcionar soluciones robustas de QoS a sus clientes. La capacidad de mapear la calidad

de la capa 3 QoS a la capa 2 CoS permite que estos proveedores ofrezcan una solución

completa de la QoS de extremo a extremo que no depende de ninguna tecnología

específica.

La compatibilidad entre una capa de transporte MPLS y la QoS de Capa 3 también se logra

trazando mapas entre los bits MPLS EXP y los bits de precedencia IP o DSCP. Un proveedor

de servicios puede asignar el marcado QoS de la Capa 3 del cliente tal cual o cambiarlo

para ajustarse a un SLA acordado. La información de los bits MPLS EXP puede llevarse de

extremo a extremo en la red MPLS, independientemente del medio de transporte. Además,

la marca de la Capa 3 puede permanecer invariable de modo que cuando el paquete

abandona la red MPLS del proveedor de servicios, las marcas originales de QoS

permanecen intactas (a menos que se utilice el modo de túnel uniforme de MPLS QoS en el

que la observación de EXP se reflejará en el marcado IP). De esta manera, un proveedor de

servicios que ofrece servicios MPLS puede garantizar que no haya interrupción en una

verdadera solución de QoS corporativa de extremo a extremo. La figura muestra una

correlación entre las capas.

426

Clasificación de la capa 7: NBAR / NBAR2

Cisco NBAR puede reconocer una amplia variedad de protocolos y aplicaciones,

incluyendo aplicaciones basadas en web, así como aplicaciones cliente y servidor que

asignan dinámicamente números de puerto TCP o UDP. Una vez que los protocolos y la

aplicación se han clasificado inteligentemente para aprovechar el NBAR, la red puede

invocar servicios específicos para estos protocolos o aplicaciones.

Cuando se utiliza en modo activo, Cisco NBAR está habilitado dentro de la estructura de

QoS CLI MQC modular para clasificar el tráfico. Por supuesto, el criterio para clasificar

paquetes en mapas de clases usando NBAR depende de si el paquete coincide con un

protocolo o aplicación específico conocido por NBAR. Las aplicaciones personalizadas se

pueden definir como parte del motor de clasificación NBAR. Utilizando MQC, el tráfico de

red que coincide con un protocolo de red específico como Citrix se puede ubicar en una

clase de tráfico, mientras que el tráfico que coincida con un protocolo de red diferente,

como Skype, puede colocarse en otra clase de tráfico. Después de que el tráfico haya sido

427

clasificado de esta manera, puede establecer diferentes valores de marcado de Capa 3 en

diferentes clases de tráfico.

Cuando se utiliza en modo pasivo, el descubrimiento del protocolo NBAR se habilita por

interfaz para descubrir y proporcionar estadísticas en tiempo real sobre las aplicaciones

que atraviesan la red.

El NBAR de próxima generación, o NBAR2, es una re-arquitectura completamente

retrocompatible de Cisco NBAR con técnicas avanzadas de clasificación, mayor precisión y

soporte para más firmas. NBAR2 está soportado en varios dispositivos, incluyendo ISR-G2,

ASR1000, ISR-4000, CSR1000, ASA-CX y Cisco Wireless LAN Controllers (WLC).

El protocolo Cisco NBAR y el soporte de firmas se pueden actualizar instalando módulos

de lenguaje de descripción de paquetes (PDLM) más recientes para sistemas NBAR o

paquetes de protocolos para sistemas NBAR2. El soporte para actualizaciones modulares

permite actualizaciones no disruptivas de las capacidades NBAR, ya que no se requiere la

actualización de la imagen base de IOS.

POLICERS Y SHAPERS

Traffic policing y traffic shaping son mecanismos de acondicionamiento del tráfico que se

utilizan en una red para controlar la tasa de tráfico. Ambos mecanismos diferencian el

tráfico mediante el uso de la clasificación, y ambos miden la tasa de tráfico y la comparan

con la política configurada de regulación del tráfico o de control del tráfico. La Figura

destaca la diferencia entre la conformación del tráfico (traffic shaping) y la vigilancia del

tráfico (traffic policing).

428

La diferencia entre traffic shaping y traffic policing se puede describir en términos de

amortiguación versus disminución del exceso de tráfico:

Traffic Shaping amortigua el tráfico excesivo para que el tráfico se mantenga

dentro de la tasa deseada. Con la conformación del tráfico, las ráfagas de tráfico se

suavizan haciendo cola el tráfico excesivo para producir un flujo más constante de

datos. La reducción de las ráfagas de tráfico ayuda a reducir la congestión de la red.

Traffic Policing reduce el exceso de tráfico para controlar el flujo de tráfico dentro

de los límites de velocidad especificados. La policía del tráfico no introduce ningún

retraso en el tráfico que se ajuste a las políticas de tránsito. La vigilancia del tráfico

puede causar más retransmisiones TCP, ya que el tráfico excede los límites

especificados.

Traffic Shaping se utiliza comúnmente para configurar los flujos de tráfico saliente cuando

la tarifa de la línea saliente es superior a la tasa de suscripción objetivo. Clientes que

suscriben servicio

Los servicios de proveedores que soportan un traspaso de Ethernet normalmente quieren

configurar el tráfico saliente en el equipo de borde de cliente (CE) para que coincida con la

tasa de información suscrita o comprometida, o CIR (la tasa contractual máxima

permitida).

El proveedor de servicios suele regular el tráfico entrante en el equipo del borde del

proveedor (PE) para que coincida con el CIR y, por lo tanto, la configuración en el extremo

del cliente evitará la política innecesaria y descarte en el PE, . Un ejemplo de este escenario

se destaca en la Figura y muestra una interfaz Fast Ethernet que se conecta a una oferta de

proveedor de servicios con una tasa de información comprometida de 20 Mbps.

La conformación en este ejemplo se utiliza para suavizar el tráfico. Lo hace almacenando

el exceso de tráfico en una cola de conformación, lo que a su vez aumenta la utilización del

búfer en el enrutador y provoca un retraso de paquete variable.

Traffic Shaping también puede interactuar con una red Frame Relay, adaptándose a las

indicaciones de congestión de la capa 2 en la WAN. Por ejemplo, si se recibe el bit de

notificación de congestión explícita hacia atrás (BECN), el enrutador puede reducir el

límite de velocidad para ayudar a reducir el congestionamiento en la red Frame Relay.

429

Los mecanismos de Traffic Policing, como la política basada en la clase, tienen capacidades

de marcado además de capacidades limitadoras de la velocidad. En lugar de eliminar el

exceso de tráfico, la política de tránsito puede alternativamente marcar el tráfico excesivo

con una prioridad menor antes de enviarlo. Sin embargo, la Traffic Shaping no admite esta

capacidad. Traffic Shaping sólo puede retrasar el exceso de ráfagas de tráfico para

ajustarse a una velocidad especificada.

Puede aplicar la política a la dirección de entrada o de salida, mientras que la

conformación se puede aplicar sólo en la dirección de salida. La política descarta el tráfico

no conforme en lugar de poner en cola la configuración del tráfico. Traffic Policing es más

eficiente para la utilización de la memoria que para la conformación del tráfico, ya que no

se necesita cola adicional de paquetes.

Tanto la política como los mecanismos de conformación del tráfico garantizan que el

tráfico no exceda el límite de ancho de banda, pero cada mecanismo tiene un impacto

diferente en el tráfico:

Traffic Shaping aumenta el retardo de paquetes y provoca fluctuación de fase, lo

que hace que no sea ideal para aplicaciones sensibles al retardo, como VoIP.

Traffic Policing descarta los paquetes con más frecuencia, causando generalmente

más retransmisiones de protocolos orientados a la conexión como TCP.

Traffic Shaping suele utilizarse para lo siguiente:

Prevención y gestión de la congestión en redes en las que se utilizan anchos de

banda asimétricos a lo largo de la trayectoria del tráfico. Si no se utiliza la

conformación, el buffer puede ocurrir en el extremo lento (normalmente el

remoto), lo que puede provocar colas (que causan retrasos) y desbordamiento

(causando caídas).

Evitar el descarte del tráfico no conforme por el proveedor de servicios al no

permitir que el tráfico rebase por encima de la tarifa suscrita (comprometida). El

cliente puede mantener el control local de la regulación del tráfico.

Traffic Policing se utiliza típicamente para satisfacer uno de estos requisitos:

Limitar la velocidad de acceso en una interfaz cuando se utiliza una infraestructura

física de alta velocidad en el transporte. Los proveedores de servicios suelen

utilizar la limitación de tarifas para ofrecer a los clientes.

Ancho de banda de ingeniería para que las tasas de tráfico de ciertas aplicaciones o

clases de tráfico sigan una política de velocidad de tráfico especificada. Por

ejemplo, limitar el tráfico de las aplicaciones de uso compartido de archivos a un

máximo de 500 kbps.

Volver a marcar el tráfico excesivo con una prioridad inferior en la Capa 2 o la Capa

3 o ambas, antes de enviar el tráfico excesivo. La policía de tráfico basada en clases

430

de Cisco puede configurarse para marcar paquetes tanto en la Capa 2 como en la

Capa 3. Por ejemplo, el tráfico en exceso se puede volver a marcar a un valor DSCP

inferior y también tiene el bit Frame Relay DE establecido antes de que se envíe el

paquete.

Características del tráfico

Sólo dirección saliente

Cola fuera de los paquetes de perfil hasta

que un búfer se llena

Características de la Policía de Tráfico

Direcciones entrantes y salientes

Se quita de los paquetes de perfil

El búfer minimiza retransmisiones de TCP

No admite marcado ni comentario

Soporta la interacción con la indicación de

congestión de Frame Relay

Caída provoca retransmisiones de TCP

Soporta marcas de paquetes o comentarios

Menor uso de búfer (la conformación requiere un

sistema de colas de formación adicional)

Algoritmos Token Bucket

A pesar de que no acreditan fichas de la misma manera, Cisco IOS policers y shapers son

modelados después de aplicar los algoritmos de cubos de token. Una explicación general y

simplificada sigue y no necesariamente representa estrictamente cómo cada algoritmo en

cada plataforma de Cisco opera. Hay muchas variaciones en los detalles de

implementación y en los productos y versiones de software.

Los algoritmos Token bucket son motores de medición que controlan la cantidad de tráfico

que se puede enviar para ajustarse a una tasa de tráfico especificada. Un token permite

que se envíe una sola unidad (normalmente un bit, pero puede ser un byte) del tráfico. Los

tokens se conceden al principio de un incremento de tiempo específico, usualmente cada

segundo, de acuerdo con la tasa especificada llamada tasa de información comprometida

(CIR). El CIR es la tasa de bits de acceso que se contrata en el SLA con un proveedor de

servicios.

Si el CIR se establece en 8000 bps, se colocan 8000 tokens en un cubo al principio del

período de tiempo. Cada vez que se ofrece un poco de tráfico a la política, se comprueba el

cubo en busca de fichas. Si hay fichas en el cubo, se considera que el tráfico se ajusta a la

velocidad, y la acción típica es enviar el tráfico. Un token se quita del cubo para cada bit

del tráfico enviado. Cuando el cubo se queda sin tokens, cualquier tráfico ofrecido

adicional se considera que excede la velocidad, y se toma la acción excedente, que es

típicamente para marcar de nuevo o para descartar el tráfico.

431

Nota Al final de la segunda, puede haber tokens no utilizados. El manejo de fichas no

utilizadas es un diferenciador clave entre los diferentes tipos de políticas.

Debido a que la tasa de reloj de la interfaz no puede cambiar para hacer cumplir la política

CIR, la única manera de imponer un límite de velocidad en una interfaz es utilizar la

multiplexación por división de tiempo (TDM), que es una técnica en la que la información

de múltiples canales puede asignarse ancho de banda en un único cable basado en

intervalos de tiempo preasignados. Con TDM, cuando se impone un límite de velocidad (o

CIR) en una interfaz, se asigna al tráfico una división de tiempo de subsegundos durante la

cual se puede enviar. Este segmento de tiempo del sub-segundo se denomina intervalo de

tiempo (o Tc). Por ejemplo, si se impone un CIR de 8 Kbps en un enlace de 64 Kbps, el

tráfico se puede enviar por un intervalo de 125 ms (64.000 bps / 8000 bits).

La cantidad total permitida por el CIR (8000 bits) podría teóricamente ser enviada de una

vez, pero entonces el algoritmo tendría que esperar 875 ms antes de poder enviar más

datos para cumplir con el límite de velocidad, causando excesos de retrasos entre

paquetes. Por lo tanto, para suavizar el flujo permitido en cada segundo, el CIR se divide

en unidades más pequeñas, denominadas burst (Bc) comprometido, que es el número

sostenido de bits que se pueden enviar por intervalo Tc. Estas unidades más pequeñas se

envían en múltiples instancias durante un solo segundo. Continuando con el ejemplo

anterior, si la Bc se establece en 1000, cada ráfaga confirmada puede tardar sólo 15,6 ms

(1000 bits / 64,000 bps) para enviar tráfico a la interfaz a la velocidad del reloj. El

algoritmo espera 109,4 ms (125 ms - 15,6 ms) y envía otros 15,6 ms de datos (1000 bits).

Este proceso se repite un total de ocho veces durante cada segundo. La transmisión de

datos "ráfaga" que comprende un Bc de 1000, y por lo tanto, un Tc de 125 ms se ilustra en

la parte inferior de la Figura.

432

Un paquete o trama de 1500 bytes constituye (1500 * 8) 12.000 bits. A 1000 bits (el valor

Bc) para cada intervalo de tiempo (el valor de Tc, en este caso de 125 ms), toma 12

intervalos de tiempo para enviar todo el paquete. Cada intervalo de tiempo es de 125 ms,

y, por lo tanto, todo el paquete tarda 1,5 segundos para ser enviado en su totalidad, dando

lugar a pequeñas ráfagas de 100 bits cada uno a velocidad de transmisión de velocidad de

línea.

El algoritmo token bucket es el siguiente: Bc = CIR * Tc (Bits = Rate * Time)

El software Cisco IOS no permite la definición explícita del intervalo (Tc). En su lugar, IOS

toma los valores CIR y Bc como argumentos y deriva el intervalo y el número de ráfagas

por segundo. Por ejemplo, si el CIR es 8000 y el Bc se establece en 4000, se producen 2

ráfagas por segundo, lo que significa que el Tc = 500 ms. La transmisión resultante de un

valor Bc de 4000 se ilustra en la parte media de la figura anterior. Si el Bc se establece en

2000, se producen 4 ráfagas por segundo (Tc = 250 ms). Si el Bc se establece en 1000, se

producen 8 ráfagas por segundo (Tc = 125 ms). La transmisión resultante de un valor Bc

de 8000 se ilustra en la parte superior de la figura.

433

HERRAMIENTAS DE POLICING: SINGLE-RATE THREE-COLOR

MARKER

La vigilancia de doble cubo permite que los testigos se acumulen en base al CIR, hasta el

Bc, con el exceso de tokens acumulados en un segundo cubo hasta el exceso de ráfaga (Be).

Técnicamente, puede configurar el control de tráfico basado en clases para soportar la

capacidad de exceso de tráfico. Con el exceso de ruptura, después de que el primer

contenedor de fichas se llena hasta Bc, se pueden acumular hasta n tokens adicionales (en

exceso) en un segundo contenedor. Be es la cantidad máxima de tráfico excedente por

encima de Bc que se puede enviar durante el intervalo de tiempo después de un período

de inactividad. Con un solo mecanismo de medición de velocidad, el segundo contenedor

de testigos con un tamaño máximo de Be se llena a la misma velocidad (CIR) que el primer

contenedor de testigos. Si el segundo cubo de fichas se llena hasta la capacidad, no se

pueden acumular más fichas y se descartan los tokens en exceso. Este mecanismo se

ilustra en la Figura.

Cuando se utiliza un modelo de cubo de token doble, la tasa de tráfico medida se puede

identificar en tres estados o tres colores:

Conforme: Hay suficientes fichas en el primer token bucket con un tamaño

máximo de Bc.

Excedido: No hay suficientes tokens en el primer token bucket, pero hay

suficientes tokens en el segundo token bucket con un tamaño máximo de Be.

Violación: no hay suficientes fichas en el primer o segundo cubo de fichas.

434

Con Traffic Policing de bucket dual-token, las acciones típicas que se realizan es enviar

todo el tráfico conforme, re-marcando a una prioridad más baja, el envío de todo el tráfico

excedente, y descartar todo el tráfico que viola. El principal beneficio de utilizar un

método de cubo de doble testigo es la capacidad de distinguir entre el tráfico que excede el

Bc pero no el Be. Se puede aplicar una política diferente a los paquetes de la categoría Be,

proporcionando un mayor nivel de flexibilidad de diseño. Utilizando un ejemplo de banco

de monedas, piense en el CIR como la tasa de ahorro de un dólar por día. Bc es cuánto

puede ahorrar en el banco, como un dólar por día. Tc es el intervalo en el que pones dinero

en el banco de monedas, lo que equivale a un día. Un Be de cinco dólares le permite

estallar sobre la tasa de gasto promedio de un dólar por día si no está gastando un dólar

por día.

La tolerancia de las rotaciones temporales de un solo agente de tres colores resulta en

menos retransmisiones de TCP y por lo tanto es más eficiente en términos de utilización

de ancho de banda. Esta es una herramienta muy adecuada para el marcado de acuerdo

con las clases AF RFC 2597 (AFx1, AFx2 y AFx3), que tienen tres preferencias de "colores"

o de caída definidas por clase, que se trató anteriormente en este capítulo. El uso de un

policía de tres colores generalmente tiene sentido sólo si las acciones tomadas para cada

color difieren. Si las acciones para dos o más colores son iguales, una política más simple

que resulte en una definición de QoS menos compleja es más adecuado.

Nota Si se definen las condiciones de "Conform y Exceed" como parte de la configuración

de la política de clase QoS, sólo se definen dos colores. Si también se agrega la condición de

"violar", tendrá un policía de tres colores que ofrece un tratamiento / tratamiento de

tráfico más específico.

HERRAMIENTAS DE POLITICAS: MARCADOR DE TRES COLORES

DE DOS VELOCIDADES

Con la medición de tasa dual, la tasa de tráfico se puede aplicar de acuerdo con dos tipos

diferentes: CIR y tasa de información de pico (PIR). El indicador / regulador de tres

colores de una sola tarifa es una mejora significativa para Traffic Policy. Se tiene en cuenta

las ráfagas temporales de tráfico siempre y cuando el promedio general de la tasa de

transmisión sea igual o inferior al CIR. En algunas situaciones con un agente de vigilancia

tricolor de tasa única, la variación en el número de créditos acumulados en exceso de

ráfaga podría causar un grado de impredecibilidad en los flujos de tráfico. Para mejorar

esto y abordar este problema, un marcador de dos tasas de tres colores / policer se define

en RFC 2698. Esta política se dirige a la PIR, que es impredecible en el modelo RFC 2697.

Además, el marcador / regulador de tres colores de dos velocidades permite una

explosión excesiva sostenible, lo que niega la necesidad de acumular créditos para

435

acomodar ráfagas temporales y permite diferentes acciones para el tráfico que exceden los

diferentes valores de ráfaga.

La política de tres colores de dos velocidades también utiliza un algoritmo con dos cubos

de testigo, pero la lógica varía ligeramente. En lugar de transferir tokens no utilizados de

un cubo a otro, este policer tiene dos cubos separados que se llenan cada segundo con dos

tasas de token separadas. El primer cubo se llena con los testigos PIR, y el segundo cubo se

llena con los tokens CIR. En la Figura se ilustra el mecanismo de dos tasas de tres colores.

La medición de tasa dual soporta un mayor nivel de gestión de ancho de banda y soporta

una tasa de exceso sostenida, que se basa en el PIR. Con la medición de tasa dual, el cubo

de testigo PIR se repone cuando llega un paquete. El número de bytes que se repone se

basa tanto en el PIR configurado como en la tasa de llegada de paquetes:

(Tiempo de llegada del paquete actual - tiempo de llegada del paquete anterior) * PIR

El cubo de testigo CIR también se rellena cuando llega un paquete, pero el número de

bytes que se reponen se basa tanto en el CIR configurado como en la tasa de llegada de

paquetes:

(Tiempo de llegada del paquete actual - tiempo de llegada del paquete anterior) * CIR

Cuando un paquete llega, se comprueba primero el cubo de token PIR para ver si hay

suficientes fichas en el cubo de token PIR para enviar el paquete. La condición de violación

se produce si no hay suficientes fichas en el contenedor de token PIR para transmitir el

paquete. Si hay suficientes tokens en el cubo de token PIR para enviar el paquete, se

comprueba el cubo de token CIR. La condición de superación ocurre si hay suficientes

tokens en el cubo de testigo PIR para transmitir el paquete, pero no suficientes fichas en el

436

cubo de testigo CIR para transmitir el paquete. La condición de conformidad se produce si

hay suficientes tokens en el cubo CIR para transmitir el paquete.

El vigilante de dos velocidades marca los paquetes como que cumplen, exceden o violan

una velocidad especificada:

Si B> Tp, el paquete está marcado como violando la velocidad especificada.

Si B> Tc, el paquete está marcado como excediendo la velocidad especificada, y el

cubo de token Tp se actualiza como Tp = Tp - B.

Si el paquete se marca como conforme a la velocidad especificada, ambos cubos de

testigo (Tc y Tp) se actualizan como Tp = Tp - B y Tc = Tc - B.

Además de la limitación de la velocidad, la vigilancia del tráfico mediante la medición de

doble tarifa permite marcar el tráfico de acuerdo con si el paquete cumple, excede o

infringe una velocidad especificada. Dentro de estas tres categorías, los usuarios pueden

decidir el tratamiento de paquetes. Un ejemplo de manipulación del tratamiento de

paquetes podría estar configurando una política policial de tal manera que se transmitan

paquetes conformes, se transmitan paquetes excedentes con una prioridad disminuida y

se descartan paquetes que violan.

HERRAMIENTAS DE COLAS

Las herramientas de gestión de la congestión, incluidas las herramientas de cola, se

aplican a las interfaces que pueden experimentar congestión. Cada vez que los paquetes

entran en un dispositivo más rápido de lo que pueden salir, existe la posibilidad de

congestión y se aplican mecanismos de cola. Es importante señalar que, aunque las

herramientas de cola están en su lugar, se activan sólo cuando existe congestión. En

ausencia de congestión, los paquetes se envían tan pronto como llegan. Cuando la

congestión se produce, los paquetes deben ser almacenados en memoria temporal o cola

en el almacenamiento temporal para la programación posterior de estos paquetes

respaldados para mitigar la caída. La gestión de la congestión abarca tanto la cola como la

programación, como se muestra en la Figura 15-17.

437

La cola de espera (Queuing), que también se conoce como almacenamiento intermedio, es

la lógica de ordenar paquetes en los búferes de salida vinculados. Los procesos de colas se

activan cuando una interfaz experimenta congestionamiento y se desactivan cuando se

borra la congestión. A medida que las colas se llenan, los paquetes pueden reordenarse

para que los paquetes de mayor prioridad salgan del dispositivo antes que los de menor

prioridad.

La programación (Scheduling) es el proceso de decidir qué paquete enviar a continuación.

La programación, a diferencia de las colas, se produce independientemente de si la

interfaz está experimentando congestión.

Existe una larga historia de algoritmos de colas en el software Cisco IOS. Los métodos más

antiguos son insuficientes para las redes modernas de medios ricos porque son anteriores

a estos tipos de tráfico. Los métodos claves de colas heredadas, todos los cuales son

anteriores a la arquitectura MQC, incluyen

Cola FIFO: es una cola única con paquetes enviados en el orden exacto en que

llegaron.

Cola de prioridad: PQ es un conjunto de cuatro colas que se sirven en orden de

prioridad estricta. El principal inconveniente de este método es el potencial de

inanición del tráfico de menor prioridad.

Colas personalizadas: CQ es un conjunto de 16 colas con un planificador roundrobin.

Proporciona garantías de ancho de banda y evita el agotamiento, pero no

proporciona la estricta prioridad que se requiere para los flujos en tiempo real

sensibles al retardo.

Colocación de filas justas ponderadas: el algoritmo WFQ divide el ancho de

banda de la interfaz por el número de flujos ponderados por IP (prioridad IP) y

garantiza una distribución equitativa del ancho de banda para todas las

aplicaciones. Este método proporciona un mejor servicio para los flujos en tiempo

real de alta prioridad, pero carece de una garantía de ancho de banda para

cualquier flujo en particular.

Colocación de prioridad IP RTP: PQ-WFQ es un método transitorio que

proporciona una cola única de prioridad estricta para tráfico en tiempo real,

además de un complejo WFQ para otro tráfico. LLQ pronto reemplazó a PQ-WFQ.

Los mecanismos de cola actuales y más nuevos, recomendados y adecuados para las redes

de medios ricos y presentes en MQC, buscan combinar las mejores características de los

algoritmos anteriores y, al mismo tiempo, tratar de minimizar sus inconvenientes. El

tráfico en tiempo real y sensible al retardo requiere dos atributos de un algoritmo de

colas: una garantía absoluta de ancho de banda y una garantía de demora. En presencia de

tráfico en tiempo real, es crítico no mueran de hambre otros tipos de tráfico. Los

algoritmos de colas recomendados actuales incluyen

438

Colocación de filas justas ponderadas por clases: un algoritmo de colas CBWFQ

híbrido que combina una garantía de ancho de banda de CQ con una imparcialidad

dinámica con otros flujos dentro de una clase de tráfico de WFQ. No proporciona

una garantía de latencia y, como tal, sólo es adecuado para la gestión del tráfico de

datos.

Colas de baja latencia: El método LLQ añade una capacidad de prioridad estricta a

CBWFQ y por lo tanto es adecuado para mezclas de tráfico en tiempo real o no.

Proporciona latencia y garantías de ancho de banda.

Anillo tx (TX-ring)

La cola y la programación ocurren en varias capas para cualquier flujo particular de

tráfico. Los algoritmos de colas más sofisticados existen en la capa 3 y son independientes

del tipo de interfaz. Los métodos de cola de la capa 3 suelen considerar únicamente la

sobrecarga de paquetes IP en su aprovisionamiento de ancho de banda. En las plataformas

de enrutador Cisco IOS, la cola de la capa 3 también se puede configurar de forma

jerárquica para que una cascada de colas de la capa 3 suministre tráfico a las colas de capa

inferior.

La cola también ocurre en la Capa 2, para ciertos tipos de interfaz, para acomodar los

requisitos e idiosincrasias específicos de los medios, como las tecnologías más antiguas

para los circuitos ATM y Frame Relay. Cuando las colas de la capa 2 se llenan, a su vez

empujan los paquetes hacia atrás en las colas de la capa 3.

Una cola final, normalmente denominada anillo de transmisión (Tx-Ring), se encuentra

dentro del controlador de dispositivo de Capa 1. Los anillos Tx son dependientes del

medio y del hardware y pueden funcionar de forma muy diferente en diferentes

enrutadores, tarjetas y módulos. Cuando la cola Tx-Ring se llena, las colas de nivel

superior se presionan en servicio, y esto es esencialmente cuando QoS se activa en el

dispositivo.

La cola de nivel de controlador de dispositivo en la Capa 1 se realiza como el último punto

de salida antes de la transmisión. El mecanismo de cola de la capa 1, Tx-Ring, es una cola

FIFO relativamente pequeña y es el buffer de salida final para una interfaz WAN. Su

propósito es maximizar la utilización del ancho de banda del enlace físico haciendo

coincidir la velocidad de transmisión de salida con la velocidad de interfaz física. La Figura

15-18 ilustra la operación Tx-Ring.

439

Si el Tx-Ring se llena a capacidad, la interfaz se considera congestionada y el software

activa todas las políticas LLQ / CBWFQ que se han aplicado a la interfaz. El tamaño del Tx-

Ring depende del hardware, el software, el medio de capa 2 y el algoritmo de colas que se

configuran en la interfaz.

Colas justas (Fair Queuing)

WFQ fue desarrollado para resolver algunos de los problemas de los métodos básicos de

cola, como el hambre de la cola, el retraso y la fluctuación de fase. WFQ divide

dinámicamente el ancho de banda disponible mediante un cálculo que se basa en el

número total de flujos y el peso de cada flujo dado. El ancho de banda no puede

garantizarse porque el número de flujos está cambiando constantemente y por lo tanto

también lo es el ancho de banda asignado a cada flujo.

Cuando se utiliza la cola FIFO, el tráfico se envía en el orden en que se recibe sin tener en

cuenta el consumo de ancho de banda o los retardos asociados. Las transferencias de

archivos y otras aplicaciones de alto volumen pueden generar una serie de paquetes que

pueden consumir todo el ancho de banda disponible y efectivamente privar a otros flujos

de tráfico de ancho de banda.

La idea de WFQ es

Disponer de una cola dedicada para cada flujo que no da lugar a hambre, retraso o

jitter dentro de la cola

Asignar el ancho de banda de manera justa y precisa entre todos los flujos para

asegurar un retraso mínimo en el horario y un servicio garantizado

Utilizar prioridad IP como valor de peso al asignar ancho de banda

El planificador WFQ, ilustrado en la figura 15-19, es una simulación de un sistema TDM.

440

WFQ se adapta al número de flujos o colas activos en un intento de asignar cantidades

iguales de ancho de banda a cada flujo. Los flujos con paquetes pequeños, como los flujos

interactivos, obtienen un servicio mucho mejor porque no necesitan gran cantidad de

ancho de banda. Sin embargo, los flujos con paquetes pequeños tienen una necesidad de

retardo bajo, que WFQ acomoda naturalmente como resultado del algoritmo subyacente.

La clasificación de los flujos en WFQ es automática y no soporta clasificación manualmente

definida. El mecanismo de descarte no es de descarte de cola simple y en su lugar descarte

de paquetes de los flujos más agresivos.

Se identifica un flujo que se basa en información que se toma de la cabecera IP y los

encabezados TCP o UDP, como

Dirección IP de origen

Dirección IP de destino

Número de protocolo (identificando TCP o UDP)

Campo de ToS

Número de puerto de origen TCP o UDP

Número de puerto TCP o UDP de destino

WFQ proporciona un mecanismo simple para proporcionar rendimiento garantizado a

todos los flujos y es ampliamente soportado en las plataformas y versiones de software de

Cisco. Las limitaciones más obvias son que no soporta la configuración de la clasificación

explícita de tráfico o garantías de ancho de banda fijo.

CBWFQ

Las colas justas ponderadas basadas en clases (Class-based weighted fair queuing:

CBWFQ) son una extensión de WFQ que permite a los administradores de red crear una

política de colas específica para los requisitos de la red.

CBWFQ proporciona la capacidad de definir clases de tráfico que se basan en criterios de

coincidencia tales como protocolos, ACL e interfaces de entrada. Los paquetes que

satisfacen los criterios de coincidencia para una clase constituyen el tráfico para esa clase.

441

Se reserva una cola para cada clase y el tráfico perteneciente a una clase se dirige a esa

cola de clases.

Después de definir una clase de acuerdo con sus criterios de coincidencia, puede asignarle

características. Caracterizar una clase implica asignarle el ancho de banda mínimo al que

tendrá acceso durante los períodos de congestión. También puede especificar el límite de

cola para la clase, que es el número máximo de paquetes que se pueden acumular en la

cola de clases. Los paquetes pertenecientes a una clase están sujetos a los límites de ancho

de banda y cola que caracterizan a la clase. Después de que una cola haya alcanzado su

límite de cola configurado, lo que suceda a continuación depende de cómo se configura la

directiva de clase y si el manejo de paquetes adicionales a la clase provoca descarte al final

o descarte aleatorio de paquetes.

CBWFQ permite la creación de hasta 256 colas, sirviendo hasta 256 clases de tráfico. Cada

cola se da servicio basado en el ancho de banda asignado a la clase. CBWFQ se configura

utilizando la palabra clave bandwidth en un mapa de políticas. Con CBWFQ, un ancho de

banda mínimo se define explícitamente y se aplica. El ancho de banda se puede especificar

en términos absolutos o porcentuales.

Si se produce una congestión, el Tx-Ring de la capa 1 para la interfaz se llena y empuja los

paquetes de vuelta a las colas CBWFQ de la capa 3 si está configurado. A cada clase CBWFQ

se le asigna su propia cola. Las colas CBWFQ también pueden tener un preordenador de

cola justa aplicado usando la palabra clave fair-queue dentro de un mapa de políticas para

administrar múltiples flujos que compiten por una sola cola de forma justa. Además, cada

cola CBWFQ recibe servicio en una forma de round-robin (WRR) ponderada basada en el

ancho de banda asignado a cada clase. El programador CBWFQ envía los paquetes al Tx-

Ring..

La función LLQ agrega colas de prioridad estricta a CBWFQ. La cola de prioridad estricta

proporciona a datos sensibles al retardo como el tratamiento preferencial de voz y video

442

sobre otro tráfico, que este tráfico se deshaga y se envíe primero antes de que los paquetes

de otras colas se eliminen de la cola.

Aunque la cola justa ponderada proporciona una cuota equitativa de ancho de banda para

cada flujo y proporciona una programación justa de sus colas, no puede proporcionar

ancho de banda garantizado y un retardo bajo para seleccionar aplicaciones. Sin la

capacidad LLQ, el tráfico de voz aún puede competir con otros flujos agresivos en el

sistema de colas WFQ porque el sistema WFQ carece de programación de prioridad para

las clases de tráfico de tiempo crítico.

Para CBWFQ, el peso de un paquete perteneciente a una clase específica se deriva del

ancho de banda asignado a la clase cuando se configuró. Por lo tanto, el ancho de banda

asignado a los paquetes de una clase determina el orden en el que se envían los paquetes.

Si todos los paquetes se reparan bastante en función del peso, ninguna clase de paquetes

puede tener prioridad estricta. No tener una prioridad estricta plantea problemas para el

tráfico de voz porque es en gran medida intolerante de retraso y especialmente

intolerante de la fluctuación de fase.

LLQ permite el uso de una única cola de prioridad estricta dentro de CBWFQ a nivel de

clase. Esto introduce la capacidad de dirigir el tráfico que pertenece a una clase a la cola de

prioridad estricta CBWFQ. Colocar el tráfico de clase a la cola de prioridad estricta implica

configurar el comando priority para la clase después de especificar la clase con nombre

dentro de un mapa de políticas. Las clases a las que se aplica el comando de prioridad se

consideran clases de prioridad. Dentro de un mapa de políticas, puede asignar un estado

de prioridad a una o más clases. Cuando varias clases dentro de un solo mapa de políticas

se configuran como clases de prioridad, todo el tráfico procedente de estas clases se coloca

en cola en una única cola de prioridad estricta.

Todo el tráfico en tiempo real debe utilizar la cola de prioridad. La Figura ilustra tres

clases de tráfico en tiempo real todas las que se canalizan en la cola de prioridades de LLQ

mientras que otras clases de tráfico usan el algoritmo CBWFQ.

443

Pueden definirse varias clases de tráfico en tiempo real y separar las garantías de ancho

de banda proporcionadas a cada uno, pero una sola cola de prioridades programa todo ese

tráfico combinado. Al igual que con CBWFQ, puede configurar LLQ con asignaciones de

ancho de banda absolutas o basadas en porcentajes.

LLQ incluye un controlador implícito que limita el ancho de banda que puede ser

consumido por el tráfico en la cola en tiempo real y evita así el hambre de ancho de banda

de los flujos que no son en tiempo real atendidos por el planificador CBWFQ. La tasa para

esta política implícita es el ancho de banda asignado a la clase, y el tráfico que excede esta

tasa es la cola de descarte.

Cuando CBWFQ está configurado como sistema de colas, crea una serie de colas, en las que

clasifica las clases de tráfico. Estas colas se programan con un planificador tipo WFQ, que

puede garantizar el ancho de banda para cada clase.

Si se utiliza LLQ dentro del sistema CBWFQ, se crea una cola de prioridad adicional en el

sistema WFQ, que es atendida por un planificador de prioridad estricta. Por lo tanto,

cualquier clase de tráfico puede conectarse a una política de servicio, que utiliza la

programación de prioridades y, por lo tanto, puede priorizarse sobre otras clases.

HERRAMIENTAS DE DESCARTE

DSCP basado en WRED

444

Memoria de búfer es un recurso limitado en cualquier interfaz. Cuando se hace cola, los

búferes se llenan y los paquetes se pueden ser descartados a medida que llegan, lo que se

conoce como descarte de cola o se eliminan selectivamente antes de que se llenen todos

los búferes. El descarte selectivo de paquetes cuando las colas se están llenando se conoce

como prevención de congestión. Los algoritmos de cola controlan el frente de una cola y

los mecanismos de prevención de congestión gestionan el extremo de una cola.

Un enrutador puede manejar múltiples sesiones TCP simultáneas. Esto es muy probable

cuando el tráfico excede el límite de cola, excede este límite debido a la naturaleza de

ráfaga de paquetes. Sin embargo, existe también una alta probabilidad de que la

profundidad de tráfico excesiva causada por las ráfagas de paquetes sea temporal y que el

tráfico no se mantenga excesivamente profundo, excepto en los puntos donde se fusionan

los flujos de tráfico o en los enrutadores de borde.

Si el enrutador receptor descarta todo el tráfico que excede el límite de la cola, como se

hace por defecto con el descarte de cola, muchas sesiones TCP entran simultáneamente en

arranque lento. Por lo tanto, el tráfico se ralentiza temporalmente hasta el extremo y luego

todos los flujos de inician de nuevo, creando una condición llamada sincronización global.

La sincronización global ocurre cuando las ondas de la cresta de la congestión son

seguidas solamente por las vaguadas, durante las cuales el acoplamiento de la transmisión

no se utiliza totalmente. La sincronización global de los hosts TCP puede ocurrir porque

los paquetes se eliminan de una vez. La sincronización global se produce cuando múltiples

hosts TCP reducen sus tasas de transmisión en respuesta al descarte de paquetes. Cuando

la congestión se reduce, sus tasas de transmisión se incrementan. El punto más

importante es que las ondas de transmisión conocidas como sincronización global

resultan en subutilización significativa del enlace. La Figura muestra la utilización

subóptima de ancho de banda que la caída de cola tiene en el tráfico TCP.

Por esta razón, los mecanismos de prevención de congestión de descarte aleatorio son

mucho más eficaces en la gestión del tráfico TCP. Aunque esta cifra puede ser algo teórica,

ilustrará visualmente los efectos de la gestión de colas de tráfico TCP. En la práctica, estas

"olas" pueden ocurrir en mayor o menor medida dependiendo de las características reales

del tráfico y los patrones de flujo presentes.

445

La detección precoz aleatoria (Random early detection: RED) contrarresta los efectos de

la sincronización global de TCP mediante la eliminación aleatoria de paquetes antes de

que las colas se llenen hasta su capacidad. Quitar paquetes aleatoriamente en lugar de

descartarlos todos a la vez, como se hace en el descarte en la cola, evita la sincronización

global de los flujos TCP. RED supervisa la profundidad del búfer y realiza descartes o

caídas tempranas en paquetes aleatorios cuando se supera el umbral mínimo de cola. La

estrategia de abandono se basa principalmente en la longitud media de la cola, lo que

significa que RED será más probable que descarte un paquete entrante que cuando la

longitud media de la cola es más corta.

Nota Cisco IOS Software no admite RED puro; soporta RED ponderado. Sin embargo, si

todos los paquetes asignados a una interfaz o clase tienen las mismas marcas DSCP, la

política resultante efectiva es simplemente RED.

Debido a que RED descarta paquetes al azar, no tiene inteligencia por flujo. La razón es

que un flujo agresivo representará la mayor parte del tráfico que llega, por lo que es

probable que RED descarte un paquete de una sesión agresiva. RED castiga las sesiones

más agresivas con una mayor probabilidad estadística y de alguna manera retrasa

selectivamente la causa más significativa de la congestión. Dirigir una sesión TCP a la vez

para ralentizar permite la utilización total del ancho de banda, en lugar de la utilización

que se manifiesta como crestas y valles de tráfico.

Como resultado de la implementación de RED, el problema de la sincronización TCP global

es menos probable que ocurra, y TCP puede utilizar el ancho de banda del enlace de

manera más eficiente. En las implementaciones RED, el tamaño medio de la cola también

disminuye significativamente, ya que la posibilidad de llenar la cola se reduce. Este

tamaño de cola más pequeño se debe a una caída muy agresiva en caso de ráfagas de

tráfico, cuando la cola ya está bastante llena.

RED distribuye las pérdidas en el tiempo y normalmente mantiene una baja profundidad

de cola mientras absorbe los picos de tráfico. La probabilidad de que un paquete se

descarte se basa en tres parámetros configurables que están contenidos en el perfil de

RED:

Umbral mínimo: cuando la longitud media de la cola es igual o superior al umbral

mínimo, RED comienza a descartar paquetes. La velocidad de las gotas aumenta

linealmente a medida que aumenta el tamaño medio de la cola, hasta que el tamaño

promedio de la cola alcanza el umbral máximo.

Umbral máximo: cuando el tamaño medio de la cola está por encima del umbral

máximo, todos los paquetes se eliminan.

Denominador de probabilidad de marca: Este valor es la fracción de paquetes

que se descartan cuando la profundidad media de cola está en el umbral máximo.

Por ejemplo, si el denominador es 512, uno de cada 512 paquetes se descarta

cuando la cola media está en el umbral máximo. El incremento lineal de las gotas de

446

paquetes desde el umbral mínimo (0 gotas) hasta el umbral máximo se basa en este

parámetro y el tamaño de la cola entre los umbrales mínimo y máximo.

El valor umbral mínimo debe establecerse lo suficientemente alto como para maximizar la

utilización del enlace. Si el umbral mínimo es demasiado bajo, los paquetes pueden

descartarse innecesariamente y el enlace de transmisión no se utilizará completamente.

La diferencia entre el umbral máximo y el umbral mínimo debe ser lo suficientemente

grande como para evitar la sincronización global. Si la diferencia es demasiado pequeña,

muchos paquetes pueden ser eliminados de una vez, lo que resulta en una sincronización

global.

La probabilidad de marca tiene el efecto de controlar el número de paquetes que se

descartan cuando la longitud media de la cola alcanza el umbral máximo. Si el valor es

demasiado bajo, resultará en demasiados paquetes perdidos. Si el valor es demasiado

grande, el descarte RED puede ser ineficaz.

Basado en el tamaño medio de la cola, RED tiene tres modos de caída:

Sin descarte: Cuando el tamaño medio de la cola está entre 0 y el umbral mínimo

configurado, no se producen descartes y todos los paquetes se ponen en cola.

Descarte aleatorio: cuando el tamaño medio de la cola está entre el umbral

mínimo configurado y el umbral máximo configurado, se producen descartes

aleatorios, que son linealmente proporcionales al denominador de probabilidad de

la marca y la longitud media de la cola.

Descarte total (descarte de cola): cuando el tamaño medio de la cola es igual o

superior al umbral máximo, RED realiza una caída completa en la cola. Esta caída

de cola es improbable porque RED debería retrasar el tráfico TCP antes de la

congestión. Si hay mucho tráfico no TCP, RED no puede eliminar eficazmente el

tráfico para reducir la congestión y es probable que se produzcan caídas de cola.

La idea detrás del uso de WRED es mantener la longitud de la cola en un nivel entre los

umbrales mínimo y máximo e implementar diferentes políticas de descarte para

diferentes clases de tráfico. WRED puede descartar selectivamente el tráfico de menor

prioridad cuando la interfaz se congestiona, y puede proporcionar características

447

diferenciadas de rendimiento para diferentes clases de servicio. También puede

configurar WRED para lograr un comportamiento RED no ponderado.

WRED puede utilizar múltiples perfiles RED distintos, donde cada perfil se identifica por el

umbral mínimo, el umbral máximo y la probabilidad de descarte máximo. La selección del

perfil WRED podría, por ejemplo, ser seleccionada en función de los valores DSCP, como se

muestra en la Figura.

WRED reduce las posibilidades de descarte de la cola por caída selectiva de paquetes

cuando la interfaz de salida comienza a mostrar signos de congestión. Al descartar algunos

paquetes antes que esperar hasta que la cola esté llena, WRED evita el descarte de un gran

número de paquetes a la vez y minimiza las posibilidades de sincronización global. Como

resultado, WRED maximiza la utilización de líneas de transmisión.

WRED es útil sólo cuando la mayor parte del tráfico es tráfico TCP. Cuando se transmite

TCP, los paquetes perdidos indican congestión, por lo que la fuente de paquetes reduce su

velocidad de transmisión. Con otros protocolos, los paquetes de fuentes pueden no

responder o continúan reenviando los paquetes eliminados a la misma velocidad y, por lo

tanto, la eliminación de paquetes podría no disminuir la congestión.

El enrutador actualiza constantemente el algoritmo WRED con la longitud de cola media

calculada, que se basa en el historial reciente de longitudes de cola.

Además, en el perfil de tráfico existen parámetros para definir las características de

descarte que WRED utiliza, como el umbral mínimo, el umbral máximo y el denominador

de probabilidad de marca. Estos parámetros definen las pendientes de probabilidad

WRED. La Figura ilustra WRED en acción.

448

Cuando un paquete llega a la cola de salida, el valor de marcado QoS se utiliza para

seleccionar el perfil WRED correcto para el paquete. El paquete se pasa a WRED para su

procesamiento. Basándose en el perfil de tráfico seleccionado y la longitud media de la

cola, WRED calcula la probabilidad de descartar el paquete actual. Si la longitud media de

la cola es mayor que el umbral mínimo pero menor que el umbral máximo, WRED pondrá

en cola el paquete o realizará un descarte aleatorio. Si la longitud media de la cola es

menor que el umbral mínimo, el paquete se pasa a la cola de salida.

Si la cola ya está llena, el paquete queda descartado. De lo contrario, el paquete se

transmitirá finalmente a la interfaz.

Los perfiles WRED se pueden configurar manualmente. Para evitar la necesidad de

configurar todos los parámetros WRED en un enrutador, se definen 64 valores para WRED

basado en DSCP. Por lo tanto, la configuración predeterminada debería ser suficiente en la

mayoría de las implementaciones. Como se ilustra en la Figura 15-26, WRED basado en

Cisco IOS DSCP se configura por defecto para que el umbral mínimo para EF DiffServ sea

alto, aumentando la probabilidad de que no se apliquen gotas a esa clase de tráfico.

449

Se espera que el tráfico EF sea abandonado tarde, en comparación con otras clases de

tráfico, y el tráfico EF se prioriza en caso de congestión.

Hay cuatro clases de AF definidas. Cada clase debe ser tratada de forma independiente y

tener ancho de banda asignado que se basa en la política QoS. Para cada clase de tráfico AF

DiffServ, WRED basado en Cisco IOS DSCP se configura por defecto para tres perfiles

diferentes, dependiendo de los bits de preferencia de descarte. Todas las clases de AF

están inicialmente marcadas con Preferencia de descarte 1 (preferencia de descarte más

baja), pero en los políticas de tráfico pueden anotar las clases a Preferencia de descarte 2 o

3, si las clases están excediendo o violando tasas de tráfico definidas administrativamente.

La Tabla enumera los perfiles EF y AF.

Tabla de Perfiles EF y AF

Clase de reenvío garantizado Probabilidad de caída (Clase) DSCP

Mínimo predeterminado Límite

Clase EF (EF) 101110 36

Clase AF 1 Bajo (AF11) 001010 32

Medio (AF12) 001100 28

Alto (AF13) 001110 24


Medio (AF22) 010100 28

Alto (AF23) 010110 24

Clase de reenvío garantizado Probabilidad de

caída

(Clase) DSCP Mínimo predeterminado

Límite


Medio (AF32) 011100 28

Alto (AF33) 011110 24


Medio (AF42) 100100 28

Alto (AF43) 100110 24

IP ECN

450

TCP determina cuántos paquetes no reconocidos puede enviar aumentando

paulatinamente el número de paquetes que la sesión envía hasta que experimenta un

paquete descartado; este ajuste se conoce como ventana TCP. Como resultado de este

proceso, TCP tiende a hacer que las colas del enrutador se acumulen en puntos de cuello

de botella de la red. Cuando las colas se llenan, el descarte de cola comienza a descartar

todos los paquetes entrantes hasta que haya espacio en la cola. El descarte de cola no

proporciona tratamiento diferencial, y por lo tanto, algunos de los paquetes de flujo

frágiles, que son sensibles a la latencia, pueden ser eliminados. Además, el descarte de cola

puede llevar a la sincronización global de la pérdida de paquetes a través de múltiples

flujos, como se destacó en la sección anterior.

Los mecanismos activos de gestión de colas como WRED detectan la congestión antes de

que las colas se llenen y se desborden. Como resultado de descartar selectivamente los

paquetes, estos mecanismos proporcionan indicación de congestión a los nodos finales.

Por lo tanto, los mecanismos activos de gestión de colas y de evitación de la congestión

pueden reducir los retrasos de colas para todo el tráfico que comparte una cola específica.

Además, la gestión de colas activa significa que ya no es necesario confiar en el

desbordamiento de búfer como el único medio de indicar la congestión.

El descarte de paquetes en estos mecanismos se basa en la longitud media de la cola que

excede un umbral predefinido, en lugar de sólo cuando el desbordamiento de colas. Sin

embargo, debido a que los paquetes se descartan antes de que las colas se desborden

realmente, el enrutador que abandona el paquete no siempre está limitado por las

limitaciones de memoria y es necesario eliminar el paquete.

La notificación de congestión explícita (ECN) permite a los dispositivos de red marcar un

bit ECN para notificar a los hosts que se ha experimentado congestión. En los enrutadores

IOS de Cisco, ECN es una extensión de la funcionalidad WRED.

WRED es un mecanismo de gestión de colas activo que utiliza descarte por gotas de

paquetes como indicador de congestionamiento para puntos finales. Los paquetes son

eliminados por WRED basado en la longitud media de la cola que excede un conjunto

específico de valores de umbral predefinidos (umbrales mínimo y máximo). ECN es una

extensión de WRED, en que ECN marca paquetes en lugar de descartarlos cuando la

longitud media de la cola excede un valor de umbral específico. Con la RFC 3168, la adición

de ECN a la gestión de colas IP activa permite a los enrutadores para señalar que el

enrutador ha experimentado la congestión en lugar de confiar en el uso de descarte por

gotas de paquetes. Cuando se utiliza la señalización de congestión, los flujos agresivos

pueden ser ralentizados, reduciendo así el impacto de la congestión y la pérdida de

paquetes en los flujos sensibles a la latencia.

451

El campo ECN consiste en los dos últimos bits de orden inferior del campo DiffServ. Estos

últimos dos bits son el bit ECT y el bit CE. Las diferentes combinaciones de bits ECT y CE

en el campo ECN tienen los siguientes significados:

00: Esta combinación de campo ECN indica que un paquete no está utilizando ECN.

01 y 10: Estas combinaciones de campos ECN, llamadas ECT (1) y ECT (0),

respectivamente, son establecidas por el emisor de datos para indicar que los

puntos extremos del protocolo de transporte son compatibles con ECN. Los

enrutadores tratarán estas dos combinaciones de campo de forma idéntica. Los

remitentes de datos pueden utilizar una o ambas de estas dos combinaciones.

11: Esta combinación de campos ECN indica a los puntos finales que la congestión

ha sido experimentada y que los paquetes que llegan a una cola completa de un

enrutador se eliminarán.

Cuando ECN está configurado con WRED, los enrutadores y los hosts finales usan esta

marca como una señal de que la red está congestionada y ralentizarán la velocidad a la que

se envían los paquetes. Además, la ECN debe ser interoperable con dispositivos no

compatibles con ECN. Dado que ECN está configurado como una extensión de WRED, los

paquetes son tratados de forma diferente por WRED cuando se ha habilitado ECN.

Si la longitud media de la cola está por debajo del umbral mínimo WRED definido, todos

los paquetes se ponen en cola y se transmiten normalmente. Este comportamiento es

idéntico a los dispositivos que están configurados para utilizar WRED no habilitado para

ECN. Si la longitud media de la cola es mayor que el umbral máximo, los paquetes son cola

caída. Este comportamiento es idéntico a los dispositivos que están configurados para

utilizar WRED no habilitado para ECN. Si el número de paquetes en la cola está entre el

umbral mínimo y el umbral máximo, se producirá uno de estos escenarios:

Si el campo ECN del paquete indica que los puntos finales son compatibles con ECN,

lo que significa que el bit ECT se establece en 1 y el bit CE se pone a 0 o el bit ECT se

452

pone a 0 y se establece el bit CE A 1, y el algoritmo WRED determina que el paquete

debería haberse descartado en función de la probabilidad de descarte, se utiliza el

proceso ECN en lugar del paquete que se está eliminando.

Si el campo ECN del paquete indica que ninguno de los extremos tiene capacidad de

ECN, lo que significa que el bit ECT está puesto a 0 y el bit CE está puesto a 0, el

paquete puede descartarse en base a la probabilidad de descarte WRED. Esta

acción es el tratamiento idéntico que recibe un paquete cuando WRED está

habilitado sin ECN configurado en el enrutador.

Los siguientes pasos (ilustrados en la Figura 15-28) explican cómo la señalización ECN

puede evitar la caída de paquetes haciendo que un host que esté transmitiendo paquetes

TCP reduzca su velocidad de transmisión:

1. El remitente (host A) establece los bits ECN en los encabezados IP de todos los

paquetes de datos en 01 o 10 para indicar a la red que es capaz de participar en

ECN.

2. Si las siguientes condiciones existen, el enrutador establece los bits ECN a 11

(Congestion Experienced) y envía el paquete al receptor (host B):

a. El campo ECN en el paquete indica que los puntos finales son aptos para

ECN.

b. La red está congestionada o la congestión es inminente.

c. El algoritmo WRED determina que el paquete debe caerse en función de la

probabilidad de caída.

3. Cuando el anfitrión B ve la marca 11 (Congestion Experienced), establece un

indicador ECE Eco ECE de bits en el encabezado TCP del siguiente paquete que

devuelve al host A. El propósito de este indicador es decirle al host A que se

desacelere Sus transmisiones.

453

4. Cuando el host A recibe el paquete con el indicador ECE, reduce su ventana de

congestión para disminuir su velocidad de transmisión. A continuación, el host A

establece un indicador de bit de reducción de la congestión reducida (CWR) en el

encabezado TCP del primer paquete nuevo que envía al host B. Este indicador

informa al host B que el host A ha reducido su ventana y reducido la transmisión.

ECN tiene las siguientes características:

Los controles de congestión TCP no son adecuados para aplicaciones sensibles al

retardo o la pérdida de paquetes.

Elimina la necesidad de confiar en la pérdida de paquetes como un indicador de

congestión.

Marca los paquetes en lugar de soltarlos cuando la longitud media de la cola excede

un valor de umbral específico.

Permite a los enrutadores y hosts finales utilizar la marca ECN como una señal de

que la red está congestionada y enviará paquetes a un ritmo más lento.

454

Capítulo 16

Principios de Diseño de

QoS y Mejores

Prácticas

455

VISIÓN GENERAL DE QOS

La calidad del servicio es fundamental para asegurar la consistencia del rendimiento de las

aplicaciones y las experiencias optimizadas del usuario final. El propósito fundamental de

la QoS es gestionar la contención de los recursos de la red mientras que los Principios de

Diseño QoS y las Mejores Prácticas abordan las aplicaciones que requieren niveles

diferenciados de servicio. Antes de desarrollar una estrategia QoS, debe realizar el

descubrimiento adecuado para identificar las aplicaciones actuales y futuras y las

características de la aplicación dentro del entorno. Esta información, junto con una

comprensión del diseño de la red de extremo a extremo y los patrones de tráfico,

impulsará el modelo de estrategia de diseño QoS que es más apropiado para el negocio.

Las siguientes son algunas preguntas comunes que usted necesita responder:

¿Qué tráfico necesita ser clasificado y marcado?

¿Es posible aprovechar un modelo de estrategia QoS de extremo a extremo de clase

4, clase 8 o clase 12?

¿Se mantendrán las características de marcado de tráfico a medida que los datos

atraviesen la infraestructura?

¿Qué tráfico debe priorizarse?

¿Qué tráfico requiere reservas de ancho de banda?

¿Qué tráfico necesita ser vigilado?

¿Es necesaria el perfilado de tráfico en el borde de la WAN o en otros lugares

dentro de la infraestructura, como el Data Center Interconnect (DCI)?

¿Cómo pueden aprovecharse las técnicas de gestión de la congestión y de evitación

de la congestión para optimizar el tráfico TCP?

PRINCIPIOS DE DISEÑO DE LA CLASIFICACIÓN Y EL MARCADO

El primer principio de diseño fundamental es que las políticas de QoS deben estar

habilitadas en el hardware siempre que sea posible. Algunos enrutadores Cisco realizan

QoS en el software, y tal comportamiento puede aumentar la carga en la CPU. Los switches

Cisco Catalyst tienen hardware dedicado llamado circuitos integrados específicos de la

aplicación (ASIC), que se utilizan para realizar operaciones QoS. Los switches pueden

realizar políticas QoS complejas bajo carga máxima de tráfico sin ningún pico marginal de

la CPU. Algunas plataformas, como Cisco ASR, pueden realizar operaciones QoS (como

colas) en ASICs de hardware dedicado, pero otras funciones (como la inspección profunda

de paquetes) todavía se procesan en software a través de la CPU.

Basándose en las recomendaciones de diseño, la clasificación y el marcado deben

realizarse de la manera más administrativa y técnica posible. Este principio de diseño

promueve los comportamientos DiffServ y per-hop (PHB) como el diseño recomendado de

extremo a extremo.

456

Por regla general, no se recomienda confiar en las marcas establecidas por los usuarios

finales aprovechando PCs u otros dispositivos de punto final. Los usuarios finales pueden

abusar intencional o involuntariamente de las políticas de QoS que confían en las marcas

de los dispositivos finales. Si los usuarios y las aplicaciones sin clasificar se aprovechan de

la política de QoS configurada como resultado de confiar en los dispositivos finales, esto

puede resultar en colas de prioridad de hambre con tráfico no prioritario, arruinando la

calidad del servicio para aplicaciones en tiempo real. Sin embargo, si las marcas QoS para

dispositivos finales y aplicaciones asociadas se administran centralmente en toda la

empresa, puede ser una opción de diseño aceptable. Un área adicional de excepción

también podría incluir dispositivos inalámbricos que pueden aprovechar el

aprovisionamiento de QoS de Multimedia Inalámbrico (WMM) en la dirección ascendente.

La otra recomendación importante es utilizar el marcado DSCP (Differentiated Services

Code Point) cuando sea técnicamente posible. Las marcas DSCP son el método

recomendado para marcar tráfico IP por las siguientes razones:

Tiene soporte para la marcación de capa a extremo de extremo a extremo.

Es un método más granular de marcado que soporta 64 niveles en comparación

con la clase de servicio (CoS) y MPLS Experimental EXP, que tienen 8 niveles.

Es más extensible que las marcas de la capa 2, ya que estas marcas se pierden

cuando cambia el medio.

Para proporcionar interoperabilidad en la frontera entre empresas y proveedores de

servicios, debe utilizar marcas DSCP PHB basadas en estándares porque el uso de dichas

marcas puede agilizar la interoperabilidad y la cooperación con las clases de servicio del

proveedor de servicios.

PRINCIPIOS DE DISEÑO DE VIGILANCIA Y MARCADO

457

El tráfico que no es deseado debe descartarse tan pronto como sea posible para preservar

los recursos de red del consumo innecesario. El tráfico no deseado puede ser el resultado

de ataques de denegación de servicio (DoS) o de gusanos. Además, el excesivo tráfico no

deseado podría provocar una interrupción de la red como resultado de un alto impacto en

la CPU y en los recursos de memoria de los dispositivos de red. El tráfico malicioso puede

enmascararse bajo puertos TCP / UDP legítimos que son utilizados por aplicaciones bien

conocidas, y este tráfico puede crear grandes cantidades de tráfico no deseado. El

comportamiento del tráfico debe ser monitoreado y marcado lo más cerca posible de la

fuente en tales circunstancias.

El tráfico debe ser marcado usando las recomendaciones de los RFC. Estas

recomendaciones aseguran la interoperabilidad y el diseño de la red QoS de extremo a

extremo. Ejemplos de estas recomendaciones son RFC 2597 y RFC 2698, donde el exceso

de tráfico con marcado de AFx1 debe ser marcado a AFx2 o AFx3. Obsérvese que 2 o 3 en

AFx2 y AFx3 representan probabilidad de caída. Este principio de reducción debe

combinarse adecuadamente con otras herramientas de QoS. Por ejemplo, con el WRED

basado en DSCP, el AFx2 debe caerse de forma más agresiva que el AFx1 pero de forma

menos agresiva que el AFx3.

PRINCIPIOS DE DISEÑO DE COLAS

La única forma de ofrecer garantías de servicio QoS a las aplicaciones críticas de la

empresa es habilitar la puesta en cola a cada nodo que tenga el potencial de congestión. La

cola debe estar habilitada independientemente de si la congestión se está produciendo

rara vez o con frecuencia. Aunque se despliega frecuentemente en el extremo de la WAN,

este principio debe aplicarse no solo a los enlaces WAN conectados, sino también dentro

de la red del campus. Las relaciones de desaceleración de velocidad, enlace de agrupación

y de suscripción de enlace pueden crear congestión en los dispositivos de red llenando

buffers de cola.

458

Como cada clase de aplicación distintiva requiere requisitos de servicio QoS únicos, se

recomienda que proporcione una cola distintiva para cada clase de tráfico. Una de las

principales justificaciones para apalancar colas distintivas es que cada clase de servicio

QoS puede aceptar ciertos comportamientos QoS habilitados tales como asignación de

ancho de banda y proporciones de caída.

Se recomienda utilizar un mínimo de cuatro comportamientos de colas basados en

estándares en todas las plataformas y enlaces de proveedores de servicios al implementar

QoS de extremo a extremo en toda la infraestructura de red:

RFC 3246 Expedited Forwarding PHB (utilizado para el tráfico en tiempo real)

RFC 2597 Assured Forwarding PHB (utilizado para la cola garantizada de ancho de banda)

RFC 2474 Default Forwarding PHB (cola predeterminada no prioritarios, mejor esfuerzo)

RFC 3662 Lower Effort Per-Domain Behavior (menos que cola mejor esfuerzo, el ancho de

banda limitado)

PRINCIPIOS DE DISEÑO DEL DESCARTE

Los mecanismos de prevención de congestión se utilizan para eliminar selectivamente los

paquetes cuando se alcanza un límite predefinido. Al eliminar los paquetes de forma

anticipada, la prevención de congestión ayuda a evitar los cuellos de botella en la red. Los

mecanismos para evitar la congestión incluyen RED y WRED. Si WRED está diseñado para

que cada clase de tráfico tenga su propia cola, WRED debe usarse sólo para algunos tipos

de colas (no necesariamente todas).

Se recomienda que WRED no se utilice para la cola de prioridad estricta, la cola de tareas

de scavenger y la cola de tráfico de control. El tráfico de la cola de prioridad estricta y de

control es altamente sensible a las pérdidas. El tráfico Scavenger es a menudo

aprovisionado con una pequeña cantidad de ancho de banda, por lo general por debajo del

1 por ciento, y para este tipo de cola, WRED no es necesario. Teniendo en cuenta que la

función WRED se realiza en software, la habilitación de WRED para la clase de tráfico

scavenger consumirá recursos adicionales de CPU sin ganancia significativa.

Para las colas marcadas AF con WRED basado en DSCP, típicamente el tráfico marcado con

AFx3 es abandonado más agresivamente que AFx2, que a su vez es más abandonado

agresivamente que AFx1.

Todos los tipos de tráfico que no se definen explícitamente en otras colas caen en la clase

de tráfico predeterminada (DF). Para esta clase de tráfico, se recomienda activar WRED.

WRED debe estar habilitado en la cola predeterminada porque aumenta el rendimiento

459

reduciendo el efecto de sincronización TCP. En el caso de la cola por defecto donde todos

los diferentes tipos de tráfico están igualmente marcados con un valor DSCP de cero, no

hay ningún mecanismo para sopesar las aplicaciones menos agresivas cuando WRED no

está habilitado.

PRINCIPIOS DE DISEÑO DE COLAS DE COMPORTAMIENTO POR

SALTO

El objetivo de la convergencia en la red es permitir que las aplicaciones de voz, vídeo y

datos coexistan de manera transparente en la red, proporcionando a cada uno las

expectativas y garantías del servicio QoS adecuado.

Cuando las aplicaciones en tiempo real son las únicas que consumen el ancho de banda del

enlace, el rendimiento de las aplicaciones en tiempo real se puede degradar

considerablemente. Los resultados de pruebas extensas muestran que hay un impacto

significativo en el rendimiento en aplicaciones que no son en tiempo real cuando más de

un tercio de los enlaces son utilizados por aplicaciones en tiempo real como parte de una

cola de prioridad estricta. Por lo tanto, se recomienda que no más de un tercio del ancho

de banda del enlace se utilice para colas de prioridad estricta. Este principio evita que las

aplicaciones que no son en tiempo real se eliminen de las recomendaciones de QoS

requeridas. En otras palabras, se recomienda que no se use más del 33 por ciento del

ancho de banda para la cola de envío expedito (EF). También es importante señalar que

este principio de diseño del 33 por ciento es simplemente una recomendación de diseño

de mejores prácticas y no necesariamente una regla obligatoria.

Se recomienda que al menos una cola se aprovisione para un comportamiento de reenvio

seguro por salto (AF PHB), pero se pueden definir hasta cuatro subclases dentro de la

clase AF: AF1x, AF2x, AF3x y AF4x. Cada cola perteneciente a la subclase AF especificada

debe tener una garantía de ancho de banda que corresponda a los requisitos del tráfico de

la aplicación de esa subclase.

La clase de reenvío predeterminada (DF) consiste en todo el tráfico que no se define

explícitamente en otras colas. Si una empresa está utilizando muchas aplicaciones, es

importante tener un espacio adecuado para esos tipos de tráfico. Se recomienda que,

típicamente, el 25% del ancho de banda del enlace se utilicen para esta clase de servicio.

460

Recomendación QoS de RFC 4594

RFC 4594 QoS proporciona directrices para el marcado, la cola, y principios de descarte

para diferentes tipos de tráfico. Cisco ha hecho una modificación de menor importancia a

su adopción de RFC 4594, cambiando el nombre de conmutación de señalización de

llamadas y señales de vídeo de difusión (a CS3 y CS5, respectivamente).

RFC 4594 es la recomendación, pero no el estándar; reside en la categoría de propuesta de

borrador RFC. Recomienda directrices sobre cómo configurar 14 clases de tráfico que

461

están asociadas con 28 valores de marcado de puntos de código diferentes. RFC 4594

incluye información sobre qué PHBs debe utilizarse para ciertos tipos de tráfico y también

qué cola y mecanismo de descarte debe ser utilizado para esa misma clase de tráfico.

Algunas recomendaciones incluyen

El tráfico de voz debe marcarse con EF / DSCP 46.

La voz debe estar en cola utilizando colas de prioridad estricta.

El tráfico de video de difusión debe estar marcado en CS5 / DSCP 40.

Las conferencias multimedia deben tratarse con un PHB AF, provisto de una cola de

ancho de banda garantizado.

RFC 4594 no es un estándar final RFC y es más que probable que continúe desarrollándose

teniendo en cuenta que las necesidades y las tendencias de los requisitos de aplicación

QoS cambian con el tiempo.

MODELOS DE ESTRATEGIA DE QOS

Antes de aplicar cualquier herramienta de QoS, las organizaciones deben definir la

estrategia y los objetivos de las diferentes aplicaciones que se ejecutan en su red. Esto

resultará en la definición de un cierto número de clases de tráfico para cumplir con los

objetivos de QoS de extremo a extremo de una organización.

Se pueden implementar tres modelos básicos de estrategia de QoS, dependiendo de la

granularidad de las implementaciones que se ejecutan dentro de la red de una

organización:

Modelo de estrategia de QoS de 4 clases

Modelo de estrategia QoS de 8 clases

Modelo de estrategia de QoS de 12 clases

Aunque más clases se definen, el tratamiento de tráfico más específico y granular será por

aplicación, la selección de un modelo de estrategia determinado debe basarse en los

requisitos de la aplicación junto con el modelo de QoS del proveedor de WAN (si hay WAN

con QoS).

Estrategia de QoS de 4 Clases

El modelo de estrategia QoS de 4 clases es el más simple de los tres modelos (en términos

de políticas de QoS) y suele dar cuenta de los datos de telefonía, señalización,

transaccional / misión crítica y mejor esfuerzo. Cuando las empresas implementan

462

aplicaciones de telefonía en su red, normalmente se requieren tres clases de tráfico

(telefonía, señalización y predeterminado / mejor esfuerzo).

Normalmente, la cuarta clase es la clase de reenvío garantizado (AF). La clase AF se utiliza

para aplicaciones de datos transaccionales y de misión crítica, como bases de datos SQL.

La clase AF también se puede utilizar para conferencias multimedia, transmisión

multimedia y datos en masa.

El modelo de estrategia QoS de 4 clases, es un ejemplo de una organización ha desplegado

la telefonía IP. Además de separar la telefonía, la señalización y el tráfico por defecto /

mejor esfuerzo, la organización ha definido una clase de datos interactivos de misión

crítica.

Las cuatro clases de tráfico de marcas y garantías de QoS son las siguientes:

Voz (tiempo real): Marcado con EF y provisto para aprovechar hasta un tercio del

ancho de banda del enlace

Señalización: Marcado con CS3 y provisto para aprovechar al menos un 7% del

ancho de banda del enlace

Datos de misión crítica (Transactional Data): marcados con AF31 y

provisionados para aprovechar el 35% del ancho de banda del enlace

Predeterminado (datos de mejor esfuerzo): Marcado con DF y provisto para

aprovechar el 25% del ancho de banda del enlace

Las garantías de voz y señalización deben seleccionarse basándose en el volumen de

llamadas de voz y el códec VoIP que se utiliza a través del enlace dado. Los datos críticos

para la misión se seleccionan basándose en la decisión del director de cada departamento

de la empresa que ha proporcionado información sobre las necesidades críticas de la

aplicación comercial al equipo de redes.


463

El modelo de estrategia QoS de 8 clases se basa en el modelo de 4 clases e incluye las

siguientes clases adicionales:

Conferencias multimedia

Transmisión multimedia

Control de red

Basurero

Los dos tipos de tráfico multimedia adicionales en este modelo son conferencias

multimedia y transmisión multimedia. La clase de tráfico de control de red explícitamente

definida se utiliza para aplicaciones tales como actualizaciones de protocolo de

enrutamiento de red o tráfico de control de infraestructura de red como OAM.

Las recomendaciones para cada clase de tráfico en este modelo son las siguientes:

Voz: Marcado con EF y limitado al 10% del ancho de banda del enlace en una cola

de prioridad estricta

Conferencias multimedia (vídeo interactivo): Marcado con AF41 o a veces como

EF y limitado al 23% del ancho de banda del enlace en una cola de prioridad

estricta

Flujo multimedia: Marcado con AF31 y garantizado 10% del ancho de banda del

enlace con WRED habilitado

Control de red: Marcado con CS6 y garantizado 5% del ancho de banda del enlace

Señalización: marcado con CS3 y provisto con un mínimo de 2% del ancho de

banda del enlace

Datos transaccionales: Marcado con AF21 y provisto con 24% de ancho de banda

de enlace con WRED activado

Predeterminado (datos de mejor esfuerzo): Marcado con DF y provisto con el

25% del ancho de banda del enlace

Scavenger: Marcado con CS1 y provisto con un máximo de 1% del ancho de banda

del enlace

464


El modelo de estrategia de QoS de 12 clases se basa en el modelo de 8 clases e incluye las

siguientes clases adicionales:

Interactivo en tiempo real

Vídeo de difusión

Gestión / OAM

Datos voluminosos

El modelo de estrategia QoS de 12 clases representa la interpretación de Cisco de la

recomendación RFC 4594 y, como se ha señalado anteriormente, incorpora una ligera

modificación intercambiando las marcas utilizadas para la señalización y difusión de

vídeo.

Las recomendaciones para cada clase de tráfico en este modelo son las siguientes:

Voz: Marcado con EF y limitado al 10 por ciento del ancho de banda del enlace en

una cola de prioridad estricta.

Vídeo de difusión: Marcado con CS5 o a veces como EF y limitado al 10% del

ancho de banda del enlace en una cola de prioridad estricta.

Interactivo en tiempo real: Marcado con CS4 o a veces como EF y limitado al 13

por ciento del ancho de banda del enlace en una cola de prioridad estricta.

Conferencia multimedia: Marcado con AF41 o a veces como EF y limitado al 10

por ciento del ancho de banda del enlace en una cola de prioridad estricta.

Flujo multimedia: Marcado con AF31 y garantizado 10% del ancho de banda del


Control de red: Marcado con CS6 y provisto como ancho de banda garantizado 2%

del ancho de banda del enlace

Señalización: marcado con CS3 y provisto de un mínimo de 2% de ancho de banda

de enlace

465

Gestión / OAM: Marcado con CS2 y provisto con un mínimo de 3% del ancho de

banda del enlace

Datos transaccionales: Marcado con AF21 y provisto con 10% del ancho de banda

del enlace con WRED habilitado

Datos masivos: Marcado con AF11 y provisto con 4% del ancho de banda del


Predeterminado (datos de mejor esfuerzo): Marcado con DF y provisto con el

25% del ancho de banda del enlace

Scavenger: Marcado con CS1 y provisto con un máximo de 1% del ancho de banda

del enlace.

466

Capítulo 17

Diseño del QoS del

Campus, WAN y Data

Center

467

DESCRIPCIÓN GENERAL DE LA QOS DEL CAMPUS

El objetivo principal de una QoS de campus no es administrar la latencia o la fluctuación

de fase, sino hacer frente a la pérdida de paquetes cuando se almacenan en los buffers de

los dispositivos de red. Los dispositivos finales actuales tienen en su mayoría conexiones

de 1 Gbps a la capa de acceso. Con un gran número de puntos finales funcionando

simultáneamente, es fácil llenar los búferes y provocar pérdidas de paquetes. Incluso con

tarjetas de línea de gran alcance en los conmutadores de núcleo, los búferes se pueden

rellenar en unos pocos milisegundos. Las aplicaciones en tiempo real, como el vídeo de

alta definición, podrían sufrir incluso las descargas de paquetes de baja velocidad.

Sorprendentemente, los usuarios de video HD pueden discernir el impacto en la

experiencia de video cuando incluso 1 de cada 10.000 paquetes es eliminado.

El objetivo secundario de la QoS del campus es administrar y diferenciar el tráfico

de datos de la aplicación en la capa de acceso. Los principios estratégicos de diseño

de QoS son relevantes cuando se diseña e implementa QoS en la red del campus:

siempre realiza QoS en hardware en lugar de software cuando existe una opción.

Clasificar y marcar las solicitudes tan cerca de sus fuentes como técnicamente y

administrativamente factibles.

Vigilar que el tráfico no deseado fluya lo más cerca posible de sus fuentes.

Habilitar políticas de colas en cada nodo donde existe la posibilidad de congestión,

independientemente de lo rara que pueda ser.

Proteger el plano de control y el plano de datos al permitir la vigilancia de los

planos de control (en las pantallas que soportan esta función), así como la

vigilancia del plano de datos (QoS de la clase Scavenger) en los switches de red del

campus para mitigar y restringir los ataques de red.

468

VoIP y Video

El primer paso en la implementación de QoS es identificar el tráfico en la red y determinar

los requisitos de QoS para el tráfico. La voz y el video suelen considerarse como tipos de

tráfico altamente críticos e importantes.

El tráfico de voz tiene requisitos de QoS extremadamente estrictos. El tráfico de voz

normalmente genera una demanda suave de ancho de banda y tiene un impacto mínimo

en otras clases de tráfico, siempre y cuando el tráfico de voz se administre correctamente.

Aunque los paquetes de voz suelen ser pequeños (de 60 a 120 bytes), no pueden tolerar

retrasos ni caídas. El resultado de los retrasos y caídas es una calidad de voz pobre y a

menudo inaceptable. Una llamada de voz típica requiere de 17 a 106 kbps de ancho de

banda de prioridad garantizada, además de un extra de 150 bps por llamada para atender

a los requisitos de tráfico de control de voz.

Las aplicaciones de videoconferencia tienen requisitos de QoS que son similares a los de

voz. Sin embargo, el tráfico de videoconferencia es a menudo codicioso por naturaleza y,

como resultado, puede afectar a otras clases de tráfico. Por lo tanto, necesita entender los

requisitos de videoconferencia para una red y también proveer cuidadosamente para ello.

El ancho de banda mínimo para un flujo de videoconferencia requiere el ancho de banda

real de la corriente, además de la sobrecarga de tráfico.

Buffers y ráfagas

Los protocolos que se han desarrollado se han adaptado a la naturaleza de ráfaga de los

datos y las breves interrupciones son sobrevivibles para ciertos tipos de tráfico, como el

correo electrónico o la navegación por Internet. Sin embargo, para aplicaciones sensibles

en tiempo real, como se indica con el ejemplo de vídeo HD, incluso la pérdida de paquetes

pequeños puede ser notable. Si desea evitar la caída de paquetes en aplicaciones frágiles,

es crítico aumentar el espacio de búfer y el ancho de banda para acomodar ráfagas.

469

Diferentes plataformas y tarjetas de línea tienen capacidades diferentes, lo que lleva a esta

pregunta: ¿Cuánto tiempo pueden los búferes de cola acomodar ráfagas?

Aumentar el ancho de banda para una cola en particular no significa necesariamente

aumentar el espacio de memoria intermedia para esa cola. Por ejemplo, puede asignar

búferes para las colas de prioridad estricta y de scavenger que se sintonizarán e

indirectamente proporcionales a sus asignaciones de ancho de banda, mientras que todos

los otros tipos de tráfico son directamente proporcionales a sus asignaciones de ancho de

banda.

No todas las plataformas admiten asignaciones de búfer. En las plataformas que soportan

esta función, pueden configurarse asignaciones de búfer de cola de espera. Por ejemplo, la

asignación de ancho de banda para la cola de prioridad puede ser un tercio de la

asignación de ancho de banda entre todas las colas de un puerto determinado. Las

asignaciones de búfer tienen menos impacto que el ancho de banda de ajuste para la cola y

sirven para complementar la política de programación en los puertos.

Límites y Estados de confianza

Si el conmutador o enrutador confía en el dispositivo final, no necesita realizar ninguna

reclasificación de los paquetes que llegan a esa interfaz. Los conmutadores y enrutadores

470

generalmente están configurados para no confiar en los dispositivos finales y deben

configurarse específicamente para confiar en los paquetes que provienen de una interfaz.

Idealmente, la clasificación debe realizarse lo más cerca posible de la fuente.

Para entender el funcionamiento de varios estados de confianza, echemos un vistazo a

cómo tres estados estáticos pueden ser apalancados en el nivel del puerto del switch:

Untrusted: El puerto descarta cualquier marca de Capa 2 o Capa 3 y genera un

valor DSCP interno de 0 para el paquete.

Trust CoS: El puerto acepta la marca CoS y calcula el valor DSCP interno de

acuerdo con la asignación predeterminada o predefinida de CoS-DSCP.

Trust DSCP: El puerto confía en el marcado DSCP y establece el valor DSCP interno

en el valor que coincide con el valor DSCP recibido.

Además de la configuración estática de confianza, los conmutadores Cisco Catalyst

también pueden definir el estado de confianza dinámica, en el que la confianza en el

puerto depende dinámicamente de la identificación del punto final de acuerdo con la

directiva de confianza. Dicha identificación de punto final depende del protocolo de

detección de Cisco (CDP) y sólo es compatible con dispositivos finales de Cisco.

Ejemplo de Estados de confianza y Límites

Considere la red del campus que contiene telefonía IP y terminales de host. Las tramas se

pueden marcar como importantes mediante el uso de los ajustes CoS de la capa 2 o

mediante el aprovechamiento de los bits de precedencia IP o DSCP en el campo ToS y

DiffServ de la cabecera IPv4. Los teléfonos IP de Cisco puede marcar paquetes de voz como

alta prioridad usando CoS y ToS. De forma predeterminada, el teléfono IP envía paquetes

marcados con 802.1P con CoS y ToS ajustados a un valor de 5 para paquetes de voz.

Debido a que la mayoría de las PC no tienen una NIC compatible con 802.1Q, envían

paquetes no marcados que no tienen un campo 802.1P. A menos que las aplicaciones que

se ejecutan en el PC envían paquetes con un valor CoS específico, este campo es 0.

471

Para protegerse contra la priorización no deseada y no autorizada de las aplicaciones,

incluso si el PC envía tramas etiquetadas con un valor CoS específico, los teléfonos IP de

Cisco pueden anular este valor antes de enviar la trama al conmutador. Este es el

comportamiento predeterminado. Las tramas de voz procedentes del teléfono IP tienen un

valor CoS de 5 y las tramas de datos procedentes del PC tienen un valor CoS de 0. Si el

DSCP está configurado, el teléfono IP no puede volver a marcar el DSCP y debe realizarse

en la capa de conmutación.

Si el dispositivo final no es un dispositivo de confianza, el conmutador de capa de acceso

puede realizar la función de reclasificación, si ese conmutador puede hacerlo. Si el

dispositivo no puede, la tarea de reclasificación recae en el dispositivo de la capa de

distribución. Si la reclasificación no se puede realizar en una de estas dos capas, puede ser

necesaria una actualización de software Cisco IOS, una actualización de hardware o ambas

para atender las necesidades de calidad de servicio de la organización.

Estado de confianza dinámico

El estado de confianza se puede establecer dinámicamente cuando se ha cumplido una

condición predefinida. En un switchport de Cisco, se puede establecer la condición a la que

debe pertenecer el dispositivo final para que la condición se cumpla satisfactoriamente.

Esta condición se comprueba utilizando CDP de tal manera que el dispositivo final

proporcione su propia información, tal como plataforma y capacidades, al conmutador.

472

Modelo de QoS Clasificación / Marcado / Vigilancia

Cuando está diseñando QoS, la segunda capa a examinar después de seleccionar el modelo

de límite de confianza deseado es la marca y la clasificación. Para la clasificación, marcado

y vigilancia, las políticas de QoS deben aplicarse en la dirección de entrada en el puerto del

switch. En la capa de acceso, el modelo de QoS que se aplica asume un estado de confianza

de puerto o una política de codificación explícita y una política de maquetación que se

aplica al puerto de conmutación. Al diseñar la QoS de extremo a extremo, debe tener en

cuenta modelos estratégicos de QoS, como los modelos de 4, 8 y 12 clases que se

aprovecharán para adaptarse a los requisitos de QoS en toda la organización. Se debe

tener cuidado de entender las clases de aplicación que están representadas en la capa de

acceso de la red y si el tráfico de la aplicación procede de un punto final de confianza o no.

No todos los tipos de aplicaciones deben clasificarse en el borde de la capa de acceso

porque algunos tipos de tráfico, como las actualizaciones de enrutamiento, nunca deben

recibirse desde un punto final. Del mismo modo, el tráfico OAM se genera normalmente a

partir de dispositivos de red, pero no de puntos finales. El abastecimiento de tráfico desde

los teléfonos IP de Cisco debe ser confiable y clasificado en el borde, pero el tráfico de voz

también puede obtenerse de PC que utilizan aplicaciones de voz como Cisco Jabber. En

algunos casos, es más sencillo clasificar el tráfico de voz según un rango de puertos UDP

que se utilizan para tráfico RTP.

La vigilancia puede aplicarse para supervisar los datos transaccionales, los datos en masa

y los flujos de mejor esfuerzo mientras se realizan acciones de eliminación o de marcado si

dicho tráfico viola los límites predefinidos. Como último paso en el proceso de ingreso de

QoS, puede optar por el ingreso de entradas. La cola de entrada es soportada en algunas

plataformas y su funcionamiento depende en gran medida de la plataforma en la que se

realiza la cola de entrada.

473

Recomendaciones de Cola / Descarte

La cola y el descarte de paquetes en los switches Catalyst se realiza normalmente en la

salida. Los switches Cisco Catalyst utilizan colas basadas en hardware; por lo tanto, el

número de colas depende de la plataforma real. Es necesario utilizar políticas de cola en

puertos de salida con una estructura de colas 1P3QyT, donde 1P representa una cola de

prioridad estricta, 3 representa el número de colas no prioritarias y “y” representa el

número de umbrales de caída para colas no prioritarias. En este caso, 1P3Q8T se

traduciría a lo siguiente:

1 cola de prioridad estricta

3 colas no prioritarias, cada una con

8 umbrales de caída por cola

Se soportan comportamientos de colas estándares mínimas basados en estándares para

un modelo de QoS de cuatro clases, donde el tráfico en tiempo real debe ser aprovisionado

para aprovechar no más del 33 por ciento del ancho de banda, el mejor esfuerzo debe ser

provisto con 25 por ciento de ancho de banda y scavenger (menos que mejor esfuerzo) el

tráfico debe ser mínimamente aprovisionado.

474

Los mecanismos de prevención de la congestión deben habilitarse solamente en las colas

no prioritarias porque las colas de prioridad serán controladas de forma predeterminada

como parte del mecanismo de cola de baja latencia (LLQ).

Diseño de QoS "EtherChannel" de agregación de enlaces

Varias interfaces Gigabit Ethernet o 10 Gigabit Ethernet pueden ser agrupadas en una

única interfaz lógica denominada agregación de enlaces de una interfaz EtherChannel. Al

implementar QoS de EtherChannel, necesita conocer los requisitos específicos de la

plataforma para decidir si aplica la directiva en la interfaz física o lógica. A continuación,

se presentan dos consideraciones principales al implementar QoS en interfaces

EtherChannel:

Equilibrio de carga: Normalmente, el equilibrio de carga en EtherChannel se

realiza por dirección MAC de origen o de destino o dirección IP de origen y / o

destino; El número de puerto de destino también se puede usar como parte del

algoritmo de hashing de equilibrio de carga. Sin embargo, el equilibrio de carga de

EtherChannel no tiene en cuenta el ancho de banda de cada flujo, sino que se basa

en la probabilidad estadística de que un gran número de flujos da lugar a una carga

distribuida más o menos equitativamente a través de los enlaces. Cuando las cargas

se asignan mediante el mecanismo IP de origen y destino, los paquetes

pertenecientes a un solo flujo conservan el orden de paquetes para ese flujo.

Configuración de enlaces físicos: La tecnología EtherChannel no tiene

conocimiento de una configuración de enlaces físicos individuales que consisten en

un grupo de puertos EtherChannel. Si falla un enlace en un grupo de puertos

EtherChannel, los enlaces físicos restantes se utilizarán para el tráfico que cruza el

enlace EtherChannel. En esa situación, un mecanismo de conmutación por error de

475

EtherChannel puede asignar más tráfico en tiempo real a través de enlaces que no

pueden acomodar la carga, lo que a su vez puede conducir a QoS degradada de las

aplicaciones en tiempo real.

Para decidir si se debe aplicar la directiva QoS de EtherChannel en una interfaz física o

lógica en una dirección de entrada, debe tener en cuenta la plataforma utilizada. Para la

dirección de salida, EtherChannel QoS siempre se puede aplicar en la interfaz física.

DESCRIPCIÓN DE LA QOS DE LA WAN

Los mismos principios de diseño aplicables a las redes de campus se aplican al diseño de

QoS de WAN / sucursal. Hay, sin embargo, algunas recomendaciones distintas están

asociadas con la aplicación de la QoS a los dispositivos WAN / borde de la sucursal.

La pérdida de paquetes y el jitterson más evidentes en los dispositivos WAN y sucursales.

Como resultado, QoS en esos lugares debe ser cuidadosamente considerado porque puede

tener un impacto importante en la calidad de las aplicaciones en tiempo real y la

experiencia general del usuario.

Un problema importante con el borde WAN / sucursal se asocia con enlaces de baja

velocidad cuando se compara con las velocidades de la red LAN / campus. La diferencia en

esas velocidades puede conducir a buffers llenos y pérdida de paquetes. En los enlaces de

menor velocidad en el borde WAN, un paquete puede ser significativamente retrasado. Un

paquete retrasado es tan malo como un paquete abandonado, porque a veces un paquete

se retrasa demasiado, y este retraso resulta en que se cae en el receptor debido a la

superación del espacio de amortiguación de jitter. Para hacer frente adecuadamente a la

pérdida de paquetes y la fluctuación de fase, debe implementar las políticas de cola

apropiadas.

Los dispositivos WAN / borde de sucursal permiten el uso de herramientas QoS tales

como Medianet o Application Visibility and Control (AVC) para mejorar la granularidad de

la clasificación. Ya sea centrado en las redes de campus, centros de datos, WAN o VPN,

debe seguir los mismos principios estratégicos de diseño de QoS y mejores prácticas en

476

toda la infraestructura para garantizar un diseño de QoS de extremo a extremo sostenible

y efectivo. Las recomendaciones anteriormente cubiertas incluyen:

Realización de QoS en hardware siempre que sea posible

Clasificar y marcar aplicaciones lo más cerca posible de la fuente

Vigilar los flujos de tráfico no deseados lo más cerca posible de sus fuentes

Habilitación de colas en todos los nodos con potencial de congestión

Habilitación de la vigilancia del plano de control para proteger los planos de datos

y control

Consideraciones sobre el rendimiento de la plataforma

Al elegir un enrutador de WAN / sucursal, debe tener en cuenta varias consideraciones de

rendimiento de la plataforma para la configuración de QoS. Aunque muchos de los

enrutadores Cisco realizan operaciones de QoS en el software, lo que puede dar lugar a

ciclos de CPU incrementados al implementar QoS, depende de la plataforma seleccionada,

por ejemplo Cisco ASRs realiza operaciones de QoS en software y hardware. Por lo tanto,

las características de aceleración de hardware, velocidades de enlace, complejidad de

políticas, tasas de paquetes y tamaños de paquetes influyen en la selección de la

plataforma. Es importante asegurarse de que la plataforma seleccionada cumple con los

requisitos actuales y futuros de rendimiento.

Habilitar QoS en Cisco IOS tiene varias ventajas:

Proporciona consistencia entre plataformas de características QoS como LLQ y

CBWFQ.

La sintaxis de la configuración de QoS es consistente como resultado de que el

enfoque de configuración modular QoS CLI MQC se comparte en todas las

plataformas.

El amplio conjunto de funciones QoS, como NBAR / NBAR2 o QoS jerárquica, no

está disponible en las plataformas de conmutación Catalyst.

477

Consideraciones de Latencia y fluctuación de fase (Jitter)

La latencia y el jitter son factores importantes cuando se implementan aplicaciones en

tiempo real a través de WAN. El control de la latencia y el jitter se realiza utilizando

enlaces WAN fiables que están soportados por las herramientas QoS.

La recomendación G.114 de la UIT establece que la latencia unidireccional para las

aplicaciones en tiempo real, como la voz y el vídeo, no debe superar los 150 ms. Para

mantenerse dentro de este límite, debe comprender los factores que influyen en el retraso

general en la red, como

Retardo de la serialización

Retardo de propagación

Demora de colas

Algunos tipos de retrasos, como la serialización y el retardo de propagación, son fijos. El

administrador de red no puede controlarlos. El retardo de serialización depende

principalmente de la velocidad de la línea (velocidad del circuito) y el retardo de

propagación depende de la distancia física entre el emisor y el receptor. Sin embargo, el

retraso de cola es un tipo variable de retraso y depende de la congestión en el dispositivo

que procesa el paquete. Para paquetes sensibles al retraso, puede aplicar una política de

cola que acortará el tiempo que un paquete permanece en la cola del dispositivo que está

congestionado. En primer lugar, debe enviar paquetes de tráfico en tiempo real al cable, ya

que deben recibirse dentro de los límites de tiempo del búfer. Cualquier paquete recibido

que se retrasa más allá del límite de memoria intermedia de jitter es tan bueno como

perdido. Estos casos afectan a la calidad de la aplicación en tiempo real y la experiencia del

usuario final

478

CONSIDERACIONES DE COLA

Es necesario tener en cuenta algunos hechos al diseñar políticas de colas en la red. La

salida final al enviar las tramas al cable es el Tx-Ring. El Tx-Ring es una cola FIFO que

maximiza el ancho de banda al hacer coincidir la velocidad de paquetes de salida con la

velocidad de la interfaz física. En ciertas plataformas de Cisco, el Tx-Ring puede ser

configurado para permitir una cola más profunda o menos profunda. Bajar el valor del Tx-

Ring hace que el motor de cola de espera del software IOS haga cola de paquetes más

pronto y más a menudo, lo que resulta en valores más bajos para el tráfico de prioridad.

Por otro lado, el ajuste de un Tx-Ring demasiado bajo puede causar una mayor utilización

de la CPU. Recuerde esto al hacer trade-offs entre retardo o jitter y uso de la CPU.

Para hacer cola en el software, puede utilizar tres estrategias de gestión de colas básicas

en dispositivos de borde WAN / sucursal:

CBWFQ: Utilice este algoritmo de colas para garantizar un ancho de banda mínimo

para ciertas clases de tráfico.

LLQ: Utilice este algoritmo de colas para transportar aplicaciones de tráfico en

tiempo real dentro de la cola de prioridad y garantizar un ancho de banda mínimo

para otros tipos de tráfico. Este enfoque permite proteger el tráfico en tiempo real

(como la conferencia de voz y video) y evita que otros tipos de tráfico interfieran

con el tráfico en tiempo real. Sin embargo, tenga en cuenta que la cola de prioridad

siempre está limitada por la velocidad que se configura dentro de una clase dada

porque se aplica un controlador implícito para la clase de tráfico prioritario.

WRED: Utilice este algoritmo de prevención de congestión para aplicaciones

basadas en TCP para evitar la congestión descartando paquetes de prioridad baja

antes de que se produzca la congestión.

Las recomendaciones de LLQ para el borde WAN / sucursal deben ser familiares; son las

siguientes:

Proveer no más del 33 por ciento de la capacidad de ancho de banda del enlace

para LLQ.

No habilite el mecanismo WRED para LLQ.

Las recomendaciones de CBWFQ para el borde WAN / sucursal son las siguientes:

En CBWFQ, a las clases separadas se les asignan asignaciones de ancho de banda de

acuerdo con los requisitos de la aplicación.

Dependiendo de la clase del tráfico, puede usar WRED basado en DSCP para

minimizar la sincronización TCP global.

479

Para la clase de tráfico CBWFQ de control, no se recomienda que habilite los preclasificadores

de fairqueuing o los WRED basados en DSCP porque estos paquetes

nunca deben ser eliminados o reordenados.

Para multimedia y datos CBWFQ, pre-clasificadores de colas justas y WRED basado

en DSCP pueden ser habilitados.

Para scavenger CBWFQ, no se recomienda que habilite pre-clasificadores o DSCP

basado en WRED.

Para la clase CBWFQ predeterminada, puede habilitar los pre-clasificadores o

WRED basado en DSCP si es necesario. Se recomienda asignar un mínimo de 25 por

ciento de ancho de banda a este tipo de tráfico. Sin embargo, esto es sólo una

recomendación genérica de mejores prácticas que puede no ser siempre el

porcentaje adecuado para sus necesidades; Por lo tanto, la recopilación y la

comprensión de los requisitos de aplicación en términos de cantidad de ancho de

banda es clave para lograr un exitoso diseño de QoS.

CONSIDERACIONES DE MODELADO

Con las interfaces WAN que utilizan Ethernet como tecnología de acceso, el punto de

demarcación entre la empresa y el proveedor de servicios puede no tener una restricción

de ancho de banda de interfaz física. En su lugar, se contrata una cantidad específica de

ancho de banda de acceso con el proveedor de servicios. Para asegurar que la carga

ofrecida al proveedor de servicios no exceda la tasa contratada que da como resultado que

el portador descarte el tráfico, debe configurar la forma en la dirección de salida en la

interfaz física. Esta configuración se realiza con una política de servicio QoS.

Una política de servicio de QoS está configurada en la interfaz Ethernet externa y esta

directiva principal incluye un formateador que hace referencia a una segunda o

subordinada (secundaria) que permite poner en cola dentro de la tasa configurada. Este

modelo de despliegue se conoce como una configuración Hierarchical Classed Weighted

Fair Queue (HCBWFQ). Al configurar el comando shape average, debe asegurarse de que el

valor coincida con la tasa de ancho de banda contratado del proveedor de servicios para

evitar que el tráfico sea controlado y descartado en el proveedor de servicios PE.

480

Ejemplo práctico de QoS de la WAN y de la rama

La empresa A tiene las siguientes redes:

Topología de red Hub-and-spoke con enlaces WAN a través de una WAN privada

MPLS VPN

IPsec a través de Internet

La empresa desea implementar QoS sobre todos los enlaces WAN para proporcionar una

experiencia de calidad para aplicaciones en tiempo real. Las políticas 1-4 se aplican en

diferentes puntos de los dispositivos de red WAN / filial de la siguiente manera:

La política 1 es para el borde de LAN del agregador de WAN y permite el ingreso de

confianza de DSCP, así como la clasificación y marcado opcional NBAR2 de entrada.

La salida LLQ / CBWFQ / WRED también se puede habilitar si es necesario.

La política 2 es para el WAN agregador/WAN borde y permite ingreso DSCP

confianza, así como salida LLQ / CBWFQ / WRED. Las políticas RSVP o las políticas

específicas de VPN también se pueden habilitar.

La política 3 es para el borde WAN de la sucursal y permite la entrada DSCP

confianza, así como salida LLQ / CBWFQ / WRED. Las políticas RSVP o las políticas

específicas de VPN también se pueden habilitar.

La Política 4 es para el borde de la LAN de la sucursal y permite el ingreso de

confianza DSCP, así como la clasificación y marcado NBAR2. Las políticas de egreso

LLQ / CBWFQ / WRED pueden aplicarse si es necesario.

481

VISIÓN GENERAL DEL QOS DEL CENTRO DE DATOS

Aunque los principios aplicados al diseño de QoS de CD son similares al diseño de QoS en

una red de campus, el diseño de QoS debe ser considerado cuidadosamente en el CD

también. El objetivo principal de QoS en un centro de datos es administrar la pérdida de

paquetes. En los centros de datos 10/40/100 Gigabit Ethernet, sólo unos pocos

milisegundos de congestión pueden provocar graves pérdidas de paquetes. El

almacenamiento en búfer de hardware y la cola no pueden hacer frente a los protocolos

específicos del centro de datos que requieren un servicio sin pérdidas.

Es necesario considerar las siguientes funciones importantes del diseño de QoS en el

centro de datos:

Realizar QoS en hardware siempre que sea posible. La plataforma de conmutación

Cisco Nexus puede realizar acciones QoS en ASIC, descargando recursos de la CPU

para otras operaciones. Esta capacidad le da la oportunidad de habilitar las

políticas de QoS en la plataforma Nexus a la velocidad de línea.

Clasifique y marque las aplicaciones lo más cerca posible de la fuente de tráfico.

Este enfoque, cubierto como parte del diseño de QoS del campus, es un principio

general de diseño de QoS y también debe seguirse en las redes de centros de datos.

Policía de tráfico más cercano a la fuente como administrativamente sea posible. El

objetivo es descargar la CPU de los dispositivos de red y preservar el rendimiento y

el ancho de banda de los enlaces.

Habilitar la cola en cada nodo que podría estar potencialmente congestionado. Este

principio es importante en los centros de datos donde las relaciones de

sobreescritura de enlaces Ethernet multigigabit crean el potencial de congestión.

Habilitar la vigilancia del plano de control. Este paso se recomienda para mejorar la

seguridad de la infraestructura del centro de datos.

ARQUITECTURA COMERCIAL DE ALTO RENDIMIENTO

Los centros de datos comerciales de alto rendimiento (HPT) tienen requisitos mínimos de

QoS porque el objetivo de esos centros de datos es eliminar la sobresuscripción, lo que

hace que la QoS en estos entornos sea innecesaria. Las instituciones financieras utilizan la

arquitectura HPT para aumentar la velocidad de ejecución y obtener ventaja competitiva.

482

En los centros de datos que tienen una jerarquía de acceso, distribución y capa central, el

tráfico de la capa de acceso que va al núcleo debe atravesar la capa de distribución que

proporciona servicios de agregación. Para evitar la congestión en la capa de distribución,

es necesario proporcionar suficiente ancho de banda y espacio de búfer en las plataformas

de capa de distribución para acomodar los dispositivos de capa de acceso hacía abajo.

Cuando aprovecha las plataformas adecuadas con suficientes puertos de alto ancho de

banda aprovisionados desde el núcleo para acceder, se evita la sobreescritura.

Gran Arquitectura de Datos

Las grandes arquitecturas de datos fueron diseñadas para procesar complejos y grandes

conjuntos de datos que no son fáciles de manejar con las arquitecturas tradicionales. En

las arquitecturas basadas en clústeres de grandes centros de datos, la informática y el

almacenamiento residen en servidores individuales que forman clusters

483

Las herramientas de QoS y el diseño son requeridos para soportar esas arquitecturas. Las

herramientas aplicadas son similares a las herramientas que se aplican en las redes de

campus, como la clasificación, el marcado y las colas de entrada y salida. La razón de esto

es que el foco principal se centra principalmente en extender el límite de confianza y la

cola que se aplica en cada nodo.

CONJUNTO DE HERRAMIENTAS DE PUENTEO DE CENTROS DE

DATOS

Además de la clasificación, marcado, cola y descarte, las operaciones de QoS en centros de

datos también requieren el transporte sin pérdidas para algunos protocolos SAN como

FCoE (Fibre Channel over Ethernet). Ethernet tradicional no puede garantizar los

requisitos de transporte sin pérdida de Fibre Channel. El IEEE ha desarrollado varias

extensiones a Ethernet que están diseñadas para satisfacer esos desafíos. Estas mejoras se

incluyen en un conjunto de herramientas denominado conjunto de herramientas Data

Center Bridging (DCB).

El control de flujo heredado utiliza el control de flujo Ethernet (EFC) que se define en IEEE

802.3x, que define la trama PAUSE. Si la estación emisora, que puede ser un servidor o un

dispositivo de red, está transmitiendo más rápidamente que la estación receptora puede

procesar el tráfico, la estación receptora envía una trama de PAUSA al remitente, lo que

indica a la terminación de detener temporalmente la transmisión. La desventaja de este

método es que la transmisión de tráfico a otros servidores que están disponibles para

recibir tráfico también se detiene. El retardo resultante para otro tráfico se llama bloqueo

de Head of Line (HOL) y es una desventaja de EFC.

484

Introducido en 2008 por el Grupo de trabajo de puenteo de centros de datos, el

mecanismo de control de flujo basado en prioridades (PFC) mejora el comportamiento de

EFC HOL. Cuando se utiliza PFC, la trama PAUSE contiene un valor CoS específico. Cuando

se implementa PFC, la emisión sólo detiene la transmisión de tráfico con un valor CoS

específico.

485

Capítulo 18

Diseño de QoS para las

VPN MPLS

486

LA NECESIDAD DE QOS EN VPN MPLS

Las VPN MPLS proporcionan servicios de WAN virtuales de capa 3 a todos los enrutadores

CE.

Una de las razones principales para usar VPN MPLS es su capacidad de conectividad anyto-any.

La naturaleza de malla completa de VPN MPLS plantea implicaciones de QoS

significativas tanto para los proveedores de servicios como para los proveedores de

servicios empresariales. Los suscriptores de clientes empresariales deben cooperar

estrechamente con sus proveedores de servicios para garantizar niveles de servicio de

extremo a extremo porque no pueden alcanzar estos niveles de servicio

independientemente de las políticas de los proveedores.

Puede ver el diseño de QoS para VPN MPLS desde dos perspectivas distintas:

El cliente empresarial que se suscribe al servicio VPN MPLS

El proveedor de servicios que proporciona el borde y la QoS principal dentro del

servicio VPN MPLS

Independientemente de la perspectiva, los diseños de QoS de empresas y proveedores de

servicios deben ser consistentes y complementarios. El núcleo IP del proveedor de

servicios proporciona transporte de paquetes de alta velocidad.

En la red de proveedores, todas las marcas, la vigilancia y el modelado deben realizarse

únicamente en el enrutador de borde del proveedor (PE) en el enlace PE-a-CE y no en el

núcleo. Sólo el borde requiere una política QoS compleja. En el núcleo, sólo se requieren

colas y descartes. La operación de cola y descarte se basará en las marcas que se realizan

en el PE. La razón de estos procedimientos es la naturaleza any-to-any y full-mesh de las

VPN MPLS, donde los suscriptores de la empresa dependen de sus proveedores de

servicios para ofrecer políticas de QoS de PE a CE que sean consistentes con su política de

CE-a-PE . Además de estas políticas PE-a-CE, los proveedores de servicios probablemente

implementarán policías de entrada en sus PEs para identificar si los flujos de tráfico del

487

cliente están dentro o fuera del contrato. Opcionalmente, los proveedores de servicios

también pueden establecer políticas de QoS dentro de sus redes principales utilizando la

ingeniería de tráfico DiffServ o MPLS para maximizar el uso de enlaces subutilizados y

optimizar el transporte del tráfico afectado por la latencia, la pérdida y la fluctuación de

fase.

El doble papel de la QoS en las redes WAN y sucursales privadas consiste en gestionar la

pérdida de paquetes y el jitter mediante políticas de cola y mejora de la granularidad de la

clasificación aprovechando los motores de inspección profunda de paquetes. Además, el

rol de QoS sobre la VPN de MPLS puede ampliarse para incluir lo siguiente:

Conformación del tráfico a las tarifas de servicio contratadas

Realización de colas jerárquicas y descarte dentro de estas tasas

Mapeo de las marcas de servicio de la clase de proveedor de servicio-a-empresa

Vigilancia de las clases de tráfico según las tarifas contratadas

Restauración de marcas de paquetes

ADMINISTRACIÓN DE LA CALIDAD DE SERVICIO WAN DE LA

CAPA 2 PRIVADA

Debido a las limitaciones de coste, escalabilidad y capacidad de gestión, los diseños WAN

privados tradicionales raramente usan modelos de malla completa. En su lugar, la mayoría

de los diseños de WAN de capa 2 giran en torno a un modelo de hub-and-spoke,

implementando un diseño de concentrador centralizado o el diseño de concentrador

regional más eficiente. Teniendo en cuenta que las WAN privadas suelen ser desplegadas

en una topología punto a punto o de hub-and-spoke, un diseño de QoS de WAN privado de

Nivel 2 es más sencillo que un diseño de QoS VPN de MPLS.

Bajo tales diseños de hub-and-spoke, QoS se administra principalmente en el enrutador de

concentrador, que asume el papel de agregador de WAN dentro de la empresa. Mientras el

proveedor de servicios cumpla con los niveles de servicio contratados, los paquetes que se

reciben en sucursales remotas reflejarán las políticas de programación del enrutador de

concentrador. El agregador de WAN controla no sólo el tráfico del campus a sucursal, sino

también tráfico de sucursal a sucursal, que se dirige a través del concentrador.

488

ADMINISTRACIÓN DE QOS DE VPN MPLS DE MALLA COMPLETA

Bajo un diseño de malla completa, el enrutador concentrador todavía administra QoS para

todo el tráfico de campus a sucursal, pero ya no controla completamente la calidad de

servicio para el tráfico de sucursal a sucursal. Aunque puede parecer que la única solución

necesaria para este nuevo escenario es garantizar que QoS se aprovisiona en todos los

enrutadores de las sucursales, esta solución es insuficiente porque sólo trata parte del

problema.

Por ejemplo, considere el caso del aprovisionamiento de cualquier conferencia

multimedia. Al igual que con un diseño tradicional de la WAN de Nivel 2, se requiere una

política de programación para priorizar la conferencia multimedia en el agregador WAN.

La empresa también debe proporcionar adecuadamente una programación de prioridad

similar para las conferencias multimedia en las oficinas de sucursales. De esta manera,

cualquier llamada de conferencia multimedia del campus a la sucursal y de sucursal a

sucursal está protegida contra el tráfico de menor importancia fluyendo entre los mismos

sitios y causando congestión. La complejidad del modelo completamente mallado surge

cuando se considera que el tráfico contendiente no siempre proviene de los mismos sitios,

sino que puede provenir de cualquier sitio. Además, la empresa ya no controla

completamente la calidad de servicio para el tráfico de sucursal a sucursal ya que este

tráfico ya no se realiza a través de un concentrador. Siguiendo el ejemplo, si se establece

una llamada de conferencia multimedia entre dos sucursales y un usuario de una de las

sucursales también inicia una descarga FTP grande desde el sitio central, el potencial de

sobreescritura del enlace PE-a-CE desde la nube VPN MPLS totalmente acoplada en una de

las sucursales se convierte en real y es probable que causen descartes que afecten a la

llamada de conferencia multimedia.

La única manera de garantizar niveles de servicio en tal escenario es que el proveedor de

servicios proporcione una programación de QoS que sea compatible con las políticas de la

empresa en todos los enlaces PE con sucursales remotas. Esto es lo que crea el cambio de

489

paradigma en la administración de QoS para las topologías de malla completa. Las

empresas y los proveedores de servicios deben cooperar para administrar conjuntamente

QoS a través de VPN MPLS

Por lo tanto, las políticas de colas son obligatorias en los bordes de salida del enrutador CE

y PE debido a las implicaciones de malla completa asociadas con VPN MPLS. Además, los

enrutadores PE tendrán políticas de vigilancia de ingreso para hacer cumplir las SLAs.

Las políticas de QoS en los enrutadores principales del proveedor son opcionales. Tales

políticas son opcionales porque algunos proveedores de servicios sobreproporcionan sus

redes centrales de MPLS y, como tales, no requieren ninguna política adicional de QoS

dentro de sus backbones; Sin embargo, otros proveedores podrían implementar políticas

DiffServ simplificadas dentro de sus núcleos o incluso implementar MPLS TE para manejar

escenarios de congestión dentro de una infraestructura de backbone que no se haya

sobreprovisionado.

MODOS DE TÚNEL MPLS DIFFSERV

Los modos de tunelización DiffServ introducen un nuevo comportamiento por salto (PHB),

que permite QoS diferenciada en la red de un proveedor de servicios. El modo de

tunelización se define en el borde de la red, normalmente en los PE LSR tanto en la

entrada como en la salida.

MPLS puede tunelizar las marcas QoS de un paquete y crear transparencia QoS para el

cliente. Es posible marcar el campo MPLS EXP en la red del proveedor de servicios

independientemente del PHB marcado por el cliente en los campos Precedencia IP o DSCP.

Un proveedor de servicios puede elegir entre una matriz existente de criterios de

clasificación, incluyendo o excluir el marcado IP PHB, para clasificar esos paquetes en un

PHB diferente. El comportamiento de PHB se marca entonces sólo en el campo MPLS EXP

durante la imposición de etiquetas. Este marcado es útil para un proveedor de servicios

que requiere el cumplimiento de SLA de los paquetes de clientes mediante la promoción o

490

rebaja del PHB de un paquete, sin tener en cuenta el esquema de marcado de QoS y sin

sobrescribir las marcas IP PHB del cliente.

Teniendo en cuenta que las etiquetas MPLS incluyen 3 bits que se usan comúnmente para

el marcado QoS, se puede tunelizar el DiffServ para preservar las marcas DiffServ de capa

3 a través de una nube VPN de MPLS, mientras se sigue remarcando a través de bits MPLS

EXP dentro de la nube, para indicar si es tráfico en contrato o fuera de contrato.

Corresponde a los proveedores de servicios definir los modelos de clase de servicio (CoS)

que ofrecerán a sus suscriptores. No existe un modelo único para todos, ya que estos

modelos CoS suelen ser un componente clave de la estrategia de diferenciación

competitiva de un proveedor de servicios. La mayoría de los proveedores de servicios

cuentan con cuatro y seis ofertas de modelos QoS de clase, mientras que unas cuantas

ofrecen ocho o más clases de servicio.

Siempre que se presenten varios modelos de proveedores de servicios como opciones, el

suscriptor debe seleccionar el modelo que más se alinea con el modelo de QoS estratégico

de extremo a extremo.

RFC 3270 define tres modos distintos de tunelización MPLS DiffServ:

Modo uniforme: El modo uniforme de tunelización DiffServ tiene sólo una capa de

QoS, que llega de extremo a extremo. El router PE de entrada copia el DSCP del

paquete IP entrante en los bits MPLS EXP de las etiquetas impuestas. A medida que

los bits EXP viajan a través del núcleo, pueden o no ser modificados por los

enrutadores P intermedios. En el enrutador P de salida, los bits EXP se copian a los

bits EXP de la etiqueta recién expuesta. Finalmente, en el enrutador PE de salida,

los bits EXP se copian a los bits DSCP del paquete IP recién expuesto.

Modo de tubería corta: el modo DiffServ de tubería corta usa las mismas reglas y

técnicas en todo el núcleo. La diferencia está en el enrutador PE de salida donde los

paquetes IP recién expuestos para la cola de salida se clasifican en base al IP PHB

del valor DSCP del paquete IP.

Modo de tubería: El modo de tubería de túnel DiffServ utiliza dos capas de QoS:

(1) una QoS adicional para los datos, que permanece sin cambios al atravesar el

núcleo; Y (2) una QoS de núcleo, que está separada de la de los paquetes IP

subyacentes. Este QoS PHB por núcleo sigue siendo transparente para los usuarios

finales. Cuando un paquete alcanza el borde del núcleo MPLS, el enrutador PE de

salida clasifica los paquetes IP recientemente expuestos para las colas de espera

basadas en MPLS PHB a partir de los bits EXP de la etiqueta recientemente

eliminada.

491

El tipo de modo de tunelización DiffServ depende de los siguientes factores:

Si el cliente y el proveedor de servicios están en el mismo dominio QoS

Si el proveedor de servicios mantiene la transparencia de QoS para el cliente

Si la política QoS del proveedor de servicio o de cliente está implícita en el

enrutador de salida PE

El comportamiento es el siguiente:

Imposición de la etiqueta (IP a etiqueta):

o La precedencia IP del paquete IP entrante se copia en los bits MPLS EXP de

todas las etiquetas empujadas.

o Los primeros 3 bits del bit DSCP se copian en los bits MPLS EXP de todas las

etiquetas empujadas.

o Esta técnica también se conoce como reflexión de ToS.

MPLS reenvío (etiqueta a la etiqueta):

o El EXP se copia a las nuevas etiquetas que se intercambian y se empujan

durante la impresión o la imposición.

o En la imposición de etiquetas, las etiquetas subyacentes no se modifican con

el valor de la nueva etiqueta que se agrega a la pila de etiquetas actual.

492

o En la disposición de la etiqueta, los bits EXP no se copian en los bits EXP de

la etiqueta recién expuestos.

Disposición de la etiqueta (etiqueta a IP):

o En la disposición de la etiqueta, los bits EXP no se copian al campo IP de

precedencia o DSCP del paquete IP recién expuesto.

Modo de tunelización uniforme

El modo de tunelización uniforme se utiliza generalmente cuando el cliente y el proveedor

de servicios comparten el mismo dominio DiffServ, como en el caso de una empresa que

despliega su propio núcleo VPN MPLS. El encabezado más externo siempre se utiliza como

la única fuente de información significativa sobre el QoS PHB. En la imposición de la

etiqueta MPLS, la clasificación de precedencia IP se copia en el campo experimental más

externo de la etiqueta (el comportamiento predeterminado). A medida que los bits EXP

viajan a través del núcleo, pueden ser modificados por los enrutadores P intermedios. En

la salida de la red del proveedor de servicios, cuando la etiqueta se dispara, el enrutador

propaga los bits EXP hacia abajo en la prioridad IP o el campo DSCP, que debe ser

configurado por el proveedor de servicios en el router PE de salida.

Modo de túnel de tubería corta

El modo de túnel de tubería corta se utiliza cuando el cliente y el proveedor de servicios se

encuentran en otros dominios DiffServ. El modo de tubería corta es útil cuando el

proveedor de servicios desea aplicar su propia política de DiffServ, mientras mantiene la

transparencia de DiffServ. La etiqueta más externa se utiliza como la única fuente de

493

información significativa como se relaciona con la QoS PHB del proveedor de servicios. En

la imposición de la etiqueta MPLS, la clasificación de IP no se aplica a la EXP de la etiqueta

más externa. En su lugar, basándose en la política QoS del proveedor de servicios, se

establece un valor apropiado para el MPLS EXP en el PE de ingreso. El valor MPLS EXP

podría ser diferente de la precedencia IP original o el DSCP. El MPLS EXP logrará la marca

CoS en la etiqueta más alta, pero conservará el IP DSCP que se encuentra en la parte

superior. Si el proveedor de servicios reclasifica el tráfico en la nube MPLS por cualquier

razón, se cambia el valor EXP de la etiqueta superior. En la salida del proveedor de

servicios, cuando la etiqueta se dispara, el enrutador PE no afectará el valor de la

información DSCP adicional. De esta manera, el MPLS EXP no se propaga al campo DSCP.

Por lo tanto, se mantiene la transparencia DSCP.

Los valores de MPLS EXP pueden marcarse de cualquier manera que el SP quiera

transmitir la significancia local y no tengan relación con los valores de marcado de

paquetes del cliente. Por lo tanto, las marcas del cliente se conservan en tránsito y están

disponibles para el consumidor a medida que el paquete sale de la VPN MPLS.

En el caso de cualquier ocurrencia de re-marcado en la nube VPN MPLS del proveedor de

servicios, los cambios se limitan a la marcación MPLS EXP solamente y no se propagan

hasta el byte ToS del paquete IP subyacente.

Modo de Túnel de Tubería

494

La principal diferencia entre el modo de MPLS DiffServ de tubería corta y el modo de

tubería es que las directivas de salida de PE hacia los CE de los clientes se suministran de

acuerdo con las marcas explícitas y re-marcas del proveedor de servicio, no las marcas IP

DiffServ del cliente de la empresa; Sin embargo, estas marcas de IP DiffServ de cliente se

conservan. Cuando un paquete alcanza el borde del núcleo MPLS, el enrutador PE de salida

clasifica los paquetes IP recién expuestos para la cola de salida basándose en el MPLS PHB

de los bits EXP de la etiqueta recientemente eliminada. Al igual que con el modo de tubería

corta, los cambios en las marcas de etiquetas que se producen dentro de la nube del

proveedor de servicios no se propagan al byte IP ToS cuando el paquete sale de la red

MPLS.

Esta implementación evita la sobrecarga operacional adicional de las configuraciones por

cliente en cada interfaz de salida del enrutador PE de salida. El funcionamiento en modo

de tubería es idéntico al de tubería corta, con la única excepción de que las políticas finales

de cola de salida PE se basan en las marcas del proveedor de servicios (y no en el del

cliente).

EJEMPLO DE LAS FUNCIONES DE QOS DE MPLS VPN

A veces, el número de clases de CoS de proveedor de servicios igualará o superará el

número de clases de aplicación que una empresa ha definido en su política de QoS

estratégica de extremo a extremo. Sin embargo, esto no suele ser el caso. Cuando el

número de clases de aplicaciones empresariales excede el número de clases CoS de

proveedor de servicios, el administrador de la empresa tendrá que mapear el modelo del

495

proveedor de servicios, colapsar tácticamente y eficientemente y combinar clases de

aplicación y realizar cualquier re-marcado necesario en el proceso.

A continuación, se incluyen algunas recomendaciones para la asignación de proveedores

de empresa a servicio:

Mapear eficiente las clases de aplicaciones empresariales a las clases CoS de

proveedores de servicios.

Equilibre los requisitos de nivel de servicio para aplicaciones de voz y video en

tiempo real con las primas del proveedor de servicios para el ancho de banda en

tiempo real.

Evite mezclar el tráfico del plano de control con el tráfico del plano de datos en un

único proveedor de servicios CoS.

Separe el tráfico TCP del tráfico UDP cuando se realice la correspondencia con el

proveedor de servicios CoS.

La mayoría de los proveedores de servicios utilizan el marcado DSCP de los paquetes que

se les ofrecen para determinar a qué proveedor de servicios CoS se debe asignar el

paquete. Por lo tanto, las empresas deben marcar o volver a marcar su tráfico de acuerdo

con los criterios de admisión de su proveedor de servicios para obtener el nivel de servicio

apropiado.

Un principio general de DiffServ es marcar o confiar en el tráfico lo más cerca posible de la

fuente de la manera más técnica posible. Sin embargo, es posible que algunos tipos de

tráfico tengan que volver a marcarse antes del traspaso al proveedor de servicios para

obtener la admisión a la clase correcta. Si se requiere una nueva marcación, se recomienda

que el re-marcado se realice en el borde de salida del CE, no dentro del campus. La razón

es que los servicios de proveedores de servicios probablemente evolucionarán o se

expandirán con el tiempo, y el ajuste a tales cambios será más fácil de manejar si la remarcación

se realiza en un solo lugar, siendo ese lugar el borde de egreso CE.

A continuación se describen las políticas de QoS específicas para estos roles:

496

1. Ingreso / QoS interno del CE del campus: Se pueden aplicar políticas internas

/ingreso de QoS (si es necesario).

2. Borde del CE LAN:

a. Se debe habilitar la confianza DSCP de ingreso (activada de forma

predeterminada).

b. Se pueden aplicar las políticas de clasificación y marcado NBAR2 de Ingreso.

c. Se pueden aplicar las políticas de egreso LLQ / CBWFQ / WRED (si es

necesario).

3. Borde CE VPN:


predeterminada).

b. Se pueden aplicar las políticas de clasificación y marcado NBAR2 de Ingreso

(para restaurar las marcas de DSCP perdidas en tránsito).

c. Se pueden aplicar las políticas de egreso LLQ / CBWFQ / WRED (si es

necesario).

d. Se deben aplicar las políticas de egreso LLQ / CBWFQ / WRED.

e. Se puede aplicar una configuración jerárquica de salidas con políticas LLQ /

CBWFQ / WRED anidadas.

f. Se pueden aplicar políticas de re-marcado DSCP de egreso (para asignar

clases de aplicación a clases específicas de servicio de proveedores).

g. Ingreso de PE / interno: se pueden aplicar políticas de QoS internas

/ingreso (si es necesario).

4. PE que hace frente al cliente borde:


predeterminada).

b. Debe aplicarse políticas de vigilancia de ingreso para medir el tráfico de

clientes.

c. Se pueden aplicar directivas de modo de túnel MPLS de entrada.

d. Se pueden aplicar directivas de modo de túnel MPLS de salida.

e. Se deben aplicar las políticas de egreso LLQ / CBWFQ / WRED.

5. Borde de la viruta del PE:


predeterminada).

b. Debe aplicarse políticas de vigilancia de ingreso para medir el tráfico de

clientes.

c. Se deben aplicar las políticas LLQ / CBWFQ basadas en EXP. MPLS EXP.

d. Se pueden aplicar directivas WRED basadas en EXP MPLS EXP.

e. Entrada de P (enrutador central) / QoS interna: se pueden aplicar políticas

de QoS internas /ingreso (si es necesario).

6. Bordes P:


predeterminada).

497

b. Se pueden aplicar directivas LLQ / CBWFQ MPLS EXP basadas en EXP (a

menos que el núcleo esté sobresuscrito o tenga MPLS TE habilitado).

c. Se pueden aplicar directivas WRED basadas en EXP MPLS EXP.

498

Capítulo 19

Diseño QoS para las

VPN IPsec

499

LA NECESIDAD DE QOS EN LAS VPN IPSEC

Teniendo en cuenta que IPsec es muy utilizado en un gran número de casos que van desde

interconexiones de sitio a sitio hasta proporcionar servicios de acceso remoto a usuarios

domésticos, el despliegue de las VPNs IPsec introduce nuevos temas a considerar. Esto es

especialmente cierto cuando se utilizan aplicaciones en tiempo real que requieren QoS

para garantizar una experiencia de usuario de calidad.

Uno de los casos de uso de IPN VPN frecuentemente implementados es el despliegue de

túneles IPsec a través de una red pública. A pesar de que el aumento del ancho de banda

asociado con servicios basados en Internet suele ofrecer velocidades más altas a menor

costo en la mayoría de las geografías, la WAN de Internet todavía suele introducir un

cuello de botella, ya que ofrece menor ancho de banda en comparación con la LAN. El

cambio de un mayor ancho de banda en la LAN a un menor ancho de banda a través de la

WAN, obliga al ingeniero de red a implementar mecanismos de clasificación, marcado y

cola para asegurar que las aplicaciones sensibles a la distorsión reciben el manejo

preferido.

Varios desafíos deben tenerse en cuenta al implementar mecanismos bien conocidos de

QoS sobre la arquitectura IPsec:

Preservación de bytes ToS: Aunque un paquete IP normal incluye el byte ToS

dentro del encabezado, esta información se oculta del mecanismo de cola, ya que se

agrega un nuevo encabezado IP mientras que IPsec encripta el encabezado original.

Clasificación de los datos cifrados: La categorización en clases de tráfico requiere

la identificación del tipo de tráfico, que puede ser oscurecido por el paquete, que

está siendo cifrado antes del proceso de clasificación.

Sobrecarga: Cada mecanismo de tunelización agrega información de encabezado

adicional al paquete IP original y, como resultado, aumenta el tamaño del paquete,

reduciendo así la cantidad de datos que se transportan a través del enlace.

Gestión de la pérdida de paquetes y jitter: IPsec incorpora capacidades antireplay

para soltar paquetes que pueden repetirse fraudulentamente o se pueden

retrasar. Los paquetes que se eliminan por la función anti-replay pueden afectar

negativamente el tráfico sensible a la latencia.

500

CASOS DE USO DE VPN Y SUS MODELOS DE QOS

IPsec se puede implementar aprovechando túneles VPN de sitio a sitio manuales entre dos

sitios o conectando usuarios de acceso remoto a la red corporativa a través de la red

pública. Las implementaciones avanzadas de IPsec también son posibles aprovechando las

siguientes tecnologías:

VPN dinámico multipunto (DMVPN): Uso de una arquitectura centralizada para

crear una VPN dinámica multipunto escalable. DMVPN ofrece la capacidad de

construir una conectividad ondemand de malla completa usando una configuración

simple hub-and-spoke.

GET VPN: Utilizando la infraestructura de enrutamiento de IP VPN subyacente para

implementar una conectividad IP a gran escala a través de IPsec sin necesidad de

un plano de control de superposición. Al eliminar los túneles punto a punto y la

arquitectura de enrutamiento de superposición asociada, GET VPN permite la

replicación de multidifusión y el mayor nivel de escalabilidad proporcionado por la

topología IP VPN.

Cada tecnología VPN utilizada para proporcionar conectividad aprovecha las diferentes

características y capacidades de QoS.

IPSEC REFRESHER

Las VPN IPsec se pueden configurar en topologías punto a punto y punto a multipunto en

función del caso de uso, del dispositivo de cabecera y de las funciones solicitadas. Además,

las VPN IPsec estándar pueden dividirse en las siguientes categorías:

Modo túnel: Al usar el modo predeterminado, el paquete IP completo está

protegido por IPsec. El enrutador VPN de envío cifra el paquete IP original y agrega

un nuevo encabezado IP al paquete. Una ventaja clave de la operación en modo

túnel es que admite la multidifusión a través del túnel VPN y permite la

implementación de protocolos de enrutamiento a través de la WAN.

Modo de transporte: A diferencia del modo túnel, el modo de transporte no cifra

todo el paquete IP, sino que encripta sólo la carga útil y conserva el encabezado IP

original. Al conservar la cabecera IP original, el modo de transporte no es capaz de

soportar la implementación de servicios como protocolos de enrutamiento y de

multidifusión. El modo de transporte se utiliza a menudo con el encapsulado

genérico de enrutamiento (GRE), por lo que el túnel GRE entero está encriptado y

501

admite protocolos de enrutamiento y de multidifusión que se implementarán en

GRE.

GRE es un protocolo de tunelización que puede encapsular varios protocolos de capa de

red dentro de un enlace punto a punto virtual a través de una red IP. Por sí mismo, GRE es

un protocolo versátil y flexible que se utiliza para interconectar redes dispares y para

apoyar casos de uso tales como

Enrutamiento y reenvío virtuales (VRF-Lite)

DMVPN

Transporte de protocolos no IP

Transporte de multidifusión

Transporte de protocolos de enrutamiento

El reto con GRE es que no proporciona ningún mecanismo de privacidad y autenticación.

Por lo tanto, el uso de una combinación con IPsec permite al administrador de red crear

conexiones seguras entre unidades remotas utilizando una infraestructura pública.

El paquete IP original está encapsulado por el encabezado GRE, que a su vez está cifrado

por IPsec para proporcionar privacidad. Como IPsec introduce varios encabezados

adicionales al paquete IP original, la sobrecarga aumenta drásticamente.

502

Se requiere que el enrutador VPN preserve el valor ToS en el encabezado IP agregado

recientemente. Si el valor ToS no se conserva, los mecanismos de cola no pueden priorizar

el tráfico sensible a la latencia como resultado del tráfico cifrado por IPsec.

Las VPN de acceso remoto proporcionan comunicaciones seguras y privilegios de acceso

dependiendo de la función de usuario remoto. Las VPN de acceso remoto amplían la red

corporativa y las aplicaciones a los usuarios remotos, independientemente de la

conectividad establecida de sitio a sitio.

El cliente VPN principal de acceso remoto de Cisco es AnyConnect Secure Mobility Client

que admite la encriptación IPsec y Secure Sockets Layer (SSL). Aunque AnyConnect no

admite ninguna clasificación específica de QoS, filas o herramientas de vigilancia, incluye

DTLS (Datagram Transport Layer Security), lo que mejora significativamente la

experiencia al utilizar aplicaciones en tiempo real.

Cuando AnyConnect se conecta primero al dispositivo de cabecera, se configura un túnel

SSL basado en TCP. Cuando la sesión SSL está completamente establecida, el cliente

negocia un nuevo túnel DTLS basado en UDP, que está reservado para el uso exclusivo de

aplicaciones en tiempo real. La naturaleza UDP de DTLS permite que los paquetes de voz y

video RTP se transmitan sin obstáculos. Si se produce una pérdida repentina de paquetes

o eventos de red inesperados, la sesión no se detiene y los paquetes perdidos no se

reenviarán. Por el contrario, los paquetes consecutivos continúan fluyendo de forma

normal, resultando en una experiencia más fluida asociada con el aprovechamiento del

software de voz o video.

ENCRIPTACIÓN Y CLASIFICACIÓN IOS: ORDEN DE

OPERACIONES

La clasificación QoS es un proceso de emparejar uno o más campos en el encabezado IP

del paquete y asignar el paquete a una clase de tráfico. Sin embargo, cuando se está

encriptando un paquete, el encabezado IP original ya no es visible y el mecanismo QoS se

vuelve ineficaz cuando se aplica al paquete original. Para solucionar este problema, la

operación consiste en copiar el campo ToS desde el encabezado IP original en el nuevo

encabezado IP que encapsula el paquete original.

503

Cuando se realiza esta copia, el proceso de clasificación todavía puede realizarse, haciendo

coincidir el valor ToS. El comportamiento de preservación de Cisco IOS está disponible de

forma predeterminada para tráfico IPsec, GRE y GRE encapsulado y encriptado con IPsec y

no req-uiere ninguna configuración adicional por parte del operador de red.

La limitación del comportamiento predeterminado de Cisco IOS es que sólo el byte ToS se

conserva. Si se requiere clasificación basada en otros campos de encabezado IP, se

requiere otro mecanismo. Ejemplos de clasificación basada en campos de encabezado IP

distintos de ToS son

Dirección IP origen

Dirección IP de destino

Puerto de origen

Puerto de destino

Banderas

La limitación del mecanismo de preservación de IOS de Cisco es que sólo el byte ToS se

utiliza desde el encabezado original en el nuevo encabezado de encapsulado. Siempre que

requiera que el proceso de clasificación se implemente en el campo de encabezado IP que

no sea el byte ToS, esto resulta en un orden inverso de operación en IOS donde la

clasificación tiene lugar antes del cifrado. Cuando este es el caso, es necesario utilizar la

función de preclasificación de IOS.

La función de preclasificación clona la cabecera IP original y la mantiene en la memoria

del enrutador con la intención de usarla para el proceso de clasificación después de la

encriptación. Este mecanismo tiene el efecto de revertir el orden normal de

funcionamiento de Cisco IOS. La función de preclasificación se puede implementar en los

túneles IPsec y GRE. Una limitación clave con este enfoque es que el encabezado IP

clonado sólo es aplicable en la interfaz de salida del enrutador de cifrado. Los enrutadores

downstream no serían capaces de hacer la clasificación QoS que se basa en parámetros

distintos de los ToS.

Si le preocupa que la política QoS cambie posteriormente para incluir criterios de

coincidencia en otros campos en el encabezado IP, la recomendación para una mejor

práctica es habilitar la característica de preclasificación en el enrutador VPN.

504

CONSIDERACIONES MTU

Los mecanismos de túnel afectarán el tamaño de la unidad de transmisión máxima (MTU)

debido a la sobrecarga añadida. Siempre que las tecnologías de tunelización se utilizan en

una red, siempre existe el riesgo de superar la MTU en algún lugar de la ruta. A menos que

las tramas jumbo estén habilitadas de extremo a extremo, es crítico abordar problemas de

MTU al usar cualquier tipo de tecnología VPN porque los problemas de MTU pueden

afectar gravemente la conectividad de red.

Tipo de túnel

GRE

IPsec (Modo de transporte)

IPsec (Modo de túnel)

IPsec (Modo de transporte) + GRE

IPsec (Modo de túnel) + GRE

Encabezado

24 bytes

36 bytes

52 bytes

60 bytes

76 bytes

Cuando está utilizando GRE y el paquete entra en el enrutador VPN, se encapsulará el

paquete original, aumentando el tamaño total del paquete en 24 bytes, reduciendo así el

tamaño máximo de la unidad a 1476 si asume una MTU predeterminada de 1500.

Enviando paquetes mayores de 1476 resultará en fragmentación y caída.

En comparación con GRE, IPsec no sólo agregará 24 bytes de sobrecarga, pero la

sobrecarga puede variar en función del conjunto de transformaciones IPsec configurado.

La sobrecarga máxima podría ser de hasta 73 bytes, lo que es mucho más. IPsec intentará

un descubrimiento MTU de ruta para establecer el tamaño máximo y para ayudar al

enrutador a fragmentar de forma preventiva los paquetes que son mayores que el tamaño

de MTU de red admitidos.

Como recomendación, siempre es mejor evitar la fragmentación si es posible y configurar

el tamaño MTU basado en la cantidad de sobrecarga que está siendo introducido por la

tecnología VPN. Existe un parámetro de unidad de transmisión máxima (MTU) para cada

enlace en una red IP y, típicamente, la MTU es de 1500 bytes. Los paquetes IP de más de

1500 bytes deben ser fragmentados cuando se transmiten a través de estos enlaces. La

fragmentación no es deseable y puede afectar el rendimiento de la red. Para evitar la

fragmentación, el tamaño del paquete original más la sobrecarga debe ser de 1500 bytes o

menos, lo que significa que el remitente debe reducir el tamaño del paquete original. Para

tener en cuenta otras posibles sobrecargas, Cisco recomienda configurar las interfaces de

túnel con una MTU de 1400 bytes. Existen métodos dinámicos para que los clientes de

redes descubran la ruta MTU, lo que permite a los clientes reducir el tamaño de los

paquetes que transmiten. Sin embargo, en muchos casos, estos métodos dinámicos no

tienen éxito, porque los dispositivos de seguridad filtran el tráfico de descubrimiento

505

necesario. Este fallo al descubrir la ruta MTU impulsa la necesidad de un método que

pueda informar de forma fiable a los clientes de la red del tamaño de paquete apropiado.

La solución es implementar el comando ip tcp adjust mss [size] en los enrutadores WAN,

lo que influye en el valor de tamaño máximo de segmento TCP (MSS) informado por los

hosts finales. El MSS define la cantidad máxima de datos que un host está dispuesto a

aceptar en un único datagrama TCP / IP. El valor MSS se envía como una opción de

encabezado TCP sólo en los elementos TCP SYN. Cada lado de una conexión TCP informa

su valor MSS al otro lado. Se requiere que el host emisor limite el tamaño de los datos en

un solo segmento TCP a un valor menor o igual al MSS informado por el host receptor. Los

encabezados IP y TCP se combinan para 40 bytes de sobrecarga, por lo que el valor MSS

típico informado por los clientes de la red será 1460. Teniendo en cuenta que los túneles

cifrados se establecerá con un MTU de 1400 bytes, el MSS utilizado por los puntos finales

debe ser 1360 para minimizar cualquier impacto de la fragmentación. Esto significa que es

necesario implementar el comando ip tcp adjust mss 1360 en todas las interfaces de

enrutador orientadas a WAN.

CONSIDERACIONES DE QOS DE DMVPN

DMVPN, combina el almacenamiento multipunto-GRE (mGRE), la detección dinámica de

los puntos finales del túnel y el Next Hop Resolution Protocol (NHRP), que permite el

despliegue sencillo y rápido de cientos de spokes sin interrupciones, permitiendo el

establecimiento dinámico de túneles de comunicación spoke-to-spoke.

506

DMVPN es parte de la red de tránsito de IP y hay una confianza implícita de las señales

DSCP de los paquetes que son recibidos en la interfaz por los enrutadores VPN hub y

spoke. Por lo tanto, las funciones de QoS primarias en una topología DMVPN son la

formación jerárquica saliente y la cola de las clases de tráfico específicas sobre los túneles

VPN.

Un desafío QoS asociado con DMVPN es que todos los túneles hub-and-spoke terminen en

una sola interfaz de túnel mGRE en el enrutador concentrador. Si bien la aplicación de una

directiva QoS para una implementación sitio a sitio sería el método recomendado con

DMVPN, sólo hay una interfaz mGRE única, que no permite configurar una directiva por

sitio. La política única sería capaz de controlar la QoS de la interfaz de túnel, pero no podía

manejar la comunicación entre los radios y no podía evitar una comunicación excesiva

entre ellos.

Por lo tanto, como DMVPN se basa en interfaces de túnel mGRE, las políticas de QoS

tradicionales en el nivel de interfaz no funcionan. Para resolver el problema, Cisco ha

implementado una característica que se denomina QoS por túnel para DMVPN. La QoS por

túnel para la característica DMVPN le permite habilitar QoS en un túnel o por spoke

cuando se usa DMVPN. La característica le permite aplicar una política de servicio de QoS

saliente en la interfaz de usuario mGRE en el concentrador DMVPN, que es aplicada por el

enrutador a cada túnel de spoke al que se asocia la política de servicio.

507

El efecto de esta nueva funcionalidad es que protege los spoke del tráfico excesivo entre sí.

Un formador se aplica automáticamente por el sistema para cada túnel. Esta aplicación, a

su vez, permite al enrutador implementar servicios diferenciados para los flujos de datos

correspondientes a cada túnel. Esta técnica se llama Jerarchical Queuing Framework

(HQF). Usando HQF, la política de QoS que se aplica a la interfaz mGRE en el hub DMVPN le

permite dar forma al tráfico del túnel a cada uno de los spoke usando una política padre y

luego aplicar servicios diferenciados para varios flujos de datos que atraviesan cada túnel

con clases ponderadas Faire queuing (CBWFQ) como parte de una Política Hijo.

Además, una ventaja clave de la QoS por túnel para la característica DMVPN es que

proporciona una generación automatizada de la política QoS para cada túnel cuando el

spoke se registra en el concentrador, reduciendo la configuración manual. DMVPN se basa

en NHRP para el descubrimiento de punto final, el enrutamiento y la QoS por túnel.

CONSIDERACIONES DE QOS DE VPN GET

Como DMVPN provee una arquitectura "hub-and-spoke" que es adecuada para redes

públicas no confiables como Internet, GET VPN es el más adecuado para su uso en redes

508

privadas como MPLS que ofrecen servicios any-to-any. En el caso de GET VPN, no existe un

concepto de asociación de seguridad (SA) entre los enrutadores particulares de la red, lo

que significa que no hay túneles IPsec. GET VPN apalanca el concepto de un grupo SA, que

es compartido por todos los nodos de cifrado en la red. Debido a que todos los

enrutadores de la VPN GET pertenecen a un grupo SA grande , no hay necesidad de aplicar

QoS en una base por sitio; basta con configurar QoS en la interfaz de salida de cada

enrutador GET VPN. El concepto de QoS por túnel que se utilizó para DMVPN es

irrelevante en un diseño de GET VPN. Dos tipos de enrutadores se utilizan en una

arquitectura GET VPN:

El enrutador miembro del grupo (GM) es el dispositivo que realiza el cifrado y

descifrado reales de los paquetes a medida que recorren el enrutador.

Key Server (KS) es responsable de administrar las claves de cifrado que utilizan los

miembros del grupo.

Aunque siempre hay al menos un enrutador GM en cada sitio remoto de la red, sólo hay un

único par de enrutadores KS redundantes desplegados para todo el GET VPN. GET VPN

utiliza tanto la preservación ToS como los mecanismos de preclasificación para permitir la

clasificación de paquetes ya cifrados. Además, como GET VPN conserva toda la cabecera

IP, puede clasificar en base a direcciones IP de origen y destino sin el uso de la función de

preclasificación. Sin embargo, la clasificación basada en números de puerto TCP y UDP

requiere que la función de preclasificación esté habilitada.

DMVPN

VPN GET

Caso de uso Redes públicas (Internet) Redes privadas (MPLS)

Estilo de red Hub-a-spoke/spoke-a-spoke Any-to-any

Arquitectura de

enrutamiento

Enrutamiento dentro de los túneles

GRE

Enrutamiento dinámico de paquetes

IPsec nativos

Estilo de

Encriptación punto a punto

Encriptación grupal

encriptado

Implementación

QoS

La QoS se aplica en cada

miembro del grupo GET VPN

Gestión de QoS por túnel a través

de la membresía en el grupo

NHRP. Utiliza un formador

jerárquico en la interfaz mGRE del

concentrador.

porque no se utilizan túneles.

Normalmente utiliza un

formador jerárquico en la

interfaz de salida.

Multicast Replicación en el concentrador Any-to-any (no es necesario que el

tráfico pase a través del concentrador)

IPsec SA Anti-Replay

IPsec SA anti-replay es un servicio de seguridad en el que el enrutador de descifrado

puede rechazar los paquetes duplicados y protegerse contra los ataques de repetición.

Cisco QoS da prioridad a paquetes de alta prioridad, y como resultado, esta priorización

puede hacer que algunos paquetes de baja prioridad sean descartados. Cisco IOS

proporciona protección anti-replay contra un atacante que duplica paquetes cifrados. Los

509

retrasos en las colas de QoS pueden provocar caídas de paquetes anti-replay, por lo que es

importante extender el tamaño de la ventana para permitir al enrutador realizar un

seguimiento de más de 64 paquetes predeterminados para evitar que se produzcan las

caídas.

510

Capítulo 20

Diseño IP Multicast de

la Empresa

511

¿CÓMO FUNCIONA LA MULTIDIFUSIÓN IP?

Dado que la multidifusión es un modo de transmisión diferente a la unidifusión, sólo los

protocolos diseñados para la multidifusión pueden utilizarse. Las redes de multidifusión

tienen segmentos de origen, red y receptor. Todos estos segmentos deben realizar

funciones específicas para poder entregar tráfico multicast. La idea principal de

multidifusión es replicar un único paquete para múltiples receptores.

El remitente envía sólo una copia de un único paquete de datos que está dirigido a un

grupo de receptores denominado grupo de multidifusión. Los enrutadores de

multidifusión en sentido descendente replican y envían el paquete de datos a todas las

sucursales donde existen receptores. Los receptores expresan su interés en el tráfico de

multidifusión al registrarse en su primer enrutador utilizando el protocolo IGMP (Internet

Group Management Protocol) para la multidifusión IPv4 o Multicast Listener Discovery

(MLD) para la multidifusión IPv6.

Los enrutadores son responsables de replicar el paquete y reenviarlo a varios

destinatarios. Los enrutadores replican el paquete en cualquier punto donde las rutas de

red divergen. La técnica de reenvío de ruta inversa (RPF) asegura que el paquete es

reenviado a las rutas de aguas abajo apropiadas sin bucles de enrutamiento. El poder de la

multidifusión es que cada paquete existe sólo en una copia en cualquier red dada. El host

de origen de multidifusión puede enviar a múltiples receptores de forma simultánea con

sólo un paquete.

512

Grupo de multidifusión

Una dirección de multidifusión está asociada con un grupo de receptores interesados. De

acuerdo con el RFC 3171, las direcciones 224.0.0 a 239.255.255.255, las antiguas

direcciones de clase D, se designan como direcciones de multidifusión en IPv4. Las

direcciones de multidifusión en IPv6 tienen el prefijo FF00 :: / 8. El remitente envía un

único datagrama a la dirección de multidifusión. Los enrutadores intermedios se encargan

de hacer copias y enviar un datagrama a todos los receptores. Los receptores han

registrado su interés en recibir los datos de multidifusión para esa dirección de

multidifusión.

Modelo de servicio de multidifusión IP

513

Los modelos de servicio de multidifusión IP están integrados por tres componentes

principales:

Los remitentes envían a una dirección de multidifusión.

Los receptores expresan interés en una dirección de multidifusión.

Los enrutadores entregan el tráfico de los remitentes a los receptores.

RFC 1112 especifica las extensiones IP de host para admitir la multidifusión:

La multidifusión IP permite a los hosts unirse a un grupo que recibe paquetes de

multidifusión.

La multidifusión IP permite a los usuarios registrar dinámicamente (unirse o

abandonar grupos de multidifusión) en función de las aplicaciones que utilizan.

La multidifusión IP utiliza datagramas IP para transmitir datos.

Las direcciones de multidifusión se asignan dinámicamente y representan los grupos de

receptores, no los hosts individuales. Los receptores pueden unirse o abandonar

dinámicamente un grupo de multidifusión IP en cualquier momento utilizando mensajes

IGMP o MLD. Los mensajes se envían a los enrutadores de último salto, que administran la

pertenencia a grupos. Los enrutadores utilizan protocolos de enrutamiento multicast

como Protocol-Independent Multicast (PIM) para enviar de forma eficiente los datos de

multidifusión a múltiples receptores. Los enrutadores escuchan todas las direcciones de

multidifusión y crean árboles de distribución multicast, que se utilizan para el reenvío de

paquetes de multidifusión.

Los enrutadores identifican el tráfico de multidifusión y envían los paquetes desde los

remitentes hacia los receptores. Cuando la fuente se activa, comienza a enviar los datos sin

ninguna indicación. Los enrutadores de primer salto (FHR), a los que las fuentes están

conectadas directamente, comienzan a reenviar los datos a la red. Los receptores que

están interesados en recibir datos de multidifusión IP se registran en los enrutadores de

último salto (LHR) utilizando mensajes de membresía IGMP o MLD. Los enrutadores de

último salto son los enrutadores que tienen receptores conectados directamente. Los LHR

envían la información de pertenencia de grupo de sus receptores a la red para que los

demás enrutadores estén informados sobre qué flujos de multidifusión son necesarios.

514

Funciones de una red de multidifusión

En una red de multidifusión, los enrutadores crean y mantienen un árbol de distribución

multicast.

Los pasos clave para una red de multidifusión que funciona correctamente son los

siguientes:

1. Aprender acerca de los miembros del grupo de multidifusión y crear un árbol de

distribución adecuado.

2. Identificar los flujos de multidifusión y reenviarlos de acuerdo con un árbol de

distribución.

515

3. Mantener el estado de grupo en los segmentos de hoja y los árboles de distribución

en toda la red.

4. Evitar los bucles y aplicar el alcance y el filtrado.

Como se puede ver en estos pasos, para construir árboles de distribución multidifusión

apropiados, los enrutadores de red de multidifusión deben aprender acerca de sus vecinos

habilitados. A medida que construyen los árboles de distribución de multidifusión, los

enrutadores comienzan a reenviar tráfico multicast según las necesidades de la red.

Durante el funcionamiento normal, los enrutadores mantienen los árboles de distribución

de multidifusión y el estado del grupo de multidifusión en los segmentos de hoja. Los

enrutadores también evitan bucles y aplican funciones de alcance o filtrado.

PROTOCOLOS DE MULTIDIFUSIÓN

Los protocolos de multidifusión pueden diferir dependiendo de dónde se implementen en

una red de multidifusión. No se usa ningún protocolo de multidifusión para el registro de

origen entre el enrutador de origen y el de primer salto, como IGMP, que se utiliza entre el

enrutador de último salto y el receptor. Sin embargo, es necesario que la multidifusión

esté habilitada en la interfaz frente a la red fuente / remitente.

Dentro de la red, se utilizan varios protocolos de enrutamiento multicast. Los protocolos

de enrutamiento multicast pueden ser separados en dos grupos basados en funciones

intradominio versus interdominio:

Intradominio: PIM y variantes

516

Interdominio: Extensiones multiprotocolo para BGP (MP-BGP) en combinación

con el Protocolo de Descubrimiento de Origen de Multicast (MSDP: Multicast

Source Discovery Protocol)

Entre el enrutador de último salto y los receptores, los receptores usan IGMP (para IPv4) o

MLD (para IPv6) para informar de su pertenencia a un grupo de multidifusión al

enrutador.

REENVÍO DE MULTIDIFUSIÓN Y COMPROBACIÓN RPF

En el enrutamiento unicast, cuando el enrutador recibe el paquete, la decisión de reenviar

el paquete se realiza dependiendo de la dirección de destino del paquete. En el

enrutamiento de multidifusión, donde reenviar el paquete de multidifusión depende de

dónde proviene el paquete. Los enrutadores de multidifusión deben conocer el origen del

paquete además de su destino, que es lo opuesto al enrutamiento unicast.

El paquete de multidifusión es enviado a cada interfaz que está en la lista de interfaz de

salida (OIL: outgoing interface list). Las entradas de OIL enumeran las interfaces de los

vecinos de multidifusión que están hacia abajo del enrutador actual. Los enrutadores

realizan una comprobación de reenvío de ruta inversa (RPF) para asegurar que los

paquetes multicast que llegan se recibieron a través de la interfaz que está en la ruta más

directa a la fuente que envió los paquetes.

Una comprobación de RPF se realiza siempre con respecto a la interfaz entrante, que se

considera ser la interfaz de RPF. La comprobación RPF tendrá éxito si la interfaz entrante

es la ruta más corta a la fuente.

El enrutador determina la interfaz RPF por el protocolo de enrutamiento unicast

subyacente o el protocolo de enrutamiento multicast dedicado en los casos en que existe

uno. Un ejemplo de un protocolo dedicado de enrutamiento multicast es MP-BGP. Es

importante tener en cuenta que el protocolo de enrutamiento multicast se basa en la tabla

de enrutamiento unicast subyacente. Cualquier cambio en la tabla de enrutamiento

unicast desencadena inmediatamente una revisión de RPF en la mayoría de los

enrutadores modernos.

517

El cálculo del RPF se basa en la dirección de origen. La mejor ruta de acceso a la fuente se

encuentra en la tabla de enrutamiento unidifusión del enrutador de último salto y resulta

en determinar dónde enviar la combinación. La combinación continúa hacia la fuente para

crear el árbol de distribución de multidifusión que crea la ruta, por lo que los datos de

multidifusión pueden fluir por el árbol. Este proceso se repite para cada receptor. En

circunstancias en las que se utiliza el enrutamiento por trayectos múltiples de igual coste

(ECMP), se utiliza la dirección IP de salto siguiente más alta como desempate, ya que sólo

puede haber una única ruta para el flujo de multidifusión.

518

El diagrama de la izquierda de la figura ilustra una comprobación fallida del RPF y la de la

derecha ilustra una comprobación del RPF satisfactoria:

El enrutador en el diagrama izquierdo recibe un paquete de multidifusión desde la

fuente 151.10.3.21 en la interfaz Serial 0. El enrutador realiza la comprobación RPF

examinando la tabla de enrutamiento unidifusión. La tabla de enrutamiento unicast

indica que la interfaz Serial 1 es la ruta más corta a la red 151.10.0.0/16. Dado que

la interfaz Serial 0 no es la ruta más corta a la red desde la cual llegó el paquete

desde la fuente 151.10.3.21, la comprobación RPF falla y el paquete se descarta.

El enrutador en el diagrama de la derecha recibe un paquete de multidifusión de la

fuente 151.10.3.21 en la interfaz de serie 1. El enrutador realiza la comprobación

RPF mirando a la tabla de enrutamiento unidifusión. La tabla de enrutamiento

unicast indica que la interfaz Serial 1 es la ruta más corta a la red 151.10.0.0/16.

Dado que la interfaz Serial 1 es la ruta más corta a la red desde la cual llegó el

paquete desde la fuente 151.10.3.21, la comprobación RPF tiene éxito. Con este

éxito, el paquete se envía en cada interfaz en la lista de interfaz de salida. En el

diagrama de la derecha, el OIL para el paquete multicast actual consta de las

interfaces Serial 2 y Ethernet 0, por lo que el paquete se reenvía en estas interfaces.

FUNDAMENTOS DEL PROTOCOLO DE MULTIDIFUSIÓN

Los árboles de distribución de multidifusión definen la ruta desde la fuente a los

receptores. Los dos tipos de árbol de distribución de multidifusión son árboles raíz de

origen (o SPT) y árboles compartidos.

Con un árbol de raíz de origen, se crea un árbol independiente para cada fuente para todos

los miembros de un grupo de multidifusión. Teniendo en cuenta que el árbol raíz de origen

toma un camino directo o más corto desde la fuente a sus receptores, también se conoce

como un SPT.

Los árboles compartidos crean rutas de reenvío de multidifusión que dependen de un

enrutador de núcleo central. Este enrutador sirve como Punto de Encuentro (Rendezvous

Point: RP) entre fuentes multicast y receptores. Las fuentes envían inicialmente sus

paquetes de multidifusión al RP, que, a su vez, reenvía datos a través de un árbol

compartido a los miembros del grupo. Un árbol compartido puede ser menos eficiente que

un SPT. En el modelo de árbol compartido, los caminos entre la fuente y los receptores no

son necesariamente los más cortos, pero es importante tener en cuenta que un árbol

compartido es menos exigente con los enrutadores en términos de memoria y uso de la

CPU.

519

Existen dos tipos de protocolos de enrutamiento multicast: el modo denso y los protocolos

de modo disperso. Los protocolos de modo denso inundan el tráfico de multidifusión a

todas las partes primero y luego podan los flujos donde no hay receptores usando un

mecanismo periódico de inundación y poda. Los protocolos de modo disperso utilizan un

mecanismo de unión explícito. Con los protocolos de modo disperso, los árboles de

distribución se crean a petición mediante mensajes de unión de árbol explícitos. Los

enrutadores, que tienen receptores conectados directamente, enviarán mensajes de unión.

La Figura muestra un SPT entre la Fuente 1, el Receptor 1 y el Receptor 2.

Se asume apropiadamente que la trayectoria entre la fuente y los receptores sobre los

enrutadores A, C, y E es la trayectoria con el coste más bajo. Los paquetes se envían por el

SPT según los pares de direcciones de origen y de grupo. Esta es la razón por la cual el

estado de reenvío que está asociado con el SPT es referido por la notación (S, G), que se

pronuncia S coma G. En esta notación, S es la dirección IP de la fuente y G es el grupo de

multidifusión dirección. Se construye un SPT separado para cada fuente S que envía a un

grupo G.

520

El enrutador D es la raíz de este árbol compartido. En PIM, la raíz del árbol compartido se

llama RP, como ya se mencionó. Los paquetes se envían por el árbol de distribución

compartida a los receptores. La notación (*, G), pronunciada estrella coma G, identifica el

estado de reenvío predeterminado para el árbol compartido. El símbolo * representa una

entrada de comodín, lo que significa que cualquier fuente se puede conectar a la notación,

y G es la dirección de grupo de multidifusión.

Los árboles siempre se construyen hacia atrás. Así que el árbol compartido comenzó

cuando el Receptor 1 envió un informe de membresía IGMP y el LHR, enrutador C, luego

creó un (*, G) y añadió la interfaz Rx 1 como un OIL. Entonces busca quién es el RP, dónde

está y cuál es el vecino del PIM RPF. A continuación, construye una unión PIM (*, G) y la

envía hacia el enrutador D.

La Figura también muestra el flujo de tráfico en dos árboles con raíces de origen además

del árbol de distribución compartida. Fuente 1 y Fuente 2 envian paquetes de

multidifusión hacia un RP a través de los árboles raíz de origen. Desde el RP, los paquetes

de multidifusión fluyen a través de un árbol de distribución compartida hacia el Receptor

1 y el Receptor 2. Tenga en cuenta que las fuentes sólo están enviando. Irán dondequiera

que se construyan los árboles. El RP envía PIM (S, G) se une de nuevo hacia la raíz del

árbol (S, G), que es el enrutador de primer salto (FHR).

Identificación de árboles de distribución de multidifusión

Es importante tener en cuenta las diferencias clave entre los árboles de distribución

multicast para comprender mejor qué protocolo de enrutamiento multicast se implementa

en la red.

521

Las entradas de reenvío de multidifusión que aparecen en las tablas de reenvío de

multidifusión pueden leerse de la siguiente manera:

(S, G): Esta notación indica que una fuente S está enviando al grupo G.

(*, G): Esta notación indica que cualquier fuente (*) envía al grupo G. Estas entradas

reflejan el árbol compartido, pero también se crean (en enrutadores Cisco) para

cualquier entrada existente (S, G).

Como ya se ha indicado, las entradas de estado SPT (S, G) utilizan más memoria de el

enrutador. La razón de esto es que hay una entrada para cada remitente y par de grupo.

Sin embargo, debido a que el tráfico se envía a través de la ruta óptima a cada receptor, el

retraso en la entrega de paquetes se minimiza.

La entrada de estado (*, G) para árboles de distribución compartida consumen menos

memoria de enrutador, pero puede obtener rutas subóptimas de una fuente a receptores,

introduciendo así un retraso adicional en la entrega de paquetes. Es importante elegir el

modelo de árbol apropiado para satisfacer las demandas de la aplicación.

DESCRIPCIÓN DE PIM-SM

El protocolo independiente de multidifusión de modo de dispersión (PIM-SM) es un

protocolo de enrutamiento de multidifusión para redes IP. PIM-SM utiliza árboles de

distribución compartida que están enraizados en el RP pero que también pueden cambiar

al árbol de distribución con raíz de origen. PIM-SM utiliza el modelo de unión explícita. Los

receptores envían un informe de membresía IGMP o un MLD (IPv6) al LHR. El LHR crea

una unión PIM (*, G) una vez que sabe quién es el RP para ese grupo de multidifusión y

luego lo envía al RP designado. El RP es la raíz de un árbol de distribución compartido que

todo el tráfico de multidifusión fluye hacia abajo.

Las características de PIM-SM incluyen:

Modelo de unión explícita a través del RP.

Los receptores se unen al RP a través del enrutador de último salto (LHR) (no

directamente).

Los remitentes se registran con el RP a través del enrutador de primer salto (FHR)

(no directamente).

Los datos fluyen por el árbol compartido y van sólo a los lugares que necesitan los

datos de las fuentes.

Los LHR pueden unirse al árbol de origen si la velocidad de datos excede el umbral.

Para obtener el tráfico de multidifusión del RP para su distribución por el árbol

compartido, los enrutadores de primer salto con remitentes conectados directamente

522

envían mensajes de registro PIM al RP. Los mensajes de registro hacen que el RP envíe una

unión (S, G) hacia la fuente. Esta actividad permite que el tráfico de multidifusión fluya de

forma nativa al RP a través de un SPT y luego hacia abajo del árbol compartido.

Los LHR pueden configurarse con un umbral SPT, el cual, una vez superado, hará que el

enrutador de último salto se una al SPT. Esta acción hará que el tráfico de multidifusión de

la fuente fluya hacia abajo del SPT directamente al enrutador de último salto.

Las siguientes variantes PIM-SM están disponibles:

PIM bidireccional (BIDIR-PIM): Construye explícitamente árboles bidireccionales

compartidos. Nunca construye un árbol de trayecto más corto, por lo que puede

tener demoras de extremo a extremo más largas que PIM-SM, pero se adapta bien

porque no necesita ningún estado específico de la fuente.

PIM-Multicast Específico de Origen (PIM-SSM): Crea árboles arraigados en una

sola fuente, ofreciendo un modelo más seguro y escalable para un número limitado

de aplicaciones.

PIMv6 es una implementación del PIM-SM para IPv6. PIMv6 proporciona soporte para el

enrutamiento entre dominios y evita los problemas de rendimiento de los protocolos de

enrutamiento multicast anteriores.

El receptor se une al árbol compartido PIM-SM

En este ejemplo, un enrutador designado (DR) en el segmento LAN recibirá informes de

membresía IGMP. El DR conoce la dirección IP del router RP para el grupo G y envía una

unión (*, G) para este grupo hacia el RP. La unión viaja salto a salto hacia el RP, la

construcción de una rama del árbol compartido que se extiende desde el RP hasta el

último salto de enrutador directamente conectado al receptor. En este punto, el tráfico del

grupo G puede fluir por el árbol compartido hasta el receptor.

523

Registro en RP

Tan pronto como una fuente activa para el grupo G comienza a enviar paquetes de

multidifusión, su primer salto DR registra la fuente con el RP.

524

Para registrar una fuente, el DR encapsula los paquetes de multidifusión en un mensaje de

registro PIM y envía el mensaje a la RP usando unidifusión. Cuando el RP recibe el mensaje

de registro de unicast, desencapsula los paquetes de multidifusión dentro del mensaje de

registro de unidifusión.

Los paquetes de multidifusión se envían por el árbol compartido hacia los receptores. Al

mismo tiempo, el RP inicia la construcción de un SPT de la fuente a la RP enviando (S, G) se

une hacia la fuente. La construcción de un SPT provoca la creación de un estado (S, G) en

todos los enrutadores a lo largo del SPT, incluyendo el RP. Después de que el SPT se

construye, desde el enrutador de primer salto a la RP, el tráfico de multidifusión empieza a

fluir desde la fuente (S) hasta la RP.

Cuando el RP comienza a recibir datos de multidifusión hacia abajo del SPT desde la

fuente, envía un mensaje de cancelación de registro PIM de unidifusión al enrutador de

primer salto.

El mensaje PIM register-stop informa al enrutador de primer salto que puede dejar de

enviar los mensajes de registro de unidifusión. En este punto, el tráfico multicast de la

fuente está fluyendo hacia abajo del SPT al RP y, desde allí, hacia abajo del árbol

compartido a los receptores.

Conmutación SPT PIM-SM

525

PIM-SM permite al enrutador de último salto cambiar al SPT y evitar el RP si la tasa de

tráfico de multidifusión está por encima de un umbral establecido. Este umbral se llama el

umbral SPT.

En los enrutadores Cisco, el valor por defecto del umbral SPT es 0. Así, tan pronto como el

primer paquete llega a través del árbol compartido (*, G), la acción predeterminada para

los enrutadores Cisco PIM-SM conectados a receptores activos es unirse inmediatamente

al SPT de la fuente.

La Figura ilustra el enrutador de último salto que envía un mensaje de unión (S, G) hacia la

fuente para unirse al SPT y eludir el RP.

El mensaje de unión viaja salto a salto hacia el enrutador de primer salto, creando otra

rama del SPT. Esta acción también crea un estado (S, G) en todos los enrutadores a lo largo

de esta rama del SPT.

Como se puede ver en la Figura, el tráfico (S, G) ahora fluye directamente de la fuente al

receptor a través del SPT.

526

Se envía un mensaje especial (S, G) RP-bit prune al árbol compartido para podar el tráfico

(S, G) del árbol compartido. Después de que el mensaje (S, G) RP-bit prune ha alcanzado el

RP, la rama del SPT desde la fuente hasta el RP todavía existe. Sin embargo, cuando el RP

ha recibido el mensaje de poda de bits RP (S, G) a través de todas las ramas del árbol

compartido, el RP ya no necesita tráfico (S, G). Este resultado se produce porque todos los

receptores de la red están recibiendo el tráfico a través de un SPT, pasando por alto el RP.

El RP ya no necesita el tráfico (S, G). Por lo tanto, enviará los mensajes de poda (S, G) hacia

la fuente para apagar el flujo de tráfico ahora innecesario (S, G)

527

Cuando el mensaje de poda (S, G) alcanza el enrutador de primer salto, elimina la rama de

(S, G). Esta poda destruirá el SPT que fue construido entre la fuente y el RP. El tráfico

ahora sólo fluye por la rama restante del (S, G) -el SPT construido entre el enrutador

fuente y el último-salto que inició la conmutación

528

TABLA DE ENRUTAMIENTO DE MULTIDIFUSIÓN

La Figura muestra una tabla de enrutamiento de multidifusión donde están presentes dos

tipos de rutas: (*, G) y (S, G).

La interfaz entrante (IIF) es comprobada por RPF para los paquetes multicast entrantes. El

OIL es una lista de interfaces donde se enviará el paquete de multidifusión.

Las reglas de estado PIM-SM (*, G) son las siguientes:

La entrada (*, G) se crea cuando se recibe una combinación (*, G) o un informe

IGMP. Esta última condición puede simularse configurando manualmente la

interfaz del enrutador para unirse al grupo.

Las entradas (*, G) también se crean automáticamente cuando se debe crear una

entrada (S, G) para el grupo. La entrada (*, G) se crea primero; Entonces se crea la

entrada (S, G).

El IIF refleja la interfaz RPF y el vecino en la dirección del RP.

El OIL de una entrada PIM-SM (*, G) refleja las interfaces con uno de estos

atributos:

o Han recibido una combinación (*, G).

o Están directamente conectados a un miembro que se ha unido al grupo.

o Se han configurado manualmente para unirse al grupo.

Las entradas (*, G) se eliminan cuando el contador de tiempo de expiración cuenta

a 0. Esta acción se produce cuando sólo existe una de estas condiciones:

o El OIL es nulo.

o No existe entrada de niño (S, G).

Las reglas de estado PIM-SM (S, G) son las siguientes:

Creación (S, G):

529

o La recepción de un mensaje (S, G) de unirse o podar.

o La recepción por el enrutador de primer salto de un paquete desde una

fuente conectada directamente. Esta acción activará el proceso de registro

PIM-SM.

o Cuando se crea un padre (*, G), si no existe.

(S, G) refleja el reenvío de S a G:

o IIF es la interfaz RPF hacia la fuente. La excepción a esta regla se produce

cuando el bit RP (indicador R) se establece en la entrada (S, G) y la interfaz

RPF apunta hacia arriba el árbol compartido. Esta acción se produce

después de la conmutación SPT y el enrutador recibe el mensaje de poda de

RP-bit para podar el tráfico (S, G) del árbol compartido. Este mecanismo

permite que el tráfico duplicado (S, G) se bloquee para que fluya por el árbol

compartido después de que un enrutador descendente haya cambiado al

SPT.

o El OIL de la entrada (S, G) se rellena con una copia del OIL de la entrada

principal (*, G), sin el IIF. El IIF no debe aparecer en el OIL; De lo contrario,

puede producirse un bucle de ruta de multidifusión.

(S, G) supresión:

o En PIM-SM, las entradas (S, G) se eliminan cuando su temporizador de

expiración cuenta a 0. El temporizador de caducidad se restablece cada vez

que se recibe y envía un paquete (S, G).

CONCEPTOS BÁSICOS DE SSM

La multidifusión de origen específico (SSM) es una variante de un PIM-SM básico. SSM

utiliza todos los beneficios de los protocolos de modo disperso, pero elimina los RP y los

árboles compartidos y sólo crea un SPT. Los árboles SSM se construyen directamente

basándose en la recepción de informes de membresía de grupo que solicitan una fuente

determinada. SSM se describe en RFC 3569.

SSM es adecuado para su uso cuando existen fuentes bien conocidas dentro del dominio

PIM local o dentro de otro dominio PIM. Ya no se necesita el protocolo de detección de

origen de multidifusión (MSDP), que se necesita para el enrutamiento de multidifusión

entre dominios cuando se utiliza un PIM-SM normal en un dominio. MSDP es un protocolo

de enrutamiento multicast que se utiliza para interconectar múltiples dominios PIM-SM,

así como para proporcionar Anycast RP dentro de un dominio PIM-SM. Un intervalo de

direcciones de grupo de multidifusión dedicado de 232.0.0.0/8 se utiliza exclusivamente

para SPTs en SSM. A los enrutadores se les impide crear un árbol compartido para

cualquiera de los grupos de este rango de direcciones. El rango de direcciones 232.0.0.0/8

está asignado para fuentes globales bien conocidas. SSM es un modelo de entrega de

530

datagramas que soporta mejor las aplicaciones uno-a-muchos, también conocidas como

aplicaciones de difusión. Ejemplos de aplicaciones en las que SSM tiene sentido incluyen

emisiones de vídeo, emisiones de audio y datos de mercado de valores.

Las siguientes son algunas de las características conocidas de SSM:

Permite que el enrutador de último salto envíe una combinación (S, G)

directamente a la fuente sin crear un árbol compartido

Permite que el enrutador de primer salto responda a solicitudes de combinación

iniciadas por el receptor para fuentes específicas dentro de un grupo

Utiliza IGMPv3 (IPv4) y MLDv2 (IPv6) para señalar exactamente a qué (S, G) SPT

debe unirse

Soporta la eliminación del estado de árbol compartido en el rango 232.0.0.0/8,

simplificando la asignación de direcciones

Como se puede ver en la Figura, SSM permite que el enrutador de último salto envíe

inmediatamente una unión (S, G) hacia la fuente. Por lo tanto, la unión PIM-SM (*, G) hacia

el RP se elimina, y los enrutadores de primer salto comienzan a reenviar el tráfico de

multidifusión en el SPT desde el principio. El SPT se construye recibiendo la primera

unión (S, G). El rango de direcciones asignado de 232.0.0.0/8 también simplifica los

problemas de asignación de direcciones porque es un rango global para fuentes que deben

ser bien conocidas. Las implementaciones en enrutadores no deben crear ningún árbol

compartido para esos grupos.

531

Es importante señalar que los grupos específicos de la fuente pueden coexistir con otros

grupos en los dominios PIMSM.

Escenario SSM

El requisito previo para la implementación de SSM es un mecanismo que permite a los

hosts informar no sólo al grupo al que desean unirse, sino también al origen del grupo.

Este mecanismo está integrado en la norma IGMPv3. Con IGMPv3, los enrutadores de

último salto pueden recibir informes de membresía IGMP que solicitan una fuente de

multidifusión específica y un flujo de tráfico de grupo. El enrutador responde simplemente

creando un estado (S, G) y activando una unión (S, G) hacia la fuente.

Exactamente cómo un host aprende sobre la existencia de fuentes puede ocurrir a través

del servicio de directorio, anuncios de sesión directamente de fuentes, o algunos

mecanismos fuera de banda (por ejemplo, páginas web). Un mecanismo fuera de banda se

ilustra en la Figura.

El resultado de construir un SPT desde el principio es que todos los mecanismos PIM-SM

que están asociados con un RP son eliminados. Los RPs para grupos SSM no son

necesarios porque el descubrimiento de fuentes se realiza a través de algún otro método.

De hecho, los enrutadores no deben crear árboles compartidos para grupos del rango SSM

(232.0.0.0/8).

Hay varios beneficios de construir inmediatamente SPTs a una fuente bien conocida sin la

necesidad de primero construir un árbol compartido. Uno de los principales beneficios se

refiere a la gestión de direcciones. Tradicionalmente, era necesario adquirir una dirección

532

de grupo de multidifusión IP única para garantizar que un origen de contenido no entraría

en conflicto con otras fuentes posibles que enviarían en el árbol compartido.

En SSM, ya no es necesaria una dirección de grupo de multidifusión IP única. El tráfico de

cada fuente se envía únicamente utilizando un SPT. Por lo tanto, diferentes fuentes pueden

utilizar las mismas direcciones de grupo de multidifusión SSM sin preocuparse por la

mezcla de flujos de tráfico.

PIM BIDIRECCIONAL

PIM-SM es unidireccional en su forma nativa. El tráfico de fuentes al RP fluye inicialmente

encapsulado en mensajes de registro. Esta actividad presenta una carga significativa

debido a los mecanismos de encapsulación y desencapsulación. Además, se crea un SPT

entre el RP y la fuente, lo que da como resultado entradas (S, G) que se crean entre el RP y

la fuente.

El PIM bidireccional (BIDIR-PIM) es una variante de un modelo PIM-SM básico. Varias

aplicaciones de multidifusión utilizan un modelo multidifusión muchos a muchos en el que

cada participante es un receptor, así como un remitente. Las entradas (*, G) y (S, G)

aparecen en los puntos a lo largo del camino de los participantes y el RP asociado. Las

entradas adicionales en la tabla de enrutamiento de multidifusión aumentan la memoria y

la utilización de la CPU. Un aumento de la sobrecarga puede convertirse en un problema

significativo en las redes donde el número de participantes en el grupo de multidifusión

crece bastante.

Un sólido ejemplo de una aplicación que se aprovecha de BIDIR-PIM es una aplicación de

comercio de acciones en la que miles de comerciantes del mercado de valores realizan

operaciones a través de un grupo de multidifusión. BIDIR-PIM elimina el proceso de

registro/encapsulación y el estado (S, G). Los paquetes se envían nativamente de una

fuente a la RP usando el estado (*, G) solamente. Esta capacidad garantiza que sólo las

entradas (*, G) aparezcan en las tablas de reenvío de multidifusión. BIDIRPIM se ilustra en

la Figura.

533

Modificaciones PIM para la operación bidireccional

En BIDIR-PIM, las reglas de reenvío de paquetes se han mejorado con PIM-SM,

permitiendo que el tráfico se pase por el árbol compartido hacia el RP. Para evitar un

paquete de multidifusión que está en bucle, BIDIR-PIM introduce un nuevo mecanismo

denominado reenviador designado (DF), que establece un SPT sin bucles con raíz en el RP.

El DF asume el papel de un enrutador designado y tiene las siguientes responsabilidades:

Es el único enrutador que envía los paquetes que viajan hacia abajo (hacia los

segmentos del receptor) hacia el enlace.

Es el único enrutador que recoge paquetes de viaje ascendente (lejos de la fuente)

del enlace y los reenvía hacia el RP.

El uso de este método asegura que sólo una copia de cada paquete será enviada a la RP,

incluso si hay rutas paralelas de costo igual al RP.

En cada enlace de la red, los enrutadores BIDIR-PIM participan en un procedimiento

llamado elección DF. El procedimiento selecciona un enrutador como el DF para cada RP

de grupos bidireccionales. El enrutador con la mejor ruta de unidifusión a la RP es elegido

como un DF. Un proceso de desempate de la elección también ocurre si hay caminos

paralelos de costo igual al RP. Si el DF elegido falla, se detecta a través del mecanismo de

PIM hello normal, y se iniciará un nuevo proceso de elección de DF.

Se selecciona un DF para cada RP de grupos bidireccionales. Como resultado, se pueden

elegir varios enrutadores como DF en cualquier segmento de red, uno para cada RP.

534

Además, cualquier enrutador en particular puede ser elegido como DF en más de una

interfaz.

Elección del DF

Las redes de acceso múltiple pueden tener rutas paralelas, lo que puede llevar a que los

miembros del grupo reciban paquetes duplicados de varios enrutadores. Para evitar este

problema, PIM utiliza mensajes afirmativos para elegir un solo reenviador PIM para el

tráfico. Este proceso se ilustra en la Figura.

El proceso BIDIR-PIM de elegir un DF en cada enlace es similar al proceso PIM Assert.

El mecanismo BIDIR-PIM DF garantiza que todos los enrutadores del enlace tengan una

vista consistente del mismo RP. Para realizar la elección del DF para un RP determinado,

los enrutadores en un enlace necesitan intercambiar su información de métrica de

enrutamiento unicast para alcanzar el RP. La elección de un DF depende del RP, no de un

grupo individual.

La elección de DF se basa en métricas de enrutamiento unicast y utiliza las mismas reglas

de desempate que se emplean en los procesos de aserción de PIM. El enrutador con la

métrica de enrutamiento unicast más preferida para el RP se convierte en el DF.

El proceso electoral ocurre sólo una vez y ocurre cuando la información sobre un nuevo

RP está disponible. Sin embargo, una actualización de la elección es necesaria bajo las

siguientes condiciones:

Se produce un cambio en la métrica de unidifusión para llegar al RP para

cualquiera de los enrutadores del enlace.

La interfaz en la que se puede acceder al RP cambia a una interfaz para la que el

enrutador era previamente el DF.

535

Se establece un nuevo vecino PIM en un enlace.

El DF elegido muere.

Mensajes de elección de DF

El mecanismo de elección del DF se basa en cuatro mensajes de control que se

intercambian entre los enrutadores en el enlace:

Mensaje de oferta: este mensaje se utiliza para anunciar una métrica unicast de

enrutador para llegar al RP. Los otros enrutadores que participan en la elección de

un DF comparan la métrica con su métrica para alcanzar el RP.

Mensaje ganador: este mensaje permite al enrutador ganador anunciar a todos los

enrutadores del enlace que ha ganado el proceso electoral de DF. El DF también

envía este mensaje para reafirmar su estado como DF elegido.

Mensaje de retroceso: Este mensaje es enviado por el DF actualmente elegido

cuando recibe un mensaje de oferta que contiene una métrica mejor para el RP que

la suya propia. El DF registra la información recibida y responde con un mensaje de

retroceso. El mensaje de retroceso, por lo tanto, se utiliza para reconocer que el

remitente (el DF activo) tiene una métrica peor a la RP que el enrutador de oferta.

Cuando el enrutador de oferta recibe el mensaje de retroceso, asumirá los deberes

como el recién elegido DF. El recién elegido DF enviará un mensaje de ganador

después de un corto tiempo, mientras que permite unicast encaminamiento para

estabilizar.

Mensaje de paso: Este mensaje es utilizado por el DF actuante para pasar su

función a otro enrutador que ofrece una métrica mejor. El viejo DF detiene sus

tareas cuando se realiza la transmisión.

536

Capítulo 21

Soluciones a la

Distribución de Puntos

de Encuentro (RP)

537

DESCUBRIMIENTO DE PUNTOS DE ENCUENTRO

Los puntos de encuentro manuales, a veces referidos como configuración de información

RP estática, aunque es relativamente fácil de implementar en algunos dispositivos dentro

de la infraestructura, no escala a grandes entornos. Con una implementación RP estática,

la dirección del RP debe ser configurado en cada enrutador del dominio. Si la red no tiene

muchos RPs diferentes definidos y/o no cambian muy a menudo, este podría ser el

método más simple para definir RP.

Hay, sin embargo, varios problemas asociados con la configuración RP estática, incluyendo

lo siguiente:

La configuración inicial de muchos enrutadores es engorrosa (si existe una

herramienta de configuración y aprovisionamiento de red, la configuración del RP

estático en muchos dispositivos no debería ser un problema importante).

Cualquier cambio en la configuración estática tiene un impacto negativo en el

esfuerzo de mantenimiento, que a largo plazo resulta aún más problemático que el

suministro inicial. Aunque las herramientas de aprovisionamiento y configuración

ayudan a simplificar la parte de la configuración y el aprovisionamiento, cualquier

cambio de configuración en un entorno de producción normalmente requiere una

ventana de cambio y puede no ser tan rápida y sencilla como se requiera.

La configuración de la información de RP estática no admite muchos escenarios en

que se aprovechan los RP redundantes, en los que se cambia la capacidad de

alcance de la red (excluyendo los escenarios en los que se define el RP con un

protocolo de redundancia como Anycast-MSDP).

538

Además del método manual de configuración de información RP, se han desarrollado dos

mecanismos de descubrimiento RP dinámico para mejorar la escalabilidad en entornos

grandes:

Auto-RP: Un método diseñado por Cisco

Router Bootstrap (BSR): Un mecanismo basado en estándares

No importa qué mecanismo se utiliza, como diseñador, debe asegurarse de que todos los

enrutadores tengan una vista coherente. En otras palabras, el mismo rango de grupos de

multidifusión tiene que ser asignado al mismo RP.

Debe configurarse

en cada enrutador

Admite direcciones

IPv4

Admite direcciones

IPv6

Redundancia RP

RP estático BSR Auto-RP

Sí

No (excepto en los No (excepto en

candidatos BSR y en los candidatos RP y

candidatos RP) agentes de mapeo)

Sí Sí Sí

Sí Sí No

No (a menos que

se utilice con

Anycast RP)

Sí

Sí

Ubicación de encuentro

La decisión sobre qué distribución de información RP utilizar no está directamente

relacionada con la cuestión de qué enrutadores deben ser declarados como RP o

candidatos RP.

RP puede estar en casi cualquier lugar. Teóricamente, ni siquiera necesitan estar en el

camino de las fuentes al receptor. En los enrutadores Cisco, el umbral predeterminado del

Árbol de ruta más corta (SPT) se establece en 0. Esto significa que los árboles de

distribución cambian inmediatamente a SPT y el tráfico en sí no fluye a través del RP.

539

Para otros valores del umbral SPT, especialmente el infinito, se recomienda una colocación

más cercana a la fuente porque el RP puede convertirse en un punto de congestión.

Auto-RP

Auto-RP permite a todos los enrutadores de la red aprender automáticamente las

asignaciones de grupo-a-RP. No se deben tomar medidas de configuración especiales,

excepto en los enrutadores que deben funcionar como:

Candidatos RP.

Agentes de mapeo.

La multidifusión se utiliza para distribuir la información de mapeo de grupo-a-RP a través

de dos grupos de extensiones especiales asignados con las direcciones de la Autoridad de

Números Asignados de Internet (IANA):

Grupo de anuncio de Cisco: 224.0.1.39

Grupo de descubrimiento de Cisco: 224.0.1.40

Teniendo en cuenta que la difusión múltiple se utiliza para distribuir esta información,

una situación de lo que ocurra primero puede suceder si los grupos 224.0.1.39 y

224.0.1.40 operan en sparse mode. Los enrutadores tendrían que conocer la dirección RP

antes de que puedan aprender la dirección de los RP a través de mensajes Auto-RP. Por lo

540

tanto, se recomienda que estos grupos se ejecuten en modo PIM Denso (PIM-DM) para que

esta información se inunde en toda la red.

Pueden definirse múltiples candidatos RP para que en el caso de un fallo RP, el otro

candidato RP pueda asumir la responsabilidad del RP.

Auto-RP puede configurarse para soportar zonas de alcance administrativo. Las zonas de

alcance administrativo pueden ser importantes cuando intenta evitar que el tráfico de

grupo de alta velocidad salga de un campus y consuma demasiado ancho de banda en los

enlaces WAN.

Candidatos RP de Auto-RP

De forma predeterminada, los mensajes que anuncia el enrutador RP se envían cada 60

segundos.

Los mensajes de anuncio RP contienen

El rango de direcciones de grupo (el valor predeterminado es la dirección de todos

los grupos de multidifusión, o 224.0.0.0/4).

La dirección IP del candidato RP.

Un tiempo de retención, que se utiliza para detectar cuando el candidato RP ha

fallado. Este tiempo de espera es tres veces el intervalo de anuncio; por lo tanto, el

valor predeterminado es 180 segundos.

Agentes de mapeo de Auto-RP

541

Un agente de mapeo Auto-RP se une al grupo de anuncios RP (224.0.1.39) para recibir

avisos RP de un candidato RP. Cuando un agente de asignación recibe un anuncio, realiza

lo siguiente:

1. Guarda el anuncio en la caché de asignación de grupo a RP

2. Selecciona el candidato RP con la dirección IP más alta como RP para el rango de

grupo

Los tiempos de espera se utilizan para expirar una entrada en la caché. Esta técnica se

convierte en útil si un candidato RP falla y ya no envía anuncios periódicos de candidato

RP. A través de mensajes de detección de RP, el agente de mapeo envía periódicamente

información sobre los RP elegidos desde su caché de asignación de grupo a RP a todos los

enrutadores de la red. Los ensayos de descubrimiento de RP son de multidifusión al grupo

de descubrimiento de Auto-RP (224.0.1.40). Se envían cada 60 segundos o cuando ocurre

un cambio en la información de la caché de grupo a mapeado.

Auto-RP y otros enrutadores

Los enrutadores Cisco se unen automáticamente al grupo de descubrimiento de Cisco

(224.0.1.40) para recibir la información de mapeo de grupo a RP que está siendo

multidifusión por el agente de asignación en la red. No se requiere ninguna configuración

para unirse a este grupo. La información de mapeo de grupo a RP que se contiene en los

mensajes de detección de RP se almacena en la caché de asignación de grupo a RP local del

enrutador. El enrutador utiliza esta información para asignar una dirección de grupo a la

dirección IP del RP activo para el grupo.

Problema de alcance de Auto-RP

Se debe tener cuidado en la selección del alcance TTL de los mensajes de anuncios RP. Los

mensajes de anuncio de RP deben llegar a todos los agentes de mapeo necesarios.

También se debe tener cuidado en la selección del alcance TTL de los mensajes de

descubrimiento de RP. Los mensajes de descubrimiento de RP deben llegar a todos los

enrutadores PIM-SM de la red. La Figura resalta un problema RP-RP de ámbito Auto-RP en

el que se utilizó un alcance arbitrario de 16 en el enrutador RP candidato. Sin embargo, el

diámetro máximo de la estructura es mayor que 16 saltos y, en este caso, un agente de

mapeo (enrutador B) está a más de 16 saltos.

542

Como resultado, este agente de mapeo no recibe los mensajes de anuncio RP del candidato

RP. Este lapso puede hacer que los dos agentes de mapeo tengan información diferente en

sus cachés de mapeo de grupo a RP. Si se produce este evento, cada agente de mapeo

anunciará un enrutador diferente como RP para un grupo, lo que tendrá resultados

desastrosos.

Además, el candidato RP está a menos de 16 saltos del borde de la red. Esta disposición

puede hacer que los mensajes de anuncio de RP se filtren en redes adyacentes y

produzcan problemas de Auto-RP en esas redes.

La Figura destaca un problema de alcance de agente de mapeo en Auto-RP. Se utilizó un

alcance arbitrario de 16 en el agente de mapeo, sin embargo, el diámetro máximo de la red

es mayor que 16 saltos, y en este caso, al menos un enrutador (enrutador D) está más lejos

que 16 saltos.

543

Como resultado, este enrutador no recibe los mensajes de detección de RP del agente de

mapeo. Este lapso puede resultar en que el enrutador no tenga información de mapeo de

grupo a RP. Si se produce este evento, el enrutador intentará operar en modo denso para

todos los grupos de multidifusión mientras que otros enrutadores de la red funcionan en

modo escaso.

Además, el agente de mapeo está a menos de 16 saltos del borde de la red. Esta

disposición puede hacer que los mensajes de detección de RP se filtren en redes

adyacentes y produzcan problemas de Auto-RP en esas redes.

PIMv2 BSR

El BSR es un mecanismo de normas IETF disponible en PIMv2; es una norma basada en

una alternativa a Auto-RP. Con BSR, se elige un único enrutador como BSR de una

colección de candidatos BSRs. Si el BSR actual falla, se desencadena una nueva elección. El

mecanismo de elección es preemptivo basado en la prioridad del candidato BSR.

Los candidatos RP envían anuncios de candidato-RP directamente al BSR. Los candidatos

RP aprenden la dirección IP de la BSR a través de mensajes periódicos BSR. El BSR no elige

el mejor RP para cada rango de grupo que aprende, sino más bien para cada rango de

grupo conocido, el BSR construye un conjunto de candidatos RP, incluyendo todos los

enrutad que anunciaron su voluntad de servir como RP para el grupo. El BSR almacena la

colección de anuncios de candidato-RP en una base de datos referida como el conjunto RP.

El BSR envía mensajes de BSR periódicamente a los enrutadores en la red para hacerles

saber que el BSR sigue vivo. Los mensajes BSR se inundan salto por salto a lo largo de la

red como multicasts al grupo todos-los-enrutadores-PIM (224.0.0.13) con una TTL de 1.

Cuando un enrutador recibe un mensaje BSR, aplica una comprobación de reenvío de ruta

inversa (RPF) que se basa en la dirección IP de origen en el paquete. Si la comprobación

RPF tiene éxito, el mensaje se inunda a todas las interfaces habilitadas para PIM.

Los mensajes BSR contienen los siguientes elementos:

El conjunto RP, que consiste en anuncios de candidato-RP

La dirección IP de la BSR, para que los candidatos RP sepan a dónde enviar sus

anuncios

Como resultado de los paquetes que se inundan a lo largo de la red, los enrutadores

recibirán los mensajes BSR. Cada enrutador receptor selecciona el RP activo para cada

rango de grupo usando un algoritmo hash que se ejecuta contra el conjunto RP. Los

enrutadores de la red seleccionarán el mismo RP para un rango de grupo dado.

Contrariamente al método Auto-RP, el alcance no se puede utilizar para BSR porque no se

consideró el alcance cuando se diseñó BSR. Los anuncios de Candidato-RP que son unicast

a la BSR pueden cruzar los límites de la multidifusión.

544

Candidatos RP de PIMv2 BSR

Los candidatos RP envían periódicamente mensajes de candidato-RP directamente al BSR

vía unicast. Ellos saben la dirección BSR porque los mensajes BSR han sido inundados

periódicamente al grupo de todos los enrutadores PIM: 224.0.0.13. El intervalo

predeterminado para los mensajes de candidato-RP es de 60 segundos. Los mensajes de

anuncio del candidato-RP contienen el rango del grupo, la dirección cid-RP y un tiempo de

retención.

PIMv2 BSR: Router Bootstrap

El objetivo principal de la BSR es recoger los anuncios de candidato-RP. Estos anuncios se

almacenan en una base de datos que se denomina conjunto RP. Los anuncios de candidato-

RP son inundados periódicamente hacia fuera a los otros enrutadores en la red usando los

mensajes de BSR. Cuando el BSR recibe mensajes de candidato-RP, estos mensajes son

aceptados y almacenados. El BSR anuncia mensajes BSR a todos los enrutadores PIM

(224.0.0.13) con una TTL de 1 cada 60 segundos, o cuando se detectan cambios. Cualquier

enrutador nuevo con una prioridad BSR superior fuerza la nueva elección.

PIMv2 BSR: Todos los routers PIMv2

Los enrutadores PIMv2 que no son BSRs o candidatos RP tienen un papel importante en el

proceso PIMv2 BSR. Los enrutadores PIMv2 funcionan de la siguiente manera:

Acepta los mensajes BSR basados en las reglas descritas anteriormente. Cuando se

acepta un mensaje BSR:

545

o El RP establecido en el mensaje BSR se almacena en la caché de asignación

de grupo a RP local.

o El mensaje BSR se reenvía a las otras interfaces, excepto de la que se recibió.

Selecciona un RP usando un algoritmo hash:

o El RP para un grupo se selecciona del conjunto de candidatos RP que

anunciaron su candidatura para un rango de grupo coincidente.

o Los enrutadores usan el mismo algoritmo hash para seleccionar el RP del

conjunto de candidatos RP en el conjunto RP. Debido a que los enrutadores

ejecutan el mismo algoritmo en el mismo conjunto de RP, seleccionarán el

mismo RP para un grupo dado.

o El algoritmo hash permite que varios candidatos RP puedan equilibrar la

carga de los deberes del RP a través de un rango de grupos. Sólo se

seleccionará un candidato RP como RP para cualquier grupo del rango del

grupo. Sin embargo, el algoritmo hash puede seleccionar otros RP

candidatos como RP para otro grupo dentro del rango del grupo.

Problema con las inundaciones de BSR

Los mensajes BSR dirigidos al grupo de multidifusión 224.0.0.13 se propagan de una

manera salto por salto a través de toda la red PIMv2

Los enrutadores de hoja reciben el paquete, llenan la memoria caché local y lo reenvían a

través de todas las demás interfaces PIMv2. El problema surge en las fronteras de dominio

que no deben perder la información acerca del RP de empresa. La filtración de esta

información puede afectar el rendimiento de la red porque se pueden seleccionar RPs de

dominio externo para los árboles de distribución de multidifusión.

Punto de encuentro incorporado para IPv6

546

El RP incorporado para IPv6 definido en el RFC 3956 es una característica de

multidifusión IPv6, lo que implica el proceso de gestión de mapeo entre grupos de

multidifusión y RPs. RP incorporado para IPv6 es un mecanismo que elimina la necesidad

de configuración estática de RPs IPv6 en los DRs de multidifusión. La dirección IP de IPv6

para un grupo de multidifusión dado está codificada dentro del grupo de multidifusión

IPv6

El RP incorporado para IPv6 tiene los siguientes atributos:

16 direcciones RP por prefijo de red

232 grupos de multidifusión por RP

Se garantiza que es único debido a la red asignada a la empresa / 64 que se utiliza

en la dirección

RP incorporado para IPv6 es ideal como un reemplazo para la RP estática. No se requiere

una configuración manual de direcciones RP porque la dirección está incrustada dentro de

un grupo de multidifusión. Sin embargo, si la dirección RP necesita cambiar, la dirección

multicast necesita cambiar, lo que requiere informar a todas las aplicaciones interesadas.

Los enrutadores que no admiten RP incorporado para IPv6 pueden configurarse

estáticamente o utilizar otros métodos como BSR.

Los siguientes puntos claves resumen el uso de RP incorporado con IPv6:

RP incorporado con IPv6 puede ser considerado un reemplazo automático a la

configuración IP RP estática.

Los enrutadores que no admiten RPs incorporados para IPv6 pueden configurarse

estáticamente o mediante BSR.

El RP incorporado para IPv6 no proporciona redundancia RP IPv6 como BSR o

Anycast RP.

Los enrutadores que sirven como RPs incorporados para IPv6 deben configurarse para

este grupo de multidifusión específico. Este proceso proporciona un mecanismo de

salvaguardia que prohíbe la selección deficiente de RP. Cuando especifique exactamente

qué grupos de multidifusión para los que se ejecutará un tráfico RP, es menos probable

que una dirección de grupo de alta velocidad se obtenga de un RP de bajo rendimiento. Sin

esta salvaguardia, puede seleccionar RP simplemente especificando la dirección de

547

multidifusión IPv6 con una dirección RP incorporada con IPv6, sin consultar al equipo de

red. Esto puede dar lugar a la posibilidad de que una dirección RP incorporada para IPv6

podría especificar un RP IPv6 que no podría procesar el tráfico de multidifusión.

CARACTERÍSTICAS DE ANYCAST RP

Anycast RP trabaja con el Protocolo de Descubrimiento de Origen de Multicast (MSDP)

para proporcionar redundancia RP, RP failover rápido y balanceo de carga RP. Anycast RP

se define en RFC 3446. MSDP es un mecanismo para conectar múltiples RP.

El mecanismo Anycast RP funciona de la siguiente manera:

Dos o más enrutadores se configuran como RP activo para el mismo rango de grupo

al mismo tiempo. Normalmente, esto es un error de configuración que particionaría

el dominio PIM-SM. Sin embargo, MSDP se utiliza para evitar que esto suceda.

A cada RP se le asigna la misma dirección RP. Esto se logra usualmente usando una

interfaz loopback y un espacio de direcciones privadas. Cada enrutador anuncia su

dirección RP como una ruta de host en el protocolo de enrutamiento unidifusión.

Fuentes y receptores usan el RP más cercano, basado en su tabla de enrutamiento

unicast.

Los RP de Anycast también establecen relaciones de peering MSDP entre sí. Esto

permite que cada RP conozca qué fuentes se han registrado con los otros RP de

Anycast en el dominio.

El comportamiento RP PIM-SM normal hace que el RP se una al árbol fuente de las

fuentes activas en las otras partes de la red según sea necesario.

Anycast RP tiene los siguientes beneficios:

Respaldo del RP sin utilizar Auto-RP o BSR

RP failover a la velocidad del protocolo de enrutamiento unicast

Anycast RP tiene los siguientes requisitos de características:

Utiliza sólo una dirección IP para todos los RP.

Los RP anuncian la única dirección IP como una ruta de host.

MSDP se utiliza entre los routers RP.

EJEMPLO DE ANYCAST RP

548

En la Figura, dos RP de Anycast, RP1 y RP2, están configurados con la misma dirección IP

(10.1.1.1). También establecen peering de MSDP entre ellos. Para establecer el peering de

MSDP, estos RP deben utilizar otra dirección diferente a 10.1.1.1.

Inicialmente, los DR (no mostrados en el diagrama) para las fuentes y receptores se

registran en el RP más cercano en base a su entrada de tabla de enrutamiento unicast para

la dirección IP 10.1.1.1. Esta acción hace que los DR en la parte izquierda de la red

registren o se unan a RP1 mientras que los DR en la parte derecha se registran o se unen a

RP2. Cuando una nueva fuente se registra con la RP más cercana, esa RP enviará un

mensaje SA de MSDP a su compañero. Esto hará que el par RP una al SPT a la nueva fuente.

Entonces el par RP puede tirar del tráfico fuente a sí mismo y enviarlo por el árbol

compartido a sus receptores.

La Figura ilustra lo que sucede cuando el RP1 disminuye.

Cuando se vuelve a reconvertir el protocolo de enrutamiento unicast, todos los DR en la

parte izquierda de la red pueden ver la ruta a 10.1.1.1 apuntando hacia RP2. Los DR en la

parte izquierda de la red envían nuevos registros y se unen a RP2, restableciendo el flujo

de tráfico.

549

VISIÓN GENERAL DEL PROTOCOLO MSDP

MSDP es un mecanismo que conecta múltiples dominios PIM-SM. MSDP permite que las

fuentes de multidifusión para un grupo sean conocidas por todos los RP en diferentes

dominios. Cada dominio PIM-SM utiliza sus propios RP y no tiene que depender de RP en

otros dominios. Un RP ejecuta MSDP sobre TCP para descubrir fuentes de multidifusión en

otros dominios. Sólo se construyen los SPT entre dominios.

Las siguientes son algunas de las principales características del protocolo MSDP:

Usa árboles fuente interdominios.

Reduce el problema de localizar fuentes activas.

Permite que RP o el receptor de último salto se unan al árbol de fuentes

interdominio.

Los RP conocen todas las fuentes en un dominio:

o Las fuentes causan un registro PIM al RP

o Pueden contarles a los RP en otros dominios de sus fuentes aprovechando

los mensajes MSDS SA.

Los RP saben acerca de los receptores en un dominio:

o A través de conexiones normales PIM (S, G)

o Necesario sólo si hay receptores para el grupo

Anycast RP es una aplicación útil de MSDP. Con Anycast RP, una fuente puede registrarse

con un RP, y los receptores pueden unirse a un RP diferente. Este método es necesario

para que los RP intercambien información sobre las fuentes activas. Todo el intercambio

de información se realiza con MSDP.

Relación de vecino MSDP

Al igual que BGP, MSDP establece relaciones de vecinos con otros pares de MSDP

utilizando una sesión TCP al puerto 639. Los pares de MSDP envían mensajes keepalive

cada 60 segundos durante un período fijo. La llegada de los datos realiza la misma función

que los mensajes keepalive en términos de mantener la sesión en funcionamiento. Si no se

reciben mensajes ni datos de mantenimiento durante 75 segundos, la conexión TCP se

restablece y se vuelve a abrir. Los pares de MSDP deben intercambiar información de

enrutamiento usando BGP. BGP se utiliza para realizar una comprobación RPF de

mensajes SA que llegan y puede utilizar la base de información de enrutamiento de

multidifusión (MRIB), la base de información de enrutamiento Unicast (URIB) o ambos.

Excepciones a esta recomendación son cuando se hace peering con un solo par de MSDP o

cuando se utiliza un grupo de malla MSDP.

550

Capítulo 22

Diseño de los Servicios

de Seguridad y la

Protección a la

Infraestructura

551

ZONIFICACIÓN DE SEGURIDAD DE RED

Para restringir el acceso entre diferentes partes de la red, se utiliza el concepto de

zonificación. La zonificación mitiga el riesgo de tener una red plana sin restricciones de

acceso entre diferentes segmentos. Para ello, se segmentan los servicios de infraestructura

en agrupaciones lógicas que tienen las mismas políticas y requisitos de seguridad de

comunicaciones. Es un enfoque de diseño que restringe la comunicación únicamente a los

flujos definidos por la política de seguridad.

Las zonas están separadas por puntos de interfaz de zona. Un punto de interfaz de zona

proporciona una interfaz de red entre una zona y otra. El punto de interfaz de zona se

implementa con dispositivos de seguridad de red. Puede crear cada punto de interfaz de

zona utilizando un único componente o una combinación de componentes.

Existen muchos tipos de zonas en la red. Las zonas más típicas son las siguientes:

Zona pública: la zona externa no está bajo control de la organización. Los servicios

públicos están ubicados en esta zona.

Zona de acceso público: Una zona que alberga los servicios públicos de la

organización y que a menudo se denomina zona desmilitarizada (DMZ). Se pueden

acceder a estos servicios desde la zona pública. Los servicios típicos incluyen proxy

de correo electrónico, proxy web, proxy inverso y servicios de acceso remoto.

Zona restringida: Zona interna que aloja los servicios de datos más importantes

para la organización. Normalmente, esta zona es la zona más segura, y el acceso a

esta zona debe ser limitado.

552

Para limitar el acceso entre diferentes zonas, los dispositivos de seguridad de red utilizan

el concepto de filtrado. El tráfico que no se permite fluir de una zona a otra se filtra en los

puntos de interfaz de zona. La política de seguridad controla el tráfico que se permite. En

las redes modernas de hoy en día, este filtrado puede variar dependiendo de varias

variables, tales como la criticidad de las aplicaciones, las zonas y los estándares de la

política de seguridad de la empresa. Por ejemplo, el filtrado de paquetes básico puede

basarse en la fuente y el destino IP/puerto o el filtrado avanzado con la inspección

profunda de paquetes.

ARQUITECTURA MODULAR DE RED DE CISCO

La arquitectura modular de red de Cisco proporciona una defensa en profundidad al

posicionar los productos y capacidades de Cisco a través de la red y mediante el uso de

capacidades colaborativas entre las plataformas. Una amplia gama de tecnologías de

seguridad se despliega en múltiples capas. Los productos y las capacidades se posicionan

donde ofrecen el mayor valor, al tiempo que facilitan la colaboración y la operación.

La arquitectura de red modular de Cisco sigue estos principios:

Defensa en profundidad: la seguridad está integrada en toda la red siguiendo un

enfoque de defensa en profundidad. Para una mayor visibilidad y control, un rico

conjunto de tecnologías y capacidades de seguridad se despliega en múltiples

capas, bajo una estrategia común y un control administrativo.

Modularidad y flexibilidad: todos los componentes se describen por funciones. La

infraestructura de red general se divide en módulos funcionales, como el campus y

el centro de datos. Los módulos funcionales se subdividen en capas y bloques

funcionales más manejables y granulares, como la capa de acceso y la capa de

distribución de borde. Los diseños modulares resultan en una mayor flexibilidad,

que permite la implementación en fases para el despliegue más la selección de las

mejores plataformas y su eventual sustitución como tecnología y la necesidad del

negocio de evolucionar. Por último, la modularidad también acelera la adopción de

nuevos servicios y funciones.

Disponibilidad y resistencia del servicio: incorpora varias capas de redundancia

para eliminar puntos de fallo únicos y maximizar la disponibilidad de la

infraestructura de red.

Cumplimiento normativo: incorpora un amplio conjunto de prácticas y funciones

de seguridad que son comúnmente requeridas por las regulaciones y estándares

para facilitar el cumplimiento de la normativa.

Esfuerzo por la eficiencia operativa: está diseñada para facilitar la

administración y las operaciones durante todo el ciclo de vida de la solución. Los

553

diseños fueron concebidos con sencillez para acelerar el aprovisionamiento y para

ayudar a solucionar y aislar problemas rápidamente, reduciendo efectivamente los

gastos operativos.

Implementaciones auditables: incluyen un conjunto de herramientas para medir

y verificar el funcionamiento y la aplicación de salvaguardias en toda la red.

Compartición y colaboración de información global: utiliza el intercambio de

información y las capacidades de colaboración disponibles en los productos y

plataformas de Cisco. El registro y la información de eventos que se genera a partir

de los dispositivos de la red se recopilan, se tienden y se correlacionan

centralmente para obtener la máxima visibilidad.

554

La arquitectura modular de red de Cisco consiste en varios módulos funcionales. Cada uno

de estos puede subdividirse en capas y bloques funcionales más manejables y granulares,

cada uno de los cuales cumple una función específica en la red. Aunque estos módulos

funcionales pueden variar de diseño a diseño basado en varios factores, tales como el

tamaño del entorno objetivo y el tipo de negocio, los módulos más comunes son:

Núcleo de la empresa: La infraestructura del núcleo es la parte principal de la red,

que conecta a todos los demás módulos. El objetivo de esta infraestructura de alta

velocidad es proporcionar un transporte de Capa 2 o Capa 3 fiable y escalable.

Centro de datos Intranet: El objetivo del centro de datos intranet es alojar

muchos sistemas para servir aplicaciones y almacenar volúmenes significativos de

datos. El centro de datos también alberga una infraestructura de red que admite

aplicaciones, incluidos enrutadores, conmutadores, balanceadores de carga y

aceleración de aplicaciones. El centro de datos de intranet está diseñado para

servir a usuarios y aplicaciones internas.

Campus empresarial: El campus empresarial proporciona acceso a la red a

usuarios y dispositivos. Puede abarcar varios pisos o edificios en la misma

ubicación geográfica. La arquitectura de red modular de Cisco incluye un diseño de

campus que permite a los usuarios del campus acceder de forma segura a cualquier

recurso interno o externo.

Borde de Internet de la empresa: El borde de Internet es la arquitectura de red

que ofrece conectividad a Internet. Incluye servicios públicos (DMZ), acceso

corporativo a Internet y VPN de acceso remoto.

555

Borde de WAN de empresa: el borde de WAN es la parte de la infraestructura de

red que agrega los enlaces de WAN que conectan sucursales geográficamente

distantes a un sitio central o un sitio de concentrador regional. El objetivo de la

WAN es proporcionar a los usuarios de las sucursales los mismos servicios de red

que los usuarios del campus en el sitio central. La arquitectura de red modular de

Cisco incluye un diseño de borde WAN que permite a las sucursales y oficinas

remotas comunicarse de forma segura a través de una WAN privada.

Sucursal empresarial: las sucursales proporcionan conectividad a usuarios y

dispositivos en una ubicación remota. Por lo general, implementan una o más LAN

y se conectan a sitios centrales a través de una WAN privada o una conexión a

Internet. La arquitectura modular de Cisco incluye varios diseños de sucursales que

permiten a los usuarios y dispositivos acceder de forma segura a los servicios de

red.

Teletrabajador: El término teletrabajador se refiere a cualquier usuario remoto,

como un usuario con una oficina en casa conectada a través de Internet pública a la

red de la empresa.

Comercio electrónico: El comercio electrónico se refiere al bloque o módulo

empresarial que aloja dispositivos de red y de seguridad para proporcionar

conectividad segura a aplicaciones de comercio electrónico, principalmente para

usuarios externos o clientes. Este módulo no debe considerarse necesariamente en

todas las arquitecturas empresariales (ya sea que dependa de los negocios y

servicios que ofrece la empresa).

Compañeros y extranet: Estos módulos proporcionan conectividad a redes

externas o usuarios, como socios comerciales, a través de enlaces o redes

dedicados.

Gestión: El diseño de la arquitectura incluye una red de gestión. La red de gestión

combina la gestión fuera de banda (OOB) y la gestión en banda (IB). El objetivo de

la red de gestión es de llevar el control y el plano de gestión del tráfico, tales como

Network Time Protocol (NTP), Secure Shell (SSH), SNMP (Simple Network

Management Protocol) y syslog.

Para proporcionar un diseño más seguro, manejable y escalable, la arquitectura de red

modular de Cisco debe incluir varias zonas de seguridad. Algunas de las zonas y las

ubicaciones de estas zonas en la arquitectura de red modular de Cisco son las siguientes:

Zona pública: La zona pública está fuera de la organización y se encuentra en el

borde Internet de la empresa.

Zona de acceso público: La zona de acceso público se utiliza para alojar los

servicios públicos de una organización y el acceso seguro de los usuarios de la

empresa a la zona pública. Se encuentra en el borde de Internet de la empresa.

Zona de operaciones: La zona de operaciones hospeda servicios de soporte para

usuarios y servicios internos. Normalmente, esta zona se encuentra en el módulo

funcional del centro de datos de intranet.

556

Zona restringida: La zona restringida aloja los servicios de datos más importantes,

y el acceso debe limitarse al tráfico necesario. Esta zona se encuentra en el centro

de datos de intranet.

Zona restringida de gestión: Esta zona proporciona gestión para la red y otras

infraestructuras. Debería garantizarse limitar el acceso a los recursos de gestión.

Esta zona está alojada en el centro de datos de intranet.

Al traducir el diseño de seguridad de su forma de alto nivel (lógico) a uno más detallado

donde se debe comenzar, se decide qué seguridad o producto debe seleccionar. Puede

utilizarse los siguientes productos y tecnologías para proporcionar un diseño de red

seguro:

Acceso seguro a la red: hoy en día, las organizaciones utilizan un conjunto

complejo y diverso de puntos de acceso, tanto por cable como inalámbrico. Los

puntos finales se encuentran en el campus empresarial y la sucursal empresarial en

una arquitectura de red modular. El objetivo principal de estos dos módulos

funcionales es proporcionar acceso seguro a la red y proteger los puntos finales de

la pérdida de datos, robo de datos e invasiones de privacidad. La seguridad debe

centrarse tanto en los terminales cableados como inalámbricos.

Tecnologías VPN: Para proporcionar conectividad al sitio central, las

organizaciones usan el acceso a la red como Internet o los servicios WAN del ISP,

que no son seguros desde el punto de vista de la organización. Por lo tanto, las

organizaciones deben utilizar tecnologías VPN para proporcionar acceso seguro al

sitio central. Las tecnologías VPN se usan principalmente en el borde WAN de la

empresa y en la sucursal de la empresa. Para permitir que los trabajadores remotos

se conecten a los recursos de la organización, las tecnologías VPN de acceso remoto

se utilizan en el borde empresarial de Internet.

Firewalls / IPS: Firewalls e IPS proporcionan control de acceso entre diferentes

puntos de la red. Estas tecnologías se utilizan normalmente en el borde

empresarial de Internet para controlar el tráfico entre las diferentes zonas de

seguridad. Los firewalls e IPS también se utilizan en el centro de datos de la

intranet para controlar el tráfico entre diferentes módulos funcionales de la red a

las aplicaciones y pilas de aplicaciones.

Protección de la infraestructura: Para proporcionar seguridad de alto nivel al

entorno organizativo, se debe proteger la infraestructura y el acceso a los

dispositivos debe limitarse a los dispositivos y empleados autorizados. Los

servicios de protección de la infraestructura deben tenerse en cuenta en todos los

módulos funcionales de la arquitectura de modular red Cisco.

Seguridad de contenido y aplicaciones: las organizaciones pueden ser

vulnerables a ataques a datos y contenido. Spam, phishing a través de correo

electrónico y ataques de contenido web han sido utilizados para proporcionar

acceso a un atacante. Para proteger a los usuarios contra los ataques de la capa de

aplicación, la organización debe implementar productos como correo electrónico o

557

accesorios de seguridad web. Estos dispositivos suelen ser desplegados en el borde

de Internet de la empresa.

Gestión de la red y de la seguridad: Las herramientas de gestión de la red y de la

seguridad normalmente se encuentran en el módulo funcional de gestión. Estas

herramientas proporcionan una gestión central de redes y seguridad. Ayudan a las

organizaciones a automatizar y simplificar la gestión de la red para reducir los

costes operativos

SEGURIDAD DE PRÓXIMA GENERACIÓN DE CISCO

Para protegerse contra las amenazas modernas (que son más sofisticadas), Cisco ofrece

productos de próxima generación como el firewall de generación remota 5500-X N de

Cisco y el sistema de prevención de intrusiones (IPS) Cisco FirePOWER de próxima

generación.

El firewall de próxima generación Cisco ASA 5500-X le ayuda a equilibrar la eficacia y la

productividad de la seguridad. Esta solución ofrece las siguientes características

destacadas:

Firewall de estado con agrupación avanzada

Acceso remoto Cisco Anyconnect

Visibilidad y control de aplicaciones granulares (AVC) para soportar más de 3000

controles de capa de aplicación y basados en el riesgo

IPS Cisco FirePOWER de próxima generación, que proporciona la prevención de

amenazas y la conciencia contextual

Filtros de cientos de millones de URL en más de 80 categorías

Descubrimiento y protección contra malware avanzado y amenazas

Capacidades físicas y virtuales del firewall

El ASA de Cisco se puede desplegar en una amplia gama de formas. El dispositivo más

pequeño es Cisco ASA 5506-X para pequeñas empresas y pequeñas sucursales; Ofrece

hasta 250 Mbps de rendimiento. Cisco ASA 5512-X a través de Cisco ASA 5555-X están

destinados a pequeñas y medianas empresas, con un rendimiento que oscila entre 300

Mbps y 1,75 Gbps. El producto Cisco ASA de gama alta 5585-X con un procesador de

servicios de seguridad (SSP, por sus siglas en inglés) puede ofrecer hasta 15 Gbps de

rendimiento por dispositivo y está pensado para grandes redes de centros de datos y de

Internet.

La solución IPS Cisco FirePOWER de próxima generación integra un conocimiento

contextual en tiempo real, visibilidad de pila completa y automatización de seguridad

inteligente para ofrecer una seguridad eficaz, un rendimiento confiable y un menor costo

558

de propiedad. La protección contra amenazas puede ampliarse con licencias de

suscripción opcionales para proporcionar protección antivirus avanzada (AMP) y

visibilidad y control de las aplicaciones.

El IPS Cisco FirePOWER de próxima generación se puede implementar como un

dispositivo físico. Los dispositivos de la serie 8000 pueden proporcionar de 15 Gbps a 60

Gbps de rendimiento IPS, mientras que la serie 7000 puede proporcionar de 50 Mbps a

1,25 Gbps de rendimiento IPS. El IPS Cisco FirePOWER de próxima generación también se

puede implementar como un dispositivo virtual o como un ASA con los servicios de

FirePOWER.

DISEÑO DE LA PROTECCIÓN DE LA INFRAESTRUCTURA

La primera capa en la seguridad de una infraestructura de red es hacer valer los elementos

fundamentales de la seguridad de la red. Los elementos fundamentales de la seguridad de

la red forman una línea de seguridad que crea una base sólida sobre la cual se pueden

construir métodos y técnicas más avanzadas. Si no se abordan los elementos

fundamentales de seguridad, las tecnologías y características de seguridad extra suelen

ser inútiles. Se identifican las siguientes áreas claves:

Asegurar el acceso a dispositivos de infraestructura

Asegurar la infraestructura de enrutamiento

Resiliencia del dispositivo y capacidad de supervivencia

Hacer valer las políticas de red

Asegurar la infraestructura de conmutación

Consideraciones de seguridad de SDN

La funcionalidad de un dispositivo de red suele estar segmentada en tres planos de

funcionamiento:

Plano de datos: La gran mayoría de los paquetes manejados por un enrutador

viajan a través de él a través del plano de datos (plano de reenvío).

Plano de control: El protocolo STP, los protocolos de control de enrutamiento,

keepalives, ICMP con opciones de IP, MPLS LDP y paquetes destinados a las

direcciones IP locales del enrutador pasan a través del plano de control.

Plano de gestión: El tráfico procedente de protocolos de gestión y otros

protocolos de acceso interactivo, como Telnet, Secure Shell (SSH) y SNMP, pasa a

través del plano de gestión.

Para proporcionar seguridad completa del dispositivo de red, debe aplicar la seguridad en

los tres planos. Para proteger el plano de gestión, debe centrarse especialmente en

asegurar el acceso al dispositivo de infraestructura. Del mismo modo, todos los protocolos

559

del plano de control deben ser asegurados. Por lo tanto, debe proteger su infraestructura

de enrutamiento y conmutación para proteger el plano de control del dispositivo de red.

Para proteger su plano de datos, debe aplicar la política de red y la infraestructura de

conmutación segura. En realidad, las redes seguras deben construirse sobre una base

segura; por lo tanto, debe considerar lo siguiente como una línea base o base para

proteger los planos anteriores:

Protección del plano de control: Protege el tráfico del plano de control

responsable del reenvío de tráfico mediante el "bloqueo" de servicios y protocolos

de enrutamiento

Protección del plano de gestión: protege el plano de gestión del acceso de gestión

no autorizado y de sondeo y proporciona un acceso seguro para la gestión y la

instrumentación

Protección del plano de datos: protege el plano de datos del tráfico malicioso y

protege los datos transmitidos a través del dispositivo

Acceso al dispositivo de infraestructura

La seguridad de la infraestructura de red requiere asegurar el acceso de administración a

estos dispositivos de infraestructura. Es fundamental evitar el acceso no autorizado.

Asegurar el acceso de gestión a los dispositivos de infraestructura es fundamental para la

seguridad de la red. Si el acceso al dispositivo de infraestructura está comprometido, la

seguridad y la administración de toda la red pueden verse comprometidas. Por lo tanto,

debe evitar el acceso no autorizado.

Los dispositivos de infraestructura de red proporcionan una gama de mecanismos de

acceso diferentes. Algunos de ellos normalmente se activan de forma predeterminada, con

una seguridad mínima asociada a ellos. Por lo tanto, debe revisar y configurar

correctamente cada dispositivo antes de implementarlo en la producción.

Los puntos clave a tener en cuenta al asegurar el acceso de gestión a un dispositivo de

infraestructura son los siguientes:

Restringir la accesibilidad del dispositivo: Limite los métodos de acceso

permitidos sólo a aquellos métodos que son necesarios para la administración.

También debe limitar el alcance de las direcciones IP que pueden acceder al

dispositivo a través de protocolos de administración.

Notificación legal actual: Se recomienda que se presente un banner de

notificación legal en todas las sesiones interactivas para garantizar que los usuarios

sean notificados de la política de seguridad que se está aplicando.

Acceso autenticado: asegúrese de que el acceso al dispositivo se conceda

únicamente a los usuarios, grupos o servicios autenticados.

560

Autorizar acciones: Restrinja las acciones y las vistas permitidas por cualquier

usuario, grupo o servicio en particular.

Asegurar la confidencialidad de los datos: Proteger los datos confidenciales

almacenados localmente de la visualización y la copia mediante algoritmos de

cifrado para almacenar contraseñas y datos similares. También debe evitar el uso

de protocolos de administración no cifrados, como Telnet o HTTP, y usar SSH o

HTTPS en su lugar.

Registrar y contabilizar todos los accesos: Grabar quién accedió al dispositivo,

qué estaba haciendo la persona y cuándo sucedió esto.

Existen muchas herramientas y mecanismos para proteger los dispositivos de

infraestructura de red. Debe desplegarlos para reducir el riesgo de abuso de acceso de

administración. Generalmente hay dos mecanismos independientes para asegurar el

acceso de gestión a los dispositivos de infraestructura:

Utilice una filosofía de administración fuera de banda que establezca una red lógica

o físicamente separada para propósitos de administración. Dicha red está aislada

del tráfico de usuarios de la red, por lo que la posibilidad de falsificar e interceptar

el tráfico de gestión es mucho menor. Puede ser aceptable utilizar protocolos de

gestión sin protección (texto sin cifrar), quizás con una autenticación más débil.

Por lo general, puede utilizar el acceso de consola a través del servidor de

terminales o de los puertos dedicados de los dispositivos.

Utilice protocolos de administración seguros en una filosofía de administración en

banda. Estos protocolos incluyen SSH, protocolo seguro de transferencia de

hipertexto (HTTPS) y protocolo simple de administración de red (SNMPv3).

Cuando se utiliza un protocolo de gestión no seguro, debe utilizar protección

criptográfica, como IPsec VPN.

También se recomienda que despliegue un filtro basado en direcciones IP para

permitir el acceso a los planos de administración de dispositivos sólo desde hosts y

redes de confianza. Para los dispositivos que utilizan el software Cisco IOS, se

pueden implementar varios mecanismos para limitar el acceso al plano de

administración del dispositivo: Puede desplegar el filtrado ACL basado en

direcciones IP, lo que niega el acceso a las direcciones IP de administración del

dispositivo en todas las interfaces del dispositivo.

Puede implementar ACL específicas del servicio que limitan el acceso a un proceso

de administración específico (por ejemplo, una línea vty).

Puede implementar Cisco IOS Software Control Plane Protection, en el que se

proporciona control de acceso en una interfaz de control virtual.

Puede implementar Cisco IOS Software Management Plane Protection, que le

permite designar la interfaz de un dispositivo como la única interfaz a través de la

cual se permite el tráfico de administración hacia y desde el dispositivo.

561

Infraestructura de enrutamiento

A menudo, es necesario proteger un protocolo de enrutamiento para evitar el acceso de

pares desconocidos y rechazar las actualizaciones de enrutamiento forjadas a través del

protocolo de enrutamiento. Esta acción sólo permite que los enrutadores de confianza

participen en el enrutamiento.

La mayoría de los protocolos de enrutamiento admiten ambas contraseñas de texto plano

(estas contraseñas se incluyen en las actualizaciones) y algoritmos basados en hash para

producir el código de autenticación de mensajes que se envía con actualizaciones. Eso

significa que un secreto compartido se combina con la información en un paquete. A

continuación, se calcula un hash a partir de la combinación. Por lo tanto, conocer el

contenido del paquete y el hash resultante no permite el cálculo inverso de la palabra

clave secreta original. Sin embargo, si el secreto compartido no se cambia durante mucho

tiempo, el riesgo de que se revele se incrementa.

Protocolo

Routing Information Protocol (RIPv2)

Open Shortest Path First (OSPF)

Enhanced Interior Gateway Routing Protocol (EIGRP)

Border Gateway Protocol (BGP)

Mecanismos de Autenticación

Cleartext Message Digest 5 (MD5)

MD5

MD5

MD5

Al implementar la autenticación de protocolo de enrutamiento, siga estas pautas:

Autenticar el protocolo de enrutamiento cuando un segmento de difusión es

compartido por enrutadores y estaciones finales no confiables.

Cuando sea posible, utilice HMAC-MD5 en vez de la autenticación de texto sin

cifrar.

Utilice contraseñas secretas sólidas porque es poco probable que las claves se

cambien regularmente.

Trate de no usar la misma contraseña secreta en todos los enrutadores de un

dominio.

Cuando cambie las claves, utilice el rollover de tecla, si está soportado.

Cuando se protegen los protocolos de enrutamiento, también se recomienda utilizar la

característica de interfaces pasivas. Esto significa que las actualizaciones de enrutamiento

se envían sólo a las redes que se necesitan. Todas las demás interfaces no participarán en

el enrutamiento. Por ejemplo, se recomienda que utilice esta función para deshabilitar las

actualizaciones de enrutamiento en las LAN.

BGP también soporta un chequeo extra para el TTL. La característica se llama TTL Security

Check, que introduce la protección EBGP contra los paquetes IP forjados. Al habilitar esta

característica, se configura el valor TTL mínimo para los paquetes entrantes. BGP

562

establecerá y mantendrá la sesión sólo si el valor TTL en el encabezado del paquete IP es

igual o mayor que el valor TTL configurado. Si el valor es menor que el valor configurado,

el paquete se descarta silenciosamente y no se genera ningún mensaje ICMP.

Para controlar la información de enrutamiento que se acepta y transmite a y desde pares

conocidos, desde una red de confianza o no confiable, despliegue el filtrado de información

de enrutamiento. Hay dos enfoques posibles con el filtrado de rutas. Puede aceptar o

transmitir sólo información bien conocida y omitir cualquier otra cosa, o puede descartar

información de enrutamiento malicioso conocida y aceptar o transmitir todo lo demás.

Existen muchas herramientas y mecanismos diferentes en el equipo de red para realizar

las funciones de filtrado de rutas, tales como distribuir listas, listas de prefijos, listas de

comunidades y redistribución con filtrado.

Resiliencia y supervivencia del dispositivo

Los enrutadores y los conmutadores pueden estar sujetos a ataques que afectan

indirectamente la disponibilidad de la red. Los posibles ataques incluyen DoS, DoS

Distribuido, ataques de inundación, reconocimiento, acceso no autorizado y más. Se

pueden seguir varias prácticas para preservar la capacidad de supervivencia de los

dispositivos de infraestructura de red.

Debe seguir estas prácticas recomendadas para reducir el riesgo de ataques que pueden

afectar la disponibilidad de la red:

Desactivar servicios innecesarios: Los dispositivos de red salen de la caja con

una lista de servicios que están activados. Algunos de los servicios normalmente no

son necesarios y por lo tanto pueden ser deshabilitados. Para ayudarle a

determinar qué servicios deben desactivarse, puede identificar los puertos

abiertos. También debe comprobar que los servicios como BOOTP (Bootstrap

Protocol), enrutamiento de origen IP, servicios Packet Assembler / Disassembler

(PAD), difusión dirigida IP, Proxy ARP y otros están desactivados a menos que sean

necesarios explícitamente.

Proteja los dispositivos mediante las ACL de la infraestructura: Las listas de

control de acceso a la infraestructura (iACL) que filtran el tráfico en el borde de red

se aplican normalmente en la dirección de entrada en la interfaz que conecta a los

usuarios de la red o a una red externa. El iACL debe configurarse de tal manera que

descarte y registre todo el tráfico que esté desinstalado a las direcciones IP de los

dispositivos de infraestructura de red y permita todo el otro tráfico de tránsito.

Implemente la redundancia: Las redes se construyen a partir de muchos

componentes de hardware y software que pueden fallar o pueden estar sujetos a

ataques. Implemente componentes redundantes, que eviten puntos de falla únicos,

mejorando la disponibilidad de la red y haciéndola más resistente a los ataques.

563

Proteger los dispositivos con CPPr / CoPP: La policía de plano de control (CoPP)

utiliza limitador de tarifa y abandono de tráfico que está destinado al procesador

central del dispositivo de red. Las directivas se aplican a una cola de agregado

virtual vinculada a la CPU, denominada interfaz de plano de control. La cola recibe

todo el tráfico agregado que está destinado al plano de control, al plano de gestión

y al plano de datos que debe ser activado por software. De forma similar, las

velocidades de protección de plano de control (CPP) limitan y descarta el tráfico

que se procesa en la CPU, pero el tráfico se clasifica automáticamente en tres colas.

Son la subinterfaz de host de plano de control, que es el tráfico que está

directamente destinado a una de las interfaces del enrutador (SSH, SNMP, IBGP,

etc.); La subinterfaz Cisco Express Forwarding-Exception, que es el tráfico

redireccionado como resultado de una característica de entrada configurada en la

ruta de reenvío de paquetes CEF para conmutación de proceso o directamente en

cola en la cola de entrada de plano de control por el controlador de interfaz (ARP,

EBGP, LDP, y así sucesivamente); Y la subinterfaz de tránsito de control-plano, que

es el tráfico que es conmutado por software por la CPU.

Aplicación de políticas de red

El cumplimiento de la política de red de base se ocupa principalmente de garantizar que el

tráfico que entra en una red se ajusta a la política de red, incluido el rango de direcciones

IP y los tipos de tráfico. Los paquetes anómalos deben ser desechados tan cerca del borde

de la red como sea posible para minimizar el riesgo de exposición.

Los dos pasos clave para implementar la implementación de políticas de red de base son:

Filtrado de bordes de acceso

Protección de IP spoofing

Todo el tráfico innecesario debe filtrarse lo más cerca posible del borde. Debe proteger el

acceso al dispositivo mediante las ACL de la infraestructura. Con iACL, controlas qué

tráfico se permite al dispositivo. Sin embargo, también debe filtrar el tráfico a las redes

internas en el borde. Debe utilizar las denominadas ACL de tránsito. Estas ACL se utilizan

para filtrar el tráfico a través de la caja. Debe permitir únicamente el tráfico autorizado a

las redes internas.

La protección de suplantación de IP implica descartar el tráfico que tiene una dirección de

origen no válida. El tráfico falsificado con una dirección IP de origen no válida puede

incluir tráfico de cualquiera de los siguientes:

La gama RFC 1918, bloques de direcciones IP de uso especial o el rango de

direcciones IP no asignado

564

El intervalo de direcciones de red IP válido, pero no procede de la red legítima

asociada

Para limitar el rango de direcciones IP posibles para ataques de spoofing de IP a un

intervalo de direcciones de red IP válido, implemente el filtrado basado en RFC 2827. Esto

significa que todas las direcciones IP del RFC 1918, direcciones IP de uso especial y la

dirección IP no asignada debe ser filtrado en el borde de los enrutadores. También debe

permitir sólo el tráfico que se origina en el bloque de red.

Existen varias técnicas para proporcionar filtrado de tráfico de entrada:

Lista de control de acceso (ACL): Las ACL son la técnica tradicional para filtrar

direcciones IP forjadas. Debido a que las ACL no son dinámicas, debe utilizarlas de

manera limitada. Por ejemplo, debe filtrar un rango de direcciones RFC 1918,

direcciones IP de uso especial y el intervalo de direcciones IP no asignado.

Reenvío de paquete inverso unicast (uRPF): esta técnica dinámica descarta

paquetes con direcciones IP de origen no válidas basadas en una búsqueda de ruta

inversa en la tabla de enrutamiento. Esta técnica ofrece una mínima sobrecarga

operacional y es escalable.

IP Source Guard: Esta técnica se utiliza en entornos conmutados para negar el uso

de MAC y direcciones IP de origen forjadas. Se implementa en dispositivos de

conmutación y está diseñado principalmente para segmentos DHCP. Las

direcciones estáticas también son compatibles, pero esta técnica introduce una

mayor complejidad operacional.

Inspección de DHCP y ARP: La detección de DHCP es una función de seguridad

que valida los mensajes DHCP; también crea y mantiene la base de datos DHCP

snooping vinculante. La inspección ARP utiliza esta base de datos para validar

solicitudes y respuestas ARP y descartar paquetes ARP no válidos.

Infraestructura de conmutación

La seguridad de conmutación de base se ocupa de garantizar la disponibilidad de las redes

de conmutación de Capa 2. Se pueden seguir varias prácticas recomendadas para reducir

la seguridad y otros riesgos. Los pasos clave para asegurar y preservar la infraestructura

de conmutación son

Restringir dominios de difusión

Uso de la seguridad STP (spanning-tree)

Uso de mecanismos de filtrado de tráfico

Seguir las mejores prácticas de VLAN

565

El segmento de LAN única presenta un único dominio de difusión. Esto significa que todas

las tramas desconocidas, de multidifusión y difusión se reenvían a través del segmento

LAN y pueden degradar el rendimiento en grandes redes. Un único segmento de LAN

también forma un único dominio de fallo, lo que significa que todos los clientes del

segmento LAN sufren generalmente durante un fallo. Para evitar estos problemas, una

buena práctica es restringir el tamaño del dominio de difusión y utilizar principios de

diseño jerárquico para implementar LAN escalables y fiables.

Al implementar las redes de conmutación de Capa 2 con STP, debe seguir estas directrices

para reducir los riesgos operativos y de seguridad:

Deshabilitar la negociación dinámica del troncal de VLAN en los puertos de usuario.

Utilice el árbol Spanning de la VLAN (PVST).

Configurar la unidad de datos de protocolo de puente (BPDU) Guard.

Configurar STP Root Guard.

Desactive los puertos no utilizados y colóquelos en una VLAN no utilizada.

Debe implementar mecanismos de filtrado de tráfico en el segmento de Capa 2, como

seguridad de puertos o control de tormentas. La seguridad de puertos puede ayudar a

mitigar las inundaciones de MAC y otros ataques de desbordamiento CAM de Capa 2

restringiendo las direcciones MAC que se les permite enviar tráfico en un puerto en

particular. El control de tormenta puede prevenir tormentas de difusión, multicast o

unicast en el puerto. Las tormentas pueden ser causadas por errores en la implementación

de la pila de protocolos, errores en la configuración de la red o usuarios que emitan un

ataque DoS.

Para evitar ataques, como el salto de VLAN, puede seguir las mejores prácticas comunes:

Restringir los ID de VLAN en los puertos troncal sólo a aquellos ID de VLAN que

sean necesarios.

Deshabilite todos los puertos no utilizados y colóquelos en una VLAN no utilizada.

No utilice la VLAN 1 para nada.

Configure todos los puertos orientados al usuario como no trunking (Dynamic

Trunking Protocol [DTP] desactivado).

Configure de forma explícita las conexiones en los puertos de infraestructura.

Utilice todo el modo etiquetado para la VLAN nativa en los troncales.

Establezca el estado predeterminado del puerto para deshabilitarlo.

Consideraciones de seguridad SDN

Las Redes Definidas por Software (SDN) tienen dos propiedades que pueden ser vistas

como objetivos atractivos para usuarios malintencionados y una fuente de dolores de

566

cabeza para operadores de red menos preparados. En primer lugar, es la capacidad de

controlar la red con el software, que siempre está sujeto a errores y una veintena de otras

vulnerabilidades. Segundo es la centralización de la inteligencia en el controlador.

Cualquier persona con acceso a los servidores que alojan el software de control

potencialmente puede controlar toda la red. Los siguientes son los grupos más comunes

de amenazas de seguridad asociadas con las soluciones SDN (también considerados

desafíos) que debe tener en cuenta al diseñar cualquier solución de infraestructura SDN:

Flujos de tráfico forjados o falsificados: Estos pueden ser utilizados para atacar a

los conmutadores y controladores. Este tipo de ataque puede ser malicioso o no

malicioso (en forma de un dispositivo defectuoso). Un atacante podría apuntar al

agotamiento de TCAMs en conmutadores OpenFlow. Las posibles soluciones son el

uso de sistemas de autenticación y sistemas de detección de intrusiones.

Ataques a vulnerabilidades en switches: Estos ataques pueden causar un gran

problema para su red. Un solo conmutador podría ser utilizado para disminuir o

descartar paquetes en la red, clonar o desviar el tráfico de red (por ejemplo, para

propósitos de robo de datos), o incluso inyectar tráfico o solicitudes forjadas para

sobrecargar el controlador o los conmutadores vecinos. Las posibles soluciones son

la implementación de un sistema de gestión de confianza y el uso de monitoreo

para detectar el comportamiento anormal de los dispositivos de red.

Ataques a las comunicaciones del plano de control: Estos ataques pueden

generar ataques de denegación de servicio o robo de datos. El uso de SSL / TSL no

garantiza una comunicación segura y esto puede comprometer el enlace

controlador-dispositivo. La seguridad de esas comunicaciones es tan fuerte como

su enlace más débil, que podría ser un certificado autofirmado, una autoridad de

certificado comprometida o aplicaciones vulnerables. Las posibles soluciones son el

uso de varias autoridades de certificación de confianza.

Ataques y vulnerabilidades en los controladores: Estos ataques son

probablemente las amenazas más graves para los SDN. Un controlador defectuoso

o malintencionado puede comprometer toda una red. Una posible solución es

emplear diversidad (de controladores, protocolos, lenguajes de programación y

software), actualizar periódicamente el sistema a un estado limpio y confiable, y

asegurar el controlador.

Falta de mecanismos estándar para garantizar la confianza entre el

controlador y las aplicaciones de gestión: Puede utilizar mecanismos o

protocolos que son comunes en las redes tradicionales para acceder al controlador

de red SDN. Estas máquinas ya son un objetivo explotable en las redes actuales, la

principal diferencia es que la superficie de la amenaza vista desde una única

máquina comprometida aumenta dramáticamente en SDNs. Se vuelve fácil

reprogramar la red desde una única ubicación. Una solución viable es el uso de

protocolos que requieren una doble verificación de credenciales, por ejemplo, que

requieren las credenciales de dos usuarios diferentes para acceder a un servidor.

567

También es importante que tenga un plan en el lugar tal que pueda recuperar el

sistema y garantizar un estado fiable después de reiniciar.

Falta de recursos confiables para forenses y remediación: Tener recursos de

confianza en su lugar le permitiría entender la causa de un problema detectado y

asegurar la recuperación. Una posible solución es registrar y localizar los

mecanismos comunes en uso. Estos registros deben almacenarse en entornos

remotos y seguros.

568

Capítulo 23

Diseño de Soluciones

de Firewall e IPS

569

ARQUITECTURAS DE FIREWALL

Los firewalls se utilizan para proteger los recursos y pueden utilizarse en muchas

ubicaciones de la arquitectura de referencia de la empresa, como el borde de Internet, el

centro de datos o el borde de la sucursal. Cuando comience a diseñar su arquitectura de

firewall, primero debe recopilar los requisitos de negocio y de seguridad y luego diseñar la

arquitectura de la red en consecuencia. El diseño de los componentes de seguridad de la

red, incluidos los firewalls, puede variar de una red a otra en función de varias variables,

como el tipo de negocio, los requisitos de las aplicaciones, la rigurosidad de las

aplicaciones y los estándares de las políticas de seguridad de la empresa; sin embargo, en

general, las dos arquitecturas de firewall comunes son las siguientes:

Arquitectura de firewall de un solo nivel: Esta es la arquitectura de firewall más

común, donde tiene una zona interna y externa. También puede albergar una o más

zonas desmilitarizadas (DMZ) para proporcionar servicios públicos a las empresas.

Esta arquitectura es relativamente simple y proporciona menores costos de

implementación y operación. Pero un solo dispositivo es responsable de

proporcionar la seguridad de los recursos internos. Si un atacante puede

comprometer el firewall, la seguridad de estos recursos está en riesgo.

Arquitectura de firewall de dos niveles: En esta arquitectura, se utilizan dos

firewalls para proteger los recursos. Uno actúa como un firewall interno, mientras

que el otro actúa como un firewall externo. Las DMZ se encuentran entre ambos

firewalls. Uno está conectado a la red interna, mientras que el otro está conectado a

la red externa. Esta arquitectura puede aumentar el nivel de seguridad general del

sistema de firewall porque un atacante debe comprometer los dos firewalls para

obtener acceso a los recursos protegidos. Pero esta arquitectura aumenta la

complejidad y el costo desde los puntos de vista de implementación y

operacionales.

570

El sistema de firewall también puede ampliarse con un IPS. La ubicación típica del IPS es

directamente después de la interfaz interna del sistema de firewall. En esta ubicación, el

IPS puede ver todo el tráfico que pasa entre redes internas y segmentos externos. Puede

implementar el IPS en modo en línea o promiscuo. Cuando se despliega en modo en línea,

el tráfico pasa a través del IPS, y el IPS puede actuar de acuerdo con la política de

seguridad. El IPS en modo promiscuo recibe sólo una copia del tráfico y no puede bloquear

ataques en tiempo real.

Para proporcionar seguridad adicional en la capa de aplicación, puede implementar varios

servidores proxy. Un servidor proxy web puede aplicar la política de seguridad para la

navegación web. Un servidor proxy de correo electrónico puede controlar el correo no

deseado y otras amenazas que se envían a través de un servicio de correo electrónico. El

firewall de la aplicación web es responsable de proteger las aplicaciones web que publica

la organización. La ubicación típica de estos servicios se encuentra en el segmento DMZ.

Se puede implementar un firewall en diferentes ubicaciones de la red. Los segmentos de

red típicos en los que se pueden encontrar un firewall incluyen el borde de Internet, el

centro de datos y las sucursales. Cuando está diseñando un sistema de firewall, la

ubicación del firewall es importante debido a los diferentes requisitos.

El objetivo principal del firewall en la zona de borde de Internet es proteger los recursos

internos de las amenazas externas. Los firewalls deben ofrecer inspección con estado en

combinación con la inspección profunda de paquetes. Por lo general, los firewalls alojan

una o varias DMZ para proporcionar servicios públicos a los hosts externos. El servidor de

seguridad debe proporcionar suficiente ancho de banda para poder servir los enlaces

proporcionados por el ISP.

571

Cuando desee implementar un servicio de firewall en la red del centro de datos, un

excelente punto de filtrado se encuentra en la capa de agregación de la red. El servidor de

seguridad en el centro de datos debe proporcionar servicios de alto rendimiento. Cisco

ofrece el firewall de la serie 5585-X de Cisco Adaptive Security Appliance (ASA) para

satisfacer las demandas de alto rendimiento que proporcionan 10 Gbps de filtrado de

paquetes con estado. Por lo general, es una buena práctica desplegar el firewall en modo

transparente. En este modo, los firewalls se configuran en un modo de capa 2 y

puentearán el tráfico entre las interfaces. Se recomienda que despliegue los firewalls en el

diseño activo activo, lo que permite compartir la carga a través de la infraestructura.

Los firewalls en las sucursales permiten la segmentación y aplicación de los distintos

dominios de políticas de seguridad. Estos firewalls proporcionan una protección mejorada

contra el acceso no autorizado que puede ser necesario si las redes tienen diferentes

zonas de nivel de seguridad. Los firewalls también ofrecen una inspección más avanzada

que las listas de control de acceso (ACL). Esta inspección es especialmente necesaria

cuando la sucursal tiene acceso local a Internet.

Cisco ofrece dos opciones para integrar un firewall en la red de la sucursal:

Firewall IOS: Un firewall rentable que normalmente se implementa en el

enrutador de borde secundario. Se puede implementar como un firewall basado en

interfaz o como un firewall basado en zonas (ZBFW).

ASA: Un firewall dedicado que permite una implementación altamente escalable,

de alto rendimiento, alta disponibilidad y completa.

FIREWALLS VIRTUALIZADOS

La virtualización de firewall se utiliza principalmente en redes de centros de datos. La

ventaja de utilizar la virtualización de firewall es la escalabilidad y la flexibilidad. El uso de

herramientas de automatización también puede reducir la carga de trabajo operacional y

los costos.

Existen dos tipos de virtualización de firewall:

Modo Multicontexto: Los firewalls virtualizados se ejecutan en un único

dispositivo ASA físico.

Firewalls virtuales: Los firewalls virtuales son firewall de software solo que se

ejecutan en un hypervisor (administrador de la máquina virtual).

El modo de multicontexto fue diseñado originalmente para despliegues de múltiples

agentes. También se despliega comúnmente en entornos virtuales de enrutamiento y

572

reenvío (VRF), donde las VLAN se asignan a los VRF, y cada VRF tiene su propio firewall

virtual.

Los firewalls virtuales están diseñados principalmente para entornos de nube, donde la

escalabilidad y la flexibilidad son los objetivos de diseñar una infraestructura de

seguridad. Los firewalls virtuales se implementan directamente en un hipervisor como

una máquina virtual.

Cisco ofrece tres tipos de firewall virtuales:

Virtual Security Gateway (VSG)

ASA 1000V

ASAv

Puede dividir un único ASA en varios firewalls virtualizados que se denominan contexto

de seguridad. Cada contexto es un firewall independiente con su propia política de

seguridad, interfaces y administradores. Tener múltiples contextos es como tener

firewalls independientes.

Cuando implementa Cisco ASA en modo de multicontexto, la configuración del sistema

principal del dispositivo físico, que identifica los ajustes básicos para el dispositivo de

seguridad, incluye una lista de contextos y las configuraciones físicas de sus interfaces. De

forma predeterminada, todos los contextos tienen acceso ilimitado a los recursos. Para

preservar los recursos de un dispositivo, una buena práctica es limitar el acceso a los

recursos mediante la administración de recursos de contexto.

En el modo de multicontexto, puede asignar una interfaz física a un contexto cuando se

requiere la separación física de otro contexto. También puede asignar una interfaz física a

varios contextos para que los contextos compartan una única interfaz física. Un algoritmo

clasificador se utiliza para determinar qué contexto debe procesar un paquete entrante

particular:

Interfaces únicas: si sólo una interfaz está asociada con la interfaz de ingreso, el

dispositivo de seguridad clasifica el paquete en ese contexto.

Direcciones MAC únicas: si varios contextos comparten una interfaz, el

clasificador utiliza la dirección MAC de destino del paquete. El clasificador lo

compara con la dirección MAC de la interfaz de cada contexto que comparte la

interfaz. Debido a que las interfaces compartidas no tienen direcciones MAC únicas,

debe configurar direcciones MAC únicas, que pueden configurarse manual o

automáticamente.

Configuración de NAT: Si varios contextos de firewall comparten una interfaz

(interfaz física) y no configura direcciones MAC únicas, el clasificador intercepta el

paquete. Realiza la búsqueda de direcciones IP de destino y la configuración de

NAT en cada contexto.

573

Puede implementar todo el contexto de seguridad en modo enrutado o en modo

transparente o puede implementar algunos contextos en modo enrutado y algunos en

modo transparente. El modo mixto es compatible con la versión 8.5. (1).

Virtual Security Gateway (VSG) es un firewall de capa 2 que se parece a un "bump in the

wire" y se ejecuta como una máquina virtual en un hypervisor. Es similar a un ASA físico

que se ejecuta en modo transparente. Los hipervisores compatibles son VMware o

HyperV. VSG se gestiona a través de Virtual Network Management Center (VNMC). Para

implementar VSG, primero debe implementar Nexus 1000V, que es un requisito para la

implementación. VSG es típicamente implementado para proteger el tráfico este-oeste,

que es el tráfico entre diferentes servidores en la capa de acceso. El tráfico puede estar en

la misma subred o entre VLANs.

Similar a VSG es el ASA 1000V, que también es un firewall virtual que se ejecuta en un

hipervisor como una máquina virtual. Esta versión sólo software ejecuta el software ASA,

pero con características limitadas. Es un firewall de borde que complementa el VSG. El

tráfico puede, por ejemplo, pasar por Cisco ASA 1000V, proporcionar seguridad de borde

de inquilino, y luego pasar por VSG para proporcionar seguridad entre máquinas virtuales.

Para implementar Cisco ASA 1000V, también debe implementar Cisco Nexus 1000V.

El Dispositivo virtual de seguridad de Cisco Adaptive Security (ASAv) proporciona un

firewall ASA completo que se ejecuta como una máquina virtual. El ASAv no requiere

Nexus 1000V. Casi todas las funciones de ASA están soportadas, excepto la agrupación

ASA, el modo de multicontexto, las interfaces EtherChannel y la conmutación por error

activa / activa, que requiere el modo multicontexto. ASAv se administra como un ASA

tradicional con CLI, Adaptive Security Device Manager (ASDM) o Cisco Security Manager

(CSM). ASAv admite la interfaz de programación de transferencia de estado de

representación (API REST) para la administración programática. Es compatible con el

despliegue en modo de firewall enrutado o transparente y suele utilizarse en entornos de

multiplexación, lo que requiere escalabilidad, control de acceso con estado o diferentes

tipos de soluciones VPN. Puede reemplazar ASA 1000V y también se puede utilizar para

complementar VSG.

ASAv ASA 1000V Virtual Security Gateway

No es necesario Nexus 1000V

Es necesario Nexus

1000V

Es necesario Nexus

1000V

Modo enrutado y transparente

Modo enrutado

únicamente

Modo transparente

únicamente

Soporte para enrutamiento estático y

dinámico

Sólo enrutamiento estático El enrutamiento no es

compatible

Soporta IPSec de sitio a sitio y VPN de

acceso remoto

Soporta VPN IPsec de

sitio a sitio

No soporta VPN

574

ESTUDIO DE CASO 1: SEPARACIÓN DE NIVELES DE

APLICACIÓN

Su aplicación de comercio electrónico sigue un modelo funcional de tres niveles, que

consta de niveles web, de aplicaciones y de bases de datos, como se muestra en la Figura.

Los servidores del nivel web ofrecen servicios de presentación front-end para la

aplicación. Los servidores en los niveles de aplicación y de base de datos funcionan como

componentes de procesamiento de middleware y back-end. Las aplicaciones que están

destinadas a ser accesibles a través de Internet pública representan el ámbito más amplio

y, por lo tanto, una preocupación importante de seguridad.

El modelo de seguridad centrado en la red es el enfoque tradicional. Este método implica

el uso de VLAN dentro del dominio de Capa 2 para separar lógicamente cada nivel de

servidores. La comunicación interconectada se establece mediante el enrutamiento en la

capa de agregación. El método centrado en la red se presta a diseños en los que algunos o

todos los servicios se aplican fuera del nivel de computación de la infraestructura. Los

flujos entre las VLAN se eliminan en la capa de agregación. El tráfico normalmente fluye a

través de firewalls y balanceadores de carga, antes y entre los niveles de aplicación, como

se muestra en la Figura.

575

El método centrado en el servidor se basa en el uso de tarjetas de interfaz de red virtual de

VM (vNIC) separadas para unir los niveles de servidor en cadenas. Este método se basa en

la capa de servidor virtualizada, aprovechando los puntos fuertes del conmutador virtual

(como Cisco Nexus 1000v) para reducir y optimizar de forma óptima los flujos de tráfico

en el nivel de conmutación de acceso virtual de la infraestructura. Aunque este enfoque

parece razonable en teoría, en la práctica, pronto descubrirá que es demasiado simplista.

Un problema es que las aplicaciones son complejas; las aplicaciones no necesariamente

siguen un estricto flujo de tráfico jerárquico. Algunas aplicaciones pueden escribirse para

funcionar de una manera centrada en la base de datos, con flujos de comunicación a los

niveles middleware (aplicación) y presentación (web) de un núcleo de base de datos. Otro

problema, particularmente común en los escenarios empresariales, es que algunos flujos

de aplicaciones pueden necesitar extenderse fuera del inquilino de la nube privada o del

contenedor del grupo de trabajo, a través de los límites de la organización y tal vez de un

sitio a otro.

Finalmente, los niveles de aplicación pueden ser distribuidos, ya sea lógicamente o

físicamente, a través del centro de datos o en un caso privado, a través del campus de la

empresa. El resultado es la proliferación innecesaria y subóptima de puntos de aplicación

de políticas. El tráfico puede innecesariamente atravesar muchos firewall en el camino de

extremo a extremo desde la fuente hasta el destino. El enfoque de modelo de política de

Cisco ACI junto con la automatización de inserción de servicios en la parte superior de la

arquitectura de red de espina-hoja ofrecen una comunicación más efectiva y eficiente en

estos escenarios.

576

Asegurar el tráfico Este-Oeste

Si bien este-oeste es la naturaleza, el tráfico de servidor-servidor todavía tiene que

atravesar el acceso a través de la capa de agregación si desea aplicar las políticas de

seguridad con el dispositivo de servidor de seguridad. Se hace aún más evidente que el

flujo de tráfico descrito es subóptimo cuando los dos servidores residen como máquinas

virtuales (VM) en un único host físico. En ese caso, el tráfico tiene que fluir desde el host

físico a través de la capa de acceso a la capa de agregación, sólo para ser filtrada por un

firewall y reenviada hacia el sur al mismo host físico, como se muestra en la Figura.

Tiene más sentido aplicar políticas de seguridad en un host físico con un dispositivo de

firewall virtual, como el ASAv (Cisco Adaptive Security Virtual Appliance) o Cisco Virtual

Security Gateway (VSG). Los dispositivos de firewall virtuales hacen cumplir la política

para el tráfico entre VM, sin la necesidad de atraer tráfico al firewall físico. Cisco ASAv

proporciona un conjunto completo de servicios de seguridad virtualizados diseñados

específicamente para entornos de DC: firewall, NGFW, NGIPS, VPN, correo electrónico y

servicios de seguridad Web. Cisco VSG también admite el aprovisionamiento dinámico de

políticas de seguridad y zonas de confianza durante la creación de instancias de VM y la

portabilidad de políticas durante el movimiento de VM. El objetivo es aplicar los servicios

de seguridad adecuados lo más cerca posible de la transacción, proporcionar escalabilidad

adecuada y dinámica y ofrecer flexibilidad dentro del centro de datos. El alto rendimiento

de los firewall virtuales se logra mediante la inicialización de múltiples redes virtuales

según sea necesario y aprovechando las implementaciones híbridas con los firewalls

físicos existentes. Para reducir la sobrecarga de gestión, puede proporcionar y administrar

firewall virtuales con controladores SDN, como Cisco APIC, lo que los convierte en una

solución perfecta de un centro de datos impulsado por SDN.

577

ESTUDIO DE CASO 2: IMPLEMENTACIÓN DE FIREWALLS EN UN

CENTRO DE DATOS

Para satisfacer los requisitos de seguridad más recientes para este estudio de caso, la

empresa tiene que desplegar el filtrado de paquetes con estado en el centro de datos. El

centro de datos aloja unos cientos de máquinas virtuales en varios servidores. Debe

decidir cómo implementar el firewall en el centro de datos.

La red de centros de datos está diseñada en una arquitectura de tres niveles. El

enrutamiento ya está implementado entre el núcleo de red y la capa de agregación. El

conmutador de interfaces virtuales (SVI) para VLANs en la capa de acceso se encuentran

en la capa de agregación y representa las pasarelas para hosts. Todas las direcciones IP ya

están asignadas. La primera pregunta que debe pensar es: "¿Cómo se integra un firewall

en un entorno así?" Tenga en cuenta la información proporcionada anteriormente acerca

de la arquitectura de red CD.

La mejor ubicación para implementar un firewall en el centro de datos está en la capa de

agregación. Presenta un conveniente punto de filtrado y la primera capa de detección para

el centro de datos. El firewall debe cumplir los requisitos de alto rendimiento al

proporcionar 10 Gbps de filtrado con estado.

La segunda pregunta clave que usted necesita para pensar aquí es "¿Qué modo de firewall

que va a elegir para la implementación?" Un firewall se implementa tradicionalmente

como un salto de enrutamiento y actúa como una puerta de enlace predeterminada para

los hosts que están conectados a una de las interfaces. Como alternativa, un firewall puede

implementarse de tal manera que los dispositivos de capa 3 no lo vean.

578

Un firewall se puede implementar en la red existente en dos modos de reenvío diferentes

(vea la Figura):

Modo enrutado: En modo enrutado, un firewall actúa como un salto de

enrutamiento y se presenta como un enrutador para hosts o enrutadores que están

conectados a una de sus redes. El reenvío de tráfico a través del firewall se basa en

la dirección IP de destino. Para integrar un firewall enrutado en la red existente,

debe cambiar cualquier direccionamiento en los dispositivos que están conectados

al firewall. Un firewall debe participar en el protocolo de enrutamiento, o debe

implementar rutas estáticas. También es necesario utilizar NAT cuando se conecta

a las redes públicas.

Modo transparente: en modo transparente, un firewall es un dispositivo de capa 2

que actúa como un "bache en el cable". No se ve como un salto enrutado a un

dispositivo conectado. Cuando se utiliza un firewall transparente, la misma subred

se conecta a las interfaces interiores y exteriores. El firewall realiza puente

transparente entre las dos interfaces. El reenvío de tráfico se basa en la dirección

579

MAC de destino. Por lo tanto, un firewall debe soportar funcionalidades de

conmutación básica como MAC learning y similares. Debido a que el firewall

transparente no es un salto de encaminamiento, reasignación de direcciones no es

necesario cuando se implementa el firewall en la red existente. Esto simplifica la

implementación y la capacidad de administración de la red.

La arquitectura de firewall transparente es muy popular en entornos de centro de datos,

donde el reajuste a menudo no es posible y el filtrado con estado cubre todos los

requisitos básicos de seguridad, como se ilustra en la Figura.

ESTUDIO DE CASO 3: ALTA DISPONIBILIDAD DEL FIREWALL

En este estudio de caso, la empresa está hospedando aplicaciones en el centro de datos.

Las aplicaciones están protegidas con un firewall que proporciona filtrado con estado. El

objetivo de la empresa es actualizar el sistema de firewall con alta disponibilidad.

El sistema de firewall está implementado actualmente con un firewall único que

proporciona filtrado con estado. El firewall está conectado a un par de conmutadores

Nexus en la zona exterior y a un par de conmutadores Nexus en la zona interior. El firewall

está conectado a los conmutadores con la tecnología EtherChannel, que proporciona una

alta disponibilidad a nivel de interfaz, como se muestra en la Figura.

580

EtherChannel le permite asignar hasta 16 interfaces a un grupo. (Sólo ocho interfaces

pueden estar activas, las restantes interfaces pueden actuar como enlaces de espera en

caso de fallo de interfaz). El grupo actúa como una interfaz única y el tráfico se equilibra

entre los puertos. Es una práctica recomendada utilizar LACP para la creación de

EtherChannel, que agrega y quita dinámicamente interfaces a EtherChannel.

En este caso, se ha conectado el firewall a varios conmutadores Nexus a través de

EtherChannel. La tecnología de canal de puerto virtual (vPC) se utiliza en un par de

conmutadores Nexus para proporcionar Multichassis EtherChannel (MCE). Como

alternativa, puede utilizar un sistema de conmutación virtual (VSS) si utiliza switches

Catalyst. No necesita configuración adicional en ASA para soportar VSS o vPC.

Una solución alternativa para proporcionar alta disponibilidad a nivel de interfaz es

implementar interfaces redundantes. Las interfaces redundantes agregan dos interfaces

físicas en una interfaz lógica. Uno de los miembros de par redundantes se convierte en el

interfaz activo, y el otro es la interfaz de respaldo. El tráfico sólo se reenvía al miembro

activo. Cuando el miembro activo se desactiva, el miembro pasivo se hace cargo. Este

modo no permite la agregación de enlaces y sólo se puede implementar en pares de

interfaces. Puede configurar hasta ocho pares de interfaces redundantes. Es una

tecnología heredada que ha sido ampliamente reemplazada por EtherChannel.

Para proporcionar una alta disponibilidad a nivel de unidad, se estudia la opción de

implementar el modo de conmutación por error activo / pasivo, en el que un firewall está

activamente enviando tráfico mientras que el otro está esperando la conmutación por

error, como se muestra en la Figura. En este modo, se conectan dos dispositivos ASA

idénticos en conmutación por error. Los dispositivos ASA están conectados con un enlace

de conmutación por error dedicado y opcionalmente con un enlace de estado. Las

interfaces de datos deben estar conectadas al mismo dominio de difusión. El servidor de

seguridad ASA se gestiona centralmente en un dispositivo principal y la configuración se

581

replica automáticamente en el dispositivo secundario. Cuando se utiliza conmutación por

error con estado, el dispositivo ASA secundario también replica la tabla de conexiones. Se

recomienda la conmutación por error de estado para conservar todas las conexiones

durante la conmutación por error. El enlace de estado que se utiliza para replicar

conexiones y otros datos con estado debe ser tan rápido como el enlace de datos más

rápido.

También puede implementar el modo activo / activo, que sólo se admite en modo de

contexto múltiple. Debe agregar manualmente algún contexto al dispositivo ASA principal

y otro al secundario. Cuando se produce un error, todos los contextos se transfieren a un

solo dispositivo.

¿Cómo aumentaría adicionalmente la alta disponibilidad? Su objetivo es cumplir con los

siguientes requisitos:

Alta disponibilidad

Escalabilidad

Utilización de todos los enlaces

Alto rendimiento

Facilidad de Gestión

Una solución mejor es implementar los clusteres de firewall. En la creación de clústeres de

firewall, varios firewalls se unen en un clúster y actúan como un solo dispositivo. Esta

solución ofrece lo siguiente:

Alta disponibilidad: Si falla un dispositivo de un clúster, los demás dispositivos se

hacen cargo.

Escalabilidad: Siempre se puede agregar un dispositivo extra en el futuro si hay

una necesidad de más rendimiento.

Utilización de todos los enlaces: Todos los dispositivos de un clúster son

dispositivos activos; por lo tanto, se utilizan todos los enlaces.

582

Rendimiento alto: el rendimiento de un clúster es de alrededor del 70 por ciento del

rendimiento combinado de todos los dispositivos de un clúster.

Facilidad de Gestión: Un clúster actúa como un solo dispositivo y, por lo tanto, también

se gestiona como un solo dispositivo

El clúster ASA de Cisco, introducido en la versión 9.0, le permite agrupar varios

dispositivos ASA en un único clúster. El tráfico de datos es equilibrado entre los miembros

del clúster. El clúster actúa como un firewall único, lo que significa que la configuración se

gestiona en un solo dispositivo y se sincroniza con otros dispositivos del clúster. Cuando

combina unidades múltiples en un clúster, obtendrá alrededor del 70 por ciento del

rendimiento combinado. Esto significa que obtendrá aproximadamente 56 Gbps de

rendimiento al combinar ocho ASA 5585-X con SSP-40, que ofrece 10 Gbps. Al

implementar un clúster, debe dedicar al menos una interfaz de hardware como el vínculo

de control de clúster, que se utiliza para controlar el tráfico, la supervisión y la replicación

de estado. Debe dimensionar adecuadamente el vínculo de control de clúster para que

coincida con el rendimiento esperado de cada miembro. Por ejemplo, si usa ASA 5585-X

con SSP-60, que puede pasar 14 Gbps, su enlace de control de clúster también debe pasar

14 Gbps. Por lo tanto, podría utilizar dos interfaces Ethernet de 10 gigabits en

EtherChannel para el enlace de control de clúster. Se recomienda que utilice EtherChannel

local en cada ASA para un enlace de control que proporcione redundancia y agregación,

como se ilustra en la Figura.

Ha decidido implementar los clúster de firewall, en la que los dispositivos ASA actúan

como un solo dispositivo. Spanned EtherChannel se selecciona como el método de

equilibrio de carga para reenviar tráfico a los miembros del clúster desde los

conmutadores Nexus. Usted seguirá utilizando la tecnología vPC en los conmutadores

Nexus para proporcionar Multichassis EtherChannel.

583

Puede elegir entre tres métodos para equilibrar el balance de carga con los miembros del

clúster:

Spanned EtherChannel: ASA utiliza una construcción de agregación de vínculo

lógico denominada Cluster Link Aggregation Control Protocol (cLACP). Está

diseñado para extender el LACP estándar a varios dispositivos para que pueda

soportar el clúster de expansión. Los EtherChannels necesitan abarcar el cluster.

CLACP permite la agregación de enlaces entre un switch, o un par de switches, a

múltiples (más de dos) ASAs en un clúster. Es el método recomendado, que ofrece

un descubrimiento de fallos más rápido, tiempo de convergencia más rápido y

facilidad de configuración. En EtherChannel expandido, una o más interfaces se

agrupan en un EtherChannel que abarca todas las unidades del clúster. Se puede

configurar tanto en modo de firewall enrutado como transparente. Se recomienda

utilizar el algoritmo de hashing de direcciones IP de origen y de destino para el

equilibrio de carga. También puede utilizar EtherChannel expandido con VSS o vPC.

Puede configurar hasta 32 enlaces activos en el EtherChannel ampliado, pero esta

característica requiere que ambos conmutadores en el vPC admitan EtherChannels

con 16 enlaces activos. Para los conmutadores que admiten 8 enlaces activos,

puede configurar hasta 16 enlaces activos en el EtherChannel expandido cuando se

conectan a dos conmutadores en un VSS / vPC (consulte la Figura 23-13).

Enrutamiento basado en directivas (PBR): este método sólo se admite en modo

enrutado y se puede configurar cuando se utilizan interfaces individuales en un

dispositivo ASA. Esto significa que las interfaces son interfaces enrutadas normales,

donde cada interfaz tiene su propia dirección IP local. El equilibrio de carga está

configurado en el conmutador o enrutador aguas arriba con PBR.

Enrutamiento de rutas múltiples de coste igual: Al igual que PBR, el

enrutamiento de rutas múltiples de coste igual se admite en modo enrutado

únicamente y también se puede configurar en interfaces individuales. Para lograr el

equilibrio de carga, debe configurar su enrutamiento en el conmutador o enrutador

de arriba de tal manera que el tráfico se reenvía basado en la tabla de enrutamiento

en la red. Se recomienda que utilice enrutamiento dinámico en lugar de estático.

584

Nota: Es importante tener en cuenta la conectividad del firewall cuando se implementa en

modo enrutado y la capa de agregación utiliza vPC. A diferencia de VSS, el enrutamiento

dinámico sobre vPC o vPC + no es compatible; Por lo tanto, es posible que tenga que

considerar el uso de rutas estáticas o cambiar el modelo de conectividad de los firewalls,

como se muestra en la Figura.

ARQUITECTURAS IPS

Para brindar protección contra amenazas modernas, puede integrar componentes como

IPS. Algunos firewalls ya admiten funciones IPS de forma nativa o mediante módulos de

585

expansión. También puede implementar IPS como un dispositivo autónomo que se ejecute

en hardware dedicado o como dispositivo virtual.

Puede desplegar IPS en dos ubicaciones en relación con un firewall:

Zona exterior: al desplegar el IPS en el exterior del firewall, el IPS puede detectar

ataques e intentos antes de que incluso golpeen el firewall. De esta manera, puede

detectar nuevos ataques o tendencias y proporcionar datos adicionales para la

correlación con el otro sensor. Sin embargo, probablemente obtendrá muchos

falsos positivos. La razón es que usualmente sintoniza IPS en tales

implementaciones para ser muy sensible a la detección de tráfico no deseado.

Debido a que probablemente habrá muchos falsos positivos, IPS generalmente no

se usa para prevenir ataques.

Zona interior: Al desplegar el IPS en el interior del firewall, el IPS detectará

ataques que pasen el firewall desde el exterior al interior. Esta implementación

también evita que el tráfico sospechoso salga de su red. El interior del firewall es la

ubicación típica del IPS. Dado que sólo se inspecciona el tráfico que permite el

firewall, es probable que reciba menos falsos positivos.

Cisco FirePOWER es una IPS de próxima generación (NGIPS). Existen dos opciones en las

que puede implementar Cisco FirePOWER:

Como un módulo de servicio en ASA

Como dispositivo autónomo

Puede implementar Cisco FirePOWER IPS como un módulo de servicio en Cisco ASA. Este

módulo también se conoce como ASA SFR. Cisco ASA con FirePOWER Services

proporciona

Visibilidad y control preciso de la aplicación (AVC). Más de 3000 controles de capa

de aplicación y basados en el riesgo pueden invocar políticas de detección de

amenazas IPS adaptadas para mejorar la eficacia de la seguridad.

586

Una prevención de amenazas altamente efectiva y una plena conciencia contextual

de los usuarios, la infraestructura, las aplicaciones y el contenido para ayudarle a

detectar amenazas multivectores y automatizar la respuesta de la defensa.

Filtrado de URL basado en la reputación y la categoría. Este filtrado proporciona

alertas completas y control sobre el tráfico web sospechoso. Hace cumplir las

políticas de cientos de millones de URL en más de 80 categorías.

Protección avanzada contra malware. La detección efectiva de infracciones con

bajo coste total de propiedad (TCO) ofrece un valor de protección. Descubrir,

comprender y detener el malware y las amenazas emergentes que se han perdido

en otras capas de seguridad.

Puede implementar este módulo cuando ASA esté en modo de contexto único o múltiple, y

en modo enrutador o transparente. El módulo tiene una interfaz de línea de comandos

básica (CLI) para la configuración inicial y la solución de problemas. Configure la directiva

de seguridad con FireSIGHT Management Center, que puede hospedarse en un dispositivo

FireSIGHT Management Center independiente o como un dispositivo virtual que se ejecuta

en el servidor VMware. El módulo puede ser un módulo de hardware (sólo en el ASA

5585-X) o un módulo de software. El módulo de hardware tiene puertos de administración

y consola separados.

Puede desplegar el módulo en dos modos:

Modo en línea: el tráfico se envía al firewall y todas las comprobaciones se

ejecutan en el firewall antes de que el tráfico se envíe al módulo ASA FirePOWER.

El módulo inspecciona el tráfico. Después de descartar el tráfico no deseado y de

tomar cualquier otra acción que se aplique por la política, el tráfico es devuelto al

ASA para el proceso adicional.

Modo sólo monitor: Se envía una copia del tráfico al dispositivo, pero no se

devuelve al ASA. El módulo aplica la política de seguridad al tráfico y puede ver lo

que el dispositivo habría hecho al tráfico si funcionaba en modo inline.

587

Cuando implementa un dispositivo independiente IPS de Cisco FirePOWER, puede

implementar el dispositivo en modo pasivo o en línea. En el despliegue pasivo, despliega el

sistema fuera de banda del flujo de tráfico de red. En una implementación en línea, se

configura el sistema de forma transparente en un segmento de red vinculando dos

puertos.

En una implementación IPS pasiva, el IPS supervisa el flujo de tráfico a través de una red

utilizando un switch SPAN o puerto espejo, como se muestra en la figura anterior. El

puerto SPAN o espejo envía una copia del tráfico de otros puertos en el conmutador.

Permite la visibilidad del tráfico sin estar en la ruta de tráfico, lo que significa que esta

implementación no afecta al tráfico en sí. La debilidad de este despliegue es que el IPS

puede tomar sólo acciones limitadas en el tráfico malicioso. El IPS no puede proporcionar

bloqueo o configuración del tráfico, por ejemplo. El IPS no envía tráfico en SPAN o puertos

espejo.

En la implementación IPS en línea, se implementa el IPS de forma transparente entre dos

segmentos de red uniendo dos puertos. Esto significa que el IPS está en la ruta de tráfico,

como se muestra en la siguiente figura. Cuando se implementa IPS en modo en línea, el IPS

puede bloquear o configurar el tráfico, los ataques y otros tráficos maliciosos. Las

interfaces en línea reciben todo el tráfico y también deben transmitir el tráfico en la otra

interfaz. El IPS aplica la directiva de seguridad configurada al tráfico.

588

Puede configurar interfaces en un dispositivo IPS en modo en línea como interfaces

conmutadas o como interfaces enrutadas. En las interfaces conmutadas, el dispositivo

proporciona conmutación de paquetes entre dos o más redes, mientras que en modo

enrutado, IPS se ve como un salto enrutado. Debe asignar direcciones IP en cada interfaz y

las decisiones de reenvío de paquetes se realizan de acuerdo con la dirección de destino.

Al implementar dispositivos en modo enrutado, debe definir rutas estáticas o implementar

un protocolo de enrutamiento para proporcionar información de enrutamiento.

ESTUDIO DE CASO 4: CONSTRUCCIÓN DE UN DISEÑO DE

BORDE DE CAMPUS SEGURO (CONECTIVIDAD DE INTERNET Y

DE EXTRANET)

Las empresas suelen querer centrarse en su negocio principal. A menudo subcontratan en

algunas actividades a sus socios. Para cooperar eficientemente con los socios, las

empresas suelen necesitar algún intercambio de datos. Muchos desafíos de seguridad

existen cuando las empresas exponen partes de la red a sus socios. Este caso se centra en

desafíos y soluciones extranet.

Al completar este estudio de caso, usted podrá:

Explicar el diseño del borde del campus en un estudio de caso.

Identificar los desafíos de conectar a los socios externos.

Identificar las opciones de conectividad.

Explicar la topología de la extranet utilizando el modelo LAN remoto.

589

Explicar la topología de la extranet utilizando el modelo de interconexión.

Describir la seguridad y la segmentación de múltiples agentes.

Borde del Campus

Usted trabaja como arquitecto de red y ha recibido la tarea de rediseñar la red del borde

del campus para una empresa de tamaño mediano.

La nueva red del borde del campus debe tener las siguientes características:

Proporcionar conectividad a y desde el Internet: Usted será el anfitrión de

servicios públicos en su red DMZ. Estos servicios tendrían que ser accedidos desde

Internet en su propio espacio de direcciones públicas. También necesita

proporcionar acceso a Internet para usuarios y servicios internos.

Aplicar una política de seguridad para el tráfico de red entre la red interna,

las redes DMZ e Internet: las redes de la sede y del sitio remoto son zonas

internas e Internet se considera una zona externa. Las redes DMZ en el borde de

Internet caen en algún lugar entre la clasificación interna y externa. El diseño debe

soportar las siguientes capacidades de seguridad:

o Ocultar direcciones de red interna mediante NAT

o Permitir el acceso a la red interna a Internet

o Permitir acceso de red interna a las redes DMZ

o Permitir el acceso a Internet a las redes DMZ

o Bloquear el resto del tráfico

Proporcionar acceso a Internet flexible: una red de borde del campus debe ser

tolerante con los tipos de fallas más comunes:

o En caso de fallo de hardware, el sistema debe proporcionar la conmutación

por error de unidades activas a unidades en espera.

o La red del borde del campus debe redirigir el tráfico del ISP primario al

secundario en caso de fallo.

Detectar y bloquear ataques entrantes a los servicios de Internet en la DMZ:

Su nuevo borde de campus debe detectar y bloquear ataques a sus servicios

públicos que se encuentran en la DMZ. El seguimiento y el bloqueo de ataques

basados en la red mejoran la fiabilidad y el rendimiento de la presencia en la Web

de una organización y mantienen los recursos disponibles para los socios y clientes.

Detectar tráfico malicioso en las redes internas: El monitoreo y la detección de

gusanos, virus y otros tipos de malware son esenciales para mantener una red de

alto rendimiento. Debe evitar que su red se convierta en la fuente de los ataques

El primer paso es diseñar una red para conectarse a Internet. Su objetivo es crear un

diseño resistente con una conexión de Internet primaria y una de respaldo. Si se pierde el

acceso a Internet a través del enlace principal, el diseño fallará automáticamente en el

590

enlace secundario. Para implementar el diseño resiliente, implementará dos enrutadores.

Cada uno se conectará a un ISP. Los enrutadores de borde están conectados a la red

empresarial a través de conmutadores externos.

Tiene un espacio de direcciones IP independiente del proveedor. Para anunciar su prefijo,

necesita enrutamiento BGP en su red de borde. Ha acordado con ambos proveedores de

servicios establecer sesiones BGP con los enrutadores proveedores. Esta opción le permite

anunciar su prefijo al resto de Internet. En este escenario, ambos ISP están enviando sólo

la ruta predeterminada a su enrutador de borde a través de EBGP. También ha establecido

el BGP interno entre ambos enrutadores de borde, como se ilustra en la Figura. Además, se

recomienda que considere establecer una sesión IBGP directa entre los enrutadores de

borde. Esta sesión de IBGP ayudará a asegurar que ambos enrutadores siempre estén

totalmente convertidos en caso de que falle un enlace ISP o una sesión peering EBGP.

El siguiente paso es agregar una capa de seguridad de red a la conectividad a Internet

conectando firewalls a la red borde del campus. Debido a que uno de los requisitos de

diseño es tener un diseño de acceso a Internet resistente, tendrá que implementar dos

firewalls. Los firewalls se configuran en modo activo/en espera para una alta

disponibilidad. Por lo tanto, en caso de cualquier fallo de hardware del firewall, el impacto

en el acceso a Internet será mínimo. Los firewalls se implementarán en modo enrutado, ya

que en el borde de Internet es posible que necesite utilizar el firewall para realizar algunas

tareas que requieren este modo, como la conversión de direcciones de red (NAT) o la

terminación del túnel VPN. Se conectarán ambos firewalls utilizando el modelo de

conectividad de EtherChannel (MEC) de Multichasis. La ventaja de esta conexión es que el

tráfico equilibrará la carga entre los enlaces. Este diseño también ofrecerá una solución

resistente para casos en los que falla uno de los enlaces.

Utilizará su propio espacio de direcciones públicas para la red externa. Esta solución

eliminará la necesidad de funciones NAT en los enrutadores de borde. Por lo tanto, no

necesita ninguna ruta al espacio de direcciones RFC 1918 en el segmento externo.

591

Utilizará Open Shortest Path First (OSPF) para distribuir la ruta predeterminada a los

firewalls de los enrutadores de borde. Para implementar una solución de este tipo, debe

agregar sus interfaces internas de los enrutadores de borde al proceso OSPF. También

necesitará agregar interfaces externas de los firewalls al proceso OSPF, como se ilustra en

la Figura. Sólo anunciará la ruta predeterminada que se recibe a través de BGP a los

enrutadores de borde. Para evitar el enrutamiento igualitario multipunto, ya que no es

conveniente en este caso, debe anunciar la ruta predeterminada desde el enrutador de

borde secundario con la peor métrica. Con OSPF, recibirá una solución resiliente con

failover rápido al proveedor secundario en caso de fallo.

Como parte del diseño del borde del campus, hay varios servicios públicos a los que se

debe acceder desde Internet. El tráfico está estrechamente restringido entre la DMZ a las

otras partes de la red. Para conectar la DMZ a la red borde del campus, desplegará un par

de conmutadores. Conectará los firewalls a esos conmutadores usando EtherChannel para

proporcionar alta disponibilidad. Los servidores DMZ también se conectarán a estos

conmutadores, como se muestra en la Figura.

592

Utilizará espacio de direcciones privadas para los servidores de la DMZ. A continuación,

realizará traducción de direcciones de red en el firewall para permitir el acceso a los

servicios desde Internet. La solución con NAT ofrecerá más flexibilidad porque el

direccionamiento DMZ interno está oculto de la Internet pública. Por ejemplo, puede

cambiar la dirección IP de los servidores de la red DMZ y sólo debe cambiar la

configuración NAT en el firewall. Los servidores DMZ tendrán la ruta por defecto a las

interfaces DMZ.

Para proporcionar conectividad a la red interna, conectará los firewalls del borde del

campus a la capa de distribución de la red interna y también deberá utilizar Multichasis

EtherChannel para proporcionar un nivel optimizado de resiliencia.

Desde un punto de vista de diseño de enrutamiento de capa 3, debe implementar la ruta

predeterminada en los conmutadores de capa de distribución que apuntarán a los

firewalls del borde del campus. Además, es necesario implementar rutas estáticas para el

espacio de direcciones RFC 1918 de la red interna, en los firewalls. Esas rutas apuntarán a

los conmutadores de la capa de distribución. Los firewalls ofrecerán servicios NAT a los

hosts internos.

593

Desea minimizar el impacto de las intrusiones en la red; por lo tanto, implementará IPS. La

tecnología IPS complementa el firewall e inspecciona el tráfico permitido por la directiva

del firewall. Utilizará los módulos de servicio en los firewalls para una solución IPS (como

Cisco FirePOWER IPS como módulo de servicio en Cisco ASA). Los servicios IPS que se

integran en el firewall dependen de los firewalls para servicios de alta disponibilidad. Los

firewalls en el borde de Internet se despliegan en una configuración activa / pasiva. Si falla

el firewall primario, el firewall secundario se hará cargo de todas las operaciones de

firewall. El módulo IPS en el firewall secundario se encargará de la inspección de tráfico.

Debe indicar a los firewalls qué tráfico se reenviará a través del módulo IPS. Usted

redirigirá todo el tráfico a sus servicios públicos en DMZ a través de IPS. También

inspeccionará el tráfico desde su tráfico interno a Internet. No desea que su red se

convierta en una fuente de ataques a otros sistemas públicos.

594

Desde el punto de vista de la seguridad de la capa de aplicación, también debe considerar

la implementación de una política de seguridad web. En este escenario, utilizará Cisco

Web Security Appliance (WSA) para implementar una política de seguridad para la

navegación web. El WSA ofrece una combinación de controles de uso de la web con

controles basados en categorías y reputación, filtrado de URL, protección de malware y

protección de datos. Desde el punto de vista del diseño, puede conectar el Cisco WSA en la

red interna a los switches de la capa de distribución o conectarlo al switch DMZ. Esta

última opción ofrece un diseño más escalable porque el WSA puede servir a múltiples

bloques de distribución de la red interna, como se muestra en la Figura. En este escenario,

se utilizará la implementación de proxy explícita, en la que se debe indicar al usuario la

utilización de un proxy web. Con esta configuración, la aplicación cliente enviará todas las

solicitudes de Internet al proxy web. El proxy web enviará la información a Internet.

Necesitará realizar NAT en el firewall para todas las solicitudes a Internet.

595

Para proporcionar alta disponibilidad, implementará dos dispositivos WSA. Tendrá que

configurar las aplicaciones cliente para usar un servidor proxy de respaldo si falla el

servidor proxy principal.

Conexión de socios externos

La estrategia de las empresas suele centrarse en el negocio principal y externalizar

algunas tareas a socios externos. Si la empresa desea externalizar exitosamente funciones

en curso, necesita una conectividad segura y asequible entre su propia red y los sitios

asociados.

El objetivo de la extranet es proporcionar acceso seguro a los recursos internos. Una de las

opciones es duplicar todos los recursos que necesitan los socios y colocarlos en una red

segura conectada a Internet. Esta opción no siempre es posible porque puede tener una

base de recursos extensa, lo que puede llevar a un alto costo y complejidad. La alternativa

es crear acceso de red administrado independiente y separado para cada socio.

Existen tres posibles escenarios para el acceso a la extranet:

El socio accede a la red de la empresa.

596

La empresa accede a la red de socios.

El acceso recíproco a la red ocurre entre el socio y la empresa.

Retos de conectar a los socios externos

Cuando desea crear una red de extranet separada, debe diseñar su red teniendo en cuenta

la seguridad. Necesita proteger sus recursos contra amenazas de seguridad, como intrusos

y virus. También debe proteger a los socios de las amenazas de seguridad que pueden

originarse desde su red. Por lo general, no desea reenviar el tráfico de uno a otro. Por lo

tanto, debe proporcionar un diseño de extranet que ofrezca separación de tráfico de cada

socio.

El diseño de la extranet debe ser asequible. Si tiene una empresa que tiene socios en todo

el mundo, la conexión de la extranet puede ser costosa si necesita enlaces dedicados. Por

lo tanto, debe considerar el costo de los enlaces al diseñar la extranet.

Topología de Extranet: Modelo de LAN remoto

Un modelo de LAN remoto es una de las topologías de extranet. El otro es el modelo de

interconexión. El modelo LAN remoto es compatible con diferentes tecnologías de

transporte.

Como se muestra en la Figura, el modelo LAN remoto es una extensión de la red

empresarial en el sitio asociado. Cuando implemente el modelo de LAN remoto,

implementa un enrutador administrado en la red de socios. Normalmente, este enrutador

termina la conectividad de transporte de la red empresarial. El enrutador se conecta a

menudo a uno o más switches gestionados. La empresa también puede proporcionar las

PC e impresoras que se instalan en el sitio del socio.

597

El modelo de LAN remoto puede admitir una conectividad de líneas arrendadas o una

conectividad VPN de sitio a sitio. La ventaja de utilizar una línea arrendada para la

conectividad de la extranet es que el proveedor de servicios a menudo ofrece calidad de

servicio (QoS) y un acuerdo de nivel de servicio (SLA). Por otro lado, la conectividad VPN

puede reducir en gran medida el costo de la conectividad de la extranet. También puede

acelerar la implementación y también es apropiado para la conectividad extranet a corto

plazo. Desde el punto de vista del diseño de seguridad, debe tener en cuenta algunos

desafíos al diseñar este modelo de conectividad, incluyendo la seguridad física con

respecto a los dispositivos de red ubicados en el sitio del partner, los puertos de acceso y

la seguridad de Nivel 2 y la consideración AAA para los dispositivos de red.

Topología de Extranet: Modelo de interconexión

Además del modelo LAN remoto, puede implementar una extranet utilizando el modelo de

interconexión. El modelo de interconexión se admite en conexiones de líneas arrendadas o

VPN.

En el modelo de interconexión (vea la Figura), un socio se conecta a través de su propia

LAN corporativa. Puede establecer una conexión VPN a través de Internet o puede

implementar una conexión de línea arrendada entre su red y la red del partner. Cuando se

utiliza el modelo de interconexión, es importante implementar un firewall en ambos

extremos. El firewall protege recursos entre sí. La ventaja de usar el modelo de

interconexión es que los socios pueden conectarse desde cualquier escritorio en sus LANs.

Además, desde el punto de vista de la seguridad, esta opción ofrece una demarcación más

controlada entre la red de socios y la red empresarial, lo que conduce a un mejor control

de seguridad.

Uno de los mayores desafíos es cómo puede manejar las direcciones IP superpuestas.

Puede implementar NAT para realizar la conversión de direcciones antes de enviar un

paquete a través de la VPN o la conexión de líneas arrendadas.

598

Extranet: Seguridad y segmentación de múltiples terminales

Uno de los mayores desafíos al trabajar con extranets es la seguridad. Por lo general, no

puede controlar la seguridad perimetral de sus socios.

Cuando se interconecta con un socio y abre la red al socio, su red está expuesta a posibles

amenazas de seguridad. Si el socio no ofrece seguridad adecuada en su propia red,

realmente abre una puerta trasera en su entorno. Algunos de los riesgos potenciales que

debes mitigar incluyen ataques de DoS, propagación de virus y gusanos y amenazas de

hop-off. Un socio no puede informarle cuando los empleados dejan la compañía del socio.

El problema radica en el hecho de que estos empleados todavía pueden tener acceso a sus

recursos, incluso si ya no están autorizados.

Para abordar estos desafíos, usted debe cuidar de las medidas legales, restricciones de

acceso, y la aplicación de la seguridad.

Para implementar medidas legales, puede hacer que sus socios firmen varios acuerdos.

Por ejemplo, un socio puede firmar un acuerdo de no divulgación, lo que obliga al socio a

no exponer su información interna. También puede hacer que su socio firme un acuerdo

que exige el comportamiento esperado del usuario y las políticas de seguridad que se

espera que el socio imponga.

Las restricciones de acceso incluyen lo siguiente:

Permisos de firewall: Debe limitar el acceso desde el sitio del socio a la red de la

organización estableciendo la directiva de acceso de máquina a máquina en el nivel

de protocolo del firewall. Esta restricción permitirá el tráfico mínimo en su red del

socio. También puede limitar el tráfico permitido de su organización al socio o

dejar esta tarea al socio para implementar una directiva de seguridad entrante.

Proxy web: puede limitar el tráfico en el firewall sólo por host y puerto. Un socio

puede utilizar cualquier servicio en ese puerto y host. Por ejemplo, puede utilizar

proxies inversos para limitar el acceso a sitios específicos de ese host y puerto.

Infraestructura de Sandbox: Las infraestructuras de Sandbox pueden protegerte

contra saltar de un host que los socios están autorizados a acceder a uno al que no

lo están. Implementar esta solución, permite que los socios accedan al host para el

que están autorizados, pero este host no puede iniciar el tráfico a otros hosts o

redes.

Autenticación y autorización: puede implementar servicios de autenticación y

autorización en las capas de host y de aplicación. El desafío es cómo supervisar qué

empleados asociados todavía están autorizados para acceder a los recursos.

Para reforzar la seguridad de la extranet, puede utilizar una combinación de sistemas de

detección de intrusiones, auditorías físicas ocasionales de los entornos de socios y

revisiones de acceso periódicas para garantizar que sus socios aún necesiten acceso a los

mismos hosts y servicios.

599

Capítulo 24

Seguridad en la

Multidifusión IP

600

RETOS DE SEGURIDAD DE MULTIDIFUSIÓN

Muchos desafíos de seguridad deben ser abordados en las implementaciones de

multidifusión IP. Algunos de ellos son genéricos y se aplican a cualquier red o

comunicaciones basadas en IP. Otros son específicos para las implementaciones de

multidifusión. Al identificar los desafíos de seguridad, los administradores de seguridad

deben considerar el sistema como un todo. Deberían buscar vulnerabilidades potenciales

en varias capas del modelo de interconexiones de sistemas abiertos (OSI) y en todos los

mecanismos de multidifusión IP implementados.

Los siguientes son los desafíos de seguridad más comunes:

Compromiso de la infraestructura:

o Interrupción en el enrutamiento

o Enrutamiento IP modificado

o Denegación de servicio (DDoS) contra recursos de red

Compromiso de señalización multicast:

o Protocol-Independent Multicast (PIM)

o BGP Multiprotocolo (MP-BGP)

o Protocolo de detección de origen de multidifusión (MSDP)

o Auto-Rendezvous Point(Auto-RP)

o Bootstrap Router (BSR)

o Protocolo de gestión de grupos de Internet (IPv4) / Descubrimiento de

escuchas de multidifusión (IPv6) (IGMP / MLD)

PROBLEMAS EN LA RED DE MULTIDIFUSIÓN

Cuando un servidor de multidifusión está mal configurado o un ataque se origina en un

host malintencionado, pueden producirse graves problemas en la red. Técnicamente, estos

problemas se producen porque incluso si los enrutadores admiten tablas de enrutamiento

de multidifusión grandes, pueden quedarse sin memoria y esto dará lugar a un problema

de red. Sin embargo, estos problemas se impiden al considerar mecanismos de protección

simples.

601

CONSIDERACIONES DE SEGURIDAD DE LA RED DE

MULTIDIFUSIÓN

En general, para asegurar una red de multidifusión, debe considerar las siguientes tres

áreas importantes:

Asegurar elementos de la red

Asegurar la red en el borde

Manejo del PIM y seguridad interna

Como arquitecto de red o diseñador, siempre debe mirar el panorama general y la

solución global y no centrarse sólo en un determinado elemento. Por ejemplo, en muchos

casos, se pueden implementar múltiples métodos de protección para proteger una única

vulnerabilidad de una solución de multidifusión IP. Tener muchas medidas aumenta la

seguridad general a través del concepto de defensa en profundidad, en el que los métodos

de protección se complementan y refuerzan mutuamente. Los mecanismos de protección

tienen varios enfoques y pueden centrarse en la infraestructura, la VPN de superposición

o las capacidades de control de admisión. Por ejemplo, los siguientes métodos están

basados en infraestructura:

Fortalecimiento del enrutador: Este mecanismo incluye seguridad de contraseña

mejorada, inhabilitación de servicios no utilizados y protección de plano de control.

Control de acceso a la red: Este mecanismo incluye ACL y Unicast Reverse Path

Forwarding (uRPF).

Calidad de servicio (QoS): Este mecanismo implica evitar la congestión.

602

Por el contrario, los servicios basados en VPN tienen como objetivo proporcionar

privacidad, integridad y autenticidad a la señal multicast y a los flujos de tráfico,

especialmente a los datos sensibles. El control de admisión se centra en el control de los

receptores que se les permite unirse a grupos de multidifusión y los intentos de registro

de origen. También incluye técnicas de filtrado que, por ejemplo, previenen ataques de

DoS que se basan en la suplantación de direcciones RP. Un ejemplo de dicho filtro es el

comando ip pim rp-announce-filter rp-list ACL [group-list ACL] que está configurado

en los agentes de asignación en la implementación de Auto-RP.

Seguridad del elemento de red

La seguridad no es una característica puntual. Es una parte intrínseca de cada diseño de

red. Como tal, la seguridad debe ser considerada en cada punto de la red. Es de suma

importancia que cada elemento de red esté debidamente asegurado.

Un posible escenario de ataque, aplicable a cualquier tecnología, es la subversión de un

enrutador por un intruso. Cuando los intrusos tienen el control de un enrutador, pueden

ejecutar varios escenarios de ataque distintos, incluyendo espionaje, suplantación y

ataques en los protocolos activos. Por lo tanto, cada elemento de red debe protegerse

adecuadamente contra cualquier forma de ataque básico, así como contra ataques

específicos de multidifusión.

Antes de tomar medidas específicas para proteger enrutadores y otros elementos de red,

como conmutadores, contra formas específicas de ataque de multidifusión, debe

implementar seguridad básica. Estas medidas de precaución se aplican a los enrutadores,

conmutadores y cualquier otro elemento en la ruta.

603

Para los enrutadores, estos pasos son los recomendados para una seguridad fundamental:

1. Asegurar el acceso remoto del enrutador.

2. Deshabilitar servidores/servicios innecesarios.

3. Configurar listas de acceso básicas.

4. Habilitar el registro.

5. Asegurar el acceso de gestión.

6. Habilitar autenticación, autorización y contabilidad (AAA).

7. Configurar el filtrado de tráfico.

8. Habilitar la seguridad de enrutamiento.

9. Realizar el mantenimiento del router y las pruebas.

Las siguientes son dos capacidades de protección comunes y efectivas disponibles en

diferentes versiones de software de Cisco que ayudan a prevenir o mitigar el impacto

de ciertos ataques dirigidos a la red:

Listas de control de acceso de recepción (ACL): Filtra el tráfico que está

destinado al plano de control de un enrutador. Este filtro global se aplica a todos

los paquetes recibidos o, en otras palabras, a todos los paquetes que se envían a

cualquier dirección propiedad del enrutador. Este grupo incluye todas las

direcciones unicast configuradas del enrutador y los grupos de multidifusión a los

que el enrutador está escuchando. Este filtro puede ser útil para restringir estos

paquetes:

o Paquetes Unicast que están dirigidos a una de las direcciones de interfaz de

enrutador

o Paquetes de difusión IP

o Paquetes para tráfico IP multicast unido

o Paquetes para grupos de alcance de enlace local

Policía de control-plano (CoPP): La evolución de las rACLs. CoPP sólo controlará

el tráfico destinado al enrutador. Debe tener cuidado al configurar rACLs y CoPP en

una red activa. Debido a que ambas funciones filtran todo el tráfico al plano de

control, se deben permitir explícitamente todos los protocolos de control y de

plano de gestión requeridos. Por lo tanto, la lista de protocolos necesarios es

grande. Es fácil pasar por alto protocolos menos obvios tales como Network Time

Protocol (NTP) o Terminal Access Controller Access Control System (TACACS).

Como tal, todas las configuraciones de rACL y CoPP deben ser probadas en un

laboratorio antes del despliegue. Además, los despliegues iniciales deben comenzar

con una política de permisos solamente. Esta precaución le permite comprobar con

los contadores de aciertos de ACL si tiene algún impacto inesperado.

En un entorno de multidifusión, los protocolos de multidifusión requeridos basados en los

requisitos de diseño, como PIM, MSDP, IGMP, etc., deben estar permitidos en las

configuraciones rACL y CoPP para que el entorno de multidifusión funcione

correctamente. El primer paquete en un flujo de multidifusión donde se utiliza PIM Sparse

Mode (PIM-SM) también es un paquete de plano de control, aunque, estrictamente

604

hablando, se trata de tráfico de datos. Se utiliza como un paquete de plano de control

porque, como el primer paquete, crea el estado de multidifusión, que es una función de

plano de control. Por lo tanto, es importante permitir los grupos de multidifusión

relevantes en rACL y CoPP. En CoPP, estos grupos pueden ser limitados.

Además, inhabilitar servicios innecesarios es un aspecto importante en la seguridad del

dispositivo. Por ejemplo, el Protocolo de Anuncio de Sesión (SAP) es un protocolo

tradicional de datos de los días del backbone de multidifusión. Sus mensajes indican

información sobre el contenido de multidifusión que podría estar disponible ahora o en el

futuro. Dado que estos mensajes pueden provocar un DoS contra la CPU del enrutador y

los recursos de memoria, se recomienda que se desactive esta función.

Del mismo modo, Multicast Information Protocol (mrinfo) es un protocolo existente que

proporciona información que ahora es mejor recuperada a través de SNMP. Se recomienda

filtrar completamente mrinfo. Además, todas las otras consideraciones acerca de la

seguridad y el control del plano de datos y del plano de control, como la seguridad de

enrutamiento (tanto para unidifusión como para multidifusión) son clave para asegurar

cualquier entorno de multidifusión. Por ejemplo, debe asegurarse de que la tabla de

enrutamiento (tabla de enrutamiento global o VRF) debe ser estable y no estar

sobrecargada con un gran número de rutas no deseadas o engañosas que pueden conducir

al tráfico de saturación o sobreutilizar los recursos de hardware del dispositivo (memoria

y CPU).

Seguridad en el Borde de la Red

Para asegurar la multidifusión en el borde de la red, primero debe controlar la operación

de multidifusión. Al considerar ACL, puede desactivar todas las operaciones para grupos

de multidifusión. Si los paquetes aparecen para cualquiera de los grupos denegados, se

eliminan en todos los protocolos de control. Estos protocolos incluyen PIM, IGMP, MLD y

MSDP. Los paquetes también se descartan en el plano de datos. Por lo tanto, no se crean

entradas de memoria IGMP o MLD, PIM, base de información de enrutamiento de

multidifusión (MRIB) o estados de base de información de reenvío de multidifusión

(MFIB) para estos rangos de grupo. Todos los paquetes de datos se descartan

inmediatamente.

605

La recomendación es implementar los siguientes dos comandos en todos los enrutadores

de la red, cuando y donde estén disponibles, para que se controle todo el tráfico de

multidifusión que se origina fuera de la red. Estos comandos afectan al plano de datos y al

plano de control porque limitan todas las operaciones de multidifusión en el plano de

datos y permiten sólo los grupos definidos en la ACL. Además, asegúrese de que el ACL

debe contener los grupos permitidos (S, G) o (*, G) y negar grupos que no están en uso:

router(config)# ip|ipv6 multicast group-range ACL

router(config)# ip multicast boundary ACL [filter-autorp]

Además, en un entorno de interdominio, asegure el plano de datos mediante el comando

multicast boundary. El límite de multidifusión garantiza que el tráfico de multidifusión

sólo sea aceptado para grupos definidos y fuentes potenciales.

Al igual que el enrutamiento unicast, la seguridad de protocolos de control de

multidifusión como PIM es un aspecto vital a considerar cuando se necesita tener una red

de multidifusión confiable y segura. Tanto Auto-RP como BSR ayudan a proporcionar un

mecanismo en el que las asignaciones de grupo-RP viables se pueden formar y propagar a

través de los enrutadores PIM en un dominio PIM / multicast. MSDP, sin embargo, se

utiliza más comúnmente para lograr lo mismo entre diferentes dominios de multidifusión.

Seguridad de Auto-RP y BSR

Auto-RP, que es un protocolo desarrollado por Cisco, tiene el mismo propósito que el

mecanismo PIMv2 BSR. Auto-RP fue desarrollado antes de BSR y sólo admite IPv4. BSR

606

soporta IPv4 e IPv6. El agente de correlación en el enfoque de Auto-RP cumple la misma

función que el enrutador de arranque en el enfoque BSR. En BSR, los mensajes del RP

candidato son unicast al enrutador bootstrap. En Auto-RP, los mensajes se envían por

medio de multidifusión al agente de asignación, lo que facilita el filtrado en los límites.

En el software Cisco IOS, el envío de paquetes AutoRP y BSR siempre está habilitado y

actualmente no es configurable. Este valor predeterminado puede presentar una

exposición de seguridad específica para Auto-RP.

Auto-RP, aunque es un mecanismo para el anuncio y descubrimiento de RP, no utiliza

paquetes PIM. Auto-RP en su lugar utiliza paquetes UDP con direcciones de multidifusión.

Auto-RP utiliza estos dos tipos de paquetes:

Paquetes de anuncio de Candidatos RP: Estos paquetes son multidifusión a todos

los agentes de mapeo usando una dirección bien conocida de IANA-reservada

(224.0.1.39).

Paquetes de descubrimiento de Candidatos RP: Estos paquetes son multidifusión a

todos los enrutadores PIM usando una dirección bien conocida de IANA-reservada

(224.0.1.40).

Cada uno de estos tipos de paquetes está destinado a ser inundado a través de la red.

Ambos 224.0.1.39 y 224.0.1.40 se reenvían en PIM Dense Mode (PIM-DM) para evitar

tener que conocer el RP de un grupo cuando ese grupo se utiliza para distribuir

información RP. Este es el único uso recomendado de PIM-DM.

En el software Cisco IOS XR, los mensajes de Auto-RP inundan la información de reenvío

de ruta inversa (RPF) para un salto de RP de un vecino a otro. Por lo tanto, no es necesario

crear un estado mroute PIM-DM para admitir Auto-RP en el software Cisco IOS XR. En

realidad, el software Cisco IOS XR no es compatible con PIM-DM.

De forma similar, los mensajes BSR deben bloquearse en la entrada y salida del dominio

de multidifusión, donde BSR debe bloquearse para filtrar mensajes maliciosos de BSR. No

607

es necesaria ninguna lista de acceso porque los mensajes BSR se reenvían salto a salto vía

multicast de enlace local.

Seguridad MSDP

MSDP es el protocolo IPv4 que permite que una fuente en un dominio sea anunciada a un

receptor en otro dominio a través de sus respectivos puntos de encuentro. MSDP se

especifica en el RFC 3618.

MSDP trabaja enviando información sobre dominios activos entre dominios PIM. Si una

fuente se activa en un dominio, MSDP se asegura de que todos los dominios de pares

aprendan acerca de esta nueva fuente. Esta notificación permite que los receptores en

otros dominios hagan contacto rápidamente con esta nueva fuente si sucede que termina

en un grupo. Por lo tanto, para tener una capa de seguridad en dicho entorno, es necesario

considerar filtrado entre dominios con MSDP.

608

Por ejemplo, cuando un ISP actúa como un proveedor de tránsito PIM-SM, sólo está

soportando MSDP peering con vecinos. Además, sólo acepta (S, G) –no el tráfico (*, G) en

los enrutadores fronterizos. En un entorno interdominio, se pueden tomar dos medidas

básicas de seguridad:

Asegurar el plano de datos, utilizando el comando de límite de multidifusión. Esta

acción asegura que el tráfico de multidifusión sólo se acepta para grupos definidos

(y fuentes potenciales).

Asegurar el tráfico de plano de control interdominios MSDP. Esta actividad

consiste en varias medidas de seguridad separadas, incluyendo el control de

contenido de MSDP, la limitación de estado y la autenticación de vecinos.

Además, prácticamente, para proporcionar una comunicación segura óptima para un

escenario interdominios debería considerar la seguridad tanto del plano de control

unicast (más comúnmente BGP) como del plano de control de multidifusión (comúnmente

MSDP).

BGP

MSDP

Autenticación entre pares MD5 MD5

Estado de límite, global maximum-prefix ip multicast routelimit

Estado límite, por vecino

neighbor peer maximumprefix

n

ip msdp sa-limit peer

n

Filtrado de prefijo Listas de filtros de prefijo ip msdp sa-filter

[in|out]

Comprobar el primer sistema autónomo enforce-first-AS

(AS)

Comprobar el camino AS

Filtro de ruta AS

Limitar el horizonte de ataque

Seguridad TTL

PIM y seguridad de multidifusión interna

Para establecer vecinos PIM, un enrutador PIM debe recibir saludos PIM. Los vecinos del

PIM son fundamentales en la elección de DR; en el proceso de conmutación por error de

DR; y en el envío y la aceptación de los mensajes de unión, podación y afirmación PIM. Las

siguientes son algunas características y capacidades de multidifusión que se pueden usar

para endurecer la seguridad de multidifusión interna

Los mensajes de registro PIM limitadores de velocidad se envían desde el

enrutador de primer salto al RP:

router(config)# ip|ipv6 pim accept-register list ACL

Filtrado de los mensajes de registro PIM en el RP:

ip|ipv6 pim accept-register list ACL

609

Filtrado de vecinos PIM basado en interfaces:

router(config-if)# ip pim neighbor filter ACL

Control de remitente de multidifusión

Los emisores de multidifusión IP, ya sean PC o servidores de vídeo, no están a veces bajo el

mismo control administrativo que la red. Por lo tanto, desde la vista del operador de red,

el remitente es tratado en su mayor parte como no confiable. Dadas las potentes

capacidades de los PC y servidores, y sus complejas configuraciones de seguridad -que a

menudo son incompletas- los remitentes representan una amenaza sustancial contra

cualquier red, incluyendo la multidifusión.

Las amenazas de los remitentes de multidifusión pueden tomar muchas formas,

incluyendo las siguientes:

Ataques de capa 2: hay una amplia gama de formas de ataque en la capa 2 para

realizar escuchas, enmascaramiento o ataques DoS. Estas amenazas se aplican a las

redes unicast y multicast.

Ataques con tráfico de multidifusión: Como se describió anteriormente, es difícil

realizar ataques con tráfico de multidifusión porque el enrutador de primer salto

no reenvía el tráfico de multidifusión IP a menos que haya un oyente para el grupo.

Sin embargo, el primer salto puede ser atacado de varias maneras con paquetes de

multidifusión:

610

o Un atacante puede inundar un segmento con paquetes de multidifusión,

sobreutilizando el ancho de banda disponible y creando una condición DoS.

Esta amenaza se conoce como un ataque de saturación de red.

o Un intruso puede inundar el enrutador de primer salto con paquetes de

multidifusión, creando demasiados estados y, por lo tanto, una condición de

ataque DoS. Esta amenaza se conoce como un ataque de estado de

multidifusión.

o Un remitente podría intentar convertirse en el PIM DR, enviando saludos

PIM. En tales casos, no se enviaría tráfico hacia o desde la LAN.

o Los paquetes de elección para un BIDIR-PIM DF podrían ser falsificados. En

tales casos, no se enviaría tráfico hacia o desde la LAN.

o Un remitente podría falsificar los mensajes de Auto-RP discovery o BSR

bootstrap. Es suplanador anunciaría efectivamente un RP falso, y reducirá o

interrumpirá un servicio PIM-SM o bidireccional.

o Un remitente podría generar ataques de unidifusión, como el registro de

origen PIM o los mensajes de bloqueo de registros. O podría enviar paquetes

de anuncio BSR y anunciar un falso BSR.

o Un remitente puede enviar a cualquier grupo de multidifusión válido, a

menos que esta actividad se filtre. Si no se evita la falsificación de

direcciones de origen en el borde, el remitente puede usar la dirección IP de

origen de un remitente legítimo y anular contenido en partes del archivo.

o Los intrusos también pueden realizar ataques de multidifusión contra

protocolos de plano de control. Varios protocolos que no están asociados

con la multidifusión, como OSPF y DHCP, utilizan paquetes de multidifusión.

Estos paquetes pueden utilizarse para atacar estos protocolos.

Enmascaramiento: Hay varias formas de ataque por las que un remitente puede

pretender ser otro remitente. La suplantación de IP de origen es una de estas

formas de ataque.

Robo de servicio: A menos que los remitentes sean controlados, los atacantes

pueden usar el servicio de multidifusión ilegítimamente desde el lado del

remitente.

Además, los hosts nunca deben enviar o recibir paquetes PIM. Si lo hacen, es probable que

intenten un ataque. A continuación, se describen las diferentes características que se

utilizan al proteger una red habilitada para multidifusión de fuentes malintencionadas:

Utilice el comando ip multicast boundary para configurar un límite de ámbito

administrativo en una interfaz para filtrar las direcciones de grupo de

multidifusión en el rango definido por el argumento de lista de acceso.

611

Utilice el comando ip pim register-rate-limit para limitar el número de registros

que el enrutador designado (DR) permitirá para cada entrada (S, G). Habilitar este

comando limitará la carga en el DR y el punto de encuentro (RP) a expensas de

dejar caer aquellos mensajes de registro que exceden el límite establecido. Los

receptores pueden experimentar la pérdida de paquetes de datos dentro del

primer segundo en el que los mensajes de registro se envían desde fuentes de

ráfaga.

Utilice el comando ip pim accept-register para evitar que fuentes no autorizadas

puedan registrarse con el RP. Si una fuente no autorizada envía un mensaje de

registro al RP, el RP enviará de inmediato un mensaje de parada de registro.

Utilice el comando ip msdp sa-filter para filtrar los mensajes SA desde o hacia el

par MSDP especificado.

Controles de receptor de multidifusión

Los ataques pueden originarse en receptores multicast, donde es necesario imponer un

nivel de control. Cualquier receptor que envíe un informe IGMP / MLD normalmente

creará un estado en el enrutador de último salto. No existe un mecanismo equivalente en

unicast. Los ataques de receptor pueden tomar tres formas:

Un receptor de multidifusión puede intentar unirse a un flujo sin autorización y

tratar de recibir contenido que no está permitido recibir.

Un receptor de multidifusión puede potencialmente sobrecargar el ancho de banda

de red disponible uniendo demasiados grupos o canales. Este tipo de ataque se

convierte en un ataque de ancho de banda compartido contra otros posibles

receptores de contenido.

Un receptor de multidifusión puede intentar lanzar un ataque contra enrutadores o

switches. Se pueden generar muchos informes IGMP, que pueden crear una gran

cantidad de estado de árbol de multidifusión y potencialmente sobrecargar la

612

capacidad del enrutador. Esta sobrecarga puede resultar en un aumento en el

tiempo de convergencia de multidifusión o en un DoS en el enrutador.

La mayoría de los problemas del receptor caen en el dominio de controlar las

interacciones del protocolo receptor IGMP / MLD. Al filtrar paquetes IGMP o MLD, debe

considerar lo siguiente:

IPv4: IGMP es un tipo de protocolo IPv4.

IPv6: MLD se transporta en paquetes de tipo de protocolo ICMPv6.

El proceso IGMP está habilitado de forma predeterminada en cuanto IP está habilitada.

Los paquetes IGMP también llevan los siguientes protocolos, lo que significa que todos

estos protocolos están habilitados cuando la IP está habilitada:

PIMv1: La primera versión de PIM, PIMv1 siempre está habilitada en el software

Cisco IOS con fines de migración. Las implementaciones actuales usan PIMv2.

Mrinfo: El software IOS de Cisco heredó este comando UNIX para mostrar los

vecinos de multidifusión. Cisco recomienda el uso de SNMP en lugar del comando

mrinfo.

DVMRP: Un protocolo vector - distancia de modo denso tradicional, el Protocolo de

Enrutamiento de Multicast de Distancia Vectorial (DVMRP) tiene características de

escala reducidas. El soporte de Cisco IOS SOFTWARE para DVMRP se está

retirando.

Mtrace: Este protocolo es el equivalente multicast de unicast traceroute y es una

herramienta útil.

Los paquetes IGMP de unidifusión siempre deben filtrarse porque estos son los paquetes

de ataque más probables y no los paquetes de protocolo IGMP válidos. Los paquetes IGMP

unicast admiten enlaces unidireccionales u otras condiciones de excepción.

613

En particular, los hosts nunca deben enviar consultas IGMP porque una consulta enviada

con una versión IGMP inferior puede hacer que todos los hosts que reciben esta consulta

vuelvan a la versión inferior. En presencia de los hosts IGMPv3 y SSM, esta reversión

puede atacar los flujos SSM. En el caso de IGMPv2, esta condición puede resultar en largas

latencias.

Si hay una LAN no redundante con una única consulta IGMP, el enrutador debe eliminar

las consultas IGMP que se reciben. Si existe una LAN pasiva redundante o común, es

necesario un conmutador capaz de realizar inspecciones IGMP. Dos características

específicas pueden ayudar en este caso:

Protector del enrutador (router guard)

Comando para establecer la versión mínima IGMP (igmp mínimum versión)

Controles de admisión de multidifusión

El control de acceso proporciona una respuesta afirmativa o negativa para ciertos flujos,

independientemente del estado de la red. El control de admisión, por el contrario, limita el

número de recursos que los remitentes o receptores pueden utilizar, suponiendo que

pasaron los mecanismos de control de acceso. Varios dispositivos están disponibles para

ayudar con el control de admisión en un entorno de multidifusión.

En el enrutador del lado del receptor, existe la posibilidad de limitar el número de grupos

IGMP unidos tanto globalmente como por interfaz. Las tres principales posibilidades de

control de admisión son las siguientes:

Límites de estado IGMP / MLD (global y por interfaz): Se recomienda que este

límite siempre esté configurado por interfaz y también globalmente. En cada caso,

el límite se refiere a los recuentos de entradas en el caché IGMP.

Límite de mroute por interfaz: Habilitar límites de estado de mroute por interfaz

es una forma más genérica de control de admisión. No sólo limita el estado IGMP y

PIM en una interfaz de salida, sino que también proporciona una forma de limitar el

estado en las interfaces entrantes.

Límites de ancho de banda: puede realizar una subdivisión adicional del ancho de

banda de acceso entre varios proveedores de contenido.

614

Capítulo 25

Diseño de Soluciones

de Control de Acceso a

la Red

615

DESCRIPCIÓN GENERAL DE IEEE 802.1X

IEEE 802.1X es un estándar de la industria que se utiliza para proporcionar control de

acceso a puerto basado en autenticación y autorización. Con la autenticación basada en

puertos IEEE 802.1X, los dispositivos de red tienen las siguientes funciones:

Solicitante (Supplicant): Este rol es un agente o servicio que se ejecuta en el

dispositivo que solicita acceso a la red. Responde a las peticiones del switch.

Autenticador (Authenticator): Los dispositivos de red, como los switches LAN y

los controladores LAN inalámbricos, actúan como autenticadores. Este dispositivo

controla el acceso físico a la red en función del estado de autenticación del cliente.

Las solicitudes del autenticador identifican la información del cliente, verifican la

información con los servidores de autenticación y transmiten la respuesta de los

servidores de autenticación al cliente.

Servidor de autenticación (Authentication server): Esta función realiza la

autenticación real del cliente. El servidor de autenticación valida la identidad del

cliente y notifica al autenticador si el cliente está autorizado a acceder a la red.

Dado que el autenticador actúa como un proxy, el servicio de autenticación es

transparente para el cliente.

Además, con 802.1X, se utilizan principalmente dos métodos para la autenticación:

Certificado digital

Nombre de usuario y contraseña

Por lo tanto, 802.1X ofrece los siguientes beneficios en las redes cableadas:

Visibilidad: 802.1X proporciona mayor visibilidad en la red porque el proceso de

autenticación proporciona una forma de vincular un nombre de usuario con una

dirección IP, una dirección MAC, un conmutador y un puerto. Esta visibilidad es útil

para auditorías de seguridad, forenses de red, estadísticas de uso de red y solución

de problemas.

Seguridad: 802.1X es el método más sólido para la autenticación y debe utilizarse

para activos gestionados que admitan un cliente 802.1X. 802.1X actúa en la capa 2

de la red, lo que le permite controlar el acceso a la red en el borde de acceso.

Servicios basados en identidad: 802.1X le permite aprovechar una identidad

autenticada para ofrecer dinámicamente servicios personalizados. Por ejemplo, un

616

usuario puede ser autorizado en una VLAN específica o asignado una lista de

acceso única que concede acceso adecuado para ese usuario.

Transparencia: En muchos casos, 802.1X se puede implementar de una manera

transparente para el usuario final.

Autenticación de usuario y dispositivo: 802.1X se puede utilizar para autenticar

dispositivos y usuarios.

Aunque 802.1X permite visibilidad y seguridad sin precedentes, su diseño debe abordar

las siguientes limitaciones:

Puntos finales heredados o no compatibles con 802.1X: de forma

predeterminada, 802.1X no proporciona acceso a la red a los puntos finales que no

pueden autenticarse porque no admiten 802.1X o no tienen un suplicante como

una impresora heredada. Mecanismos alternativos como el Bypass de autenticación

de MAC (MAB), en el que se autentica un dispositivo basado en la dirección MAC, o

se debe proporcionar autenticación web para estos puntos finales.

Retraso: De forma predeterminada, 802.1X no permite ningún acceso antes de la

autenticación. Los puntos finales que necesitan acceso inmediato a la red deben ser

capaces de realizar 802.1X en o cerca del tiempo de arranque / conexión, o deben

utilizarse mecanismos alternativos para otorgar el acceso necesario de manera

oportuna.

802.1X utiliza los siguientes protocolos:

Extensible Authentication Protocol (EAP): Este es el formato de mensaje y la

trama definida por RFC 4187; proporciona una forma para que el suplicante y el

617

autenticador negocien un método de autenticación (el método EAP). En otras

palabras, el marco de EAP proporciona un transporte para los parámetros de

autenticación.

Método EAP: este protocolo define el método de autenticación, es decir, el tipo de

credencial y cómo se envía desde el solicitante al servidor de autenticación

mediante el marco de EAP.

EAP sobre LAN (EAPOL): Este método de encapsulación se define por 802.1X para

el transporte de la EAP desde el suplicante al conmutador sobre las redes IEEE 802.

EAPOL es un protocolo de capa 2.

Servicio de usuario de acceso telefónico de autenticación remota (RADIUS):

Este es el estándar de facto para la comunicación entre el conmutador

(autenticador) y el servidor de autenticación. El conmutador extrae la carga útil de

EAP de la trama EAPOL de Capa 2 y encapsula la carga útil dentro de un paquete

RADIUS de Capa 7.

El solicitante o el autenticador pueden iniciar la autenticación. El autenticador inicia la

autenticación cuando el estado del enlace cambia de abajo a arriba, o periódicamente

mientras el puerto permanezca inactivo y no autenticado.

El autenticador envía una solicitud EAP o una trama de identidad al cliente para solicitar

su identidad. Tras la recepción de la trama, el solicitante responde con una respuesta de

EAP o una trama de identidad. Sin embargo, si durante el arranque, el solicitante no recibe

una solicitud de EAP o una trama de identidad del autenticador, el solicitante puede iniciar

una autenticación mediante el envío de una trama de inicio EAPOL. Así indica al

autenticador que solicite la identidad del cliente.

Cuando el suplicante proporciona su identidad, el autenticador comienza su papel como

intermediario y pasa las tramas EAP entre el solicitante y el autenticador hasta que la

autenticación tiene éxito o falla. Si la autenticación tiene éxito, se autoriza el puerto del

autenticador.

El intercambio específico de tramas EAP depende del método de autenticación que se

utiliza.

618

PROTOCOLO DE AUTENTICACIÓN EXTENSIBLE

Un estándar IEEE para el control de acceso basado en puertos utiliza EAP para autenticar

a los usuarios que deseen acceder a la red.

Los mensajes EAP se intercambian entre un suplicante y un servidor de autenticación. Los

mensajes EAP se encapsulan directamente en el protocolo LAN entre un solicitante y un

autenticador que utiliza la encapsulación EAPOL. Están encapsulados en el protocolo

RADIUS entre un autenticador y un servidor de autenticación. El autenticador actúa como

un proxy entre un suplicante y un servidor de autenticación y no participa activamente en

la comunicación. En su lugar, espera la decisión del servidor de autenticación, que se le

comunica de forma nativa a través del protocolo RADIUS.

EAP proporciona autenticación bidireccional entre el cliente y el servidor de

autenticación. Muchos métodos de autenticación (algunos de ellos híbridos) son posibles,

y admiten muchos tipos de credenciales. La principal ventaja de EAP es que es extensible

para implementar casi cualquier proceso de autenticación.

Los dos tipos de arquitecturas EAP son los siguientes:

EAP sin túnel: En la arquitectura EAP sin túnel, existe una única sesión entre el

solicitante y el servidor de autenticación. El suplicante envía su identidad en texto

plano al servidor de autenticación. El siguiente paso es el intercambio de mensajes,

que autentica el servidor de autenticación al usuario y al usuario a los servidores

de autenticación.

619

Túnel EAP: En la arquitectura de túnel EAP, el EAP exterior encapsula un EAP

interno. El EAP externo proporciona al servidor autenticación y un túnel

criptográficamente seguro para que se ejecute el método EAP interno.

Tipo de

EAP

EAP-MD5

Evite usarlo.

Vulnerable a los

ataques de hombreen-el-medio.

Utilícelo en entornos

de Active Directory.

EAP-

MSCHAPv2

EAP-TLS

EAP-GTC

Modo

Sin

túnel

Sin

túnel

Sin

túnel

Sin

túnel

Protocolo de

autenticación

Respuesta de

desafío con

hashing

Respuesta de

desafío con

hashing

Desafío de

respuesta con

claves públicas

Transferencia de

contraseñas de

texto claro

EAP-FAST Túnel Respuesta de

desafío con

criptografía

simétrica

PEAP Túnel Respuesta de

desafío con

criptografía de

clave pública

Credenciales compatibles

Contraseñas para la

autenticación del cliente;

sin autenticación de

servidor

Contraseña para la

autenticación del cliente y

del servidor

Certificados de

autenticación de cliente y

servidor

Contraseñas u OTPs para

la autenticación del cliente

Contraseñas u OTPs para

el cliente y contraseñas

para la autenticación del

servidor

Certificados de

autenticación del lado del

servidor de; Otras

credenciales dentro de los

protocolos tunelizados

PEAP

Cuándo usar

Utilizar con

certificados del lado

del cliente.

Utilícelo en el entorno

de OTP.

Utilizar para dar

soporte a contraseñas

planas como

credenciales de

cliente y servidor

Utilice para tunelizar

otras variaciones

internas de EAP:

EAPMS-CHAPv2 o

EAP-GTC.

EAP permite la autenticación de usuario o máquina. La autenticación tradicional de la

máquina y del usuario funciona tratando a la máquina y al usuario como dos entidades

620

separadas e independientes. La autenticación de usuario se realiza cuando el usuario

inicia sesión. Cuando el usuario cierra la sesión, se realiza la autenticación de la máquina.

Todos los suplicantes comunes, como AnyConnect o Windows supplicant nativo, admiten

estas dos opciones de autenticación.

Una opción más avanzada es usar el encadenamiento EAP (EAP chaining). Soporta la

autenticación de máquina y de usuario dentro de un único túnel TLS (Transport Layer

Security). Le permite combinar los resultados de la máquina y la autenticación de usuario

en un solo resultado de autenticación general. Por ejemplo, puede asignar mayores

privilegios a los usuarios que se conectan a la red mediante equipos administrados por la

empresa.

El encadenamiento EAP se implementó por primera vez en el protocolo de autenticación

extensible: autenticación flexible mediante túnel seguro (EAP-FASTv2), que es una

solución de Cisco. El Internet Engineering Task Force (IETF) está trabajando en una

solución similar, que se llama Tunnel Extensible Authentication Protocol (TEAP).

SUPLICANTES 802.1X

Cisco AnyConnect Secure Mobility es un software que incluye módulos para VPN, acceso a

la red, seguridad web y otros. El módulo que se utiliza para proporcionar servicios de

acceso a la red se denomina Network Access Manager.

621

Network Access Manager proporciona la administración y autenticación de dispositivos de

Nivel 2 para el acceso tanto a redes cableadas como inalámbricas. Permite a las

organizaciones implementar un único marco de autenticación 802.1X para acceder tanto a

redes cableadas como inalámbricas. También puede administrar la identidad de usuario y

dispositivo y los protocolos de acceso a la red.

Network Access Manager admite los siguientes métodos EAP:

EAP-TLS

EAP con soporte para los métodos internos EAP-TLS, EAP-MS-CHAPv2 y EAP-GTC

EAP-FAST con soporte para los métodos internos EAP-TLC, EAP-MS-CHAPv2 y

EAP-GTC

EAP-TTLS con soporte para los métodos internos PAP, CHAP, MS-CHAP, MS-

CHAPv2, EAP-MD5 y EAP-MS-CHAPv2

Para combinar la autenticación de usuario y máquina en un resultado de autenticación,

Network Access Manager admite EAP-Chaining (EAP-FASTv2). En este modo, puede

diferenciar el acceso basado en activos empresariales y no empresariales. Network Access

Manager sólo se admite en Windows en el cliente AnyConnect de Cisco versión 4.0.

También puede utilizar suplicante nativo 802.1X en Windows. Windows ofrece

aplicaciones separadas para acceso alámbrico e inalámbrico. Los suplicantes nativos

apoyan todos los métodos EAP más comunes como PEAP, EAP-FAST y otros. EAP-Chaining

no es compatible actualmente.

IMPLEMENTACIÓN EN FASES DE IEEE 802.1X

IEEE 802.1X se puede implementar utilizando un modelo de despliegue en fases que

permite un impacto limitado en el acceso a la red mientras se introduce la autenticación y

la autorización. En el enfoque por fases, los administradores de red pueden obtener

visibilidad sobre quién tendrá éxito y quién fallará, determinará el motivo del fallo y

solucionará el problema antes de habilitar un modo de imposición más estricto.

Los siguientes son los tres modos de despliegues en fases:

Monitoreo

Bajo impacto

Cerrado

622

El despliegue de fase comienza con un modo de monitoreo y luego cambia a un modo de

bajo impacto o un modo cerrado. El modo de monitoreo permite la implementación de los

métodos de autenticación sin ningún efecto sobre el usuario o punto final al acceder a la

red. El modo de monitoreo está habilitado usando 802.1X con acceso abierto y modo

multiauth. La función de acceso abierto le permite proporcionar acceso sin restricciones a

todo el tráfico, aunque la autenticación esté habilitada.

Con el modo de bajo impacto, la seguridad se mejora añadiendo una lista de control de

acceso de entrada (ACL) a los puertos habilitados para 802.1X. Estos puertos se

configuran en el modo abierto. La ACL controla qué tráfico se permite para hosts no

autenticados. Por ejemplo, puede permitir el uso de DHCP o DNS y el acceso a Internet, al

tiempo que bloquea el acceso a los recursos internos. Cuando se autentica un puerto,

puede aplicar la directiva de autorización adecuada.

El comportamiento predeterminado en el Cisco switchport que está configurado para

802.1X es el modo cerrado, en el que sólo se permite el tráfico EAPOL hasta que finalice el

proceso de autenticación. Cuando se completa la autenticación, puede aplicar la directiva

de autorización adecuada.

CISCO TRUSTSEC

Los usuarios finales utilizan muchos tipos de dispositivos, incluidos ordenadores

portátiles, teléfonos inteligentes y tabletas, para conectarse a la red con cable, de forma

inalámbrica y remota a través de VPN. Con el acceso a su propio dispositivo (BYOD), los

dispositivos pueden ser personales o de propiedad corporativa. Cada empresa tiene

políticas que dictan quién puede acceder a qué aplicaciones y bases de datos, cuándo y

cómo. Tradicionalmente, la TI administra la política introduciendo dispositivos en los

puntos del campus donde los usuarios se conectan o configurando manualmente todos los

conmutadores de acceso. Los aparatos incurren en gastos adicionales de capital y de

operación, mientras que la configuración manual de los switches requiere el

mantenimiento de cada switch. Además, la red puede transportar tráfico utilizando

623

Ethernet, IPv4, IPv6 u otras tecnologías, por lo que la configuración debe mantenerse al

día con los cambios en la tecnología, lo que lleva a una mayor complejidad y costos

operacionales.

Cisco TrustSec simplifica el suministro y la gestión del acceso seguro a los servicios y

aplicaciones de red. En comparación con los mecanismos de control de acceso basados en

la topología de red, Cisco TrustSec define políticas que utilizan grupos de políticas lógicas.

Por esta razón, el acceso seguro se mantiene de manera consistente incluso cuando los

recursos se mueven en redes móviles y virtualizadas.

De hecho, Cisco TrustSec, como una solución de control de acceso inteligente, mitiga los

riesgos de seguridad proporcionando una visibilidad completa de quién y qué se conecta a

través de toda la infraestructura de red y controla sobre qué y a dónde pueden ir. Además

de combinar modelos basados en estándares de identidad y aplicación, como el IEEE

802.1X y el control de VLAN, el sistema TrustSec también incluye capacidades avanzadas

de identidad y cumplimiento como autenticación flexible, listas de control de acceso

descargables (dACL), Security Group Tagging (SGT), perfiles de dispositivos, evaluaciones

de postura y más.

Servicio de perfiles

El servicio de perfiles es una de las capacidades avanzadas de identidad y aplicación de

Cisco TrustSec que proporciona detección dinámica y clasificación de puntos finales

conectados a la red. Utilizando direcciones MAC como identificadores únicos, el motor de

servicios de identidad de Cisco (ISE) recopila varios atributos para cada punto final de red

para crear una base de datos de punto final interno. El proceso de clasificación coincide

con los atributos recopilados con las condiciones reconstruidas o definidas por el usuario,

que luego se correlacionan con una extensa biblioteca de archivos. Estos perfiles incluyen

una amplia gama de tipos de dispositivos, incluyendo clientes móviles (iPads, tablets

Android, teléfonos BlackBerry, etc.), sistemas operativos de escritorio (por ejemplo,

Windows, Mac OS X, Linux y otros) y numerosos sistemas no usuarios como impresoras,

teléfonos, cámaras y consolas de juegos.

624

Una vez clasificados, los puntos finales se pueden autorizar a la red y se les otorga acceso

basándose en su perfil. Por ejemplo, los puntos finales que coinciden con el perfil de

teléfono IP se pueden colocar en una VLAN de voz utilizando Autenticación MAC y Bypass

(MAB) como método de autenticación. Otro ejemplo es proporcionar acceso de red

diferenciando a los usuarios basado en el dispositivo utilizado. Por ejemplo, los empleados

pueden obtener acceso completo cuando acceden a la red desde su estación de trabajo

corporativa, pero se les concede acceso limitado a la red al acceder a la red desde su

iPhone personal.

Etiqueta de grupo de seguridad

Siendo parte de la arquitectura Cisco TrustSec, Cisco Security Group Tag (SGT) es una

tecnología que supera las deficiencias de los enfoques tradicionales de administración de

políticas. Cuando un usuario se conecta a la red e intenta acceder a una aplicación, el

conmutador de acceso de Cisco perfila automáticamente al usuario y descubre el ID del

usuario, el dispositivo que se está utilizando, la ubicación y la hora de acceso. A

continuación, el conmutador etiqueta todo el tráfico procedente del dispositivo del

usuario basado en la política de TI del perfil del usuario. La etiqueta es un valor numérico

y se asigna manualmente a los conmutadores de acceso o se administra automáticamente

a través de la aplicación de Cisco Identity Services Engine (ISE). Si se utiliza ISE de Cisco,

se transmite la información de la etiqueta a todos los dispositivos Cisco admitidos en la

red (configuración centralizada y aprovisionamiento).

Cisco TrustSec clasifica el tráfico basado en la identidad contextual del punto final frente a

su dirección IP. Esto significa que una etiqueta de grupo de seguridad de políticas de Cisco

TrustSec (SGT) se asigna a un punto final normalmente basado en los atributos de usuario,

dispositivo y ubicación de dicho punto final (perfiles predefinidos). El SGT denota los

derechos de acceso al punto final y todo el tráfico del punto final llevará la información

SGT. Los conmutadores, enrutadores y firewalls utilizan SGT para tomar decisiones de

reenvío basadas en una política de seguridad.

625

Las características asociadas con los SGT en los dispositivos de red pueden dividirse en

tres categorías:

Clasificación

Transporte

Aplicación

Clasificación es la asignación de SGT a una dirección IP, que puede realizarse de forma

dinámica o estática. La clasificación dinámica se realiza típicamente en la capa de acceso y

se puede hacer usando una solución de control de acceso a la red tal como 802.1X. El SGT

se asigna mediante la autorización del punto final. La clasificación estática se utiliza

típicamente en el centro de datos y se configura en el conmutador al que se conectan los

servidores. Las opciones para la clasificación estática incluyen la asignación de la

dirección IP, VLAN o puerto a un SGT.

Las asignaciones de grupos de seguridad siguen el tráfico a través de la red, lo que se

puede realizar mediante el etiquetado en línea o el protocolo de intercambio de etiquetas

de grupo de seguridad (SXP). Con el etiquetado en línea, el SGT se incrusta en el

encabezado de trama Ethernet. Debido a que no todos los dispositivos de red admiten el

etiquetado en línea, SXP puede utilizarse para transportar aplicaciones SGT en estos

dispositivos.

La aplicación está implementando una autorización o denegación de una decisión de

política que se basa en los SGT de origen y de destino. Puede realizarse con listas de

control de acceso de grupo de seguridad (SGACL) en plataformas de conmutación y

Security Group Firewall (SGFW) en las plataformas de enrutamiento y firewall.

Por ejemplo, en el escenario ilustrado en la Figura, el equipo de seguridad de TI estableció

una directiva de acceso en el motor de servicios de identidad de Cisco (ISE, Cisco Identity

Services Engine), indicando que el grupo de marketing no puede acceder a la aplicación

financiera. Cuando una persona de marketing conecta una computadora portátil o tableta

a la red, ISE utiliza credenciales de Active Directory para autenticar al usuario. ISE

entonces asigna una etiqueta, por ejemplo, 20 para el grupo de marketing. El conmutador

626

de acceso y el controlador de LAN inalámbrica (WLC) reciben la etiqueta 20 del ISE y la

añaden a cada paquete procedente del dispositivo del usuario. El paquete atraviesa la red

con la etiqueta 20. Si el usuario intenta conectarse a la aplicación financiera / base de

datos, que sólo permite una etiqueta de 10, el conmutador de acceso conectado al servidor

rechazará la solicitud. Si el usuario de marketing cambia el rol a finanzas, el grupo de

usuarios del usuario cambiará en base a Active Directory y se podrá acceder a una

aplicación sin que TI tenga que programar todas los switches de acceso. Todo el proceso

de autenticación y ejecución es automático. Del mismo modo, en este ejemplo, la

aplicación financiera ha recibido el valor SGT 30, el cual está bloqueado en la capa de

distribución (VSS) del usuario para comunicarse con las subredes de los usuarios de

marketing (cableado e inalámbrico) para prevenir también cualquier flujo de tráfico

proveniente de esta aplicación.

627

Designing Cisco Network Service Architectures

Create successful ePaper yourself

Delete template?

Save as template?