Practicando MPLS: Primeras configuraciones

Como comentaba en la entrada anterior, vamos a empezar a realizar algunas prácticas desde cero para intentar comprender las configuraciones y así ir complicando el escenario según vallamos asentando conocimientos para hacerlo lo más real que podamos.

Vamos a utilizar el emulador de red GNS3 con el que podemos cargar las imágenes IOS que necesitemos y así disponer de todos los comandos y configuraciones. En la página Artículos por fascículos de este mismo blog, podéis encontrar la serie Emulador de Red donde se describe el uso de herramientas como Dinamyps/Dinagen y GNS3, así como otras funcionalidades como hipervisores para repartir la carga del programa.

El escenario que vamos a desarrollar es el siguiente:

El direccionamiento de los PEs utilizado es:

Vamos a introducir un concepto clave dentro de las redes MPLS, los VRFs (Virtual Routing Forwarding), routers virtuales que aíslan el tráfico de los clientes dentro de la red MPLS, aún utilizando el mismo direccionamiento.

Los VRFs se definen principalmente con un Nombre y un valor numérico llamado RD (Route Distinguisher) que identifica a cada cliente. Además, y como punto fundamental, tenemos el concepto RT (Route Target) con el que podemos exportar e importar la información de una VRF.

Me ha gustado la siguiente definición del estándar BGP/MPLS (RFC-4364):

"A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address. If several VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in several different VPNs, it is possible for BGP to carry several completely different routes to that address, one for each VPN."

Nos dice que el campo RD, de 8 Bytes de tamaño, junto con una dirección IPv4 (4 Bytes) definen una dirección VPN-IPv4 (VPNv4) de 12 Bytes de tamaño, que identifica de forma única la VPN de un cliente utilizando el protocolo BGP inclusive usando el mismo direccionamiento IP.

La cabecera VPNv4 (12 Bytes) anteriormente comentada obviando los 4 Bytes menos significativos correspondientes a la dirección IPv4, constan de un campo Tipo (2 Bytes) y otro Valor (6 Bytes) del que existen tres tipos:

* Type 0 (ASN:nn): En este primer caso se utiliza el sistema autónomo de BGP (ASN), de 2 Bytes de tamaño, junto con un valor numérico que identifique únicamente la VRF (4 Bytes).
* Type 1 (IPv4:nn): En este caso, en el primer campo se utiliza una dirección IP de 4 Bytes de tamaño junto un valor numérico identificativo de 2 Bytes.
* Type 2 (ASN:nn): Éste último es inverso al primero, el campo correspondiente al ASN ocupa 4 Bytes de tamaño mientras que el valor numérico único ocupa 2 Bytes.

En nuestro caso vamos a utilizar el modelo ASN:nn, donde utilizaremos los 2 o 4 primeros Bytes de tamaño dependiendo del valor ASN que configuremos en nuestro routing BGP.

La gracia de todo esto es que tenemos disponibles políticas de exportación e importación de rutas, pudiendo importar la información no sólo de nuestra VRF sino también de otras que sean necesarias. Intentaré hacer algún ejemplo para que se entienda mejor con la práctica.

En relación a los Route Targets, el estándar citado anteriormente define:

"When a VPN-IPv4 route is created (from an IPv4 route that the PE has learned from a CE) by a PE router, it is associated with one or more Route Target attributes.  These are carried in BGP as attributes of the route.

[...]

Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic that is received from the corresponding sites."

Que en pocas palabras nos viene a decir que cuando se crea una dirección VPNv4 se asocia con uno o más RT y que asociando un RT a una VRF podremos utilizar el tráfico que aprendamos por la misma.

La configuración que utilizaremos para nuestras VRFs sera la siguiente:

Y el direccionamiento de cada cliente (VRF):

Manos a la masa

Vamos añadiendo equipos al escenario hasta que tenemos la siguiente topología:

* Configuración Inicial:

