Balanceamento de Trafego em Redes MPLS

Balanceamento de Tráfego em Redes MPLS

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

Introdução

O balanceamento de tráfego, também conhecido por "load balancing" ou "load sharing", é um mecanismo que permite a distribuição de fluxos tráfego através de múltiplos caminhos existentes em uma infraestrutura. Esta estratégia é comumente utilizada em ações de planejamento de capacidades visando uma distribuição e o compartilhamento destes múltiplos caminhos para fins de prevenção de congestionamentos de enlaces na rede. Outro benefício ofertado por esta iniciativa é a melhor resiliência durante cenários de falhas dos enlaces da rede, dependendo de como a solução for construída. E isto será melhor esclarecido na sequência.

Embora neste artigo as técnicas de balanceamento de tráfego sejam de certa forma abordadas ou discutidas, o foco primário será sobre os desafios quanto a adoção deste mecanismo em redes MPLS.

Revisão de Fundamentos: Tecnologias de Balanceamento de Tráfego em Redes

Para que este artigo atinja melhor o seu propósito de esclarecer os desafios quanto ao balanceamento ou distribuição de tráfego em redes MPLS, promoveremos uma breve revisão das tecnologias existentes para este propósito de distribuição de tráfego em redes Ethernet/IP. Há algumas soluções muito bem conhecidas para este tipo de necessidade, das quais as mostradas a seguir:

Agregação de Enlaces L3

Esta técnica é muito difundida e geralmente é concebida com a tecnologia descrita pelo IEEE 802.3ad Link Aggregation (LAG). Uma técnica clássica conhecida pelos termos Port-Channel, Link Bundling, Link Bonding, Channel Bonding e afins. Outras formas de conquistarmos o mesmo objetivo e com tecnologias similares incluem recursos proprietários de fabricantes (ex: PAgP com Cisco, ou simplesmente sem envolvimento de protocolos (modo incondicional "On")). A quantidade de interfaces físicas que podem ser agregadas depende da arquitetura do fornecedor e de suas restrições conforme o modelo do equipamento.

Neste cenário, o administrador configura o equipamento para agregar duas ou mais interfaces físicas, criando, portanto, uma única interface lógica. O endereço de rede (IPv4, IPv6) e demais recursos tais como ACLs, QoS, e outros, são então configurados nesta interface lógica. É por esta interface lógica que ocorrerá toda a comunicação IP, inclusive as vizinhanças envolvendo os protocolos de roteamento. Como vantagem, além do aumento da capacidade de comunicação entre os dois roteadores neste "canal agregado", a falha de um dos enlaces físicos deste canal não provoca eventos de convergência significativos na rede pelos protocolos IGP, exceto a propagação da notificação de mudança da métrica associada ao canal agregado, que, num evento de falha, passaria a ter menor capacidade e, consequentemente, uma métrica maior na perspectiva de um protocolo como o OSPF.

No exemplo ilustrado a seguir, temos dois roteadores com três conexões físicas entre eles. Na configuração de ambos os roteadores, as três interfaces físicas participantes foram agregadas em uma única porta lógica, que recebeu a configuração de endereços de rede e por onde deverá ocorrer toda a comunicação entre ambos os roteadores. Internamente, cada roteador entende que as transmissões precisam ser distribuídas entre os enlaces físicos participantes, ou seja, promovendo desta forma a desejada distribuição do tráfego ao mesmo tempo em que fornecendo proteção em caso de eventual indisponibilidade de um destes enlaces.

Uma agregação típica Ethernet (L2)

Encaminhamento de Tráfego Através Caminhos L3 de Custos Iguais

Uma técnica muito difundida chamada "Equal-Cost Multipath" (ECMP). Neste cenário, não há a agregação de enlaces físicos individuais em um único canal lógico, como seria o caso de um port channel, mas sim apenas rotas de custos iguais na perspectiva das estruturas de comutação dos equipamentos envolvidos. Ou seja, o clássico "rotas de custos iguais" referenciadas ao endereço de rede de destino. Na prática, o roteador passa a ter duas ou mais opções de caminhos ou rotas de custos iguais para algumas ou todas as redes via determinado roteador vizinho/adjacente, ou através de vários roteadores vizinhos. O roteador, quando possui duas ou mais rotas de custos iguais em sua tabela de roteamento, buscará distribuir o tráfego através destes caminhos, fomentando equilíbrio na utilização dos enlaces de rede envolvidos e certa confiabilidade também durante eventos de falhas de um ou mais destes circuitos físicos.

