MPLS (Multi Protocol Label Switching) – parte 2

Como iniciado no primeiro post, em uma rede com arquitetura MPLS cada roteador da topologia possui uma designação que define a sua posição e atribuição na topologia:

  • CE (Customer Edge Router) – possui a função de prover conectividade para a rede MPLS e é situado na “borda do cliente”. Não encaminha e nem troca labels.
  • PE (Provider Edge Router) – é responsável pela conexão entre uma rede IP (rede do cliente) e a rede MPLS (rede da Operadora/Provider)
  • P (Provider Edge Router) – é responsável pelo encaminhamento de pacotes baseando-se nos labels.

Label Switch Router

Diversas documentações também atribuem um nome mais genérico para roteadores que tratam o recebimento e encaminhamento de pacotes MPLS, chamados de Label Switch Routers(LSR). Na topologia, os LSR podem ser chamados de:

  • Ingress LSRs – responsáveis por receber um pacote não “rotulado” e inserir o Label
  • Egress LSRs – responsáveis por receber um pacote “rotulado” e remover o Label
  • Intermediate LSRs – responsáveis por inserir, encaminhar e trocar Labels.

Os Roteadores LSRs são responsáveis por três operações principais para encaminhamento de pacotes e/ou labels: POP (remover o label), PUSH (inserir o label) ou SWAP (trocar o label).

A seqüência de Roteadores LSRs que são responsáveis pela comutação de um pacote com label em uma rede MPLS, é chamada de LSP (Label Switched Path).

O LSP é definido como o caminho por onde os pacotes irão passar numa rede MPLS. No momento em que um pacote entra numa rede MPLS, este é associado a uma classe de equivalência (FEC) e assim é criado um LSP relacionado a esta FEC.

Como a criação de uma LSP só ocorre na entrada de uma rede MPLS, os LSR ( Label Switch Router) da nuvem só terão o trabalho de fazer as trocas dos rótulos (swap), encaminhando assim o pacote de acordo com o LSP determinado anteriormente, não havendo mais a necessidade de fazer o roteamento dos pacotes (somente a comutação via Label).

Protocolos de distribuição de Labels

Atualmente são utilizados 2 principais protocolos para distribuição de Rótulos em uma rede MPLS, (daremos um foco especial no LDP):

  • Label Distribution Protocol (LDP)
  • Resource Reservation Protocol – Traffic Engineering (RSVP-TE)

O vinculo de Rótulos é a associação de um label a um prefixo (rota). O LDP trabalha em conjunto com um IGP (OSPF, IS-IS, etc) para anunciar os vínculos de labels (binding) para as rotas, como por exemplo, em um backbone. Conforme desenho abaixo:

Resumidamente, é atribuído um valor de label para cada prefixo. No exemplo abaixo segue o exemplo da configuração do LDP em um Roteador P com o processo OSPF em um roteador com IOS Cisco.

Exemplo de Configuração do Roteador P

ip cef
mpls ip
mpls ldp router-id loopback 0
!
int loo 0 
ip add 10.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.1.5 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.1.1 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.1.4 0.0.0.3 area 0
 network 10.2.2.2 0.0.0.0 area 0
!
----------------------------------------------

R2#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
23     Pop tag     10.1.1.0/30       636      Fa0/0      point2point
24     Pop tag     10.1.1.4/30       641          Fa0/1      point2point
25     26          192.168.1.0/24    234          Fa0/0      point2point
26     30         192.168.1.0/24     143          Fa0/1      point2point
27     28         192.168.2.0/30     143          Fa0/1      point2point
-
R2#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.2.646 - 10.1.1.1.11012
        State: Oper; Msgs sent/rcvd: 21/21; Downstream
        Up time: 00:10:29
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 10.1.1.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        
    Peer LDP Ident: 10.1.1.6:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.6.11000 - 10.1.1.5.646
        State: Oper; Msgs sent/rcvd: 28/31; Downstream
        Up time: 00:16:00
        LDP discovery sources:
          FastEthernet0/1, Src IP addr: 10.1.1.6
        Addresses bound to peer LDP Ident:
          10.1.1.6        192.168.1.0      192.168.2.0


Referências

http://www.gta.ufrj.br/grad/04_2/MPLS/conceitos.htm
http://blog.ccna.com.br/2008/09/12/multi-protocol-label-switching-mpls-parte-3/

Roteamento entre VRFs com MP-BGP

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamento virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.

A configuração de VRFs é bem simples. Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para  nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…

Habilitando o import e export das VRFs

Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)

RD

Como explicado anteriormente,  as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .

O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente  como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.

O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.

R1(config-vrf)#rd ?
  ASN:nn or IP-address:nn  VPN Route Distinguisher
! Configurando a VRF para os clientes A B e C 
ip vrf Cliente_A
 rd 65000:1
