Implementação MPLS TE

Como havia falado na matéria anterior, vamos mostrar agora como implementar o MPLS TE.

O primeiro passo na configuração é habilitar o MPLS TE através do comando global mpls traffic-eng tunnels, em todos os roteadores que participarão da arquitetura MPLS TE. Além disso, é necessário ativar MPLS TE em todas as interfaces que participarão da arquitetura MPLS TE.

Todos os roteadores devem, obrigatoriamente, estar com a funcionalidade CEF (Cisco Express Forwarding) habilitadas para permitir a ativação do MPLS. Esta funcionalidade é habilitada com o comando ip cef no modo de configuração global do roteador. A seguir será mostrada a configuração necessária para habilitar MPLS TE nos roteadores. !
¡ habilita o CEF

ip cef ¡
¡ habilita o MPLS TE no modo de configuração global

mpls traffic-eng tunnels ¡
interface pos2/1

.
.

! habilita MPLS TE nas interfaces dos roteadores
mpls traffic-eng tunnels

!
Caracterizando os Enlaces
A caracterização dos enlaces envolve a configuração dos atributos dos enlaces que participarão da arquitetura MPLS TE. Após a configuração destas características é necessário configurar o protocolo OSPF para divulgá-las.

Os enlaces são caracterizados de acordo com a banda reservável, o Affinity e a Métrica TE. Uma vez configurados estes atributos, eles serão divulgados pelo protocolo OSPF. Desta forma o roteador divulgará a informação de banda disponível, Affinity, e a Métrica TE de todas as conexões que estão envolvidas na Arquitetura MPLS TE.
A informação da banda reservável para MPLS TE é configurada através do comando ip rsvp bandwidth que é inserido em cada interface onde será utilizado o MPLS TE. O parâmetro - - de banda máxima reservável por fluxo não tem relevância para o MPLS TE, portanto, é necessário configurar apenas a banda reservável total.

Os túneis MPLS TE podem ter sete níveis de prioridades. Isto significa que um túnel tem precedência sobre um outro túnel de menor prioridade. Em conseqüência disso, as informações da banda reservável e alocada numa interface são divulgadas para cada nível de prioridade. Por exemplo, se um túnel 0 com prioridade 7 alocar 70 Mbps de uma interface FastEthernet (100 Mbps), restarão 30 Mbps para serem alocados pelos túneis com a mesma prioridade, no entanto, para os túneis com prioridade melhor, poderá ser alocado 100 Mbps. Dessa forma, se for requisitada, por um túnel com prioridade 1, uma reserva de 70 Mbps na mesma interface FastEthernet, o túnel com prioridade 7 terá de encontrar outro caminho que atenda os seus requisitos, pois o túnel com prioridade 1 tem precedência sobre o túnel de prioridade 7.

O atributo Affinity de um enlace se refere a um Flag de 32 bits que podem ser utilizados para determinar a característica de um enlace. Esta característica é configurada através do comando mpls traffic-eng attribute-flags <0x0> inserido em cada interface. Se este comando não for configurado na interface, o OSPF divulga o valor default que é igual a 0x0.

A métrica do TE é configurada utilizando o comando mpls traffic-eng administrative-weight em cada interface onde será utilizado o MPLS TE. Se não for utilizado este comando na interface, a métrica TE divulgada será igual à métrica do protocolo OSPF.

A seguir será mostrado um exemplo da configuração necessária para habilitar MPLS TE e configurar os atributos de uma interface.

¡ habilita o CEF

ip cef ¡
¡ habilita o MPLS TE no modo de configuração global

mpls traffic-eng tunnels ¡
interface pos2/1

.
.

! habilita MPLS TE nas interfaces dos roteadores
mpls traffic-eng tunnels

! configura o atributo affinity do enlace
mpls traffic-eng attribute-flags 0x00000001

! configura a métrica do TE
mpls traffic-eng administrative-weight 2

! configura a banda reservável
ip rsvp bandwidth 2500000