No exemplo ilustrado a seguir, o Roteador 1 possui três roteadores vizinhos OSPF. Este Roteador 1 possui três rotas OSPF de custos iguais referentes à rede 10.1.2.0/24, onde está posicionado o computador à direita da topologia demonstrada. O Roteador 1 promoverá uma distribuição do tráfego através destas três rotas de custos iguais, ou seja, fazendo com que as comunicações não percorram através de um único enlace físico apenas, mas sim através de todas as opções de custos iguais disponíveis. A quantidade de rotas permitidas para um cenário ECMP depende da arquitetura de hardware e de software do fabricante, assim como de eventuais restrições impostas.

Um ECMP típico

Agregação de Enlaces L2

Basicamente empregando as mesmas estratégias discutidas no primeiro cenário, só que envolvendo interfaces de rede configuradas especificamente para tráfego comutado na camada 2 (L2). As tecnologias empregadas são essencialmente as mesmas, sendo modificado apenas a perspectiva de operação da porta do equipamento (L2 ou L3). No exemplo demonstrado a seguir, dois roteadores (Roteador 1 e Roteador 2) são interconectados por um elemento de camada 2 (Switch L2 1). As interfaces entre cada roteador e o switch são agregadas pelo mecanismo LACP e, na configuração de cada roteador, haverá uma porta lógica representando esta agregação e, sobre esta porta, o endereço de rede, por onde deverá ocorrer toda a comunicação entre os dois roteadores. Na perspectiva do elemento switch deste cenário demonstrado, a agregação é puramente L2, e havendo também duas portas lógicas para representar as agregações com os respectivos roteadores vizinhos.

Toda e qualquer comunicação IP entre o Roteador 1 e o Roteador 2 ocorrerá através das interfaces lógicas envolvidas sendo que, internamente, o roteador distribuirá o tráfego utilizando as conexões físicas agregadas. O switch também realizará o procedimento de distribuição de tráfego com os seus respectivos roteadores vizinhos.

Uma agregação típica Ethernet envolvendo roteadores e switches

Outras Tecnologias Conhecidas

Para não sacrificarmos o objetivo primário deste artigo, suprimiremos os detalhamentos de outras estratégias existentes, tais como Multi-Chassis LACP ou Multi-Chassis Link Aggregation Group (MC-LAG), Multi-Chassis EtherChannel (Cisco), Virtual PortChannel (vPC) (Cisco), mLACP (Cisco), M-LAG (Huawei), Multi-Chassis Trunking (Brocade), e implementações similares realizadas por outros fabricantes. Isto poderá ser um tema de outros artigos, em futuro próximo.

Benefícios dos Mecanismos de Distribuição de Tráfego

Há várias vantagens relacionadas ao emprego destes mecanismos de distribuição de tráfego, em particular aos demonstrados anteriormente. Não será o foco deste artigo dissertar sobre as vantagens e desvantagens de cada mecanismo citado, mas todos os mecanismos apresentados promovem benefícios para os projetos de infraestruturas. Por exemplo:

• Agregação de portas: aumento da capacidade do canal de comunicação entre dois elementos ativos vizinhos. Ao agregar, por exemplo, quatro interfaces físicas 10 Gbps, temos aí virtualmente um canal de 40 Gbps de capacidade. Isto poderia fazer a diferença em projetos onde uma única porta de 10 Gbps fosse óbvia e completamente insuficiente para lidar com um volume de tráfego próximo a 40 Gbps, especialmente em ambientes onde os equipamentos presentes não suportassem a instalação de uma interface 40 Gbps Ethernet. Ou seja, uma solução de curto prazo para viabilizar o escoamento do tráfego neste volume. Outra vantagem aqui seria uma economia na quantidade de endereços IP exigidos, pois a configuração do endereço de rede é realizada somente sobre a interface lógica. Numa topologia ponto a ponto envolvendo dois roteadores, por exemplo, uma única subrede /30 ou /31 seria exigida e independentemente da quantidade de portas físicas agregadas no canal.
• Agregação de portas: baixo impacto no plano de controle dos equipamentos durante cenários de falhas. Para agregações em L3, os protocolos de roteamento são ativados sobre as interfaces lógicas e não diretamente sobre as interfaces físicas agregadas. Durante o rompimento de um dos enlaces físicos agregados o overhead de processamento é menor e tende a provocar eventos de convergência mais brandos na maioria dos casos. A porta lógica permanecerá ativa e funcionando normalmente enquanto houver um mínimo de portas físicas participantes ativas configuradas (o padrão é de "1", mas isto pode ser ajustado pelo engenheiro da rede na configuração do canal). Para agregações L2 e em ambientes onde há a presença de protocolos de resiliência Ethernet, eventos de falhas de um enlace físico de um canal agregado tendem a passar quase que despercebidos na maioria dos incidentes.
• ECMP: distribuição de tráfego com potencial de previnir a saturação dos enlaces. Em um ambiente com duas ou mais rotas de custos iguais para determinadas redes de destino o ECMP viabiliza uma distribuição mais uniforme do tráfego sobre estes caminhos disponíveis, o que, em muitos projetos, ajuda a prevenir cenários de congestionamentos. Com um bom projeto técnico em mãos e através de uma rede topologicamente bem montada, é possível inclusive conceber boa simetria nos fluxos de tráfego através das rotas de custos iguais. Durante eventos de interrupção de uma ou mais destas rotas do cenário ECMP, haverá normalmente os eventos de convergência ditados conforme o protocolo de roteamento utilizado. Uma das desvantagens do ECMP está na quantidade de endereços IP exigidos, já que cada interface do roteador deverá ser tratada como uma interface IP completamente independente, logo, portanto, precisando estar definida em sua própria subrede.

