Capítulo 1. Introducción a MPLS y SDN
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Este capítulo presenta los conceptos básicos de la Conmutación de Etiquetas Multiprotocolo (MPLS) y las Redes Definidas por Software (SDN). Estas tecnologías nacieron por una razón, y una muy buena forma de situarlas en el contexto adecuado es comprender su historia. Por ejemplo, aunque el MPLS tiene innumerables aplicaciones y casos de uso hoy en día, se concibió originalmente para resolver un problema muy concreto en Internet.
Internet
Internet es un conjunto desistemas autónomos(SA) . Cada AS es una red operada por una única organización y tiene conexiones de enrutamiento con uno o más AS vecinos.
Los números de AS comprendidos entre el 64512 y el 65534 están reservados para uso privado. Aunque los ejemplos de este libro utilizan números de AS de este rango, en la vida real, los Proveedores de Servicios de Internet (ISP) utilizan números de AS públicos para comunicarse con sus AS vecinos.
Tradicionalmente, los números de AS tenían una longitud de 16 bits (2 bytes), pero las nuevas implementaciones del protocolo también admiten números de AS de 32 bits (4 bytes) de longitud.
La Figura 1-1 ofrece una visión muy simplificada de Internet. Aquí vamos a echar un vistazo a Annika, una usuaria de Internet cualquiera. Vive en Europa, tiene una conexión a Internet por cable en casa y trabaja en una gran empresa que también está conectada a Internet. Da la casualidad de que la empresa que emplea a Annika tiene su propio número AS (65001), lo que no es un requisito para el acceso corporativo a Internet. Casualmente, esta empresa está conectada a Internet a través del mismo ISP (AS 65000) que Annika utiliza para su acceso residencial.
Figura 1-1. Internet: un día en la vida de Annika
Como se muestra en la figura, Annika tiene dos amigos que también están abonados al ISP:
-
Ruijiao vive en Oceanía y se conecta con su teléfono móvil a AS 65100.
-
Luis vive en Sudamérica y se conecta con su portátil a AS 65005.
Annika también utiliza los servicios de nube pública de un proveedor de África (65201) y consume contenidos de distintos proveedores de Asia (AS 65510), Europa (AS 65002) y Norteamérica (AS 64900).
La Figura 1-1 muestra diferentes tipos de proveedores. La lista que sigue describe cada uno de ellos:
- ISP nacionales
- En este ejemplo, las conexiones a Internet residencial y corporativa de Annika pasan por un ISP nacional (AS 65000) que proporciona acceso a Internet en un país, estado o región concretos. Del mismo modo, Ruijiao y Luis también están conectados a Internet a través de ISP nacionales (AS 65100 y AS 65005, respectivamente).
- ISP globales
- 101.230Los ISP nacionales a los que están conectados Annika (AS 65000) y Luis (AS 65005) pertenecen al mismo grupo ISP global, que tiene presencia en varios países de Europa y América. Este ISP global utiliza una red específica (AS 65010) para interconectar entre sí a todos los ISP nacionales del grupo. Además, los ISP globales también conectan a sus ISP domésticos con el resto del mundo.
- Proveedores de contenidos y de la nube
- Estos proveedores de servicios (PS) no generan ingresos cobrando a los abonados por el acceso a Internet. En su lugar, ofrecen otros tipos de servicios a los usuarios de todo el mundo. Por ejemplo, ofrecen servicios multimedia, de alojamiento, en la nube, etc.
- Proveedores de transporte
- Suelen ser grandes redes de nivel 1 que constituyen el esqueleto de Internet. Sus clientes son otros SP. Si dos SP no están conectados directamente, suelen llegar el uno al otro a través de uno o más proveedores de tránsito.
En la práctica, esta clasificación es un poco confusa. La mayoría de los SP intentan diversificar sus carteras obteniendo una parte de más de uno de estos mercados.
Hay otro dato clave en la Figura 1-1: los enlaces que interconectan AS tienen routers en sus extremos. Presta atención a los iconos utilizados para Junos e IOS XR porque esta convención se utiliza en todo este libro.
Un router situado en la frontera de un AS y que conecta con uno o varios AS externos se denomina AS Border Router (ASBR ). Los ASBR de Internet se comunican entre sí mediante el Protocolo de Pasarela Fronteriza (BGP), descrito en el RFC 4271. BGP se ejecuta sobre el Protocolo de Control de Transmisión (TCP); se denomina BGP externo (eBGP) si los puntos finales de la sesión están en AS diferentes. Internet eBGP se encarga de distribuir las tablas de enrutamiento globales IPv4 e IPv6. La primera ya contiene más de medio millón de prefijos y está en continuo crecimiento.
Y esto es Internet: algunos ladrillos (AS), enlaces y un protocolo (eBGP) que distribuye la información de encaminamiento por todo el mundo. La Figura 1-1 es una representación simplista de Internet; en realidad, se parece más a la Figura 1-2.
Figura 1-2. Internet en 2011: topología de sistemas autónomos (copyright © Peer1 Hosting; utilizado con permiso)
Esta magnífica imagen, proporcionada por su propietario, Peer1 Hosting, representa a los AS como nodos. La descripción que Peer1 hace de la imagen es la siguiente:
Esta imagen muestra un gráfico de 19.869 nodos de AS unidos por 44.344 conexiones. El tamaño y la disposición de los EA se basan en su centralidad eigenvectorial, que es una medida de lo central que es cada EA en la red: un EA es central si está conectado a otros EA que son centrales. Se trata del mismo concepto teórico de grafos que constituye la base del algoritmo PageRank de Google.
La disposición del grafo comienza con los nodos más centrales y avanza hacia los menos, colocándolos en una cuadrícula que se subdivide tras cada orden de magnitud de centralidad. Dentro de las limitaciones del nivel de subdivisión actual, los nodos se colocan lo más cerca posible de los nodos colocados anteriormente con los que están conectados.
Nota
Hasta aquí, esta descripción de Internet no está relacionada con MPLS. Para entender la motivación original del MPLS, tienes que mirar dentro de un AS.
Tomémonos el tiempo necesario para comprender la topología que se utilizará en los ocho primeros capítulos de este libro. Es una inversión de tiempo que merece la pena.
Ejemplo de topología ISP
Esta topología se basa en el ejemplo anterior. Annika está trabajando, y su portátil es H1. En un momento dado, se da cuenta de que necesita recuperar algunos datos del proveedor (más concretamente de H3).
Nota
Por el momento, olvidémonos de la Traducción de Direcciones de Red (NAT) e imaginemos que todas las direcciones son realmente públicas.
Figura 1-3. Topología ISP básica
Más de la mitad de los escenarios de laboratorio creados para este libro se ejecutan en un único servidor. El hipervisor generó máquinas virtuales (VM) que ejecutaban Junos o IOS XR, conectadas internamente a través de un vSwitch/vRouter.
Alrededor de cada router, puedes ver números en círculos. Son los números de interfaz de red. Por ejemplo, si el número dentro del círculo es <#>, el número de puerto real es el siguiente:
-
En los dispositivos que ejecutan Junos, ge-2/0/<#>
-
En dispositivos con IOS XR, Gi 0/0/0/<#>
Esta convención se utiliza en todo el libro.
Todos los enlaces entre routers son punto a punto (/31), excepto la conexión multipunto 10.2.0.0/24. Aunque esta última topología se puede encontrar en el acceso a la WAN, se está considerando progresivamente como heredada. De momento, pensemos en estas LAN como las clásicas subredes /24 IPv4 e ignoremos cómo se instancian realmente.
El ISP de este ejemplo ejecuta un único dominio IS-IS de Nivel 2 con interfaces punto a punto. Los enlaces PE1-PE2 y PE3-PE4 están configurados con la métrica IS-IS simétrica 100, y los enlaces centrales restantes (PE-P y P-P) se dejan con la métrica IS-IS por defecto 10. Estas métricas se representan entre corchetes en la Figura 1-3.
Advertencia
Asegúrate de que los RR están configurados con el bit de sobrecarga IS-IS o con métricas altas de Open Shortest-Path First (OSPF) para que no atraigan tráfico de tránsito.
Tipos de router en un proveedor de servicios
Aunque a primera vista parecen similares, la Empresa (AS 65001) y el Proveedor de Contenidos (AS 65002) desempeñan un papel diferente desde la perspectiva del ISP (AS 65000):
-
La Empresa es un cliente corporativo que paga al ISP por el acceso a Internet. Puede estar conectada a más de un ISP por redundancia, pero en general la relación entre la empresa y el ISP es la tradicional entre cliente y proveedor.
-
El Proveedor de Contenidos tiene una relación de peering con varios ISP, como AS 65000, AS 64777 y otros. El modelo de negocio es más complejo y no existe una relación clara cliente-proveedor: los SP llegan a acuerdos sobre cómo facturar el tráfico.
Los dispositivos de la Figura 1-3 desempeñan diferentes funciones desde la perspectiva de la AS 65000, que exploraremos en los apartados siguientes.
Equipo del cliente
Los CE1 y CE2 de la Figura 1-3 son Equipos en las Instalaciones del Cliente (CPE), también conocidos como equipos del cliente (CE). Tradicionalmente, están ubicados físicamente en las instalaciones del cliente. En la era SDN, también es posible virtualizar algunas de sus funciones y ejecutarlas en la red SP: esta solución se denomina CPE virtual o vCPE.
De momento, pensemos en los CE tradicionales que están en la red de un cliente. El funcionamiento y la gestión del CE pueden ser responsabilidad del ISP o del cliente, o de ambos. Podemos clasificar los CE de la siguiente manera:
- Residencial
- Pueden ser módems DSL, ONTs FTTH, etc. No ejecutan ningún protocolo de encaminamiento y son vistos por la capa IP del ISP como conectados directamente.
- Móvil
- Se trata de teléfonos inteligentes, tabletas, etc. Tampoco ejecutan ningún protocolo de encaminamiento y son vistos por la capa IP del ISP como conectados directamente.
- Organización
- Son routers físicos o virtuales dedicados que pueden (o no) implementar un conjunto adicional de funciones de red de valor añadido. Suelen tener enrutamiento estático o dinámico hacia el ISP. eBGP es el protocolo dinámico más utilizado -y el más escalable-. Si la organización es multihomed con varios ISP, eBGP es sencillamente la única opción razonable.
Nota
La organización puede ser una empresa externa, un departamento interno del ISP, una institución gubernamental, un campus, una ONG, etc.
Ahora, veamos las distintas funciones que realizan los routers del núcleo (backbone) del ISP (AS 65000): PE1, PE2, P1, P2, PE3 y PE4.
El perímetro núcleo-proveedor
El perímetro del proveedor (PE) es una función de perímetro realizada por dispositivos de red central propiedad del ISP que tienen tanto conexiones externas con los CE como conexiones internas con otros routers centrales. Los PE1 y PE2 de la Figura 1-3 desempeñan la función de PE cuando reenvían tráfico entre los CE y otros routers centrales.
El proveedor principal
Proveedor (P) es una función central realizada por routers centrales propiedad de un ISP que tienen conexiones troncales internas con más de un router central. P1 y P2 son routers P puros porque no tienen conexiones con proveedores externos ni con clientes. En cuanto a PE1, PE2, PE3 y PE4, pueden desempeñar la función P cuando reenvían tráfico entre dos interfaces del núcleo. Por ejemplo, si PE1 recibe un paquete en ge-2/0/3 y lo envía por ge-2/0/4, está actuando como enrutador P.
La frontera-ASBR
ASBR es una función de perímetro realizada por routers centrales propiedad de un ISP que establecen peering eBGP externo con otros SP. Aunque PE1 y PE2 pueden establecer sesiones eBGP con CE1 y CE2, no se consideran ASBR, porque el peer remoto es un cliente, no un SP.
Por otro lado, PE3, PE4, BR1 y BR2 son ASBR, y realizan esa función cuando reenvían tráfico entre interfaces externas e internas. Por ejemplo, si PE3 recibe un paquete en ge-2/0/1 y lo envía a ge-2/0/3, se está comportando como un ASBR.
El Proveedor de Contenidos (AS 65002) de la Figura 1-3 tiene una red demasiado simplificada. Esto está bien, ya que aquí nos centramos en el ISP (AS 65000).
Anfitriones
El propósito de los hosts (H) H1 y H3 en este ejemplo es ejecutar ping y traceroute, por lo que su SO no es muy relevante. En este ejemplo, estos hosts son máquinas virtuales que ejecutan IOS XR; de ahí el icono de router para un host.
H1 pertenece a la intranet del cliente, y H3 está conectada al núcleo del proveedor de contenidos. Ni H1 ni H3 ejecutan protocolos de encaminamiento.
Configuración de BGP
El Sistema Intermedio a Sistema Intermedio (IS-IS) proporciona conectividad loopback-a-loopback dentro del ISP, necesaria para establecer las sesiones BGP internas multisalto (iBGP).
La Figura 1-4 muestra las sesiones BGP y sus puntos finales: direcciones de loopback para iBGP, y direcciones de enlace en la frontera (eBGP).
Figura 1-4. Sesiones eBGP e iBGP de Internet
Configuración de BGP-PEs y ASBRs que ejecutan Junos
El Ejemplo 1-1 muestra la configuración BGP en PE1.
Ejemplo 1-1. Configuración de BGP en PE1 (Junos)
1 routing-options {
2 autonomous-system 65000;
3 }
4 protocols {
5 bgp {
6 group iBGP-RR {
7 type internal;
8 local-address 172.16.0.11;
9 family inet {
10 unicast {
11 add-path {
12 receive;
13 send {
14 path-count 6;
15 }
16 }
17 }
18 }
19 export PL-iBGP-RR-OUT;
20 neighbor 172.16.0.201;
21 neighbor 172.16.0.202;
22 }
23 group eBGP-65001 {
24 family inet {
25 unicast;
26 }
27 peer-as 65001;
28 neighbor 10.1.0.0 {
29 export PL-eBGP-65001-CE1-OUT;
30 }
31 neighbor 10.1.0.6 {
32 export PL-eBGP-65001-CE2-OUT;
33 }
34 }
35 }
36 }
37 policy-options {
38 policy-statement PL-iBGP-RR-OUT {
39 term NHS {
40 from family inet;
41 then {
42 next-hop self;
43 }
44 }
45 }
46 policy-statement PL-eBGP-65001-CE1-OUT {
47 term BGP {
48 then {
49 metric 100;
50 }
51 }
52 }
53 policy-statement PL-eBGP-65001-CE2-OUT {
54 term BGP {
55 then {
56 metric 200;
57 }
58 }
59 }
60 }
PE1 y PE3 tienen una configuración similar. La diferente relación comercial con los proveedores de peering no cambia el hecho de que el protocolo sea el mismo: eBGP.
Las líneas 6 a 22 contienen la configuración de bucle de retorno a bucle de retorno para las sesiones iBGP PE1-RR1 y PE1-RR2. La funcionalidad Añadir Ruta (líneas 11 a 16) se explicará más adelante.
Cuando un router vuelve a anunciar un prefijo en iBGP, no cambia por defecto el atributo original del siguiente salto BGP. Así, si PE1 anuncia la ruta 10.1.12.0/24 a los RR, el siguiente salto BGP de la ruta es 10.1.0.0. Este siguiente salto no es alcanzable desde dentro del ISP -por ejemplo, desde PE3 y PE4-, lo que hace que la ruta BGP sea inútil. La solución más limpia es hacer que PE1 reescriba el atributo de siguiente salto BGP en su propio loopback (líneas 19, y líneas 38 a 45) antes de anunciar la ruta a través de iBGP.
Las líneas 23 a 34 contienen la configuración eBGP de un solo salto PE1-CE1 y PE1-CE2. Las políticas de ruta eBGP (líneas 29, 32 y 46 a 59) se explicarán en breve.
Configuración de BGP-RRs con Junos
Esta configuración BGP en RR1 es muy similar a la de PE1, pero tiene una diferencia clave, como se demuestra en el Ejemplo 1-2, cuyos vecinos se omiten por brevedad.
Ejemplo 1-2. Configuración de BGP en RR1 (Junos)
1 protocols {
2 bgp {
3 group iBGP-CLIENTS {
4 cluster 172.16.0.201;
5 }}}
Lo que convierte a RR1 en un Reflector de Rutas es la línea 4; sin ella, se aplicaría la regla iBGP por defecto: las rutas iBGP no se deben anunciar a través de iBGP.
El peering con el otro RR (RR2) está configurado como neighbor en un group diferente que no contiene la declaración cluster.
Configuración BGP-PEs y ASBRs ejecutando IOS XR
PE2 y PE4 tienen una configuración similar. El Ejemplo 1-3 presenta la de PE2.
Ejemplo 1-3. Configuración de BGP en PE2 (IOS XR)
1 router bgp 65000 2 address-family ipv4 unicast 3 additional-paths receive 4 additional-paths send 5 ! 6 neighbor-group RR 7 remote-as 65000 8 update-source Loopback0 9 address-family ipv4 unicast 10 route-policy PL-iBGP-RR-OUT out 11 ! 12 neighbor 10.1.0.2 13 remote-as 65001 14 address-family ipv4 unicast 15 route-policy PL-eBGP-65001-IN in 16 route-policy PL-eBGP-CE2-OUT out 17 ! 18 neighbor 10.1.0.4 19 remote-as 65001 20 address-family ipv4 unicast 21 route-policy PL-eBGP-65001-IN in 22 route-policy PL-eBGP-CE1-OUT out 23 ! 24 neighbor 172.16.0.201 25 use neighbor-group RR 26 ! 27 neighbor 172.16.0.202 28 use neighbor-group RR 29 ! 30 ! 31 route-policy PL-iBGP-RR-OUT 32 set next-hop self 33 end-policy 34 ! 35 route-policy PL-eBGP-CE1-OUT 36 set med 200 37 pass 38 end-policy 39 ! 40 route-policy PL-eBGP-CE2-OUT 41 set med 100 42 pass 43 end-policy 44 ! 45 route-policy PL-eBGP-65001-IN 46 pass 47 end-policy
La sintaxis es diferente, pero los principios son muy similares a los de Junos. La funcionalidad Añadir Ruta (líneas 3 a 4) se explicará más adelante.
Una diferencia notable entre la implementación de BGP de Junos e IOS XR es que IOS XR bloquea por defecto la recepción y el anuncio de rutas a través de eBGP. Hay dos formas alternativas de cambiar este comportamiento por defecto:
-
Configura explícitamente las políticas de entrada y salida (líneas 15 a 16, 21 a 22 y 35 a 47) para permitir que IOS XR señale rutas eBGP.
-
Configurar
router bgp 65000 bgp unsafe-ebgp-policy. Se trata de un atajo que puedes utilizar para una configuración rápida, especialmente útil en el laboratorio. Este comando crea y adjunta automáticamente las políticas "pasar todos
Nota
Debido a las limitaciones de espacio, a partir de este punto, los ejemplos de configuración de Junos e IOS XR pueden representarse con líneas fusionadas.
Configuración de BGP-RRs ejecutando IOS XR
La configuración BGP en el RR2 mostrada en el Ejemplo 1-4 es muy similar a la del PE2, pero tiene algunas diferencias.
Ejemplo 1-4. Configuración de BGP en RR2 (IOS XR)
1 router bgp 65000 2 address-family ipv4 unicast 3 additional-paths receive 4 additional-paths send 5 ! 6 neighbor-group iBGP-CLIENTS 7 cluster-id 172.16.0.202 8 address-family ipv4 unicast 9 route-reflector-client 10 !
Lo que hace que RR2 sea un Reflector de Rutas son las líneas 7 y 9; sin ellas, se aplicaría la regla iBGP por defecto: las rutas iBGP no deben ser anunciadas de nuevo a través de iBGP.
El peering con el otro RR (RR1) no está configurado a través de este neighbor-group.
Señalización y redundancia de rutas BGP
Este libro considera tres modelos de redundancia BGP -No redundante, Activo-Respaldo y Activo-Activo- y todos ellos son compatibles con la topología de la Figura 1-3.
Rutas BGP no redundantes
En este ejemplo, los CEs y BRs anuncian sus propios loopacks a un único peer eBGP:
-
CE1 anuncia 192.168.10.1/32 sólo a PE1.
-
CE2 anuncia 192.168.10.2/32 sólo a PE2.
-
BR3 anuncia 192.168.20.3/32 sólo a PE3.
-
BR4 anuncia 192.168.20.4/32 sólo a PE4.
Si falla una sesión eBGP, el loopback del CE o BR afectado deja de ser alcanzable a través del AS 65000. Este escenario es frecuente en topologías de acceso single-homed. En este ejemplo, se simula bloqueando selectivamente el anuncio de loopback local de CE1 y CE2 (políticas de exportación eBGP), y configurando sólo una sesión eBGP en cada BR.
La Figura 1-5 muestra el proceso de señalización de ruta loopback de CE1.
Figura 1-5. Señalización de rutas eBGP e iBGP en Internet - loopback CE1
El bucle de retorno de CE1 está conectado en single-homed a PE1, por lo que un paquete que cualquier dispositivo de AS 65002 envíe al bucle de retorno de CE1 deberá pasar por PE1 en algún momento.
Los RR no cambian el valor de los atributos BGP siguiente salto y ruta AS cuando reflejan la ruta a PE2, PE3 y PE4.
Por otro lado, PE2 no anuncia la ruta a CE2, porque daría lugar a un bucle de AS. Este comportamiento, que puedes cambiar utilizando el comando de configuración as-override, se explica con más detalle en el Capítulo 3.
La Figura 1-6 muestra el proceso de señalización de la ruta loopback de BR4.
Figura 1-6. Señalización de rutas eBGP e iBGP de Internet-B loopback de BR4
El bucle de retorno de BR4 está conectado en single-homed a PE4, por lo que un paquete que cualquier dispositivo del AS 65001 envíe al bucle de retorno de BR4 deberá pasar por PE4 en algún momento.
Hay un nivel de redundancia adicional en el lado izquierdo de la Figura 1-6. CE1 prefiere llegar a BR4 a través de PE1 (Multi Exit Discriminator [MED] 100 es mejor que MED 200), pero si falla la sesión eBGP CE1-PE1, aún puede conmutar por error a PE2.
En ausencia de fallos en el enlace de acceso:
Copia de seguridad activa de rutas BGP
Como puedes ver en la Figura 1-7, tanto BR3 como BR4 anuncian la ruta 10.2.34.0/24, pero lo hacen con un MED diferente. Como resultado, PE1 y PE2 prefieren llegar a BR4 a través de PE4. Si, por cualquier motivo, PE4 deja de anunciar la ruta 10.2.34.0/24 (o si la ruta se encuentra en un estado no válido), entonces PE1 y PE2 pueden conmutar por error a PE3.
Figura 1-7. Señalización de rutas eBGP e iBGP de Internet-Subred de H3
H1 tiene una ruta por defecto que apunta a la dirección IPv4 virtual 10.1.12.100. CE1 y CE2 ejecutan el Protocolo de Redundancia de Routers Virtuales (VRRP) en la LAN del host, y en ausencia de fallos CE1 es el maestro VRRP que mantiene la dirección 10.1.12.100. Por otro lado, el seguimiento de rutas VRRP está configurado de modo que si CE1 no tiene ruta para llegar a H3 y CE2 sí, CE2 se convierte en el maestro VRRP. El mecanismo es muy similar entre BR3 y BR4, salvo que en este caso BR4 es el maestro VRRP nominal.
Por último, el esquema MED configurado en las políticas de exportación eBGP de PE1 y PE2 es tal que CE1 prefiere llegar a H3 a través de PE1 en lugar de a través de PE2. Con todos los enlaces y sesiones activados, la ruta que siguen los paquetes H1→H3 (10.1.12.10→10.2.34.30) es CE1-PE1-PE4-BR4. La maestría VRRP en el primer salto, y luego MED en los saltos restantes, son los mecanismos de desempate para elegir la mejor ruta.
Rutas BGP Activo-Activo
Tanto PE1 como PE2 tienen una ruta eBGP a 10.1.12.0/24 con MED 100, por lo que ambos anuncian la ruta con MED 100 a los RR, como puedes ver en la Figura 1-8.
Figura 1-8. Señalización de rutas eBGP e iBGP de Internet-Subred de H1
La ruta que siguen los paquetes H3→H1 es BR4-PE4-PE2-CE2. PE4 prefiere PE2 porque el valor MED es 100 para ambos próximos saltos BGP (PE1 y PE2) y la métrica IGP de la ruta interna más corta PE4→PE2 es menor que la métrica IGP de PE4→PE1. Del mismo modo, PE3 prefiere PE1, pero BR4 es el maestro VRRP, por lo que PE3 no está en la ruta nominal H3→H1.
El resultado final es un reenvío asimétrico pero óptimo de los flujos H1→H3 y H3→H1. Es óptimo porque los RR reflejan todas las rutas, no sólo las que consideran mejores, como se muestra en el Ejemplo 1-5.
Ejemplo 1-5. Reflexión de ruta iBGP con Add-Path-RR1 (Junos)
1 juniper@RR1> show route advertising-protocol bgp 172.16.0.44 2 10.1.12.10 3 4 inet.0: 33 destinations, 38 routes (33 active, ...) 5 Prefix Nexthop MED Lclpref AS path 6 * 10.1.12.0/24 172.16.0.11 100 100 65001 I 7 172.16.0.22 100 100 65001 I 8 9 juniper@RR1> show route advertising-protocol bgp 172.16.0.44 10 10.1.12.0/24 detail 11 12 inet.0: 33 destinations, 38 routes (33 active, ...) 13 * 10.1.12.0/24 (3 entries, 2 announced) 14 BGP group CLIENTS type Internal 15 Nexthop: 172.16.0.11 16 MED: 100 17 Localpref: 100 18 AS path: [65000] 65001 I 19 Cluster ID: 172.16.0.201 20 Originator ID: 172.16.0.11 21 Addpath Path ID: 1 22 BGP group CLIENTS type Internal 23 Nexthop: 172.16.0.22 24 MED: 100 25 Localpref: 100 26 AS path: [65000] 65001 I 27 Cluster ID: 172.16.0.201 28 Originator ID: 172.16.0.22 29 Addpath Path ID: 2
Esto es posible gracias a las extensiones Add-Path (líneas 21 y 29). Sin ellas, RR1 elegiría la ruta con la mejor métrica IGP desde su propia perspectiva -del RR al siguiente salto BGP-, que no coincide necesariamente con la perspectiva desde PE4.
En resumen, las políticas se configuran de forma que la métrica MED o BGP se establezca simétricamente. A continuación se muestran los resultados:
-
CE1 prefiere llegar a H3 a través de PE1 que a través de PE2.
-
CE2 prefiere llegar a H3 a través de PE2 que a través de PE1.
-
PE1 prefiere llegar a H1 a través de CE1 que a través de CE2.
-
PE2 prefiere llegar a H1 a través de CE2 que a través de CE1.
-
PE1 y PE2 prefieren llegar a H3 a través de PE4 en lugar de a través de PE3.
-
PE3 y PE4 prefieren llegar a H1 a través de PE1 y PE2, respectivamente.
Reenvío de paquetes en un núcleo sin BGP
Hasta ahora todo va bien, salvo un detalle importante: H1 y H3 no pueden comunicarse entre sí. Tomemos el ejemplo de un paquete IPv4 con origen H1 y destino H3. PE1 decide reenviar el paquete a través de PE4, pero PE1 y PE4 no están conectados directamente entre sí. El camino más corto de PE1 a PE4 es PE1-P1-P2-PE4. Por tanto, PE1 envía el paquete a su siguiente salto, P1. Aquí está el problema: P1 no habla BGP, por lo que no tiene ruta al destino H3. Como resultado, P1 desecha el paquete.
¿Qué te parece establecer sesiones iBGP entre P1 y los RR? Se trata de una práctica relativamente habitual en grandes SP con dispositivos centrales de gama alta. En la Internet real hay más de medio millón de rutas, y sigue creciendo. Aunque la integración de rutas es posible, sigue requiriendo una importante carga en el plano de control para que P1 programe todas las rutas BGP necesarias. P1 también perdería agilidad ante cambios en la topología de la red, porque necesitaría reprogramar muchas rutas en el plano de reenvío.
P1 y P2 son routers internos del núcleo (no tienen peerings eBGP), y su función es llevar paquetes de la forma más rápida y fiable posible entre routers de perímetro como PE1, PE2, PE3 y PE4. Esto es posible si PE1 añade al paquete IPv4 H1→H3 una cabecera adicional -o conjunto de cabeceras- con la siguiente instrucción: llévame a PE4.
Una opción es utilizar el túnel IP. Encapsulando el paquete IPv4 H1→H3 dentro de otra cabecera IPv4 con origen y destino PE1→PE4, el paquete llega a PE4. Entonces, PE4 elimina las cabeceras de tunelización y realiza con éxito una búsqueda IPv4 en el paquete original H1→H3. Existen varias tecnologías de tunelización IP, como GRE, IP-in-IP y VXLAN. Sin embargo, este enfoque tiene varios problemas cuando se trata de reenviar terabits por segundo o petabits por segundo, o más.
El más inmediato de estos problemas era el coste, dado que los túneles IP solían ser caros:
-
En primer lugar, sólo una cabecera IPv4 consta de 20 bytes. Si añades las cabeceras de adaptación adicionales, la sobrecarga se vuelve significativa, por no mencionar el esfuerzo que requiere crear y destruir cabeceras con muchos campos dinámicos.
-
En segundo lugar, realizar una búsqueda IPv4 ha sido tradicionalmente caro. Aunque las plataformas modernas han reducido drásticamente su coste diferencial, en los años 90 el reenvío IPv4 daba lugar a un rendimiento mucho peor que la conmutación de etiquetas.
Hay otra tecnología que es mejor en términos de sobrecarga (4 bytes por cabecera) y eficacia de reenvío. Esta tecnología está integrada de forma nativa con BGP y aporta una amplia cartera de características que son de suma importancia para los SP. Puede que ya hayas adivinado que su nombre es MPLS, o Conmutación de Etiquetas Multiprotocolo. En la era de la SDN, el coste de reenvío ya no es el principal motor para la implementación de MPLS: lo son su arquitectura y flexibilidad.
MPLS
MPLS se inventó a finales de los 90, en una época en la que el Modo de Transferencia Asíncrono (ATM) era una tecnología WAN muy extendida.
ATM tenía algunas virtudes: multiservicio, transporte asíncrono, clase de servicio, estado de reenvío reducido, previsibilidad, etc. Pero tenía al menos otros tantos defectos: ninguna tolerancia a la pérdida o reordenación de datos, una sobrecarga de reenvío que lo hacía inadecuado para altas velocidades, ningún multipunto decente, falta de integración nativa con IP, etc.
MPLS aprendió de la instructiva experiencia ATM, aprovechando sus virtudes y resolviendo al mismo tiempo sus defectos. El MPLS moderno es una tecnología de reenvío asíncrono basada en paquetes. En ese sentido, es similar a IP, pero MPLS tiene un plano de reenvío mucho más ligero y reduce enormemente la cantidad de estado que hay que señalizar y programar en los dispositivos.
MPLS en acción
Probablemente, la mejor forma de entender el MPLS sea observando un ejemplo real, como el que se muestra en la Figura 1-9.
Figura 1-9. MPLS en acción
La Figura 1-9 muestra dos rutas unidireccionales MPLS Label-Switched Paths (LSPs) denominadas PE1→PE4 y PE4→PE2. Empecemos por el primero. A PE1 llega un paquete IPv4 H1→H3 (10.1.12.10→10.2.34.30), que conduce a lo siguiente:
-
H3 es alcanzable a través de PE4, por lo que PE1 coloca el paquete en el LSP PE1→PE4. Lo hace insertando una nueva cabecera MPLS entre las cabeceras IPv4 y Ethernet del paquete H1→H3. Esta cabecera contiene la etiqueta MPLS 1000001, que es localmente significativa para P1. En terminología MPLS, esta operación es un "label push". Por último, PE1 envía el paquete a P1.
-
P1 recibe el paquete e inspecciona y elimina la cabecera MPLS original. A continuación, P1 añade una nueva cabecera MPLS con la etiqueta 1000002, que es localmente significativa para P2, y envía el paquete a P2. Esta operación MPLS se denomina intercambio de etiquetas.
-
P2 recibe el paquete, inspecciona y elimina la cabecera MPLS, y luego envía el paquete IPv4 simple a PE4. Esta operación MPLS se denomina "label pop".
-
PE4 recibe el paquete IPv4 sin ninguna cabecera MPLS. Esto está bien porque PE4 habla BGP y conoce todas las rutas IPv4, por lo que sabe cómo reenviar el paquete hacia su destino.
El paquete H3→H1 viaja de PE4 a PE2 en un LSP más corto en el que sólo tienen lugar dos operaciones MPLS: label push en PE4 y label pop en P2. No hay intercambio de etiquetas.
Nota
Resulta que estos LSP siguen la ruta IGP más corta entre sus puntos finales. Esto no es obligatorio y a menudo no es el caso.
Funciones del router en un LSP
Volviendo a la Figura 1-9, el LSP PE1→PE4 empieza en PE1, atraviesa P1 y P2, y termina... ¿en P2 o en PE4? Veamos. Al colocar el paquete en el LSP, PE1 básicamente lo está enviando a PE4. De hecho, cuando P2 recibe un paquete con la etiqueta 1000002, la instrucción de reenvío es clara: salta la etiqueta y envía el paquete por la interfaz Gi 0/0/0/5. Así que el LSP termina en PE4.
Nota
El paquete H1→H3 llega sin etiquetar a PE4 en virtud de un mecanismo llamado Penultimate Hop Popping (PHP) ejecutado por P2.
A continuación se describen los distintos roles de los routers desde el punto de vista del LSP PE1→PE4. Para cada una de estas funciones existen muchos términos y acrónimos:
-
PE1Ingress PE, Ingress Label Edge Router (LER), LSP Head-End, LSP Upstream Endpoint. El término entrada proviene del hecho de que los paquetes de usuario como H1→H3 entran en el LSP en PE1, que actúa como punto de entrada o ingress.
-
P1 (o P2)Transit P, P-Router, Label Switching Router (LSR), o simplemente P.
-
PE4PE de salida, Label Edge Router (LER) de salida, LSP Tail-End, LSP Downstream Endpoint. El término egress proviene del hecho de que los paquetes de usuario como H1→H3 salen del LSP en este PE.
La cabecera MPLS
Parafraseando a Ivan Pepelnjak, director técnico de NIL Data Communications, en su blog www.ipspace.net:
MPLS no es tunelización, es una tecnología basada en circuitos virtuales, y la diferencia entre ambas es importante. Puedes hablar de tunelización cuando un protocolo que debería estar más abajo en la pila de protocolos se encapsula en un protocolo que normalmente encontrarías por encima o al lado. MAC-en-IP, IPv6-en-IPv4, IP-sobre-GRE-sobre-IP... son túneles. IP sobre MPLS sobre Ethernet no es un túnel.
Sin embargo, es cierto que MPLS utiliza circuitos virtuales, pero no son idénticos a los túneles. Que todos los paquetes entre dos puntos finales sigan la misma ruta y los conmutadores del medio no inspeccionen sus cabeceras IP, no significa que utilices una tecnología de túneles.
Las cabeceras MPLS se insertan elegantemente en los paquetes. Su tamaño es de sólo 4 bytes. El Ejemplo 1-6 presenta una captura del paquete H1→H3 mientras atraviesa el enlace P1-P2.
Ejemplo 1-6. Paquete MPLS en la red
1 Ethernet II, Src: MAC_P1_ge-2/0/3, Dst: MAC_P2_gi0/0/0/2 2 Type: MPLS label switched packet (0x8847) 3 MultiProtocol Label Switching Header 4 1111 0100 0010 0100 0010 .... .... .... = Label: 1000002 5 .... .... .... .... .... 000. .... .... = Traffic Class: 0 6 .... .... .... .... .... ...0 .... .... = Bottom of Stack: 1 7 .... .... .... .... .... .... 1111 1100 = MPLS TTL: 252 8 Internet Protocol Version 4, Src: 10.1.12.10, Dst: 10.2.34.30 9 Version: 4 10 Header Length: 20 bytes 11 Differentiated Services Field: 0x00 12 # IPv4 Packet Header Details and IPv4 Packet Payload
Aquí tienes una descripción de los 32 bits que componen una cabecera MPLS:
-
Los primeros 20 bits (línea 4) son la etiqueta MPLS.
-
Los 3 bits siguientes (línea 5) son la Clase de Tráfico. Antes se denominaban bits experimentales. Este campo es semánticamente similar a los 3 primeros bits del campo Punto de Código de Servicios Diferenciados (DSCP) de la cabecera IPv4 (línea 11).
-
El siguiente bit 1 (línea 6) es el bit Bottom of Stack (BoS). Se pone a valor 1 sólo si se trata de la cabecera MPLS en contacto con la cabecera del siguiente protocolo (en este caso, IPv4). En caso contrario, se pone a cero. Este bit es importante porque la cabecera MPLS no tiene campo de tipo, por lo que necesita el bit BoS para indicar que es la última cabecera antes de la carga útil MPLS.
-
Los siguientes 8 bits (línea 7) son el tiempo de vida (TTL) MPLS. Al igual que el TTL IP, el TTL MPLS implementa un mecanismo para descartar paquetes en caso de bucle de reenvío. Normalmente, el PE de entrada disminuye el TTL IP en uno y luego copia su valor en el TTL MPLS. Los P-routers de tránsito disminuyen el TTL MPLS en uno en cada salto. Por último, el PE de salida copia el TTL MPLS en el TTL IP y luego disminuye su valor en uno. Puedes ajustar esta implementación por defecto tanto en Junos como en IOS XR.
La Figura 1-10 muestra otras dos operaciones con etiquetas que no se han descrito hasta ahora:
-
El primer paquete entrante tiene una pila de dos etiquetas. Puedes ver el uso del bit BoS. La operación de intercambio sólo afecta a la etiqueta superior (más externa).
-
El segundo paquete entrante tiene inicialmente una pila de una etiqueta, y se procesa mediante una operación compuesta de etiquetas: swap y push. El resultado es una pila de dos etiquetas.
Figura 1-10. Otras operaciones MPLS
Configuración MPLS y Plano de Reenvío
Configuración de la interfaz MPLS
El primer paso es habilitar MPLS en las interfaces en las que quieras reenviar paquetes MPLS. El Ejemplo 1-7 muestra la configuración Junos de una interfaz en PE1.
Ejemplo 1-7. Configuración de la interfaz MPLS-PE1 (Junos)
1 interfaces {
2 ge-2/0/4 {
3 unit 0 {
4 family mpls;
5 }}}
6 protocols {
7 mpls {
8 interface ge-2/0/4.0;
9 }}
Las líneas 1 a 4 habilitan la encapsulación MPLS en la interfaz, y las líneas 6 a 8 habilitan la interfaz para protocolos MPLS. En sentido estricto, este último bloque de configuración no siempre es necesario, pero es una buena práctica añadirlo sistemáticamente.
Nota
A lo largo de este libro, se asume que cada interfaz habilitada para MPLS en Junos tiene al menos la configuración del Ejemplo 1-7.
En IOS XR, no existe una configuración MPLS genérica. Tienes que habilitar la interfaz para cada uno de los sabores MPLS que necesites utilizar. Este capítulo presenta el más sencillo de todos los sabores MPLS: MPLS estático. El Ejemplo 1-8 presenta la configuración de una interfaz en PE4.
Ejemplo 1-8. Configuración de la interfaz MPLS-PE4 (IOS XR)
mpls static interface GigabitEthernet0/0/0/0 !
Ruta de conmutación de etiquetas PE1→PE4-configuración
Recuerda que los paquetes H1→H3 pasan por PE1 y PE4. Necesitas un LSP que lleve estos paquetes de PE1 a PE4. Hagamos que el LSP siga la ruta PE1-P1-P2-PE4 que vimos en la Figura 1-9.
Nota
Este ejemplo se basa en los LSP estáticos, que no son escalables porque requieren asignaciones manuales de etiquetas en cada salto de la ruta. A partir del Capítulo 2, la atención se centra en los LSP dinámicos, mucho más escalables.
El ejemplo 1-9 muestra la configuración completa a lo largo de la ruta.
Ejemplo 1-9. Configuración LSP PE1→PE4-Junos e IOS XR
#PE1 (Junos)
protocols {
mpls {
static-label-switched-path PE1--->PE4 {
ingress {
next-hop 10.0.0.3;
to 172.16.0.44;
push 1000001;
}}}}
#P1 (Junos)
protocols {
mpls {
icmp-tunneling;
static-label-switched-path PE1--->PE4 {
transit 1000001 {
next-hop 10.0.0.7;
swap 1000002;
}}}}
#P2 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000002 allocate
forward
path 1 nexthop GigabitEthernet0/0/0/5 10.0.0.11 out-label pop
!
PE4 recibe paquetes IPv4 simples de P2, por lo que no necesita ninguna configuración específica de LSP.
Las etiquetas 1000001 y 1000002 son localmente significativas para P1 y P2, respectivamente. Sus valores numéricos podrían haber sido idénticos y seguirían correspondiendo a instrucciones diferentes porque no son interpretadas por la misma LSR.
LSP PE1→PE4-plano de reenvío
Es hora de inspeccionar las instrucciones de reenvío que dirigen el paquete H1→H3 IPv4 a través del LSP PE1→PE4. Empecemos por PE1, que se muestra en el Ejemplo 1-10.
Ejemplo 1-10. Estado de enrutamiento y reenvío en el PE-PE1 de entrada (Junos)
1 juniper@PE1> show route receive-protocol bgp 172.16.0.201 2 10.2.34.30 active-path 3 4 inet.0: 36 destinations, 45 routes (36 active, ...) 5 Prefix Nexthop MED Lclpref AS path 6 * 10.2.34.0/24 172.16.0.44 100 100 65002 I 7 8 juniper@PE1> show route 172.16.0.44 9 10 inet.0: 36 destinations, 45 routes (36 active, ...) 11 + = Active Route, - = Last Active, * = Both 12 13 172.16.0.44/32 *[IS-IS/18] 1d 11:22:00, metric 30 14 > to 10.0.0.3 via ge-2/0/4.0 15 16 inet.3: 1 destinations, 1 routes (1 active, ...) 17 + = Active Route, - = Last Active, * = Both 18 19 172.16.0.44/32 *[MPLS/6/1] 05:00:00, metric 0 20 > to 10.0.0.3 via ge-2/0/4.0, Push 1000001 21 22 juniper@PE1> show route 10.2.34.30 active-path 23 24 inet.0: 36 destinations, 45 routes (36 active...) 25 + = Active Route, - = Last Active, * = Both 26 27 10.2.34.0/24 *[BGP/170] 06:37:28, MED 100, localpref 100, 28 from 172.16.0.201, AS path: 65002 I 29 > to 10.0.0.3 via ge-2/0/4.0, Push 1000001 30 31 juniper@PE1> show route forwarding-table destination 10.2.34.30 32 Routing table: default.inet 33 Internet: 34 Destination Next hop Type Index NhRef Netif 35 10.2.34.0/24 indr 1048575 3 36 10.0.0.3 Push 1000001 513 2 ge-2/0/4.0 37 38 juniper@PE1> show mpls static-lsp statistics name PE1--->PE4 39 Ingress LSPs: 40 LSPname To State Packets Bytes 41 PE1--->PE4 172.16.0.44 Up 27694 2768320
La mejor ruta BGP hacia el destino 10.2.34.30 (H3) tiene un atributo de siguiente salto BGP (línea 6) igual a 172.16.0.44. Hay dos rutas hacia 172.16.0.44 (loopback de PE4):
-
Una ruta IS-IS en la tabla de enrutamiento global IPv4
inet.0(líneas 10 a 14). -
Una ruta MPLS en la tabla auxiliar
inet.3(líneas 16 a 20). El LSP estático configurado en el Ejemplo 1-9 instala automáticamente esta ruta MPLS.
El objetivo de la tabla auxiliar inet.3 es resolver los siguientes saltos BGP (línea 6) en siguientes saltos de reenvío (línea 20). De hecho, la ruta BGP 10.2.34.0/24 se instala en inet.0 con un siguiente salto de reenvío etiquetado (línea 29) que se copia de inet.3 (línea 20). Por último, la ruta BGP se instala en la tabla de reenvío (líneas 31 a 36) y se envía a los motores de reenvío.
El hecho de que Junos disponga de una tabla auxiliar (inet.3) para resolver los siguientes saltos BGP es bastante relevante. Ten en cuenta que Junos utiliza inet.0 y no inet.3 para programar la tabla de reenvío. Por esta razón, el comportamiento predeterminado de PE1 es no colocar ninguna etiqueta en los paquetes que envía a destinos internos (no BGP) como el loopback de PE4, como se demuestra en el Ejemplo 1-11.
Ejemplo 1-11. Traceroute no etiquetado a un destino no BGP-PE1 (Junos)
juniper@PE1> traceroute 172.16.0.44 traceroute to 172.16.0.44 1 P1 (10.0.0.3) 42.820 ms 11.081 ms 4.016 ms 2 P2 (10.0.0.25) 6.440 ms P2 (10.0.0.7) 3.426 ms * 3 PE4 (10.0.0.11) 9.139 ms * 78.770 ms
Volvamos al LSP PE1→PE4 y pasemos a P1, el primer LSR de la ruta.
Ejemplo 1-12. Estado de enrutamiento y reenvío en un P-P1 en tránsito (Junos)
juniper@P1> show route table mpls.0 label 1000001
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1000001 *[MPLS/6] 07:23:19, metric 1
> to 10.0.0.7 via ge-2/0/3.0, Swap 1000002
La tabla mpls.0 almacena instrucciones de etiqueta. Por ejemplo, si P1 recibe un paquete con la etiqueta 1000001, la instrucción dice: cambia la etiqueta por 1000002 y envía el paquete por ge-2/0/3 a P2. Este conjunto de instrucciones se conoce como Base de Información de Reenvío de Etiquetas (LFIB). La tabla mpls.0 no es auxiliar: rellena la tabla de reenvío.
Por último, veamos la LFIB de P2 en el Ejemplo 1-13.
Ejemplo 1-13. Estado de enrutamiento y reenvío en un P-P2 en tránsito (IOS XR)
RP/0/0/CPU0:P2#show mpls forwarding labels 1000002 Local Outgoing Outgoing Next Hop Bytes Label Label Interface Switched ------ ----------- ------------ --------------- ------------ 1000002 Pop Gi0/0/0/5 10.0.0.11 8212650
No tiene sentido fijarse en PE4, que se comporta como un router IP puro con respecto a los paquetes H1→H3.
LSP PE4→PE2-Configuración
Para completar, el Ejemplo 1-14 presenta la configuración completa del LSP PE4→PE2.
Ejemplo 1-14. Configuración LSP PE4→PE2-IOS XR
#PE4 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000200 allocate per-prefix 172.16.0.22/32
forward
path 1 nexthop GigabitEthernet0/0/0/0 10.0.0.10 out-label 1000110
!
#P2 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000110 allocate
forward
path 1 nexthop GigabitEthernet0/0/0/0 10.0.0.4 out-label pop
!
La sintaxis clave en PE4 es per-prefix: esto dice que para colocar un paquete en un LSP cuyo extremo de cola es PE2 (172.16.0.22), coloca la etiqueta 1000110 y envíalo a P2.
El primer valor de etiqueta (1000200) del Ejemplo 1-14 no forma parte realmente del LSP PE4→PE2. Significa que si recibe un paquete MPLS con la etiqueta más externa 1000200, PE4 coloca el paquete en el LSP PE4→PE2 cambiando la etiqueta por 1000110. Esta lógica no es muy relevante para el ejemplo actual, en el que los paquetes H3→H1 llegan sin etiqueta a PE4.
El ejemplo 1-15 muestra el estado de enrutamiento y reenvío en el PE de entrada (PE4).
Ejemplo 1-15. Estado de enrutamiento y reenvío en el PE-PE4 de entrada (IOS XR)
RP/0/0/CPU0:PE4#show bgp 10.1.12.0/24 brief
[...]
Network Next Hop Metric LocPrf Weight Path
* i10.1.12.0/24 172.16.0.11 100 100 0 65001 i
*>i 172.16.0.22 100 100 0 65001 i
RP/0/0/CPU0:PE4#show cef 10.1.12.10
[...]
local adjacency 10.0.0.10
via 172.16.0.22, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa137dd74 0x0]
next hop 172.16.0.22 via 172.16.0.22/32
RP/0/0/CPU0:PE4#show cef 172.16.0.22
[...]
local adjacency 10.0.0.10
via 10.0.0.10, GigabitEthernet0/0/0/0, 4 dependencies, [...]
next hop 10.0.0.10
local adjacency
local label 1000200 labels imposed {1000110}
RP/0/0/CPU0:PE4#show mpls forwarding labels 1000200
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ -------- -------------- ---------- --------- --------
1000200 1000110 172.16.0.22/32 Gi0/0/0/0 10.0.0.10 10410052
La lógica en IOS XR es muy similar, salvo que en este caso no hay tablas auxiliares. Como resultado, el comportamiento predeterminado de PE4 es insertar etiquetas en los paquetes que envía a destinos internos (no BGP) que están a más de un salto de distancia, como el loopback de PE2 que se muestra en el Ejemplo 1-16.
Ejemplo 1-16. Traceroute etiquetado a un destino no-BGP-PE4 (IOS XR)
RP/0/0/CPU0:PE4#traceroute 172.16.0.22 1 p2 (10.0.0.10) [MPLS: Label 1000110 Exp 0] 9 msec ... 2 pe2 (10.0.0.4) 0 msec ...
Tráfico de usuario de extremo a extremo
Una vez que los LSP PE1→PE4 y PE4→PE2 están activados, la conectividad de extremo a extremo es correcta.
Ejemplo 1-17. Traceroute de usuario de extremo a extremo a través de una red MPLS
RP/0/0/CPU0:H1#traceroute vrf H1 10.2.34.30 1 ce1 (10.1.12.1) 0 msec ... 2 pe1 (10.1.0.1) 0 msec ... 3 p1 (10.0.0.3) [MPLS: Label 1000001 Exp 0] 9 msec ... 4 p2 (10.0.0.7) [MPLS: Label 1000002 Exp 0] 9 msec ... 5 pe4 (10.0.0.11) 9 msec ... 6 br4 (10.2.0.4) 9 msec ... 7 h3 (10.2.34.30) 9 msec ...
Como era de esperar, traceroute muestra la ruta de avance con las etiquetas del LSP PE1→PE4.
Te preguntarás cómo puede P1 enviar un mensaje de Protocolo de Mensajes de Control de Internet (ICMP) Tiempo Excedido a H1, teniendo en cuenta que ni siquiera tiene una ruta para llegar a H1. Lo que ocurre es lo siguiente
-
P1 recibe un paquete UDP con etiqueta MPLS 1000001 y TTL MPLS =1.
-
P1 disminuye el TTL, detecta que ha expirado y encapsula el paquete UDP original con la etiqueta MPLS 1000001 dentro de un paquete ICMP Tiempo Superado, que a su vez está encapsulado con la etiqueta MPLS 1000002. Este paquete tiene TTL=255.
-
P1 envía el paquete ICMP Time Exceeded encapsulado en MPLS a P2, que retira la etiqueta y envía el paquete a PE4.
-
PE4 mira el destino del paquete ICMP Tiempo Superado, que es H1. Según una búsqueda IPv4 normal, PE4 envía este paquete a través del LSP PE4→PE2, y así es como llega a H1.
Consejo
Este mecanismo funciona por defecto en IOS XR, pero debes activarlo explícitamente en Junos mediante el comando set protocols mpls icmp-tunneling.
Clase de equivalencia de reenvío
El ejemplo anterior se centraba en la comunicación entre dos hosts, H1 y H3. Demos un paso atrás y pensemos en la Internet global. Imagina que PE1 elige a PE4 como siguiente salto BGP para 100.000 rutas. Piénsalo dos veces: todas estas 100.000 rutas tienen el mismo siguiente salto BGP. Esto significa que PE1 puede enviar todos los paquetes hacia cualquiera de estos 100.000 prefijos a través del mismo LSP. Por supuesto, esto puede plantear problemas con respecto al equilibrio de carga y la redundancia, pero estos temas se tratan a fondo en este libro.
Cada paquete que PE1 mapea al LSP PE1→PE4 pertenece a una única Clase de Equivalencia de Reenvío (FEC). Los LSR de tránsito sólo necesitan saber cómo reenviar en el contexto de esta FEC: básicamente, una sola entrada en la LFIB. Así, se pueden reenviar con éxito billones de flujos con una sola entrada de reenvío.
Nota
La agregación del estado de reenvío es una de las primeras ventajas inmediatas de MPLS.
De nuevo, ¿Qué es MPLS?
MPLS no es una encapsulación. Es un marco arquitectónico que desacopla el transporte de los servicios. En este caso, el servicio es el acceso a Internet (unidifusión IPv4) y el transporte se realiza mediante LSP MPLS.
Este desacoplamiento se consigue codificando las instrucciones en las cabeceras de los paquetes. Tanto si la encapsulación es MPLS como si es otra cosa, el paradigma MPLS se mantiene.
Internet es la prueba viviente de que MPLS es la piedra angular de la escalabilidad de los servicios de red. Cada segundo que nuestra usuaria, Annika, está en una videoconferencia con su amigo Ruijiao, más de 1.000 etiquetas MPLS se empujan, intercambian o saltan para que esto ocurra. Los dispositivos centrales que realizan estas operaciones de etiquetas no tienen visibilidad de las direcciones IP públicas que utilizan los terminales de Annika y Ruijiao para conectarse a Internet.
Otro aspecto importante del MPLS es el apilamiento de instrucciones. Tanto si estas instrucciones tienen forma de etiquetas como de otra cosa, poder apilarlas equivale a proporcionar una secuencia de instrucciones. Para los servicios de red que van más allá de la simple conectividad, éste es un factor clave.
Como se verá más adelante en el Capítulo 10, las arquitecturas de red escalables tienen una dirección Norte-Sur y otra Este-Oeste. El apilamiento de instrucciones introduce otra dimensión: Arriba-Abajo.
Nota
MPLS es un ajuste natural para arquitecturas con un perímetro de red rico en funciones combinado con una red troncal rápida y resistente.
MPLS nació para Internet. Empezó siendo pequeño y sigue creciendo. El objetivo inicial del MPLS era resolver un reto muy concreto, pero ahora sigue evolucionando para satisfacer muchos otros requisitos en términos de servicio, transporte, clase de servicio, rendimiento, resistencia, etc.
OpenFlow
La era SDN comenzó con un protocolo experimental que creó una gran expectación: OpenFlow.
OpenFlow permite programar un motor de reenvío basado en flujos. Su versión inicial (v1.0) es básicamente una abstracción de conmutador de red. Con el tiempo, las distintas versiones de OpenFlow han incorporado más funcionalidades, cuyos detalles quedan fuera del alcance de este libro. Puedes encontrar todas las definiciones y especificaciones en el Open Networking Forum(https://www.opennetworking.org/sdn-resources/openflow).
La Figura 1-11 muestra OpenFlow v1.0 en funcionamiento. OpenFlow supone que hay un software controlador central que se ejecuta como una máquina virtual (VM), o como un contenedor, o directamente en el SO anfitrión de un servidor. El controlador debe tener conectividad IP con los conmutadores mediante una de las siguientes opciones:
-
Una red fuera de banda que no está bajo el mando del controlador
-
Una conexión de red en banda que depende de algún estado de reenvío preexistente
Figura 1-11. Openflow en acción
Los conmutadores tienen un plano de control ligero y un motor de reenvío comparativamente más potente. El elemento de estado más importante de un conmutador controlado por OpenFlow es su tabla de flujo. El plano de control de los conmutadores está conectado al controlador central mediante una sesión TCP OpenFlow, cuya finalidad es intercambiar mensajes OpenFlow.
La Figura 1-11 muestra al Anfitrión A enviando el primer paquete de un flujo TCP de usuario al Anfitrión B. Cuando el paquete llega al puerto 1, el Conmutador nº 1 se da cuenta de que este flujo no está programado en su tabla de flujos, por lo que su agente de control "envía" el paquete al controlador. El controlador había aprendido previamente dónde está el Host B, y con esta información es capaz de programar el nuevo flujo en los conmutadores. En este punto, los conmutadores pueden reenviar los paquetes de este flujo al destino.
Reenvío basado en OpenFlow-Flow
Un atributo arquitectónico fundamental de OpenFlow es su programabilidad por flujo, que ofrece una granularidad fina a la hora de definir los flujos y sus acciones asociadas. El resultado es un modelo de reenvío basado en flujos. Durante décadas, la industria ha producido una amplia variedad de soluciones de reenvío basadas tanto en flujos como en paquetes. ¿Qué modelo es mejor? Ninguno, ambos lo son. En realidad, depende del caso de uso.
Hay partes de la red en las que incluso pensar en el reenvío basado en flujos está fuera de lugar, como en el núcleo y en la mayoría de las funciones de perímetro de banda ancha, porque no escalaría y no hay necesidad de ello. Internet requiere agregación de estados (FEC) en lugar de expansión de estados (flujos). Mantener el estado de los flujos es intrínsecamente más caro y complejo que hacer un reenvío basado en paquetes. Sin embargo, hay otras funciones de red, como cortafuegos, DPI y CGNAT, entre otras, que necesitan estar basadas en flujos debido a la naturaleza de la función que ejecutan.
Los mismos principios por los que la industria ha seleccionado de forma natural qué partes de la red deben basarse en flujos y cuáles no, siguen siendo completamente válidos. El hecho de que exista un nuevo protocolo para programar flujos en una red no hace que el reenvío basado en flujos sea ni mejor ni peor idea.
Los nuevos avances en tecnología de reenvío, memoria y costes, podrían cambiar las cosas en un sentido o en otro. Por esta razón, es prudente desvincular la existencia del protocolo OpenFlow del debate sobre si el reenvío basado en flujos es una buena idea o no. De hecho, OpenFlow, como tal, no obliga ni especifica la granularidad de los flujos a programar.
Cuando decidas utilizar un modelo u otro, la primera pregunta que debes responder es ¿necesitas el reenvío basado en flujos? Si no es así, es mejor utilizar el reenvío basado en paquetes. Los tejidos de los centros de datos (descritos en el Capítulo 10) son un buen ejemplo de los riesgos que entraña pasar ciegamente a un paradigma de reenvío basado en flujos. A primera vista, parece una buena opción, pero un análisis más profundo demuestra que realmente depende del uso principal del centro de datos.
Ivan Pepelnjak escribió un esclarecedor artículo titulado "OpenFlow y las estimaciones de Fermi", que se incluye en su libro SDN and OpenFlow-The Hype and the Harsh Reality (autoeditado, 2014, http://www.ipspace.net/Books). Puede que te hayas dado cuenta de que tu navegador web establece automáticamente conexiones con muchas URL que no tenías intención de visitar. Por ejemplo, cuando lees tu periódico online favorito, se carga automáticamente una gran variedad de contenidos -como anuncios, multimedia y estadísticas- procedentes de sitios externos. Cada contenido se recupera a través de una conexión individual de corta duración. Esta característica efímera de muchos flujos de Internet hace que la programación de flujos sea una tarea muy intensiva. Esto es especialmente cierto en los conmutadores de alta velocidad de los centros de datos, que tienen un plano de control comparativamente débil. La estimación Fermi de Pepelnjak muestra que la capacidad de reenvío de un conmutador de centro de datos típico se reduce en varios órdenes de magnitud cuando debe realizar el reenvío basado en flujos de flujos HTTP. El plano de control se convierte en el cuello de botella en este caso, por lo que no se puede utilizar la mayor parte del ancho de banda. Si tu red transporta flujos de corta duración, utiliza OpenFlow con cuidado.
OpenFlow-Openness y P4
OpenFlow es un protocolo abierto y P4 (un lenguaje de alto nivel más reciente,que programaprocesadores de paquetes independientes del protocolo, por eso delas cuatro P) lo lleva un paso más allá, de un protocolo a un lenguaje de programación. A pesar de las definiciones, no todo el mundo está de acuerdo en si OpenFlow y P4 son realmente de alto nivel o de bajo nivel.
No es de extrañar, lo abierto mola. Por otra parte, implementar características de perímetro de grano fino es complejo. No hay forma de evitarlo. Independientemente de si la complejidad está en los circuitos integrados específicos de la aplicación (ASIC), o en el microcódigo de bajo nivel, o en las instrucciones de alto nivel, debe estar en algún sitio, y no todos los enfoques son igual de eficientes o flexibles. Estandarizar un lenguaje de alto nivel oculta la complejidad, lo que está muy bien, pero para muchas funciones, los desarrolladores necesitan bajar a los niveles inferiores.
Los lenguajes de bajo nivel tienen valor porque proporcionan flexibilidad debido a lo cerca que están del hardware real. Son, y deben ser, inherentemente específicos, y si quieren ser genéricos, perderán precisamente esa especificidad. El hardware tiene diferencias que deben exponerse, porque los fabricantes añaden muchas innovaciones a sus ASIC para diferenciarlos unos de otros. Si se exponen, el lenguaje se vuelve específico. Si no se exponen, la innovación se pierde, y el sistema se convierte en un desincentivo para la innovación.
A un cierto nivel bajo, la relación entre el hardware y el software que lo programa es muy íntima. Intentar insertar una capa intermedia, aunque sea una capa definida por la industria, no garantiza impulsar la innovación. Sólo el tiempo dirá si estandarizar la forma en que se programa un dispositivo de red aporta innovación o ralentiza la implantación de nuevas funciones. Sin duda será una historia interesante que observar o en la que al menos desempeñar un papel.
Otra característica importante del modelo OpenFlow es el desacoplamiento de los planos de control y reenvío. Vamos a tratar este tema en el contexto más amplio de la SDN.
SDN
Este libro no pretende redefinir el concepto SDN en sí: eso corresponde a los inventores del acrónimo. Lo que este libro se toma la libertad de describir es la era SDN. Hablemos primero de la definición oficial de SDN y pasemos después a la era SDN.
SDN ha sido definida por Open Networking Forum(https://www.opennetworking.org) de la siguiente manera:
La separación física del plano de control de la red del plano de reenvío, y donde un plano de control controla varios dispositivos.
Siguiendo esta definición, afirma:
La Red Definida por Software (SDN) es una arquitectura emergente que es dinámica, gestionable, rentable y adaptable, lo que la hace ideal para la naturaleza dinámica y de gran ancho de banda de las aplicaciones actuales. Esta arquitectura desacopla las funciones de control y reenvío de la red, lo que permite que el control de la red sea directamente programable y que la infraestructura subyacente se abstraiga para las aplicaciones y los servicios de red. El protocolo OpenFlow™ es un elemento fundamental para construir soluciones SDN.
Separación de los planos de control y reenvío
El proceso de desacoplar los planos de control y de reenvío se presenta como un elemento clave que impulsa la adopción de la SDN; sin embargo, algunos ingenieros sostienen que esa separación existe desde hace muchos años en sus propias redes. Por ejemplo, tanto los routers de Juniper como los de Cisco separaban claramente los planos de control y reenvío en la década de 1990. El hecho de que funcionaran en el mismo chasis físico no negaba tal separación, que era, de hecho, fundamental para permitir el crecimiento en Internet. Cuando Juniper introdujo dicha separación, junto con el reenvío basado en ASIC, desencadenó una era de crecimiento de la capacidad sin precedentes. Y en retrospectiva, era necesario para sostener el crecimiento sin precedentes del tráfico que se avecinaba.
Desde principios de la década de 2000 -unos años antes de que se propusiera OpenFlow-, los proveedores de redes han implementado y distribuido soluciones que instancian el plano de control en un dispositivo físico externo. Se trata esencialmente de un controlador que programa el llamado "chasis de tarjeta de línea".
Por tanto, es justo señalar que el atributo arquitectónico fundamental asociado a la SDN, separar los planos de control y de reenvío, no es esencialmente nuevo, y ya se utiliza ampliamente en las redes. De todos modos, nuevo o no, este atributo es valioso.
Otro ingrediente arquitectónico fundamental de la SDN es la centralización. A veces es la centralización lógica, porque la centralización física no siempre es factible. Si supones que el plano de control de tu red está físicamente desacoplado del plano de reenvío, se plantea un interesante conjunto de retos:
-
Necesitas una red que conecte ambas funciones (los planos de control y de reenvío). Si esa red falla, ¿cómo funciona la solución?
-
Existen limitaciones de latencia para un correcto interfuncionamiento entre los planos de control y de reenvío. La latencia es importante para la resiliencia, la respuesta a eventos de red, la telemetría, etc. ¿A qué distancia puede estar el controlador de los elementos de reenvío?
No es trivial generalizar, para cualquier red, una forma de aplicar estos principios. Los principios de SDN se analizan mejor en el contexto de casos de uso concretos. Entonces podrás ver si una arquitectura que se adhiera a estos principios es viable o no.
Separación de los planos de control y reenvío - superposición de centros de datos
Un caso de uso paradigmático para el que encajan bien los principios de la SDN es la arquitectura superpuesta en los centros de datos, suponiendo lo siguiente:
-
Hay un tejido subyacente que proporciona conectividad resistente entre el plano de reenvío de la superposición (normalmente un vRouter o un vSwitch en un servidor) y el plano de control (controlador central).
-
La latencia está contenida dentro de unos límites de trabajo específicos.
Separación de los planos de control y reenvío-WAN IP/MPLS
Analicemos ahora la aplicabilidad de los principios arquitectónicos de la SDN a la red WAN IP/MPLS en cualquier ISP. Aunque hay ciertas funciones del plano de control que podemos centralizar, es inviable lograr una centralización total. De hecho, si colocas todo el plano de control a cientos o miles de kilómetros (y N saltos de red) de distancia del plano de reenvío, no es posible garantizar la interacción entre ambos planos de forma fiable y con capacidad de respuesta. Por esta razón, el concepto SDN sólo puede aplicarse al entorno WAN de forma táctica.
Disponer de cierta inteligencia de control centralizada en toda la red puede dar lugar a cálculos más precisos, lo que es muy útil para casos como la Ingeniería de Tráfico. En este caso, el plano de control distribuido se mejora con una inteligencia centralizada adicional. Esto se explica detalladamente en el Capítulo 15.
Estos ejemplos demuestran que la SDN puede tener distintos niveles de aplicabilidad para cada escenario (no hay una talla única para todos). Los vendedores de redes han aplicado este principio de diseño a lo largo de los años a muchos diseños de tecnología y arquitectura: centraliza lo que puedas, distribuye lo que debas. Si algo puede centralizarse, y no hay limitaciones físicas o funcionales, centralízalo; de lo contrario, debe dejarse distribuido.
SDN y los protocolos
Es justo afirmar que OpenFlow fue una chispa que provocó un cambio de mentalidad en la industria, desencadenando un sano debate que ha actuado como catalizador de la era SDN.
Dicho esto, existe cierta controversia sobre la relevancia técnica de OpenFlow. Mientras que algunos ingenieros creen que OpenFlow es la piedra angular de la SDN, otros opinan que no propone nada fundamentalmente nuevo. Para ser justos, como cualquier otro protocolo o tecnología, OpenFlow está evolucionando a través de sus diferentes versiones. Si realmente permitirá un beneficio fundamental en el futuro o no, sólo el tiempo lo dirá.
Paralelamente al desarrollo continuo de OpenFlow, otros foros de la industria, como el IETF, también han estado desarrollando conceptos similares. De hecho, dos de las joyas de la corona del IETF, BGP y MPLS, están ganando impulso como protocolos habilitadores de SDN.
No es sorprendente encontrar BGP en la era SDN, porque es el protocolo de red más escalable que jamás se haya diseñado e implementado. Por otra parte, el paradigma MPLS (desacoplar el servicio del transporte, colocar las instrucciones en las cabeceras de los paquetes) está adquiriendo una relevancia cada vez mayor en el desarrollo e implementación de soluciones SDN escalables. De hecho, este paradigma ha sido rebautizado por la comunidad OpenFlow como SDN 2.0.
Nota
Recuerda que el paradigma MPLS no es una encapsulación.
Los capítulos11 y 12 describen soluciones SDN listas para la producción, basadas principalmente en BGP -y sus derivados- en combinación con el paradigma MPLS.
En la práctica, OpenFlow es un elemento opcional de las arquitecturas tipo SDN. Muchas soluciones SDN modernas no se basan en OpenFlow y ni siquiera se inspiran en él. Otras sí: por supuesto, OpenFlow pertenece a la era SDN.
Algunos proyectos paralelos del IETF se centran en estandarizar la forma de programar y configurar el comportamiento de los elementos de red (por ejemplo, PCEP, BGP Flowspec, NETCONF/YANG/OpenConfig, I2RS y ForCES). Aunque algunas no han sido ampliamente adoptadas, otras están ganando impulso y también pertenecen a la era SDN. El Capítulo 15 trata en detalle el PCEP.
Independientemente del debate terminológico y de la elección del protocolo, una cosa es cierta: la industria seguirá explorando e implantando nuevas arquitecturas que, sin duda, están cambiando la forma en que vemos y utilizamos las redes.
La era SDN
Si observas todas las implantaciones y tecnologías similares a la SDN, encontrarás dos elementos en común que revelan lo que faltaba a principios de siglo en nuestra industria:
- Automatización
- Crear las condiciones para automatizar las acciones en las redes (configuración, aprovisionamiento, funcionamiento, resolución de problemas, etc.)
- Abstracción
- Lograr la comunicación Norte-Sur superando las barreras y complejidades específicas de cada proveedor a las que los clientes tenían que adaptarse o evitar
Si te fijas en cómo la industria ha adoptado dos protocolos como OpenFlow o Netconf, normalmente se ha centrado en el "cómo": cómo programar flujos de bajo nivel o cómo configurar un dispositivo. Sin embargo, lo que la industria necesita realmente es centrarse en el "qué": cuál es la intención. Es ir al alto nivel, ir a lo abstracto, lo que permite definir intenciones y automatizar acciones en torno a esas intenciones. Dicho de otro modo: "Di lo que quieres, no cómo lo quieres". Luego haz que la red sea lo bastante inteligente para decidir el mejor "cómo" posible.
En resumen, lo que es común en la miríada de términos e iniciativas cruzadas de SDN, en toda la industria, es la automatización y la abstracción. Ésta es la verdadera esencia de lo que este libro considera la era SDN y de lo que, como industria, probablemente deberíamos preocuparnos. Veamos brevemente algunos casos concretos de uso de nuevas tecnologías que parecen aportar un valor añadido concreto a los retos reales de los clientes mediante la automatización y la abstracción.
Casos de uso de la era SDN
Si nos alejamos del término SDN y de sus múltiples interpretaciones, en realidad hay nuevas soluciones y tecnologías desarrolladas para casos de uso concretos que suponen tanto un cambio arquitectónico como una respuesta a un problema real. A continuación se presenta una lista de escenarios representativos que forman parte del nuevo pensamiento en la era SDN. Algunos utilizan tecnologías probadas de forma práctica, a menudo brillante.
Centro de datos
Los requisitos de los centros de datos han crecido en órdenes de magnitud en muchas dimensiones, y muy rápidamente. Los centros de datos han sufrido una rápida transición, pasando de ser meras LAN densas a infraestructuras a hiperescala con requisitos muy estrictos, no sólo en rendimiento, sino también en latencia, escala, multiarrendamiento y seguridad. Y asociada a todo ello está la necesidad de mejorar la capacidad de gestión.
Algunas infraestructuras de conmutación de centros de datos propuestas se basan en OpenFlow, con un controlador central que programa los flujos a lo largo de la ruta, pero el sector también se ha fijado en otras arquitecturas y tecnologías que han demostrado cumplir los mismos requisitos a escala. No hace falta buscar muy lejos para encontrarlas: la propia Internet. El conjunto de protocolos y arquitecturas utilizados para construir Internet y las redes IP de los ISP se han convertido en el mejor espejo en el que mirarse para construir la próxima generación de centros de datos que hagan lo siguiente:
-
Desacoplar el transporte de los servicios (principio arquitectónico del MPLS)
-
Construir una infraestructura de transporte estable e independiente del servicio (tejidos)
-
Prestar servicios sólo en el perímetro y utilizar protocolos escalables para el plano de control (BGP)
Esta arquitectura ISP se ha adaptado a los centros de datos de varias formas. En primer lugar, el plano de reenvío de la capa base está optimizado para los requisitos específicos de los centros de datos, que incluyen una latencia muy baja entre los sistemas finales (servidores) y una capacidad de transporte muy alta sin apenas restricciones.
El perímetro del ISP se sustituye por los reenviadores de perímetro con capacidad de superposición del centro de datos, normalmente instanciados por el vRouter/vSwitch en hipervisores de servidor o, eventualmente, el conmutador Top-of-Rack (ToR).
Esto ofrece una buena oportunidad para utilizar un controlador central capaz de programar los reenviadores de perímetro como si fueran los motores de reenvío de paquetes o las tarjetas de línea de un dispositivo de red físico multicomponente. Puedes ver este modelo en detalle a lo largo del Capítulo 11.
WAN
La WAN del ISP -la red troncal interna del ISP- es otro caso de uso específico para el que hay que afrontar nuevos retos. Los recursos de ancho de banda son más escasos que nunca, y los niveles de control de CAPEX hacen imposible desplegar tanta capacidad como en el pasado. Sin embargo, el tráfico sigue creciendo, y una variedad cada vez mayor de servicios fluye a través de la infraestructura WAN, lo que plantea la necesidad de mecanismos capaces de gestionar estos recursos de forma más eficiente y dinámica. La Ingeniería de Tráfico MPLS existe desde hace muchos años, pero la naturaleza distribuida de las decisiones de Ingeniería de Tráfico provocaba ineficiencias.
Ahora, con la mayor disponibilidad e implementaciones de protocolos como el PCEP, es posible habilitar controladores inteligentes centralizados que complementen el plano de control distribuido de la red, añadiendo una visión y un proceso de decisión a nivel de toda la red. La WAN ISP puede aprovechar ahora las implementaciones que ofrecen una gestión inteligente de los recursos y la automatización de tareas que antes sólo podían hacerse de forma limitada y hasta cierto punto manual, o simplemente no se hacían, porque había suficiente capacidad. La escasez de recursos y los requisitos empresariales exigen ahora una forma diferente de hacerlo, y éste es otro ejemplo y caso de uso de las nuevas implementaciones que emplean conceptos antiguos, como la arquitectura Cliente-Servidor de PCE. Este modelo se detalla en el Capítulo 15.
Convergencia paquete-óptico
La conmutación basada en paquetes y la basada en circuitos son dos paradigmas fundamentalmente distintos, y ambos tienen razones para existir. Tradicionalmente han sido capas separadas, la mayoría de las veces con la red de conmutación de circuitos como capa servidor para la red de conmutación de paquetes (el cliente). A veces este papel se invierte; por ejemplo, con circuitos TDM emulados sobre MPLS en escenarios de backhaul móvil, brevemente tratados en el Capítulo 6.
Las redes ópticas son la tecnología de conmutación de circuitos más común. Proporcionan circuitos ópticos que las redes basadas en paquetes utilizan para la comunicación punto a punto entre los distintos nodos de conmutación de paquetes (encaminadores, conmutadores, etc.).
En la era SDN, la gran mayoría del tráfico se está convirtiendo en IP, incluso la voz móvil con tecnologías como VoLTE. Ya es un hecho que la finalidad principal (si no única) de la red óptica es transportar la red IP. Por esta razón, la estrecha coordinación y optimización de las redes óptica e IP se convierte en crítica para el negocio. Cualquier ineficiencia en dicha integración se convierte inmediatamente en una gran fuente de CAPEX y OPEX adicionales.
Por tanto, he aquí otra área en la que los ISP se enfrentan a un fuerte reto que requiere soluciones específicas. La necesidad de coordinación, automatización y optimización de recursos se aborda haciendo lo siguiente:
-
Exponer recursos de forma normalizada (abstracción)
-
Tener la capacidad de automatizar las decisiones correctas de asignación de recursos (establecer rutas, optimizar rutas, buscar recursos de reserva, etc.) teniendo en cuenta tanto la capa óptica como la capa de paquetes
De nuevo, el papel de un controlador centralizado es primordial. El modelo descrito en el Capítulo 15 también se dirige a este caso de uso.
Interconexión IP
El peering IP ofrece otra oportunidad para mejorar y optimizar los mecanismos existentes. Hasta ahora, el comportamiento de los puntos de interconexión IP se ha regido exclusivamente por las reglas del protocolo BGP. BGP implementa un algoritmo de decisión que busca la mejor ruta libre de bucles -libre de bucles en el sentido de que la ruta del AS no contiene el mismo AS dos veces-. Aunque se pueden utilizar muchas herramientas, como los atributos BGP, para influir en el proceso de decisión, sigue siendo un algoritmo incorporado que se basa en ciertas reglas predefinidas. Dichas reglas pueden no tener en cuenta aspectos relacionados con el negocio que un proveedor podría necesitar considerar para tomar las mejores decisiones de enrutamiento.
Algunos de estos aspectos empresariales son el precio de la conexión peering (puede ser un enlace de tránsito), la latencia real hasta el destino (las rutas AS más cortas no implican necesariamente una latencia menor), la ocupación del enlace, y quizá otros. A medida que las condiciones empresariales se hacen más estrictas en nuestro sector, las decisiones de red deben tener en cuenta más variables.
Los ISP suelen utilizar túneles superpuestos ad hoc (basados en IP o MPLS) para eludir las decisiones de reenvío por defecto, pero este enfoque no es escalable: Los ISP merecen una solución mejor.
Una solución basada en un controlador que aborde esta oportunidad necesita tener una visibilidad detallada de todo el estado de enrutamiento BGP en el SP. El Protocolo de Monitoreo de BGP (BMP), implementado tanto en Junos como en IOS XR, permite recuperar el estado de un determinado router:
- El Adj-RIB-in
- Son los prefijos que el router sondeado ha recibido de un peer, antes de la aplicación de las políticas de enrutamiento de importación.
- El Adj-RIB-out
- Son los prefijos que el router sondeado ha anunciado a un peer, tras la aplicación de las políticas de enrutamiento de exportación.
Además, se están implementando mecanismos de telemetría mejorados para recuperar estadísticas de tráfico significativas. En conjunto, una solución así es definitivamente factible en un futuro a medio plazo.
Este es otro ejemplo de un verdadero reto del cliente que puede resolverse en la era SDN mediante una centralización parcial del proceso de decisión a través de la inteligencia incremental. Y es otro caso de automatización y abstracción.
La sucursal
Los servicios ofrecidos en la sucursal han sido sustancialmente estáticos. Los SP están buscando formas de ofrecer servicios más dinámicos que el cliente pueda incluso autoproveerse. Estos servicios pueden reducir los gastos operativos delegando algunas tareas en el cliente, y al mismo tiempo ayudar a aumentar los ingresos mediante una adopción más rápida del servicio (aprovisionamiento de servicios al cliente "apuntar y hacer clic") y nuevos modelos de negocio (probar y comprar).
Ésta es una vieja aspiración de los SP y ha sido objeto de tecnologías tradicionales como servidores de políticas, PCRF, Radius/CoA y similares. Por ejemplo, el llamado Botón Turbo, con el que el cliente puede aumentar temporalmente el ancho de banda de su conexión de banda ancha, o los portales de autoaprovisionamiento que lo permiten, entre otras posibilidades, existen en la industria desde hace muchos años. Sin embargo, ahora el mercado y el negocio están en alza y cada vez más SP están interesados en ofrecer activamente estas opciones.
Hoy, en la era SDN, la presión empresarial amenaza la sostenibilidad, por lo que aumentar los ingresos se convierte en una necesidad mediante la oferta de servicios más flexibles. Esto supone una oportunidad para las nuevas soluciones emergentes basadas en controladores centralizados que implementan una configuración de servicios flexible y automatizada.
Aunque estos escenarios utilizan tecnologías existentes y no representan ningún cambio arquitectónico radical, todos estos casos de uso representan una combinación inteligente de uno o más de los siguientes atributos:
-
Automatización y abstracción
-
Complementar la inteligencia de la infraestructura existente
-
Hacer más dinámicas las decisiones de la red
-
Desacoplar la superposición de la subyacente para escalar
Estos atributos son los que los autores pretenden aplicar a los numerosos capítulos del libro sobre MPLS, convirtiéndolo fundamentalmente en una herramienta clave en la era SDN.
Get MPLS en la era SDN now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