!
Adiante vou descrever as recomendações para a utilização de Affinity, Prioridade e Métrica do TE. Porém, antes é recomendável o entendimento de algumas funcionalidades dos túneis MPLS TE, necessárias para a leitura destas recomendações. Estas funcionalidades estão descritas a seguir.

Divulgando informações de MPLS TE
Exemplo utilizando o protocolo OSPF para a divulgação dos prefixos internos que será também usado para a divulgação das informações de MPLS TE. A Tabela mostra, de maneira consolidada, as informações de MPLS TE que são divulgadas pelo LSA tipo 10 do OSPF.


















Estas informações são divulgadas pelo processo de flooding do OSPF. Para prevenir uma grande quantidade de flooding na rede, o OSPF divulga estas informações baseando-se em três regras descritas a seguir.A primeira regra faz com que o roteador divulgue estas informações quando a banda alocada numa interface atinge limiares pré-definidos. Por exemplo, se a banda alocada numa interface representa um acréscimo de 1 por cento da banda reservável, e um novo túnel reserva uma banda que resulta numa alteração percentual da banda reservada igual a acréscimo de 15 por cento, o roteador divulgará imediatamente estas alterações via OSPF. A mesma regra vale quando há decréscimo do percentual de reserva.
Estes limiares pré-definidos podem ser alterados, porém, recomenda-se a adoção dos valores default. Os limiares default têm os seguintes valores válidos em ambas as direções, ou seja, quando há uma variação positiva ou negativa: 15, 30, 45, 60, 75, 80, 85, 90, 95, 96, 97, 98, 99 e 100.
O comando para alterar os valores default está descrito a seguir e é aplicado por interface.
mpls traffic-eng flooding thresholds {up down} <0>
A segunda regra faz com que os roteadores divulguem estas informações periodicamente. O valor default é 180 segundos. Recomenda-se não alterar este valor no início da implementação, pois depois da implementação pode-se ter uma idéia do sincronismo destas informações entre os roteadores e, assim, decidir qual o melhor valor a ser utilizado. O comando para alterar os valores default está descrito a seguir.
mpls traffic-eng flooding timers periodic-flooding <0-3600>
A terceira faz com que o roteador divulgue imediatamente estas informações quando há um erro. O RSVP envia um erro quando uma mensagem Path requisita reserva numa interface, e o roteador sinaliza que não há banda disponível na mesma. Este erro significa que as informações não estão sincronizadas entre todos os roteadores, e assim faz-se necessário um flooding para obter uma informação atualizada.
Para que o OSPF passe a divulgar as informações de MPLS TE, os seguintes comandos são necessários.
! habilita o roteamento OSPFrouter ospf
! define o RID TEmpls traffic-eng router-id loopback100
! Ativa o TE na Areampls traffic-eng area 0
!
Como visto acima, definimos a loopback100 para ser o router ID do MPLS TE da rede .Todo o OSPF está operando numa única área 0. Isto simplifica a adoção do MPLS TE.
Definição do Túnel MPLS TE
Com a configuração do OSPF para a divulgação de informações de MPLS TE e a caracterização dos enlaces, estara pronta para a ativação dos túneis MPLS TE. A ativação do túnel TE necessita da definição dos seguintes atributos do túnel:
- nós Headend e Tailend;- banda requerida;
- prioridade;- afinidades (affinities) incluídas ou excluídas do caminho;
- nós incluídos ou excluídos do caminho;- recuperação rápida requerida (Fast Reroute).
As configurações do túnel são realizadas no roteador Headend no qual deve ser especificado o roteador Tailend do túnel. Os roteadores presentes no caminho entre o roteador Headend e Tailend de um túnel são denominados de Midpoint. A configuração a seguir mostra um exemplo dos comandos necessários no roteador Headend.
! Ativa a interface Túnel 1interface Tunnel1
ip unnumbered Loopback100! define o roteador Tailend
tunnel destination 10.140.1.11! define o modo do túnel
tunnel mode mpls traffic-eng
Especificação da Banda Requerida Pelo Túnel
A banda requerida pelo túnel é especificada pelo comando tunnel mpls traffic-eng bandwidth . Se este comando não for especificado, a banda sinalizada pelo túnel será igual a zero. Portanto, na implementação dos túneis MPLS TE será necessário determinar a banda sinalizada pelo túnel. Porém, inicialmente, o túnel pode ser estabelecido sem esta especificação a fim de determinar, através da monitoração, a banda necessária e ajustar o valor da banda do túnel com este comando. O tráfego transportado pelo túnel pode ser monitorado pelo comando show interface tunnel do IOS Cisco.
A outra estratégia para especificar a banda requerida de um túnel é utilizar a feature do IOS Cisco denominada de Ajuste Automático de Banda (Auto-BW). Com a utilização desta feature, os túneis ajustam a banda automaticamente de acordo com o tráfego transportado. Este ajuste é realizado, por default, após um período de monitoração de 24 horas utilizando coletas realizadas a cada 5 minutos. Para ativar esta feature é necessário inserir o comando tunnel mpls traffic-eng auto-bw na interface túnel e ativá-lo no modo de configuração global através do seguinte comando: mpls traffic-eng auto-bw timers 330. Este comando, além de habilitar o Auto-BW no roteador, define o período em segundos da coleta de banda na interface túnel.