Mitos acerca do Encaminhamento de Tráfego sobre Agregação de Portas e ECMP

Aqui começaremos a explorar o problema, e iniciando esta abordagem com uma "grande revelação":

"Não, a solução de agregação de portas não distribui o tráfego com alternância ('round-robin') 'por pacotes' através dos enlaces agregados. Os pacotes são distribuídos por orientação de fluxos de tráfego".

Muitos profissionais de redes acreditam que soluções de agregação de portas tais como LAG (não importando o fabricante) distribuem o tráfego de forma rigorosamente uniforme, pacote por pacote, sendo um pacote a ser transmitido sobre cada um dos enlaces físicos agregados e assim, sucessivamente, para os próximos pacotes e sobre as próximas portas. Definitivamente não é assim que funciona este tipo de solução; não há o chamado round-robin de pacotes durante estas transmissões. Isto até já foi possível um dia quando o procedimento era realizado exclusivamente por interrupções de software, método este, obviamente, não mais empregado nos dias atuais e muito em função das arquiteturas dos processadores de rede (NPU) utilizados pelos equipamentos de última geração.

O que muitos ainda não sabem é que a distribuição de tráfego se dá na verdade por orientação dos fluxos de tráfego, e não por pacotes! Como exatamente isto é executado em um equipamento depende única e exclusivamente da arquitetura de hardware e software do fabricante de cada equipamento. A distribuição de tráfego por conceito de fluxos de tráfego (e não os pacotes) é viabilizada por técnicas de hashing computados sobre informações observáveis nos cabeçalhos contidos em cada pacote recebido. Quando um pacote é recebido pelo roteador, informações são extraídas dos cabeçalhos de forma a permitir a computação de um valor que será utilizado posteriormente para a determinação de qual rota IP será utilizada quando houver mais de uma opção de caminhos (cenário ECMP), assim como a determinação de qual adjacência será considerada para efetivamente encaminhar o pacote.

Um exemplo bem simples, prático, e didático considerando a ilustração a seguir:

1. O equipamento "Roteador 1" possui uma rota para a rede de destino 10.1.1.0 /24 via uma adjacência L3 que possui com o equipamento "Roteador 2".
2. O canal de comunicação entre ambos os roteadores é por agregação de portas L3 (um LAG), onde sabemos que os endereços IP estão definidos nas portas lógicas resultantes desta agregação.
3. Este LAG possui duas portas físicas associadas.
4. Na perspectiva do Roteador 1:
   1. Recebe o quadro Ethernet, valida o seu CRC e determina se aquele quadro tem como destino na camada 2 o endereço MAC do próprio Roteador 1 (ou seja, atuando como gateway aqui).
   2. Faz uma consulta no EtherType deste quadro para determinar o protocolo de camada superior a qual o PDU se destina (ex: IPv4), extrai e descarta completamente o quadro Ethernet, deixando exposto somente o cabeçalho IP + payload
   3. Analisa o CRC do cabeçalho IPv4, consulta o endereço IP de destino mencionado neste cabeçalho.
   4. Na sequência, determina o caminho através do procedimento de incidência sobre o prefixo IPv4 mais específico ("longest prefix match") contido em sua estrutura de encaminhamento de pacotes - uma versão sofisticada da tabela de roteamento, e que é mantida/atualizada em hardware especializado (isto será tema de outro artigo). Ou seja, o roteador aqui executa o procedimento de determinação de caminhos fazendo uma consulta ("lookup") do endereço IP de destino citado no cabeçalho do pacote recebido, e buscando a rota mais específica e que satisfaça aquele endereço IP de destino.
      1. Todo o prefixo IP, seja numa tabela de roteamento (no Plano de Controle do equipamento) ou numa estrutura mais especializada no Plano de Dados (ex: FIB + ADJ) possui um apontamento para o próximo salto. Ou seja, o endereço IP do roteador de próximo salto para onde as transmissões para aquela rede de destino deverão ser encaminhadas. Neste cenário ilustrado, trata-se do endereço IP da interface agregada do Roteador 2.
      2. Juntamente com o endereço IP do próximo salto (next hop) há a informação da interface de saída associada àquele próximo salto; geralmente uma rede diretamente conectada.
   5. Neste cenário, a rede conectada foi definida em uma porta lógica que representa uma agregação de duas portas físicas!
   6. O roteador precisa determinar por qual das portas físicas aquele pacote será transmitido. E é justamente aí que ocorre o procedimento de balanceamento ou distribuição de tráfego!
   7. Na sequência, o roteador subtrai um "hop" do campo TTL do cabeçalho IPv4, recomputa o CRC deste cabeçalho, e reescreve um novo cabeçalho de camada 2, colocando como endereço MAC de origem o de sua interface de saída (porta agregada) e como endereço MAC de destino aquele que estiver associado ao endereço IP do próximo salto que, neste caso, seria o endereço MAC da porta agregada do Roteador 2.
   8. O próximo e último passo deveria ser o efetivo encaminhamento do pacote, certo? Mas, lembre-se, temos duas portas físicas agregadas em um único canal lógico. Por qual das duas interfaces físicas deverá percorrer a transmissão deste pacote?

Novamente, engana-se que o Roteador 1 fizesse um round-robin, o que se traduziria num "um pacote pela primeira porta, e o próximo pacote pela segunda porta" e assim por diante, neste ciclo.

O fato é que o roteador precisa determinar por qual interface física aquele pacote deverá ser transmitido, pois ele não pode simplesmente pegar pacote por pacote e encaminhar por "enlace sim, enlace não". É nessa hora que os mecanismos de hashing são usados: dados observáveis dos cabeçalhos do pacote são utilizados para derivar um valor que identificará qual interface física (de um bundle Ethernet) ou qual rota (de um cenário ECMP) deverá ser utilizada para aquela transmissão.

Ilustração o conceito de hashing e chaves de consulta em estrutura de encaminhamento de pacotes

A ilustração acima é auto-explicativa: dados contidos nos cabeçalhos são usados para gerar uma chave de consulta. O roteador com isto poderá facilmente determinar se a transmissão é L2 (em uma Bridge Domain) ou se é L3 (ele deve atuar como gateway para aquela transmissão). Além disto, permitir uma rápida localização do prefixo IP mais específico assim como qual adjacência e respectiva interface de saída deverão ser utilizados para a transmissão daquele pacote. Todos os pacotes deste mesmo fluxo obviamente produzirão os mesmos resultados de geração de chaves de consultas (lookup key) e, consequentemente, as mesmas ações quanto a seleção de rota, no caso do ECMP, ou, de interface física, no caso de LAG.

Mecanismos de Distribuição de Tráfego Conhecidos

Conforme citado anteriormente, exatamente qual método é suportado para um determinado projeto depende muito do modelo do equipamento, da classe do produto e das especificações técnicas do fabricante. No entanto, podemos citar alguns métodos suportados por muitos equipamentos utilizados no mercado de provedores:

• dst-ip — endereço IP de destino
• dst-mac — endereço MAC de destino
• dst-port — portas TCP/UDP de destino
• mpls — instruções do shim header
• src-dst-ip — endereços IP de origem e destino, simultaneamente
• src-dst-mac — endereços MAC de origem e destino, simultaneamente
• src-dst-port — portas TCP/UDP de origem e destino, simultaneamente
• src-port — porta TCP/IDP de origem
• src-ip — endereço IP de origem
• src-mac — endereço MAC de origem

Para que você possa compreender exatamente o "problema-foco" deste artigo, torna-se necessário em primeiro momento você compreender como funciona a distribuição de tráfego em cenários LAG e ECMP. Imagine a seguinte situação:

Um exemplo de mecanismo de hashing para efeitos de distribuição de pacotes

Caso o critério utilizado pelos roteadores acima seja o endereço MAC de origem (src-mac), a tendência é que toda a comunicação entre os dois roteadores utilize apenas um único enlace, dos três enlaces disponíveis. Da mesma forma, caso o critério utilizado, conforme configurado pelo administrador da rede, seja o endereço IP de destino (dst-ip), a tendência é que toda a comunicação entre estes dois roteadores percorra, também, através de um único enlace, dos três enlaces disponíveis demonstrados.

Agora, caso o mecanismo configurado nos roteadores permita a observação de mais dados dos cabeçalhos, por exemplo, uma combinação de IP de origem + IP de destino + portas TCP/UDP de origem e destino (src-dst-ip-ports), a tendência é que ocorra uma distribuição mais uniforme do tráfego através dos três enlaces disponíveis e demonstrados, não exatamente perfeita em muitos casos. Isto porque a diversidade de informações extraídas dos cabeçalhos usando um mecanismo mais "completo" permitiria uma alternância mais frequente dos valores das chaves de consulta, proporcionando uma incidência mais uniforme sobre os índices representado as interfaces físicas participantes desta agregação ou das adjacências de um ECMP.

E é exatamente isto que administradores de rede fazem quando configurando seus projetos com estas soluções. Um simples monitoramento da ocupação das interfaces do projeto revelará que está ocorrendo saturação em uma das portas, enquanto as demais apresentam baixa utilização. É nesta hora que o administrador procura programar um mecanismo de distribuição de tráfego que vá proporcionar uma distribuição mais uniforme através dos enlaces físicos disponíveis.

Observação importante: na maioria das vezes não haverá uma distribuição perfeitamente uniforme do tráfego. Por exemplo "50/50" quando usando dois links, ou "33/33/33" quando usando três links

O Problema com o Balanceamento de Tráfego em Redes MPLS

Agora que você compreende melhor como funcionam os mecanismos de balanceamento ou distribuição do tráfego, inclusive as consequências da configuração incorreta dos mecanismos de distribuição, ficará bem mais fácil esclarecer os desafios comumente encontrados em redes MPLS - o tema principal deste artigo. Exatamente duas situações são frequentemente enfrentadas pelos provedores:

• Distribuição de tráfego através de enlaces L2 ou ECMP no backbone de uma rede MPLS
• Distribuição de tráfego de L2VPN sobre uma rede MPLS

Conforme citado anteriormente, o balanceamento de tráfego é tipicamente implementado onde um caminho é selecionado com base em chaves de consulta (hash/lookup keys) derivados a partir de dados contidos nos cabeçalhos dos pacotes. As chaves que são escolhidas dependem do tipo do pacote como, por exemplo, endereços IP de origem e destino e portas TCP/UDP de origem e destino. No caso do MPLS, para os pacotes MPLS, as mesmas chaves de consultas podem ser usadas juntamente com uma inspeção detalhada do pacote realizada pelo roteador (chamamos isto de deep packet inspection) ou sobre o topmost label. Há desvantagens quanto ao uso de uma inspeção detalhada do pacote feita por todos os roteadores em uma rede MPLS: aumento de processamento e/ou latência, incompatibilidade com certos recursos necessários em um dado projeto, ou simplesmente por ser um mecanismo não suportado pelo roteador - e, sim, para constar aqui, vários roteadores não suportam este tipo de análise/inspeção detalhada no MPLS, e isto tem a ver com a complexidade do parsing de dados dos cabeçalhos no pacote, onde é mais limitado em plataformas de pipeline fixo de processamento de pacotes. Ilustrando o problema aqui

Suponhamos que, para todos os efeitos, o ambiente demonstrado aqui tenha sido configurado para derivar as chaves de consultas com base nos endereços IP de origem e destino + portas, o que trata-se de uma situação bastante comum, corriqueira, no ambiente dos provedores de Internet. A situação acima apresentaria um notável problema com a distribuição de tráfego entre os três links disponíveis demonstrados, pois, numa rede MPLS, os roteadores não consultam dados do cabeçalho IP - em particular aqui o roteador P-1, já que recebe um quadro Ethernet com EtherType 0x8847 (MPLS Unicast) e, portanto, não faz a consulta sobre a FIB e sim em outra estrutura específica para operações com labels. O que ocorrerá na sequência é muito simples: todo o tráfego entre PC-1 e PC-2 percorrerá apenas um único enlace no backbone entre os roteadores P1 e PE-2.