!
ip vrf Cliente_B
 rd 65000:2
!
ip vrf Cliente_C
 rd 65000:3

Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.

RT
Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.

O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).
Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.

!
ip vrf Cliente_A
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1
 route-target import 65000:2
!
ip vrf Cliente_B
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2
 route-target import 65000:1
!
ip vrf Cliente_C
 rd 65000:3
 route-target export 65000:3
 route-target import 65000:3
!

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip vrf forwarding Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip vrf forwarding Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip vrf forwarding Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf Cliente_A
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_B
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_C
 redistribute connected
 no synchronization
 exit-address-family
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs e o teste de ICMP

R1#show ip route vrf Cliente_A
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
B 2.2.2.0 is directly connected, 00:08:22, Loopback2
R1#ping vrf Cliente_A 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms



Para dúvidas ou sugestões deixe um comentário.

MPLS (Multi Protocol Label Switching)

Apesar de existirem inúmeros sites em português com ótimas referencias de Introdução ao Protocolo MPLS, escreveremos uma serie de artigos com a utilização de MPLS em diversos cenários. Esse post servirá como uma pequena introdução para a descrição e utilização do protocolo com o foco um pouco mais simples na arquitetura e serviços.

O protocolo MPLS (Multi Protocol Label Switching) foi criado para permitir o encapsulamento de diversos protocolos de rede para serem encaminhados por Roteadores baseando-se apenas no endereço do Label ao invés do endereço de rede. A tecnologia é largamente utilizada pelos Provedores de Internet com diversas topologias de serviços orientado a redes em apenas uma única rede convergida com o MPLS em seu Backbone, permitindo a utilização de Redes Privadas (VPNs MPLS), Qualidade de Serviço (QoS), Any Transport over MPLS (AToM) e Engenharia de tráfego (MPLS-TE).

Ele é chamado de Multiprotocolo pois é utilizado com qualquer protocolo da camada de Rede e em certos cenários permite até o transporte de protocolos da Camada de Enlace sobre MPLS, apesar de quase todo o foco estar voltado no uso do MPLS com o IP.

O objetivo de uma rede MPLS dentro dos Provedores de Serviço não é o de conectar diretamente a sistemas finais.  Ao invés disto ela é uma rede de trânsito, para transporte de pacotes.

Em sua função básica os Roteadores do Backbone chamados de Provider Routers (P) encaminham o tráfego baseando-se apenas nos Labels.  Já os roteadores que são responsáveis por receber os pacotes IP e encapsulá-los com labels em uma rede MPLS são chamados de Provider Edge Routers (PE).

A terminologia dada aos equipamentos em uma rede MPLS é muito importante para identificarmos a função de cada equipamento na topologia e a sua função na arquitetura.

De certa forma, um cliente ao comprar uma comunicação entre as filiais utilizando um link MPLS privado (MPLS VPN), não terá necessariamente em seus roteadores o encaminhamento de pacotes via labels e muito menos a troca deles. Os roteadores designados para clientes, chamados de Customer Edge Routers (CE) possuem a função de prover conectividade na rede MPLS situados na “borda do cliente” (saída para rede).

A conectividade entre PE e CE poderá ser tanto provida por roteamento estático ou via IGP.

Mas o que são os Labels?

Em uma tradução literal, poderíamos dizer que label teria a atribuição de um rótulo. Em sua função no modo frame o label é inserido na frente do cabeçalho da camada de rede. Um pacote pode ter um ou mais rótulos dependendo do serviço oferecido na rede MPLS.

O label é um identificador, de tamanho fixo e significado local. Todo pacote ao entrar numa rede MPLS recebe um label. Desta forma os roteadores só analisam os labels para encaminhar os pacotes. O cabeçalho MPLS deve ser posicionado depois de qualquer cabeçalho da camada de enlace e antes do cabeçalho da camada de rede, ele é conhecido como Shim Header pelo seu posicionamento entre os 2 cabeçalhos e é “carinhosamente” chamado de protocolo da camada 2,5.do Modelo OSI.

Nos próximos posts daremos foco no processo de encaminhamento e troca de labels, outros termos comuns em uma rede MPLS e a configuração de Roteadores para a troca de labels.

Um grande abraço

Referências:

http://www.gta.ufrj.br/grad/01_2/mpls/mpls.htm
http://pt.wikipedia.org/wiki/MPLS
Designing and Implementing, IP/MPLS-Based Ethernet Layer 2 VPN Services, An Advanced Guide for VPLS and VLL, Zhuo ( Frank) Xu – Wiley Publishing, INC – 2010
MPLS Fundamentals, Luc De Ghein. – Cisco Press – 2006
TCP sobre MPLS, ENNE, ANTONIO JOSE FIGUEIREDO – Ciência Moderna – 2009