Especificação da Prioridade do Túnel

A prioridade é outra característica que está associada aos túneis MPLS TE. O túnel pode ter uma escala de prioridade de 0 até 7, sendo que o valor menor de prioridade tem precedência sobre o de valor maior. Cada túnel pode ter duas prioridades: Setup e Hold. A prioridade Setup de um túnel que está sendo ativado é comparada com prioridade Hold de um túnel já estabelecido. Para ilustrar esta definição, considere o exemplo mostrado na abaixo. O túnel 1 já foi ativado e alocou uma reserva de 80 Mbps de um enlace de 100 Mbps. Agora suponha que seja ativado um túnel 2 no mesmo caminho utilizado pelo túnel 1 e com uma demanda de banda de 80 Mbps. Como a banda de 100 Mbps não é suficiente para os dois túneis, a prioridade de Setup do túnel 2 é comparada com a prioridade Hold do túnel 1. Em conseqüência disso, o túnel 2 terá preferência, pois a prioridade Setup (5) do túnel 2 é melhor do que a prioridade Hold (7) do túnel 1. A reserva será estabelecida para o túnel 2 fazendo com que o túnel 1 seja desativado, pois não há outro caminho que atenda aos seus requisitos.






























Para especificar a prioridade de um túnel é necessário utilizar o seguinte comando na interface túnel:
tunnel mpls traffic-eng priority
Se este comando não for especificado, o túnel terá uma prioridade de Setup e Hold igual a 7.

Especificação do Affinity do Túnel

O Affinity de um túnel é utilizado para incluir ou excluir circuitos do caminho entre o Headend e o Tailend. Para isso, o Affinity do túnel representado por 32 bits é comparado com o Affinity configurado nos enlaces. O comando para especificar o Affinity do túnel é mostrado a seguir.
tunnel mpls traffic-eng affinity <0x0> mask <0x0>
O parâmetro máscara (mask) do comando é utilizado para identificar os bits do affinity do túnel que vão ser comparados com os bits do affinity do enlace. Para isso, o bit da máscara com valor 1 identifica o bit da string do affinity que será comparado. Por exemplo, ser for configurado um túnel com affinity 0x000000001 e máscara 0x00000001, significa que o primeiro bit da string affinity do túnel será comparado com o primeiro bit do affinity dos enlaces. Portanto, como o primeiro bit da string affinity do túnel tem valor igual a um, o túnel utilizará somente os enlaces cujo primeiro bit seja igual a 1.Se este comando não for especificado, o túnel terá um affinity default 0x00000000 e uma máscara 0xFFFFFFFF.

Especificação do Caminho do Túnel

O caminho utilizado pelo túnel é calculado pelo algoritmo CSPF e é baseado nos atributos especificados no túnel. Ele pode ser determinado dinamicamente ou explicitamente. A determinação explícita permite definir os nós do caminho por onde o túnel passará até o roteador Tailend. A determinação dinâmica faz com que o túnel defina o melhor caminho automaticamente. A especificação do caminho de um túnel permite definir várias opções de caminhos diferenciados por níveis de preferência. Por exemplo, o túnel utilizará a primeira opção, mas se este caminho não atender aos requisitos de banda e Affinity, será verificada a possibilidade da utilização da segunda opção e assim por diante.