Para que o roteador P-1, ou o switch, ou ainda o roteador PE-2, pudesse distribuir o tráfego de maneira mais uniforme, o equipamento precisaria suportar um mecanismo de chaves de consulta mais específico para a realização de uma análise bem detalhada dos cabeçalhos especificados no pacote (o qual alguns fabricantes mencionam isto como "DPI"), só que esta capacidade não é amplamente suportada por muitos equipamentos. Consequentemente, teríamos aqui um problema com a distribuição de tráfego numa rede MPLS, tal qual a demonstrada na ilustração acima.

Soluções para o Problema com o Balanceamento de Tráfego em Redes MPLS

Felizmente há mecanismos inteligentes disponíveis para sanearmos estas dificuldades. Estes são:

• Entropy Label, RFC 6790
• Flow-Aware Transport (FAT) Label, RFC 6391

E uma ressalva aqui sobre a importância do Pseudowire Control Word, RFC 4385 em alguns projetos.

Entropy Label

As soluções proprietárias implementadas pelos fabricantes, tais como a inspeção detalhada de pacotes para a derivação das chaves de consulta, são um desafio para as redes heterogêneas e a sustentação de uma solução fim-a-fim para este propósito. Pensando nisto, a proposta do RFC 6790 foi a de suportar um mecanismo de balanceamento de tráfego padronizado através do uso de um label adicional sobre a pilha de labels (label stack) do MPLS, ou seja, com o advento do Entropy Label. Para que isto seja funcional, obviamente, é imperativo que haja a capacidade de sinalização por parte dos roteadores para que um label seja inserido única e exclusivamente para informar como deverá ser feito a distribuição de tráfego de um determinado fluxo, assim como garantir que todos os pacotes deste fluxo obedeçam a estas instruções e que sejam distribuídos da mesma forma.

Entropy Label

O Entropy Label em funcionamento

1. O Entropy Label Capability (ELC) é sinalizado do Egress LSR (roteador PE-2) para o Ingress LSR (roteador PE-1). Esta sinalização poderá ocorrer via LDP, BGP ou RSVP.
   1. A sinalização e o uso de entropy labels em um sentido é completamente independente da sinalização e uso de entropy labels do sentido inversno.
2. O Egress LSR deverá saber lidar com pacotes contendo ou não o EL.
3. O Egress LSR poderá enfileirar o pacote com base no EXP bits do LSP-L ou ELI e pode ainda usar o TTL do LSP-L ou ELI para calcular o TTL restante do cabeçalho (o TTL do EL é ignorado).
4. O Egress LSR sinaliza ambos ELC e Implicit Null (PHP habilitado) e deverá fazer o pop do ELI e do EL caso seja encontrado um pacote com ELI como topmost label.
5. O Ingress LSR (roteador PE-1) calcula o valor do label EL baseado no hash do conjunto de chaves de consulta derivado a partir do pacote IP original.
6. O Ingress LSR pode fazer um push do LSP-I, ELI e EL para o pacote, caso o Egress LSR (roteador PE-2) tenha indicado que pode processar o EL.
   1. O TTL e o TC (EXP) no ELI deverão ser os mesmos para o LSP-L.
7. O Ingress LSR poderá inserir (push) vários entropy labels na pilha, cada qual precedido por um ELI.
8. Se um Transit LSR (roteadores P-1 e P-2) reconhecerem o ELI eles poderão optar por balancear somente com base no EL, caso o ELI exista na pilha, ou olhar além da pilha, caso o ELI não seja encontrado.
   1. Os roteadores transit LSR (P-1 e P-2), os quais possuem ECMP ou LAG, então determinam as interfaces de saída com base no EL.
9. Na ilustração demonstrada, o switch presente na topologia poderia ser um problema para os objetivos de balanceamento de tráfego desejados, pois ficaria dependente exclusivamente de operações com endereços MAC (inclusive para as funções de derivação de chaves de consulta) ou, em último caso, ter que realizar um procedimento similar a um DPI. Este switch foi deixado na ilustração de propósito, mas, se preferir, ignore-o por enquanto.
10. No penúltimo salto (roteador P-2), o roteador reconhecerá o ELI e poderá fazer o pop de ambos ELI e EL, em adição ao LSP-L, antes de encaminhar o pacote "IP puro" para o roteador PE-2.