En primer lugar deberemos de configurar ciertos servicios y protocolos, así como desactivar ciertos comportamientos molestos. En mi caso, realizo la siguiente configuración:

! Services and features

no ip domain-lookup

no logging console

logging buffered 100000

no ip http server

service password-encryption

!

! Hostname

hostname <Hostname>

!

! Conf MPLS

mpls label protocol ldp

mpls ldp loop-detection

mpls ldp explicit-null

* Configuración Interfaces

Vamos a configurar las interfaces que participarán en el core MPLS así como una interfaz Loopback para las sesiones iBGP entre los distintos PEs.

! Interface Loopback
interface Loopback 0
  description <Description>
  ip address <IP> <Mask>
!
! Interface WAN -> FastEthernet
interface FastEthernet <Number>
  description <Description>
  ip address <IP> <Mask>
  speed 100
  duplex full
  mpls ip
  ! Depend of IOS version and platform
  ! 'override' word is mandatory
  mpls mtu [override] 1520
  no shutdown

Comprobamos que tenemos conexión entre las interfaces directamente conectadas:

Comando: ping <IP>

* Routing IGP

Como comentaba en la entrada anterior, para la conexión de los P y PEs vamos a utiliza el protocolo OSPF en el que definiremos el área 0 para las redes del core.

! Routing OSPF
router ospf 100
  log-adjacency-changes
  network <Network> <Wildcard Mask> area <Number>

Pasados pocos minutos comprobamos que conocemos por OSPF las redes definidas en el peer vecino.

Comando: show ip route

* Routing MP-BGP

Como comentaba en la entrada anterior y un poco más arriba, debemos configurar el enrutamiento para la conexión VPNv4 entre los PEs. Estableceremos sesiones iBGP con el Sistema Autónomo 300 para la conexión con el peer vecino (neighbor) a través de la interfaz Loopback.

! Routing iBGP
router bgp <ASN>
  bgp log-neighbor-changes
  neighbor <IP> remote-as <ASN>
  neighbor update-source Loopback 0
!
address-family vpnv4
  neighbor <Neighbor> activate
  neighbor <Neighbor> send-community both

Comprobamos que existe comunicación BGP entre los PEs vecinos:

Comando: show ip bgp summary

* Creando Clientes

En este punto pasamos a crear los VRFs de los distintos clientes, en nuestro caso ROJA y VERDE utilizando los valores de la tabla anterior.

! Create VRF
ip vrf <VRF>
  rd <ASN>:<nn>
  route-target export <ASN>:<nn>
  route-target import <ASN>:<nn>
!
! Routing VRF IPv4 Address Family
router bgp <ASN>
!
address-family ipv4 vrf <VRF>
  redistribute connected

Comprobamos que la configuración es correcta y que todavía no tenemos asociada ninguna interfaz a las VRFs:

Comando: show ip vrf

* Configurando clientes

Vamos a realizar una configuración básica utilizando VLANs en interfaces FastEthernet y ni siquiera vamos a realizar subnetting, es un ejemplo simple para entender el enrutamiento MPLS y comprobar que podemos tener el mismo direccionamiento en distintas VRFs.

! Physic Interface -> FastEthernet
interface FastEthernet <Number>
  no shutdown
  speed 100
  duplex full
!
! VLAN Subinterface
interface FastEthernet <Number>.<VLAN>
  description <Description>
  encapsulation Dot1Q <VLAN>
  ! Define VRF before IP address
  ip vrf forwarding <VRF>
  ip address <IP> <Mask>

Y comprobamos que conocemos por BGP la red configurada en el nodo vecino:

Comando: show ip route vrf <VRF>

Y si probamos a lanzar pines por las distintas VRFs vemos que tenemos conexión con los equipos distantes.

Comando: ping vrf <VRF> <IP>

Comentarios