O exemplo seguinte de configuração de túnel apresenta duas opções de caminhos.
Na configuração abaixo, a opção 10 é a prioritária e ela define um caminho explícito, mas se este caminho não atender os requisitos do túnel, será utilizada a opção 20 que determina o caminho automaticamente.

interface tunnel 1.
.! define a primeira opção explícita de caminho
tunnel mpls traffic-eng path-option 10 explicit identifier 1_r1/r2/r3! define a segunda opção dinâmica de caminho
tunnel mpls traffic-eng path-option 20 dynamic

A ordem de preferência do caminho começa da opção com menor número. Na definição explícita é necessário criar um explicit-path especificando o caminho a ser utilizado pelo túnel.

! configura o explicit-pathip explicit-path name 1_r1/r2/r3
! especifica os next-hop do caminho do túnelnext-address 192.168.3.2
next-address 192.168.4.2next-address 192.168.1.3

Exemplo de Configuração Básica de um Túnel

Para exemplificar a configuração básica de um túnel MPLS TE, considere a topologia mostrada na Figura abaixo. Como pode ser visualizado, será estabelecido um túnel MPLS TE entre o roteador Headend R1 e o roteador Tailend R3. Este túnel sinalizará uma requisição de banda de 100 Kbps.











A seguir será mostrada a configuração aplicada no roteador Headend R1. A configuração mostra os comandos necessários para o MPLS TE no roteamento OSPF, nas interfaces e na definição do Túnel.

! Habilita CEF ip cef
! Habilita o TE no roteadormpls traffic-eng tunnels ! !
interface Loopback100ip address 10.129.1.11 255.255.255.255 ! !
! Ativa a interface Túnel 1interface Tunnel1
ip unnumbered Loopback100! define o roteador Tailend
tunnel destination 10.130.1.11! define o modo do túnel
tunnel mode mpls traffic-eng! define a forma de encaminhamento do tráfego
tunnel mpls traffic-eng Autoroute announce! define a prioridade do túnel
tunnel mpls traffic-eng priority 7 7! reserva de banda sinalizada pelo Túnel
tunnel mpls traffic-eng bandwidth 100! O estabelecimento do caminho será dinâmico
tunnel mpls traffic-eng path-option 10 dynamic! armazena as informações dos next-hop do caminho utilizado
tunnel mpls traffic-eng record-route ! ? facilita troubleshooting! !
interface Serial2/0bandwidth 125
ip address 10.129.55.1 255.255.255.252! Habilita o TE na Interface
mpls traffic-eng tunnels! Define a banda reservável na interface
ip rsvp bandwidth 100 !
router ospf 1network 10.129.1.11 0.0.0.0 area 0
network 10.129.55.1 0.0.0.0 area 0! Define a Loopback 100 como RID
mpls traffic-eng router-id Loopback100! Habilita TE na área 0
mpls traffic-eng area 0

O comando tunnel mpls traffic-eng record-route ativa o registro dos endereços IPs de todos o Hops do caminho utilizado pelo túnel e o registro do label nas mensagens do RSVP. Este comando é recomendável porque facilita o processo de resolução de problemas.

Encaminhando o Tráfego no Túnel

Após a ativação do túnel MPLS TE é necessário definir o tráfego que será encaminhado pelo mesmo. Há seis métodos que podem ser utilizados, no roteador Headend, para encaminhar o tráfego pelo túnel:- Rotas Estáticas.

- Policy-Based Routing (PBR).- Autoroute.

- Forwarding Adjacency.- Pseudowire Class.

- Class-Based Tunnel Selection.

Para a encaminhar o tráfego no túnel utilizando rotas estáticas, é necessário definir os prefixos de rede que serão acessíveis via túnel. A seguir será mostrado um exemplo de uma rota estática apontando para o túnel.