Exigências Gerais para o Entropy Label

• Considerando a topologia exemplificada acima, ambos os roteadores PE-1 e PE-2 devem suportá-lo.
  • O backbone, mesmo não suportando ou não compreendendo o EL, continua a realizar as operações normalmente com labels com base no LSP-L citado no exemplo acima.
• Sinalização por LDP, BGP e RSVP são suportadas.

Flow-Aware Transport (FAT) Label

A proposta do Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network é a de fomentar o balanceamento de tráfego através de L2VPNs sinalizadas por LDP, tais como o Virtual Private LAN Service (VPLS) e Virtual Private Wire Service (VPWS).

Numa rede MPLS os roteadores tipicamente realizam o balanceamento de tráfego com base no primeiro label contido na pilha de labels, o que certamente promoveria o mesmo valor de label para todos os fluxos de um determinado pseudowire. Isto resultaria em um balanceamento de tráfego um tanto assimétrico, pois, compreendendo melhor a definição de fluxo aqui, seriam sequências de pacotes contendo os mesmos pares de endereços de origem e destino e sendo transportados de um mesmo ingress PE para um mesmo egress PE. Com o FAT-Label ou FAT-PW é possível identificar fluxos individuais em um pseudowire e possibilitar aos roteadores da rede MPLS a habilidade de usar estes fluxos para os propósitos de balanceamento de tráfego, tanto para regimes ECMP quando para bundles Ethernet em L2.

FAT PW

O Flow-Aware Transport (FAT) Label em funcionamento

1. O roteador Ingress LSR (PE-2) realiza um push de labels para: identificar o serviço (Service Label, tipo uma L3VPN ou VC ID/L2VPN), além de um Flow Label, o qual será usado pelos roteadores do backbone para fins de balanceamento de tráfego.
2. Os roteadores do Transit LSR (P-1 e P-2) utilizam o Flow Label para a realização do balanceamento do tráfego, tanto em cenários ECMP quando bundle Ethernet em L2.
3. O penúltimo salto da rede MPLS (P-1), e considerando aqui que o Penultimate Hop Popping (PHP) esteja habilitado neste ambiente, faz a disposição (pop) do LSP-L e entrega o payload para o último salto/Egress PE (PE-1).
4. O Egress PE (PE-1), com base nas instruções do label SL saberá identificar a qual serviço L2 aquele pacote deverá ser destinado, e poderá ainda usar o Flow Label também para derivar o balanceamento de tráfego dos circuitos L2 locais, antes de fazer a disposição de toda a pilha de labels e encaminhar o payload restante para o equipamento de destino (SW-CE-1).

Algumas considerações sobre o FAT Label ou FAT PW

• É mandatório que todos os equipamentos da rede MPLS suportem estas especificações, ou seja, compreendam o Flow Label.
  • Para o balanceamento de tráfego funcionar com o FAT PW, o protocolo LDP utilizado deverá suportar a sinalização das extensões desta solução. E isto é mandatório para todos os roteadores PE onde as L2VPN são definidas com o recurso FAT PW adicionado.
• Flow Labels suportados com sinalização LDP com as seguintes Forwarding Equivalence Classes (FECs) para pseudowires em VPWS e VPLS:
  • FEC 128 para VPWS—LDP - sinalizado com vizinhos VPWS que são configurados estaticamente (BGP autodiscovery não é suportado)
  • FEC 128 para VPLS—LDP - sinalizado com vizinhos VPLS que são configurados estaticamente (BGP autodiscovery não é suportado).
  • FEC 129 para VPWS—LDP - sinalizado com vizinhos VPWS com BGP autodiscovery habilitado/suportado.
  • FEC 129 para VPLS—LDP - sinalizado com vizinhos VPLS com BGP autodiscovery habilitado/suportado.
• O Flow-Aware Transport of Pseudowires Extension for BGP (draft-keyupdate-l2vpn-fat-pw-bgp) discute a implementação disto nativamente pelo BGP:
  • Para ambientes BGP-signaled VPLS (RFC 4761) e BGP-signaled VPWS (RFC 6624), mas baseando-se na mesma proposta discutida no RFC 6391 original (Flow Aware Transport PW).
  • Inclusão de uma Layer 2 Info Extended Community no VPLS NLRI para fornecer instruções tais como Control Word, MTU, etc.

Control-Word