Recomiendo realizar la práctica con routers Cisco 2691 para la configuración de los PEs y utilizar una IOS de la familia 12.4 dado que es una de la más utilizadas actualmente. La última familia de IOS publicada por Cisco es la 12.5.

He realizado esta misma práctica, saltándome el switch, en un par de equipos físicos de la serie 1800 (Cisco 1841) con una IOS también de la familia 12.4 y la configuración, aunque básica es funcional.

En la siguiente entrada añadiremos un router P y otro PE al escenario y comentaremos las limitaciones surgidas con este tipo de configuraciones.

Un saludo, Brixton Cat.

Practicando MPLS: Introducción

Como hace poco comente por Twitter, últimamente he estado investigando y practicando con redes MPLS y como no podía ser de otra manera traigo algunos ejercicios que me gustaría compartir con ustedes.

Las siglas MPLS corresponden con el término Multi-Procotol Label Switching, donde el transporte de la información no se realiza conmutando paquetes como en las redes Ethernet IP tradicionales, sino etiquetas (Label Switching) al estilo de otras tecnologías de capa 2 como ATM.

MPLS es una tecnología escalable de alta disponibilidad y fácil de mantener que proporciona mecanismos para decidir qué camino tomar (ingeniería de tráfico), compartir direccionamiento en distintos clientes, configuraciones QoS para priorizar el tráfico, políticas de importación/exportación de rutas, etc. La gallina de los huevos de oro que se podría decir...

Caracterizado por una red mallada (full-mesh) de routers intermediarios, llamados P's (Provider), en los que se conectarán los equipos fronterizos, llamados PE's (Provider Edge), que darán servicio a los equipos de las sedes remotas, CE's (Customer Edge).

MPLS es un protocolo llamado de capa 2 y media, dado que añade una cabecera de 32 bits entre la capa de enlace (Layer 2) y la de red (Layer 3). Es posible que dicha etiqueta supere el MTU designado para el protocolo, por lo que es común modificar dicho valor en las interfaces que intervienen en el core.

La cabecera que se incorpora al paquete IP tradicional esta compuesta por los siguientes campos:

* Label: Valor numérico de 20 bits asociado al puerto por el que pasa el paquete dentro de la red MPLS.

* Exp: Campo experimental de 3 bits que se utiliza, por lo menos, para la priorización del trafico mediante QoS a través del campo CoS de la trama Ethernet (Si está disponible).

* Stack: Valor booleano de 1 bit de tamaño para indicar si el paquete es el último en ser transmitido.

* TTL: Valor de 8 bits de tamaño para indicar el tiempo de vida del paquete (Time To Live).

Para nuestras prácticas nos imaginaremos un núcleo repleto de routers P's y PE's que se conocerán utilizando algún protocolo IGP (Interior Gateway Protocol) mientras que para conectar los distintos CE's deberíamos utilizar  protocolos EGP (Exterior Gateway Protocol) como BGP (Border Gateway Protocol), aunque es posible utilizar otros como RIP (Routing Information Protocol).

En nuestro caso utilizaremos OSPF (Area 0) para el core MPLS e iBGP (AS 300) para la conexión entre los distintos PE's que configuremos.

Como comentaba anteriormente, las redes MPLS utilizan la conmutación de etiquetas y no revisan la MAC de origen o destino así como las correspondientes IP's de los paquetes. Aparte de mantener una tabla ARP, mantienen un listado donde se especifican los puertos utilizados por un cliente así como las etiquetas correspondientes.

Entre las distintas interfaces MPLS estableceremos túneles LDP's (Label Distribution Protocol) para distribuir la información. Cada equipo ira añadiendo y quitando etiquetas (Etiquetas) según el paquete vaya pasando por las interfaces (Puertos), entre o salga de algún router frontera.