¡ [cor2]todos os pacotes destinados ao prefixo 200.165.0.0 serão encaminhados via túnel! no roteador Headend[/cor2]
ip route 200.165.0 255.255.0.0 tunnel 0

O método PBR permite encaminhar o tráfego baseando-se em critérios como o prefixo de origem do pacote, precedência do pacote, tamanho do pacote, endereço de destino etc. Para isso, é necessário criar um route-map para selecionar o tráfego e definir a ação que será tomada para o mesmo. A ação no caso de MPLS TE será encaminhar o tráfego para o túnel. A seguir um exemplo de configuração de PBR.!

interface fastethernet 0/0¡ aplica o PBR para o tráfego que entra nesta interface
ip policy route-map traffic_to_tunel0
¡ cria o route-map para o PBRroute-map traffic_to_tunel0
¡ seleciona o tráfego, baseando-se no ACL 101, que será encaminhado ao túnel 0match ip address 101
¡ encaminha o tráfego selecionado para o túnel 0set interface tunnel0 !
access-list 101 permit ip any 200.165.0.0 0.0.255.255

O método Autoroute é uma feature de MPLS TE que faz com que todos os prefixos que estão atrás do roteador Tailend sejam, automaticamente, acessíveis via interface túnel. Esta feature coloca na tabela de roteamento do roteador Headend todos os nós ou prefixos que são downstream em relação ao roteador Tailend. O custo para cada prefixo presente na tabela de roteamento do roteador Headend, e acessível via túnel, será igual ao custo calculado pelo OSPF.
A Figura abaixo mostra a ativação de um túnel com a feature Autoroute entre os roteadores R1 e R3. Como pode ser visualizada, a tabela de roteamento do roteador Headend R1 terá os roteadores R3 e R4 acessíveis via interface túnel.


Para ativar a feature Autoroute é necessário especificar o seguinte comando na interface túnel.
tunnel mpls traffic-eng autoroute announce
O custo dos prefixos inseridos pelo Autoroute será igual ao custo calculado pelo OSPF. Porém, este custo pode ser alterado utilizando o comando tunnel mpls traffic-eng autoroute metric . Este comando faz com que a métrica do túnel seja alterada, ou seja, ele não utilizará o custo OSPF entre os roteadores Headend e o Tailend.

Por exemplo, se for inserido o comando tunnel mpls traffic-eng autoroute metric 5 na interface túnel, o túnel terá uma métrica igual a 5. Isto significa que os custos dos prefixos presentes na tabela de roteamento do roteador Headend, alcançáveis via interface túnel, sejam iguais ao custo da interface túnel - no exemplo será igual a 5 - mais o custo do OSPF calculado no roteador Tailend para estes prefixos. Considerando o exemplo da Figura acima, o custo calculado pelo roteador Headend R1 para o prefixo do roteador R4 terá um custo igual a 15, e o roteador R3 terá um custo igual a 5.
O método de encaminhamento recomendado depende muito da aplicação do túnel MPLS TE. Por exemplo, se for criado um túnel exclusivamente para o tráfego direcionado a um gateway de voz, basta configurar uma rota estática para o endereço do gateway apontando para o túnel.
A rota estática permite ter mais precisão nos prefixos que serão acessíveis via túnel. Porém, o método Autoroute facilita a definição dos túneis na abordagem estratégica quando há uma grande quantidade de prefixos que serão acessíveis via túnel.O método PBR deve ser utilizado quando o critério de encaminhamento baseado em prefixos de destinos não for suficiente.
Com Autoroute o túnel não é visto na rede OSPF como um link válido. Portanto, a não ser para o Headend, o túnel não existe para o restante dos roteadores da rede.
Logo, para os roteadores upstream ("antes" do headend, que envia tráfego para o mesmo), o túnel não interferirá na tabela de rotas. Com o mecanismo Forwarding Adjacency, o túnel será visto como um link LSA do database do OSPF. Desta maneira, roteadores upstream ao headend poderão ser influenciados por este link lógico que é o túnel.
Com Autoroute basta um túnel, numa direção, do Headend para o Tailend, para que ele funcione. O Forwarding Adjacency exige dois túneis entre os dois pontos da rede onde o link lógico deve ser montado. Um túnel do Headend para o Tailend e outro justamente na direção inversa.
Para habilitar o Forwarding Adjacency o seguinte comando deve ser inserido na interface túnel:
tunnel mpls traffic-eng forwarding-adjacency {holdtime }
O argumento holdtime é opcional. É o tempo de espera, após a queda do túnel, para que o MPLS TE informe ao OSPF que o link virtual, o túnel, caiu. Holdtime é ajustado na unidade de milissegundos e seu valor default é 0. No nosso caso o caminho do túnel será explícito, fixo e único; não havendo alternativas para que o mesmo possa ser reconstruído. Desta maneira, o holdtime a ser aplicado dependerá da qualidade do serviço que a transmissão dos circuitos físicos de contingência ofertar. Em suma, este parâmetro será inicialmente deixado em seu valor default. Caso necessário, com o tempo e para cada túnel em específico, ele poderá ser ajustado.
O método Pseudowire Class é maneira de seletivamente inserir apenas o tráfego não-IP num túnel MPLS. Pseudowires AToM (Any Transport over MPLS), por exemplo, poderiam ter seu tráfego de forma exclusiva ser inserido num túnel, sem a inserção de eventual tráfego IP concorrente.
A funcionalidade Class-Based Tunnel Selection oferta a capacidade de inserir tráfego de diferentes classes de serviço do QoS em diferentes túneis entre o mesmo Headend e o mesmo Tailend.

