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 <distributed>
¡
¡ 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 <Kbps reservável total> <Kbps reservável por fluxo> que é inserido em cada interface onde será utilizado o MPLS TE. O parâmetro – <Kbps reservável por fluxo> – 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 – 0xFFFFFFFF> 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 <métrica> 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 – 100>
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 segundos>
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 OSPF
router ospf <processo>
! define o RID TE
mpls traffic-eng router-id loopback100
! Ativa o TE na Area
mpls 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 1
interface 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 <Kbps>. 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 <n> 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 <setup> <hold>
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 – 0xFFFFFFFF> mask <0x0 – 0xFFFFFFFF>
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-path
ip explicit-path name 1_r1/r2/r3
! especifica os next-hop do caminho do túnel
next-address 192.168.3.2
next-address 192.168.4.2
next-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 roteador
mpls traffic-eng tunnels
!
!
interface Loopback100
ip address 10.129.1.11 255.255.255.255
!
!
! Ativa a interface Túnel 1
interface 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/0
bandwidth 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 1
network 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 PBR
route-map traffic_to_tunel0
¡ seleciona o tráfego, baseando-se no ACL 101, que será encaminhado ao túnel 0
match ip address 101
¡ encaminha o tráfego selecionado para o túnel 0
set 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 <metrica>. 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 <tempo em milissegundos>}
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 <N> de <Headend> para <Tailend>
Onde:
o<N> – representa a numeração do túnel no roteador Headend;
o<Headend> – representa o nome do roteador Headend;
o<Tailend> – 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.
<número do Caminho>_<nome do roteador1>/<nome roteador 2>/<nome roteador N>
Onde:
o<número do caminho> – indica o número do caminho de forma a diferenciar caminhos que utilizam os mesmos roteadores, porém, utilizando interfaces diferentes;
o<nome roteador 1> – indica o nome do roteador por onde passa o túnel.
Balanceamento de Carga
O balanceamento de carga entre túneis MPLS TE é realizado no Headend entre os túneis que têm os mesmos prefixos de destino. A diferença entre o balanceamento de carga MPLS TE e o fornecido pelo roteamento OSPF é que os túneis MPLS TE permitem realizar o balanceamento de tráfego de maneira proporcional à banda alocada para cada túnel ou de acordo com uma proporção especificada e independente da banda.
A taxa de tráfego enviada para cada túnel é calculada de acordo com a proporção da alocação de banda entre os túneis envolvidos no balanceamento. Considerando o exemplo mostrado na Figura abaixo, a partir do roteador R1 foram ativados dois túneis MPLS TE com a feature Autoroute em direção ao roteador R3. O túnel T1 solicitou uma reserva de 10 Mbps e o túnel de T2 solicitou uma reserva de 20 Mbps. A tabela de roteamento do roteador R1 (Headend) mostra que o roteador R3 estará acessível via interfaces túneis T1 e T2 com custo 20, porém, a taxa de tráfego enviada para cada túnel em direção ao R3 será na proporção da banda configurada para cada túnel, ou seja, a proporção será de 20 para 10. No entanto, o algoritmo da tabela de roteamento utilizará proporção 2 para 1, baseando-se no seguinte cálculo:
– Reduzir a menor banda para 1, ou seja, 10/10.
– Obter a proporção da banda de outros túneis em relação ao de menor banda, ou seja, 20/10 é igual 2.
– Arredondar o resultado para cima.
– Obter a proporção resultante, ou seja, 1/2.
Vale sublinhar que o IOS utiliza um algoritmo de balanceamento de carga que contém até 16 hash bucket. Isto significa que o IOS faz uma aproximação desta proporção fazendo uma racionalização de modo que os valores sejam múltiplos de 1/16.
Por exemplo, caso sejam configurados dois túneis com uma proporção um para um, cada túnel receberá 8/16 do tráfego. Se forem configurados 3 túneis numa proporção 4:1:1, um túnel receberá 11/16 do tráfego, outro 3/16 e o outro 2/16.
A taxa enviada para cada túnel é proporcional à banda alocada através do comando tunnel mpls traffic-eng bandwidth <Kbps>.
O outro comando utilizado para definir esta proporção está descrito a seguir. Com a ativação deste comando, a proporção de tráfego enviado para cada túnel passa a se basear no parâmetro configurado no mesmo. Por exemplo, se forem configurados dois túneis entre R1 e R2 (veja Figura acima), sendo que um tem load-share igual a 3 e outro igual a 1, isto significa que a razão de tráfego entre este dois túneis será igual a 1/3.
tunnel mpls traffic-eng load-share <0-1000000>
Se estiver sendo utilizada a feature Autoroute e os túneis que têm o mesmo roteador Tailend estiverem utilizando caminhos com custos diferentes, o roteador Headend atribuirá o menor dos custos aos caminhos utilizados pelos túneis que têm o mesmo Tailend. Por exemplo, na Figura abaixo todos os circuitos têm uma métrica igual a 781. Foram ativados dois túneis em direção ao roteador R3 e que utilizam caminhos diferentes. Apesar de utilizarem caminhos com custos diferentes – 1562 e 782 – o custo atribuído na tabela de roteamento para ambos os caminhos será o valor menor (782). Assim, o roteador realizará balanceamento de carga entre os túneis numa razão de tráfego proporcional à banda alocada a cada um.
Vale ressaltar que a interface túnel presente na tabela de roteamento do roteador Headend não é divulgada via OSPF para os outros roteadores. Em outras palavras, a informação dos prefixos acessíveis via interface túnel é local ao roteador Headend.
O balanceamento de carga realizado entre os túneis utiliza a tecnologia CEF. Portanto, o balanceamento pode ser realizado por pacotes ou por fluxos. É importante ressaltar que a proporção de pacotes ou fluxos enviados para cada túnel será proporcional à razão da banda alocada entre eles.
Fast Reroute: Recuperação Rápida do Serviço
As redes são projetadas com um alto nível de redundância para garantir a oferta dos serviços oferecidos aos clientes. No entanto, muitas vezes, a falha em um circuito de comunicação faz com que a recuperação de um serviço demore algumas dezenas de segundos dada a quantidade de protocolos envolvidos na convergência. Este tempo de convergência é resultante, principalmente, do tempo de propagação do protocolo IGP utilizado na rede. Dependendo do tamanho da rede, este tempo pode levar de 5 a 10 segundos. Durante esta convergência há perda de pacotes e, conseqüentemente, uma indisponibilidade do serviço oferecido ao usuário e isto pode afetar o SLA acordado entre o usuário e o provedor.
A Arquitetura MPLS TE permite reduzir este tempo de convergência para tempos na ordem de milissegundos, o que contribui em muito para o aumento da disponibilidade dos serviços oferecidos aos clientes. Para isso, é necessário utilizar a feature IOS Cisco denominada de Fast Reroute.
Para reduzir o tempo de convergência é necessário criar túneis de backup ou túneis de proteção. Estes túneis são utilizados para proteção, em situações de falha, do túnel principal.
Os esquemas de proteção podem ser categorizados em:
– Path Protection.
– Link Protection.
– Node Protection.
O esquema Path Protection, atualmente, não é implementado pelo IOS Cisco. Ele consiste na criação de um túnel de backup de forma a proteger todo o caminho utilizado pelo túnel principal.
Os esquemas Link Protection e Node Protection são denominados de proteção local. Este termo é utilizado porque os túneis backup protegem apenas um segmento do caminho do túnel principal. A Figura abaixo mostra a proteção local do circuito entre R3 e R5 denominada de Link Protection e a proteção do Nó R5 denominada de Node Protection.
O túnel principal mostrado na Figura acima está utilizando o caminho R1-R3-R5-R7. Como pode ser visualizado, o circuito R3-R5 está protegido pelo túnel de backup 1. O roteador R5 está protegido pelo túnel de backup 2.
Se falhar a conexão R3-R5, o túnel principal terá de encontrar outro caminho e, durante esta transição, o tráfego utilizará o túnel de backup 1 até o túnel principal ser restabelecido. Esta proteção é denominada de Link Protection.
Se falhar o roteador R5, o túnel principal terá de encontrar outro caminho e, durante esta transição, o tráfego utilizará o túnel de backup 2 até o túnel principal ser restabelecido. Esta proteção é denominada de Node Protection.
O esquema de proteção Link Protection utiliza o túnel backup NHop, ou seja, o túnel backup deve terminar na outra ponta do circuito a ser protegido.
O esquema de proteção Node Protection é similar ao Link Protection, no entanto, o MP deve ser o roteador NNHop.
A vantagem do esquema de proteção local em relação ao Path Protection é que um único túnel backup permite proteger vários túneis principais, por isso, o esquema de proteção local é representado por 1:N. Além disso, para um circuito protegido pode ser criado mais de um túnel backup.
A configuração da proteção local envolve a definição dos túneis que necessitam desta proteção e a configuração dos túneis backup de acordo com o esquema de proteção local adotado. A seguir será mostrado um exemplo, baseado na Figura acima, de configuração utilizando o Link Protection.
Na definição do túnel principal a ser realizada no roteador Headend R1 é necessário ativar a proteção do túnel.
Roteador R1
!
interface tunnel 0
.
.
! sinaliza que este túnel principal necessita de proteção
tunnel mpls traffic-eng fast-reroute
O outro passo será definir a proteção do link no roteador PLR R3 através da ativação do túnel 1 de backup conforme mostrado a seguir.
Roteador R3
! Ativa a interface backup Túnel 1
interface Tunnel1
ip unnumbered Loopback100
! define o roteador Tailend que será o MP
tunnel destination 10.130.1.11
! define o modo do túnel
tunnel mode mpls traffic-eng
! O estabelecimento do caminho será estático
tunnel mpls traffic-eng path-option 1 explicit name 1_r4/r6/r5
! armazena as informações dos next-hop do caminho utilizado
tunnel mpls traffic-eng record-route
ip explicit-path name 1_r4/r6/r5
! especifica os Next Hops do caminho do túnel
next-address <IP Next Hop>
next-address <IP Next Hop>
next-address <IP Next Hop>
next-address <Loopback100_R5>
!
! configura a interface física do circuito protegido
interface pos1/1
ip address 10.129.55.5 255.255.255.252
mpls traffic-eng tunnels
! Protege a interface POS1/1 com o túnel backup 1
mpls traffic-eng backup-path Tunnel1
ip rsvp bandwidth 155000
pos ais-shut
Nas interfaces POS, um outro recurso que pode ser utilizado para diminuir o tempo de convergência é utilizar o comando pos ais-shut. Este recurso pode ser utilizado independentemente da feature Fast Reroute. Com este recurso ativado em ambos os lados das interfaces POS, quando a interface é desativada administrativamente, é enviado um sinal de alarme de indicação de linha para que a interface detecte imediatamente que o outro lado está inativo. Sem este comando a interface teria de esperar pelo tempo de keepalive dos protocolos PPP/HDLC.
O túnel backup pode ser utilizado por qualquer túnel que estiver requerendo proteção e que utilize o circuito protegido. Quando o circuito protegido falhar, todos os túneis principais utilizarão o túnel de backup até serem restabelecidos. Nesta transição pode ocorrer um congestionamento no túnel backup. Para proteger-se desta situação há uma feature Fast Reroute denominada de Bandwidth Protection que faz com que o túnel backup faça um controle de admissão dos túneis principais baseando-se na banda disponível. Na ativação do túnel backup é necessário configurar a banda que será protegida através do comando tunnel mpls traffic-eng backup-protection <Kbps>.
Prioridades
A prioridade indica o nível de precedência de um túnel sobre os demais. Em situação onde há competição devido à escassez de recursos, por exemplo, banda, o túnel de melhor prioridade terá precedência sobre o outro. A prioridade de um túnel é composta pela prioridade Setup (S) e prioridade Hold (H), sendo que, num túnel, a prioridade Setup não pode ser menor que a prioridade Hold.
A Tabela abaixo mostra um exemplo de recomendação dos níveis de prioridades para cada tipo de túnel.
É recomendável que os túneis criados especificamente para o tráfego de VPNs MPLS tenham precedência sobre os túneis (se criados) utilizados para tráfego internet que, por sua vez, é considerado Best Effort. Dentre o tráfego VPN MPLS, é recomendável priorizar os túneis de tráfego para aplicações de tempo real.
A classificação do tipo de túnel dependerá do tipo de tráfego que ele transportará. Desta forma, o túnel que for configurado para transportar, exclusivamente, tráfego internet (se tal túnel existir) será considerado um túnel internet (menor precedência de Setup e Hold). O túnel que for utilizado para transportar tráfego VPN MPLS e qualquer outro tráfego será considerado túnel VPN em geral (média precedência de Setup e Hold). O túnel que for utilizado para transportar, exclusivamente, tráfego de categoria tempo real deverá ter maior precedência de Setup e Hold.
Affinity
O Affinity descrito anteriormente neste documento é utilizado, basicamente, para incluir ou excluir um enlace do caminho calculado pelo túnel.
Para exemplificar a aplicação do Affinity, pode-se considerar a diferenciação das conexões terrestres das conexões via satélite. Esta diferenciação é importante porque as conexões via satélite apresentam um atraso alto de propagação e isto pode influenciar negativamente na qualidade de algumas aplicações, e até impactar na garantia do SLA. Portanto, as conexões de satélite teriam Affinity diferente das conexões terrestres. Na ativação do túnel MPLS TE seriam definidos Affinity de acordo com a restrição do túnel em relação ao tipo de conexão. Por exemplo, se for ativado um túnel para transportar tráfego que tenha restrição de atraso, o Affinity do túnel excluiria as conexões satélites do cálculo do caminho do túnel. Mesmo não havendo circuitos via satélite na rede da Claro, o exemplo aqui descrito do Affinity continua válido para seu entendimento.
Para viabilizar esta diferenciação, o primeiro bit menos significativo do atributo de 32 bits dos enlaces será utilizado para indicar se a conexão é via satélite ou não. Por exemplo, o primeiro bit com valor 1 indica uma conexão via satélite e com valor 0 indica uma conexão terrestre.
A Tabela abaixo mostra o comando necessário numa interface para indicar se ela é utilizada para conexão via satélite ou via terrestre. Vale ressaltar que o valor default do atributo de 32 bits de uma interface é 0x00000000, portanto é necessário inserir estes comandos apenas nas conexões via satélite, pois as conexões terrestres terão o valor default.
Na definição do túnel será necessário indicar, através do Affinity, se há alguma restrição com relação ao tipo de enlace. A definição do Affinity envolve a configuração de strings de 32 bits do Affinity do túnel e da máscara. A máscara é utilizada para indicar os bits do Affinity do enlace que serão comparados com o Affinity do túnel. O valor 1 em um dos bits da máscara indica o bit que será comparado, e o valor zero indica o bit que não será comparado.
A Tabela acima mostra a combinação de máscara e Affinity realizada na definição do túnel e a indicação da restrição com relação ao tipo de enlace. Vale lembrar que se não for especificado o Affinity do túnel, ele terá um valor default 0x00000000 e máscara 0xFFFFFFFF. Isso significa que, por default, os túneis não utilizarão caminhos via satélite. A seguir será mostrado um exemplo de especificação do Affinity de um túnel, de forma a não apresentar restrição quanto ao tipo de conexão.
interface tunnel 1
.
.
! especifica o affinity do túnel 1
tunnel mpls traffic-eng affinity 0x00000000 mask 0x00000000
A especificação do Affinity requer um esforço de configuração e gerenciamento que tem de ser justificado por um bom resultado prático. Portanto, se a implantação de MPLS TE não abordar as conexões via satélite ou se as localidades via satélite não tiverem alternativas para acesso via terrestre, é recomendável que os valores de Affinity dos túneis e dos enlaces fiquem com os valores default, isto é, que eles não sejam especificados nos túneis e nem nos enlaces.
Métrica do TE (Weight)
A métrica TE das interfaces divulgada pelo OSPF tem, por default, um valor igual à métrica calculada pelo protocolo OSPF. O CSPF utiliza esta métrica para determinar o caminho a ser utilizado pelo túnel.
Um exemplo da aplicação da manipulação da métrica TE nas interfaces é o mapeamento do atraso existente em cada conexão na métrica do TE. Desta forma, serão ativados túneis sensíveis ao atraso. Por exemplo, o valor da métrica configurada na interface representaria o atraso, em milissegundos, medido na conexão da interface.
A Figura abaixo mostra um atraso de 2 ms entre os roteadores R1 e R2. Dessa forma, a métrica do TE foi configurada para representar este atraso existente entre os dois roteadores. A alteração da métrica TE não influencia na métrica IGP calculada pelo OSPF. A monitoração do atraso existente entre dois roteadores pode ser obtida através da feature SAA Agent presente no IOS Cisco ou através de testes de ping entre os roteadores.
Os roteadores envolvidos na Arquitetura MPLS TE terão a informação da métrica do TE e a métrica do IGP. Na ativação do túnel TE, o CSPF se baseia, por default, na informação da métrica TE para determinar o caminho que será utilizado pelo túnel. No entanto, o túnel pode ser configurado para utilizar a métrica do IGP como base para o cálculo do caminho ao invés de utilizar a métrica TE. Dessa forma, pela seleção da métrica TE há a flexibilidade de ativar túneis sensíveis ao atraso.
Para selecionar a métrica que será utilizada na determinação do caminho, o seguinte comando pode ser utilizado na interface Túnel. Vale lembrar que a opção default é utilizar a métrica TE.
interface tunnel 1
.
.
! especifica a métrica que será utilizada para a determinação do caminho
tunnel mpls traffic-eng path-selection metric <IGP | TE>
Na próxima matéria falaremos um pouco sobre os túneis MPLS e o LPD. Atá a próxima!