Desde 1998 que algunas empresas del sector comenzaron a desarrollar tecnologías de switching y etiquetado de paquetes IP, hasta la actualidad en el que se ha convertido en un estandar IETF (RFC 3031). MPLS proporciona alta velocidad de enrutamiento y VPNs sobre redes IP con ingeniería de tráfico. Otras tecnologías como VPLS amplían las capacidades LAN de los clientes simulando un switch en la red del proveedor o GMPLS que permite crear túneles LSPs (Label-Switched Paths) sobre tecnologías de transmisión como SDH con la que cubrir grandes distancias.

Hasta aquí un pequeño resumen teórico de lo que suponen las redes MPLS y los distintos protocolos que se utilizan o se pueden utilizar. En siguientes entradas, pasaremos a realizar algunos ejercicios básicos e iremos ampliando y dificultando el escenario para "asemejarlo" a una situación real.

Un saludo, Brixton Cat.

Bash Script: Transferencias de zonas públicas

Hoy traigo un post sobre DNS y transferencias de zonas, tanto de forma teórica como práctica, pero también he de decir que en esta entrada no voy a descubrir nada nuevo sobre el protocolo o las maneras de explotarlo. Entremos en materia...

Introducción

El protocolo DNS es utilizado para la resolución de direcciones IP a nombres de hosts y dominios, de forma directa (nombre -> IP) e inversa (IP -> nombre). Tradicionalmente, utiliza el puerto 53 del protocolo de transporte UDP para el envio y recepción de consultas, aunque últimamente han surgido proyectos para la utilización de TCP para proteger dichas conexiones.

Cada dominio es considerado dentro del servidor como un ente independiente que recibe el nombre de zona y entre los registros que se pueden definir dentro de las zonas podemos encontrar:

* A. Resolución de nombre a IP.
* CNAME. Alias para un mismo host.
* PTR. Punteros para resolución inversa.
* MX. Servidores de correo electrónico.
* SRV. Localizador de servicios.
* TXT. Información en texto plano.

Dentro de la configuración de cada dominio, se define el campo SOA (Start of Authority) que se utiliza para realizar un control de cambios sobre dicha información. Puede ser configurado de manera manual o automática pero hay que tener en cuenta que a través de este valor, los servidores determinarán si la información es más reciente que la que tienen almacenada.

Debido a la estructura distribuida del protocolo, se utilizan las denominadas transferencias de zonas para retransmitir la información de servidores maestros hasta otros secundarios. Con ello se asegura la disponibilidad de los nombre de dominio consiguiendo una estructura jerarquizada de tipo árbol.

En caso que las zonas no estén correctamente configuradas, una tercera persona es capaz de obtener dicha información a través de los servidores maestros.

Consultas AXFR

Como comentaba anteriormente, las transferencias de zonas se utilizan para retransmitir los registros DNS entre servidores maestros y esclavos. Existen varias consultas que pueden ser realizadas a dichos servidores: completas (AXFR) e incrementales (IXFR).

Generalmente las transferencias de zonas se realizan utilizando el puerto 53 del protocolo TCP, aunque depende de la configuración del servidor así como de las herramientas que utilicemos.

Primero obtenemos la dirección IP del dominio

Se realiza una consulta SOA y queda a la espera de la respuesta, así se asegura que dispone de la última información sobre el dominio.

Posteriormente se realiza la propia consulta AXFR para obtener la información. En caso de visualizar la captura de red con Wireshark, nos muestra una petición y una respuesta para dicha consulta.

Podemos comprobar con más detalle que se establece la conexión

Se realiza la propia transferencia de zona, en la que se van añadiendo paquetes para formar la consulta.

Y se cierra la conexión

Herramientas

nsloouk

Nslookup es una de las herramientas que tradicionalmente se ha utilizado para la resolución de nombres DNS. Aunque se pueden añadir opciones al comando, su mayor potencial la obtenemos de forma interactiva:

Comandos: # nslookup
                    > set all
                    > dominio

Podemos realizar una consulta para obtener los DNS asociados al dominio

Comandos: > set q=NS
                    > dominio

O consultar cúal es el servidor maestro

