Exibir código-fonte para Protecao e Resiliencia em Redes L2 de Provedores

=== Proteção e Resiliência em Redes L2 de Provedores ===

==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====
Consulte [[Direitos Autorais Licenca de Uso|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: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''

=== Introdução ===
Este artigo foi elaborado com o objetivo de dissertarmos sobre os problemas, desafios, complicações e necessidades quanto à adoção de mecanismos de resiliência apropriados para as infraestruturas baseadas no Ethernet. Da mesma forma, este artigo provê uma introdução acerca das opções e tecnologias disponíveis para viabilizar a devida proteção das redes Ethernet e as vantagens e desvantagens de cada caso.

=== Algumas características e realidades sobre as redes Ethernet ===
A tecnologia Ethernet foi introduzida e disponibilizada comercialmente no início dos anos 80 e, desde então, teve um crescimento avassalador a ponto de hoje ser a tecnologia de enlace de redes predominante. Durante muitos anos o Ethernet conviveu com uma diversidade de tecnologias e protocolos para a comunicação de dados nas especificações de Camadas 1 e 2, tais como PPP, HDLC, X.25, Frame Relay, Token Ring, FDDI, ATM, ISDN e outros, categorizados em tecnologias de transmissão estatística (como as redes baseadas em pacotes) quanto as tecnologias de transmissão determinística (redes PDH, SDH são exemplos clássicos). 

A principal vantagem do Ethernet está na sua excepcional relação custo x benefício. Para exemplificar, comparado com interfaces de tecnologias de redes digitais, o Ethernet oferece maior capacidade de circuito e a um custo mais proporcionalmente bem mais baixo, e é justamente este modelo econômico do Ethernet que o tornou tão atraente desde o seu surgimento. Apesar disto, levaram-se muitos anos até que o Ethernet pudesse ser adotado nos ambientes de telecomunicações onde, por décadas, prevaleceram as tecnologias de transmissão determinísticas, como é o caso de redes de primeira e última milhas inteiras baseadas em xDSL e redes inteiras contando com infraestruturas PDH/SDH. E, por um bom período, as melhores redes eram baseadas em tecnologia ''Asynchronous Transfer Mode'' (ATM), que basicamente reunia o melhor dos dois mundos: transmissão estatística baseada em ''células'' com bons recursos de diagnósticos de falhas e qualidade de serviço.

Realmente nunca houve o que reclamar de tecnologias tais como o SDH, muito pelo contrário: confiabilidade próxima do impecável e excelentes recursos nativos para diagnósticos e suporte de falhas, detecção e mitigação de degradação de serviços, dentre outras ferramentas e recursos bem interessantes. O problema com as tecnologias não-Ethernet é justamente a questão financeira: com uma transmissão determinística, simplesmente não há como adotar o excesso de subscrição (''oversubscription''), e isto praticamente anula ou inviabiliza qualquer possibilidade de termos um modelo econômico sequer próximo daquele que é possível com uma rede Ethernet. E numa rede SDH os upgrades são sempre muito custosos e um tanto engessados por conta disto. 

Já que o Ethernet possui um excelente modelo econômico, através de ótima relação custo x porta, por que, então, demorou tanto tempo para termos redes Ethernet em ambientes de telecomunicações? A resposta para esta pergunta está justamente naquilo que o Ethernet não possuía nativamente (e de certa forma, pensando por um lado aqui, ainda não possui, pois isto é feito por mecanismos periféricos): '''''confiabilidade'''''.

Os mecanismos nativos para fins de detecção e reparação de falhas do Ethernet, se comparados aos de uma rede SDH, são pífios, nulos. A ausência de suporte a técnicas adequadas para deteção e restauração de falhas no Ethernet foi um dos principais empecilhos para o seu desenvolvimento para fora dos ambientes de redes locais (LAN).

No entanto, com o surgimento do consórcio ''[https://www.mef.net/ Metro Ethernet Forum]'' (MEF) no ano de 2001, reunindo os principais fabricantes e fornecedores de tecnologias para o Ethernet do mundo, assim como grandes esforços do ''Institute of Electrical and Electronics Engineers'' (IEEE) e do ''Internet Engineering Task Force'' (IETF), o Ethernet ganhou corpo e sofreu a adição de tecnologias complementares que agregaram boas capacidades e recursos, injetando componentes de gerenciamento (Falhas, Desempenho, Segurança e outras áreas) e mecanismos de confiabilidade que estimularam a sua adoção para ambientes de provedores de serviços de telecomunicações.

Como não é o escopo deste artigo dissecarmos os padrões do MEF, recomendo a leitura destes aqui: http://www.mef.net/resources/technical-specifications

=== Por que precisamos adotar uma tecnologia de resiliência para as redes Ethernet? ===
Se analisarmos com cautela o funcionamento de uma rede Ethernet e a própria estrutura de seu cabeçalho, perceberemos que há uma fragilidade muito grande presente no Ethernet como um todo. Comecemos pelo fato que switches Ethernet são meramente ''bridges transparentes multiportas''. O que isto significa? Que não há modificações nos endereços físicos (''Media Access Contro'', ou simplesmente "''Endereço MAC''"). Nem o endereço MAC de origem nem o endereço MAC de destino são modificados pelas bridges (switches) em trânsito. Em adição, não há um mecanismo nativo no quadro Ethernet para controle de diâmetro (ex: um campo TTL não existe no cabeçalho Ethernet!). Isto significa que um ''frame'' (quadro Ethernet) pode "loopar" indefinidamente. Isto mesmo, um "loop eterno" que, no mínimo, provocará muita lentidão na rede e, em muitos casos, podendo paralisar a rede por completo até que o loop seja resolvido/mitigado. Para que você possa compreender isto com clareza, permita-me desenhar:
[[Arquivo:Bpf-resilienciaethernet-1.png|centro|miniaturadaimagem|900x900px]]
# Switches são ''bridges'' multiportas que fazem a microssegmentação da rede.
## Um domínio de colisão por porta.
## Permite comunicações em modo de operação full duplex em cenário ponto a ponto.
## Permite misturar portas de capacidades distintas.
# As comunicações ''unicast'' (entre dois computadores, por exemplo) empregam somente as portas interessadas naquela comunicação.
## As demais portas não recebem cópias dos quadros destas transmissões.
## Para este procedimento, o switch precisa construir e manter atualizada uma tabela contendo os endereços físicos ("''Tabela MAC''") que são acessíveis pelas portas onde encontram-se conectados.
### A porção "Endereço MAC de Origem" do quadro Ethernet é usado pelo switch para associar aquele endereço físico sobre a porta em que o quadro foi recebido.
### A porção "Endereço MAC de Destino" do quadro Ethernet é usado pelo switch para determinar a porta que será utilizada para encaminhar o quadro recebido.
# Os endereços físicos (MAC) '''<u>não</u>''' são modificados pelo switch.  Por isto que nos referimos à tecnologia de comutação Ethernet como ''transparent bridging.''
Então o nosso primeiro desafio está assinalado justamente no item "3" acima: os switches não modificam os endereços MAC de destino dos quadros em trânsito (de uma porta para a outra). E, conforme citado anteriormente, não possuem um campo com uma funcionalidade parecida com o campo TTL do cabeçalho IP, por exemplo. E isto implica que:
* A construção de uma topologia redundante (equipamentos e enlaces físicos) provocará naturalmente um loop no Ethernet. E loop na camada 2 provoca situações graves de degradação de performance e até mesmo indisponibilidades de partes ou de toda a infraestrutura.
* Que necessitamos de topologias redundantes para justamente termos maior disponibilidade do ambiente. Afinal de contas, precisamos aprimorar o nosso SLA sobre os serviços que mantemos com os nossos clientes e parceiros, certo?
E é nesta parte que entram os protocolos de resiliência Ethernet que serão apresentados na sequência do artigo.

Antes abordarmos os protocolos de resiliência, façamos uma revisão das consequências de um ''bridging loop'' numa rede Ethernet:
[[Arquivo:Bpf-resilienciaethernet-2.png|centro|miniaturadaimagem|900x900px]]

'''"Um endereço MAC só pode estar registrado/associado à uma <u>única</u> porta de um switch".'''

Switches utilizam o campo "Endereço MAC de origem" do cabeçalho Ethernet para associar aquele endereço com a porta por onde o quadro foi recebido. E utilizam o campo "Endereço MAC de destino" do mesmo quadro para tomar a decisão de comutação ou de encaminhamento do quadro. E o switch não modifica estes endereços dos quadros em trânsito. E não há um controle de diâmetro (ex: TTL) no cabeçalho Ethernet. Tudo isto já foi exaustivamente comentado neste e em outros artigos publicados na Wiki do BPF. Continuando com o cenário ilustrado acima, teríamos um grave problema com este único quadro disparado pelo PC-1 com destino ao PC-2, numa topologia redundante e sem a presença de um protocolo de resiliência:
[[Arquivo:Bpf-resilienciaethernet-3.png|centro|miniaturadaimagem|900x900px]]
Como um determinado endereço MAC só pode estar associado à uma única porta do switch, e que switches não modificam os endereços MAC dos quadros em trânsito, temos aí todos os elementos para um problema. Um único quadro, apenas um único quadro mesmo, poderá loopar indefinidamente numa rede topologicamente redundante que não tenha um protocolo de resiliência habilitado. Ou, mesmo que haja um protocolo de resiliência presente na infraestrutura, a má configuração deste protocolo assim como eventos inesperados podem provocar este "loop eterno" na rede. E estamos falando até então de um <u>único</u> quadro percorrendo a rede! Agora imagine como ficaria uma rede real, onde um computador transmite centenas de quadros por segundo? Os switches ficariam tão ocupados fazendo "reparos" em suas tabelas MAC e inundando os quadros através de suas portas, que vários efeitos seriam notados:
# '''Aumento expressivo do consumo de banda.''' Sim, aparentando inclusive ser uma "bola de neve".
# '''Lentidões excessivas na rede.''' Decorrentes do aumento da banda que vai se acumulando nos enlaces em função do loop, assim como o aumento do processamento dos equipamentos.
# '''Desconexões e mau funcionamento de aplicações'''. Beirando o cenário de impedimento absoluto das conversações na rede.
# '''Potencialmente, a paralisação da rede'''. Muitos switches do mercado não sabem lidar nem um pouco com esta situação, e "abrem o bico" logo nos primeiros minutos de um loop na Camada 2. São situações que impediriam, inclusive, o administrador da rede de conseguir acessar os equipamentos para ver o que está acontecendo!

==== As exigências pela adoção de um protocolo de resiliência ====
Precisamos de protocolos de resiliência pelas seguintes e óbvias razões:
* '''Aprimorar os índices de disponibilidade da infraestrutura.''' 
As redes precisam dispor de componentes físicos em disposição redundante assim como diversos recursos de software que maximizam a confiabilidade proporcionada pelo aparato físico redundante, incluindo alguns protocolos e similares, para que sejam asseguradas a alta disponibilidade e níveis de serviço adequados para seus usuários. <u>Os protocolos de resiliência servem num primeiro momento para viabilizar topologias redundantes ao mesmo tempo em que prevenindo o surgimento de bridging loops</u>.
* '''Permitir a rápida recuperação da infraestrutura em cenários de falhas.'''
Um tanto alinhado quanto ao ponto acima, porém sendo mais específico aqui nas ações de reparo e recuperação de eventuais falhas que afetarem partes da infraestrutura. <u>Uma das principais atribuições dos protocolos de resiliência é a de ofertar mecanismos confiáveis para a recuperação de falhas que eventualmente afetarem a infraestrutura</u>.

Ou seja:

'''''"Possibilitar topologias físicas redundantes ao mesmo tempo em que prevenindo loops na Camada 2, e ofertando mecanismos confiáveis para rápida recuperação de falhas."'''''

Se considerarmos as premissas determinadas pelos padrões Carrier Ethernet 2.0 vigentes, a resiliência das redes Metro Ethernet deverá contemplar:
# Não deverá permitir loops no plano de dados de redes L2.
# Deverá garantir congruência nos caminhos do plano de dados para a ida e o retorno das transmissões. O que significa: não deverá haver mudanças do endereço MAC em cenários de distribuição de tráfego.
# Deverá garantir um ponto único de entrada e saída do segmento Ethernet, evitando-se loops e a duplicidade de pacotes numa rede.
# Deverá garantir mecanismos de ''flushing'' e re-aprendizado de endereços em eventos de mudanças na topologia da rede, com o intuito de prevenirmos o ''blackholing'' do tráfego. As tabelas MAC precisam ser atualizadas após eventos de convergência.
Estes são os motivos pelos quais necessitamos de um protocolo de resiliência para redes Ethernet.

=== Exemplos de Tecnologias para a Resiliência de Redes Ethernet ===
Para manter a objetividade do artigo, descreveremos apenas as principais tecnologias no certame "L2" e sem esmiuça-las tecnicamente ou com detalhes. Suprimiremos as tecnologias de resiliência usadas em redes IP e MPLS. Futuros artigos na Wiki do BPF entrarão em detalhes sobre estas tecnologias. 

==== Resilient Ethernet Protocol (REP) ====
O REP é um protocolo proprietário da Cisco, na verdade o primeiro protocolo de resiliência para o Ethernet projetado em topologias em formato de anel. O REP foi desenvolvido para sanear os principais problemas encontrados no protocolo Spanning Tree, possuindo muitas vantagens sobre as implementações de STP tradicionais:
* Menor tempo de convergência
* Confiabilidade na questão "imunidade contra bridging loops"
* Maior escalabilidade, se comparado aos diâmetros máximos recomendados por redes mantidas pelo STP
A proposta do REP é viabilizar uma topologia redundante isenta de loops, além de ofertar excepcional tempo de convergência em cenários de falhas (entre 50 a 250 ms), com rápida notificação de falhas, mesmo em anéis de acesso grandes. Para seu funcionamento, as interfaces participantes não possuem o protocolo STP habilitado, mas há o envio de Topology Change Notification (TCN) do STP quando ocorre uma falha num segmento REP. O REP também permite cenários de engenharia de tráfego com o balanceamento disto feito por VLANs.

O REP funciona de forma relativamente bem simples: não deverá haver conectividade entre duas portas ''Edge''. Portanto, um segmento REP é construído em um sequência de interfaces identificadas com um ''Segment ID'' e, quando todas as portas deste segmento estiverem operacionais, uma porta definida como ''Alternate'' fica em estado de bloqueio, justamente impedindo a comunicação entre as duas portas ''Edge''. Quando ocorre a falha de um dos links que estão presentes neste segmento REP, a porta ''Alternate'' é então desbloqueada, saindo do estado ''Blocked'' para ''Open.'' E, com isto, consegue-se rapidamente a restauração da comunicação do Anel. Há recursos adicionais no REP, tais como o ''REP No Neighbor'', que permite a integração bem interoperável entre segmentos REP e domínios STP e VPLS.
[[Arquivo:Bpf-resilienciaethernet-4.png|centro|miniaturadaimagem|650x650px|Fonte: BRKOPT-2018]]
[[Arquivo:Bpf-resilienciaethernet-5.png|centro|miniaturadaimagem|650x650px|Fonte: BRKOPT-2018]]
Por ser um protocolo proprietário da Cisco, não recomendamos a abordagem por este protocolo, particularmente em redes heterogêneas. Para este propósito, recomenda-se a abordagem pelo padrão aberto equivalente, o G.8032.

==== G.8032 - Ethernet Ring Protection Switching ====
Assim como o REP, o G.8032 tem a proposta de fornecer proteção e resiliência em redes de Acesso primariamente dispostas em topologia de anel. Possui excelentes capacidades de recuperação de falhas (tipicamente 50 ms). A tecnologia é dependente do mecanismo de deteção de falha denominado ''Ethernet OAM'', como seu canal de controle, e do ''Y.1731 Ring-Automatic Protection Switching (R-APS)'' para sinalizar falhas para o upstream, suportando anéis ''open'' e ''closed'', à exemplo do REP.
[[Arquivo:Bpf-resilienciaethernet-6.png|centro|miniaturadaimagem|650x650px|Fonte: BRKOPT-2018]]
O funcionamento do G.8032 é relativamente simples também. Empregando o ''Ethernet OAM'' como canal de controle, em condições normais, será identificado a possibilidade de cenário de loop na infraestrutura e uma porta do anel ficará em estado de bloqueio denominado ''Block Ring Protection Link'' (RPL). Quando ocorrer uma falha em um dos links deste anel, o mecanismo ''Y.1731 R-APS'' sinalizará uma mensagem ''Signal Failure'' (SF), culminando no desbloqueio do RPL, além de uma manutenção de uma tabela mantida pelo mecanismo chamada ''Forwarding Database'' (FDB), para todo o anel, conforme necessário.

O G.8032 tem a mesma proposta do REP da Cisco, porém é melhor em alguns aspectos e é padrão aberto, ou seja, suportado por todos os fabricantes de primeira linha.

==== Multi-Chassis LACP e Inter-Chassis Communication Protocol (ICCP) ====
São tecnologias utilizadas para a construção de agregação de portas Ethernet em de um equipamento para dois equipamentos distintos. Os motivos pelos quais você deveria ou poderia agregar portas Ethernet físicas, tornando-as um único canal lógico, serão suprimidos deste artigo. No entanto, confira este artigo publicado na Wiki do BPF para maiores informações: [[Balanceamento de Trafego em Redes MPLS]]

No cenário demonstrado logo abaixo, o equipamento à esquerda, em termos de L2, acredita estar conectado fisicamente para um único equipamento remoto (à direita) mas, no entanto, tratam-se na verdade de dois equipamentos físicos completamente distintos. Este tipo de cenário é um tanto interessante, tanto na perspectiva de distribuição de tráfego quanto na questão de maior disponibilidade do ambiente.
[[Arquivo:Bpf-resilienciaethernet-7.png|centro|miniaturadaimagem|650x650px|Fonte: BRKOPT-2018]]
Para este cenário funcionar, o dispositivo à esquerda é identificado como um ''Dual-Homed Device'' (equipamento de acesso que possui dos equipamentos de borda adjacentes). O DHD opera como se estivesse conectado para um único equipamento adjacente - mas, na prática, sabemos que são dois aqui - e opera com o protocolo ''IEEE 802.1AX-2008'' (LACP) típico. Já o ''Point of Attachment'' roda um protocolo específico chamado ''Inter-Chassis Communication Protocol'' (ICCP) para sincronizar o estado e formar então um grupo de redundância (''Redundancy Group'' (RG)). Esta solução de mLACP oferece proteção contra cinco pontos de falhas:
* Falha da porta DHD
* Falha do uplink DHD
* Falha da porta do PoA ativo
* Falha do nó PoA ativo
* Isolamento do nó PoA ativo do Core da rede
A combinação de um ambiente empregando diversas destas tecnologias de resiliência é possível mediante um sólido, bem elaborado, projeto técnico e de suas referidas especificações.

==== Ethernet Automatic Protection Switching (EAPS) ====
Alinhado com os mesmos objetivos ou propósitos das demais tecnologias discutidas neste artigo, o EAPS foi desenvolvido pela Extreme Networks e submetido para o IETF na forma do <nowiki>RFC 3619</nowiki>. A proposta é a de fornecer uma infraestrutura Metro Ethernet baseada em anel apoiada por mecanismos próprios para prevenção da formação de ''bridging loop'' e também a rápida recuperação contra falhas em um dos sentidos do anel. Há variações na implementação do EAPS com o Ethernet Protection Switching Ring (EPSR), sendo esta uma das modalidades de implantação mais difundidas em ambientes multivendor e que fomentou a base para o estabelecimento do G.8032.

Alguns fabricantes adotaram o EAPS, sendo um deles a Datacom, bastante conhecida pelos provedores de Internet do Brasil.

==== Spanning Tree Protocol e suas variações: 802.1D (STP), 802.1W (RSTP), 802.1D (MST) ====
Não será ainda (ou a vez) de escrevermos um artigo esmiuçando o funcionamento do protocolo Spanning Tree. Citaremos apenas como uma das possíveis tecnologias de resiliência para redes Ethernet. O STP é um conhecido protocolo de resiliência Ethernet que surgiu e ainda é indicado para infraestruturas do porte de uma rede local (LAN). É possível, sim, rodar o STP em redes metropolitanas, mas desde que sejam respeitadas as suas limitações acerca de diâmetro máximo recomendado, além das restrições quanto à engenharia de seus temporizadores, e, por último, você arcar com as consequências de algumas de suas limitações e desafios impostos por este protocolo.

Muitos provedores investem em aparato tecnológico (ex: switches) de missão inadequada para a atuação em infraestruturas Ethernet de escala metropolitana. Não é incomum encontrarmos provedores que realizam investimentos em switches de missão definida para '''LAN''' e até casos de switches destinados para '''conectividade de servidores'''. Para todos os efeitos, informo que estes tipos de equipamentos não foram projetados para a missão específica de provedores, assim como não atendem bem às dezenas de requerimentos e exigências das redes Metro Ethernet. 

Não dá realmente para generalizar, mas, se a sua rede precisar ser completamente L2 - futuramente publicarei um artigo explicando as vantagens e desvantagens entre ambientes de Acesso Metro L2 e L3 - tente construir uma topologia mais simplificada (ex: anéis de tamanho adequado, nada excessivo) e adote um protocolo de resiliência melhor que o STP. Por exemplo, o G.8032.

Aqui na Wiki do BPF publicaremos artigos específicos para tratarmos do STP, assim como das demais tecnologias citadas neste artigo. Fique antenado!

'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
[[Categoria:Roteamento]]