Geralmente não implementado na maioria das infraestruturas MPLS com serviços L2VPN dos dias atuais, o Control Word, apesar de ser opcional, era mandatório em algumas situações como, por exemplo, o Frame Relay e o AAL5. A principal função do Control Word é a de identificar o L2 PDU quando isto se faz necessário. O Control Word possui 32 bits de comprimento e fica situado entre o VC Label e o payload L2 sendo transportado. Na prática, o roteador ingress PE adiciona o Control Word e o egress PE o retira após o devido processamento. As cinco principais funções do Control Word:

• Padding
• Sequence Number
• Transportar bits de controle do cabeçalho L2 do protocolo sendo transportado (ex: FECN e BECN do Frame Relay sobre MPLS (FRoMPLS))
• Facilitar a fragmentação e remontagem de pacotes fragmentados, onde suportado
• Contribuir para o balanceamento de tráfego na rede MPLS - sendo este o foco do que está sendo discutido aqui.

Onde o Control Word não é de fato exigido, ou seja, "opcional" mesmo, não há problemas com ambiente ECMP em redes MPLS. Inclusive, no início dos projetos com pseudowire, há muitos anos, alguns equipamentos bem conhecidos eram incapazes de processar o Ethernet Control Word, e os roteadores MPLS pesquisavam logo após a pilha de labels de um pacote recebido para determinar de fato se o payload sendo transportado era IP e, a partir dali, ter condições de realizar o balanceamento de tráfego com base nas instruções contidas no cabeçalho IP.

Naquela época ainda não havia endereços MAC começando por 0x4 ou 0x6, e, por causa disto, era seguro adotar pseudowires sem o Control Word. Uma das técnicas que os roteadores utilizavam era justamente a de "bisbilhotar" além da pilha de labels para determinar se o pacote era realmente IP, além de determinar a sua versão (IPv4 ou IPv6), e fazendo a identificação do fluxo logo em seguida.

Em suma, o que os fabricantes faziam, e de forma até ingênua, era uma breve "verificada" no pacote logo após a pilha de labels para determinar o tipo de payload: se for 0x4 é IPv4, se for 0x6 é IPv6!

E quando o payload não era um pacote IPv4 ou IPv6, mas sim um payload L2 de uma L2VPN? Obviamente não seria identificado um 0x4 ou 0x6 ali, e sim "zeros", o que não traria o problema que será discutido a seguir.

O problema começou a surgir, e com ele a necessidade efetiva de adoção do Control Word, com o início da alocação de endereços MAC começando em 0x4 e 0x6, já que este tipo de situação passou a causar um problema com a ordenação das transmissões de L2VPN e até mesmo de transmissões IPv4 e IPv6: se, logo após a pilha de labels, for identificado no primeiro octeto um valor 0x4 ou 0x6, o roteador tratará esta transmissão como um payload IP e não como um payload de pseudowire. Aí teremos um problema, ou seja, uma confusão entre um quadro Ethernet e um pacote IP! Quando um pacote não for IP mas no primeiro octeto, após a pilha de labels, tiver sido identificado 0x4, este pacote será tratado como um pacote IPv4 ou, se identificado como 0x6, como um pacote IPv6.

É desnecessário frisar que isto afetaria consideravelmente os fluxos de tráfego daquele pseudowire, e, potencialmente, afetando muito negativamente as transmissões por protocolos mais exigentes neste sentido, como é o caso do TCP, dentre outros aborrecimentos. E por este motivo o Control Word passou a ser efetivamente útil.

Como o RFC 4385 resolveu isso? O Ingress LSR "estufa" 4 bytes no início do payload, sinalizado por LDP ou BGP, onde o primeiro nibble disto possui um valor de "zeros" para que, desta forma, o payload não seja confundido como um pacote IPv4 ou IPv6. Para que este serviço seja efetivo, obviamente, ambos os roteadores PE deste serviço de L2VPN deverão não somente suportar o Control Word, mas ter o Control Word habilitado para o pseudowire em questão.

Fonte: Cisco Live, apresentação

Este mesmo mecanismo de Control Word pode ser usado para evitar o problema e permitir ao Ingress PE identificar pacotes IPv4, IPv6, e pseudowires, possibilitando ainda que a inspeção possa ser feita para fins de geração das chaves de consulta com o intuito de ocorrer o balanceamento do tráfego. Na prática, você não substituirá os mecanismos Entropy Label e FAT PW citados: o Control Word não anula a necessidade de adoção das outras duas técnicas, de uma ou outra, onde isto for exigido, e vice-versa.

Espero ter contribuído.

Autor: Leonardo Furtado