Comandos: > set q=HINFO
                    > dominio

En este caso las transferencias de zonas no parecen funcionar, si lanzamos el comando ls o si visitamos el manual de la herramienta, vemos que no esta implementado.

Como comentaba anteriormente, también es posible realizar algunas consultas desde la línea de comandos

host 

La herramienta host también nos permite realizar consultas específicas sobre determinados registros, así como realizar transferencias de zonas.

Comando: host -t NS domain

Comando: host -l domain

En este caso, obtenemos un time out porque no ha conseguido conectar con el servidor, pero no significia que no puedan realizarse.

dig

Dig es un cliente en línea de comandos e interactivo para la resolución de nombres de dominios, viene incluida en la suite BIND y reemplaza a las herramientas anteriormente descritas. Debido al potencial y flexibilidad de la herramienta, es muy utilizado para la resolución de problemas relacionados con servidores DNS.

Para obtener los servidores de nombres asociados con el dominio objetivo, utilizaremos el comando:

Comando: dig NS domain

Para realizar la transferencia de zonas propiamente dicha utilizaremos:

Comando: dig axfr @NS domain

Automatización

Podemos utilizar las herramientas aqui descritas para crear scripts con los que automatizar y filtrar las consultas. En mi caso he creado un script en bash, ZoneTransfers.sh, que utiliza dig para obtener los servidores de nombres e intentar recopilar la información del dominio que pasemos como argumento del mismo.

Me he inspirado en el siguiente script del amigo Zerial, para obtener un listado único de nombres de hosts así como de direcciones  relacionadas con el dominio objetivo.




Recientemente he estrenado un repositorio público en Github donde almacenar los distintos scripts que vaya desarrollando, en él podeis encontrar este último así como un pequeño archivo README con la descripción del mismo.

Tened en cuenta que la transferencia de zonas es un ataque activo dado que consultamos directamente los servidores DNS objetivos. Esta entrada se publica de modo informativo y para un uso educativo del protocolo y las herramientas disponibles. En ningún caso se incita a los lectores a realizar dichas consultas y no me responsabilizo del uso que terceras personas puedan dar de esta información, así como los daños que puedan provocar.

Un saludo, Brixton Cat.

Python Script: ToSCalc.py

ToSCalc.py

En esta entrada se muestra el código fuente del script ToSCalc.py con el que calcular los distintos valores ToS y DSCP para configuraciones de calidades de servicio.

Sintaxis: ./TosCalc.py VALUE

VALUE corresponde a los posibles valores configurables dentro del campo IP Precedence o Class Selectors para la priorización de tráfico en las redes IP.

Código fuente:

#!/usr/bin/env python
#
# Name: ToSCalc.py
# Description: Calculate ToS and DSCP values for IP Precedence
# or Class Selector argument.
# Author: Brixton Cat
# Date: 10 Mar 2012
# Version: 0.1
# Sintax: ./ToSCalc.py VALUE
#

### Dependencies
import sys

### Functions
def Arguments(decimal):
    """ This function check the introduced argument and call ThreeBits
    function if the value is correct """

    # If not valid value, exit of script
    if decimal < 1 or decimal > 7:
        print "ERROR: %d not valid CS or IP Precedence value" % \
            decimal
        sys.exit(1)
    else:
        ThreeBits(decimal)

def ThreeBits(decimal):
    """ This function convert decimal argument to a 3 bits value and
    check correct lenght of this """

    # Array ['0', 'value']
    bina = bin(decimal).split('b')

    # If less of 3 bits, add 0s to left of binary variable
    if bina[1] < "3":
        rest = 3 - len(bina[1])
        binary = str(0) * rest + bina[1]
    else:
        binary = bina[1]
 
    # Run SixBits functions
    SixBits(decimal, binary)