Padrão de Identificação dos Túneis

A implementação de um túnel MPLS TE envolve a ativação de uma interface túnel no roteador Headend, com a sua numeração e uma descrição (description). A descrição apropriada na interface tunnel auxiliará a identificação da mesma em comandos de monitoração e troubleshooting do MPLS TE. Além disso, é necessário especificar um caminho explícito que será utilizado pelo túnel. Para facilitar a administração das configurações é importante definir uma nomenclatura para a criação dos túneis, de forma que um túnel possa ser facilmente identificado a partir de qualquer roteador da Arquitetura MPLS TE.

Numeração dos Túneis

A numeração de túneis específicos para a aplicação MPLS TE no IOS varia de 0 a 65.535. Isto significa que no comando interface tunnelX, X pode variar de 0 a 65.535 quando se tratam de túneis MPLS TE.
Esta faixa de 0 a 65.535 trata-se de numeração e não necessariamente de quantidade. A quantidade de interfaces túneis possíveis de serem estabelecidas num roteador dependerá da diversos fatores: CPU, memória, interfaces lógicas até então definidas, placas e interfaces físicas, parâmetro IDB (Interface Descriptor Block) da plataforma, IOS etc.

Descrição dos Túneis

Além da numeração do túnel, é importante inserir a descrição ("description") na interface de forma a facilitar a identificação e o gerenciamento dos túneis em todos os roteadores. Para a descrição do túnel, recomenda-se a identificação do número do túnel, o nome do roteador Headend e do roteador Tailend. A descrição do túnel principal terá então os seguintes atributos.

description Tunel de para
Onde:o - representa a numeração do túnel no roteador Headend;
o - representa o nome do roteador Headend;o - representa o nome do roteador Tailend.

Explicit-Path

Para a especificação do caminho explícito de um túnel é necessário identificar todos os Next Hops ou RID entre o roteador Headend e o Tailend. Esta especificação envolve a configuração de um Explicit-path. A recomendação para a nomeação do Explicit-path consiste em inserir o nome de todos os roteadores envolvidos no caminho entre o início e o fim do túnel. A nomenclatura de Explicit-path está descrita a seguir.
_//
Onde:o - indica o número do caminho de forma a diferenciar caminhos que utilizam os mesmos roteadores, porém, utilizando interfaces diferentes;
o - indica o nome do roteador por onde passa o túnel.

1 comentários:

drlopezr disse...

Hola douglas quisiera saber si es posible tener un tunel mpls-te stm-1 con varios backup mpls-te load share e-1

 
BlogBlogs.Com.Br