def EightBits(decimal, binary, dscpb, dscpd):
    """ This function add 0s to right of tosb variable and run Results
    function with all prints values """

    # Rest of 8 and binary lenght
    rest = 8 - len(binary)
    # Type of Service binary value
    tosb = binary + str(0) * rest
    # Type of Service decimal value
    tosd = int(tosb, 2)

    # Call Results function with all values
    Results(decimal, binary, dscpb, dscpd, tosb, tosd)

def Main():
    """ Declare decimal variable and run Arguments function with
    this value """

    # Fisrt argument of the script
    decimal = int(sys.argv[1])
    # Run Arguments functions
    Arguments(decimal)

def Results(decimal, binary, dscpb, dscpd, tosb, tosd):
    """ Prints values relationated with IP Precedence or Class
    Selectors introduced argument"""

    # Header
    print "Value  3bits   DSCP Bin  DSCP   ToS Bin   ToS"
    print "-----  -----   --------  ----   -------   ---"
    # Values
    print "  %d\t%s\t%s\t  %d\t%s  %d" % \
        (decimal, binary, dscpb, dscpd, tosb, tosd)
 
def SixBits(decimal, binary):
    """ This function add 0s to right of dscpb variable and calculate
    their decimal value """

    # DSCP binary value
    dscpb = binary + str(0) * 3
    # DSCP decimal value
    dscpd = int(dscpb, 2)
 
    # Run EightBits function
    EightBits(decimal, binary, dscpb, dscpd)

### Script
Main()

### Exit
# Exit Codes
# 0 -> Normal exit
# 1 -> No valid argument
sys.exit(0)

#EOF
##FVE

En la siguiente entrada hay información sobre el mismo así como algunas pruebas multiplataforma.

Un saludo, Brixton Cat.

Python Script: Calculando calidades de servicio

Como hace poco he estado indagando sobre Quality of Service, Type of Service, Class Selectors y demás campos con los que priorizar el tráfico en las redes IP, he creado un script (ToSCalc.py) en Python que calcula los distintos valores decimales y binarios de estos.

El script recibe los posibles valores de nuestras configuraciones IP Precedence y Class Selectors, devolviendo los valores decimales y binarios para los campos Differentiated Services Code Points (DSCP) y Type of Service (ToS).

Como todavía estoy aprendiendo Python no he sido capaz de hacer una función ayuda, por lo que si se lanza el script sin argumentos falla.

Los posibles valores van del 0 al 7, por lo que en caso de introducir argumentos superiores o inferiores muestra un mesaje de error indicando que no es un valor válido.

Como el script necesita únicamente el módulo sys para recibir el argumento y para los código de salida, es compatible entre sistemas operativos sin necesidad de realizar ningún cambio.

Conclusiones

He de decir que estoy aprendiendo Python y el paradigma de la programación orientada a objetos.

El script funciona de manera secuencial dada la versatibilidad del lenguaje aunque utilizando la variable self propia de éste, sería mucho más simple e igual de funcional. Tal vez para versiones posteriores, alguien se apunta?

Un saludo, Brixton Cat.

Quality of Service: ToS, CoS y otros bits

Con los nuevos vientos provenientes del mundo del networking: Comunicaciones unificadas, redes convergentes, soluciones NGN, el tan llamado Cloud... Se hace cada vez más necesario la utilización de mecanismos para garantizar la conexión de las nuevas tecnologías de telefonía, video, Internet movil, telepresencia, etc.

Para ello, en 1994 el ITU define las calidades de servicio (Quality of Service) con las que asegurar las conexiones telefónicas así como corregir fallos como el eco, lentitud, ruido, etc. Estás han sido aplicadas a las redes de datos y han posibilitado la unificación de ambas tecnologías sobre un mismo soporte físico, como el uso de softphones.

Entrando un poco más en materia, vamos a bucear entre las cabeceras IP y Ethernet para entender cómo se reflejan las configuraciones de nuestros dispositivos.

Dado que utilizamos el modelo de capas basado en el modelo OSI, la pila TCP/IP difenrencia tareas y delega funciones entre ellas. Como transmitir en binario los impulsos eléctricos/ópticos enviados desde el puerto físico, utilizando la información lógica que proviene de las aplicaciones de usuario. Esto es en pocas palabras, si quieres una definición más exacta no sé que haces visitando éste blog... Ponte a estudiar de verdad cacho patán! : p

Layer 2

A nivel de trama, en la cabecera Ethernet se define el campo CoS (Class of Service) dentro de la etiqueta que añade el protocolo 802.1Q para discriminar tráfico a través de VLANs. Añadiendo 32 bits a la trama Ethernet donde se define un campo de 16 bits con valor 0x8100 para identificar las que son marcadas.

El resto de campos corresponden a:

- Priority Code Point (PCP): Los 3 bits más significativos restantes, los llamados Class Selectors que van del 0 (CS0) al 7 (CS7) para indicar el nivel de prioridad de menor a mayor numericamente.
- Cannonical Format Indicator (CFI): Debido a un fallo de implementación a la hora de transmitir la dirección MAC (dcha->izq VS izq->dcha), se establece éste valor booleano. Y hasta aqui puedo hablar...
- VLAN Identifier: Campo de 12 bits que corresponde al identificador de la VLAN con la que se marcarán los paquetes. Los valores 0x000 y 0xFFF están reservados pudiendo definirse 4096 redes virtuales según el estandar.

Layer 3

A nivel de red, en capa 3, se utilizan 8 bits de la cabecera IPv4 para definir el campo ToS (Type of Service) del que se utilizan los tres bits más significativos para definir la precedencia (IP Precedence). El bit menos significativo debe valer 0. ¿Alguien capaz de explicarlo?

En diciembre de 1998, se restructura y se definen los Differentiated Services Code Points (DSCPs) que utilizan los 6 bits más significativos del campo. Los dos bits restantes definen el Explicit Congestion Notification (ECN), que se utiliza para informar que se están rechazando paquetes por congestión.

Relaciones

Dado que inicialmente se utilizaba IP Precedence para definir las calidades de servicio junto con los Class Selectors, en la siguiente tabla se muestra la relación entre ambos:

Como comentaba anteriormente, en 1998 se definen los códigos DSCP que proporcionan más opciones con las que controlar el tráfico. La siguiente tabla muestra la relación entre ellos:

Dado que los códigos DSCP proporcionan mayor granularidad, en esta tabla se muestran las relaciones entre DSCP, IP Precedence y Class Selectors:

Se introduce el concepto de AF (Assured Forwarding) que completa y proporciona todo un nuevo sistema de control de tráfico.

Posibilita la retrocompatilibidad y utiliza el campo que se añade para generar un sistema con el que diferenciar los paquetes.

Precedence                   ECN
      000     |    XX YY    |    00
        Priority (Class+Level)

Hibrido L2/L3

He de decir que a nivel de ISP, en los cores de red: MPLS/VPLS hasta donde conozco, también se utilizan las QoS para priorizar tráfico. Sino hay concordancia entre el equipo final y el de central, mal vamos... luego vienen las averias : p

Como no tengo mucha experiencia sobre el tema y la documentación que he encontrado es un poco abstracta... Sólo puedo decir que se utiliza el campo experimental de la cabecera MPLS (Exp), de 3 bits de tamaño, para arrastrar el valor establecido en la trama Ethernet (L2). Eso tengo entendido, ¿Alguien nuevamente puede corregir?

Enlaces

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd803e5269.html
http://mccltd.net/blog/?p=1199
http://www.pbxphreak.com/QoS/
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp62023
http://bogpeople.com/networking/dscp.shtml
http://www.network-core.net/2010/02/comparacion-entre-ip-precedence-y-dscp.html
http://blog.ine.com/2010/02/21/the-mpls-forwarding-plane/

Un saludo, Brixton Cat.