Tradicionalmente, as redes ethernet (tanto para Data Center como para campus LAN), respeitam um modelo hierárquico de arquitetura chamado “three tier layer”, onde há uma camada de core (núcleo), distribution (distribuição) e access (acesso). Cada uma dessas camadas define uma função específica.
Via de regra, a camada de acesso é utilizada para prover a conexão dos dispositivos de rede dos usuários finais (desktops, laptops, impressoras, pontos de acesso wireless, etc.) à rede propriamente dita.
A camada de distribuição, é utilizada no sentido de prover o roteamento e a agregração entre as VLANs dos usuários nas camadas de acesso. É nesse camada onde se definem listas de acesso, regras de segurança, políticas de roteamento entre VLANs, etc.
Por fim, a camada de núcleo (core) é a cada responsável por agregar tudo isso e fazer o “hand off” da rede para o mundo externo. Via de regra, nessa camada se conectam os roteadores, firewalls e todos os dispositivos responsáveis pela interconexão do mundo LAN para o mundo WAN (ou outras redes fora de uma determinada rede LAN). A figura abaixo, ilustra o conceito da arquitetura “three tier”:
Notem que por uma questão de redundância e alta disponibilidade da rede, todos os switches (ilustrados pelos quadrados) possuem duas conexões para a camada vizinha: se uma conexão falhar, a outra pode assumir todo o tráfego sem problemas.
Além da arquitetura “three tier”, há uma adaptação desse desenho, chamado de “two tier”. A idéia é similar à da primeira. Porém justifica-se utilizá-la em redes menores (até 500 pontos na camada de acesso). Nesse caso, a camada de core e distribution serão “colapsadas” em uma única camada. Assim:
Mesmo nesse desenho, a idéia da redundância para alta disponibilidade continua presente: tenho dois links para a camada de cima. Se um falhar, o outro assume o tráfego.
Alguém nessa altura do texto (espero que sim) poderia se perguntar: se a idéia é prover redundância de conectividade, porque não aumentar o número de links entre as camadas? Porque manter só dois links entre um elemento de uma camada e o outro de outra, sendo que eu poderia fazer 3, 4, ou 5 links?
Antes de responder o porquê, vale uma observação: mesmo que não houvesse restrição tecnológica para usarmos mais de dois links, valeria a pena financeiramente falando? Em redes de data Center, estou certo que sim. Em redes campus LAN (para usuário final), a resposta pode não ser tão óbvia…
Mas, voltando à tecnologia: lembram-se do Spanning Tree Protocol? O protocolo que limitava a utilização dos meus links entre as camadas da rede hierárquica, com o intuito de evitar as “broadcast storms”? A resposta do porquê não fazer mais de dois links entre as camadas está aí.
Lembrem-se que o Spanning Tree é um protocolo que deixava um link habilitado (funcionando) e o outro em “stand by” (aguardando uma possível falha no primeiro). Essa é uma limitação do protocolo. Dessa forma, um switch que está na camada de acesso conectado por dois links a dois switches de distribuição (ou core) distintos, estará de fato utilizando apenas um link. O outro está esperando a falha do primeiro para entrar em ação. Na figura abaixo, a linha inteira representa o link ativo. A linha pontilhada, o link bloqueado. A mesma idéia se multiplica por todos os “n” dispositivos conectados às camadas da rede (não importa qual).
Se fizéssemos 3, 4 ou 5 links, a mesma coisa aconteceria: apenas um link estaria ativo. Todos os outros ficariam parados. Dessa forma, não faria sentido adicionar tantos links quanto fossem possíveis, já que você só continuaria utilizando apenas um de fato.
Até aqui falamos do desenho tradicional de redes Ethernet hierárquicas (em três em duas camadas). Em resumo, podemos relacionar algumas das suas características principais:
- Links entre as camadas sempre feito em dois uplinks: um ativo, um bloqueado (em stand by, aguardando a falha do primeiro link).
- Protocolo Spanning Tree presente: previne os loops de broadcast na rede, porém reduz sua capacidade instalada de utilização simultânea de uplinks (em fibra óptica ou pares metálicos) em 50%. Além disso, num ambiente com múltiplos domínios de broadcast (VLANs), configurar spanning tree pode ser algo desafiador… (usa-se nesse caso o PVSTP – per VLAN Spanning Tree Protocol)
- Switches de core e/ou distribuição do tipo “chassis”: dada a necessidade de alta concentração de portas nessas camadas, switches de configuração de portas fixas podem não oferecer um número de portas suficientes para conectar todo mundo que está logo abaixo. Além disso, essas equipamentos oferecem um nível de redundância intrínseca à sua própria arquitetura de hardware. Via de regra, é possível configurá-los com duas placas de processamento (Supervisor como gostam de chamar os Cisco Guys, Management Module como gostam de chamar os Brocade Guys, Route Engine como gostam de chamar os Juniper Guys…), várias fontes de energia redundantes, coolers redundantes e por aí vai…
Mas… e se fosse criado um protocolo que endereçasse todas as ineficiências do Spanning Tree protocol. Onde fosse possível fazer plena utilização dos meus recursos de uplink (inclusive se eu quisesse utilizar mais de dois), tudo funcionando na camada 2 (Ethernet mesmo) sem ter que apelar para uma segmentação através de endereçamento IP (o que pode ser trabalhoso também) e sem correr o risco de ver minha rede com loops infinitos de broadcast “comendo” os meus uplinks e processadores dos switches?
A boa notícia: esse protocolo já existe! Trata-se do TRILL – Transparent Interconnect of Lots of Links. Esse protocolo permite o conceito de core distribuído (onde é possível colocarmos mais de dois switches na camada de core com utilização de todos os uplinks entre as camadas que compõe a rede).
O TRILL reúne em um único protocolo as vantagens da comutação (feita em camada 2) com as vantagens do roteamento (feito em camada 3). Além disso, para evitar eventuais loops de broadcast, utiliza um conceito extremamente simples que já é utilizado hoje pelo protocolo IP – o conceito de hop count – cada vez que um quadro de dados passa por um switch, um campo de hop count é decrementado. Quando esse valor chega a zero, o switch descarta o pacote (no IP esse campo é chamado de TTL – time to live)
Por conta de incorporar conceitos de comutação e roteamento em um único dispositivo, os switches são comumente referenciados como RBridges (Route-Bridges) na terminologia do protocolo TRILL.
E já que estamos falando em terminologia, nas redes de core distribuído as camadas são chamadas de camadas de SPIN e LEAF.
Além disso, o TRILL utiliza um protocolo do tipo “link state” para fazer o roteamento entre os nós da rede. Trata- se do IS-IS (Intermediate System to Intemediate System). Porém, ao invés de roteamento de endereços IP, ele faz o roteamento de endereços físicos, ou seja: roteamento de MAC ADDRESS!!!
Portanto, podemos dizer que o TRILL é um protocolo da camada 2,5: ele opera na camada 2, porém utiliza recursos de camada 3 para funcionar!
Além disso, o TRILL possibilita o que era impensável em redes hierárquicas tradicionais usando Spanning Tree protocol – a utilização do conceito de ECPM – Equal Cost Multi Path – que nada mais é do poder encaminhar as informações entre as camadas e nós através de diversos links simultaneamente – fazendo assim, load balance entre os diversos links que interligam as camadas da topologia.
Em resumo, com TRILL, é possível criar redes com topologias assim:
Note que cada switch da camda de leaf (a de baixo), possui uma conexão para cada elemento da camada de spin (a de cima). Isso cria o conceito da rede ethernet full fabric. E note que, se eventualmente um dos switches da camada de spin falhar, os demais continuam suportando o tráfego que vem dos equipamentos da camada de leaf, sem comprometer o funcionamento da rede. Além disso, todos os links estão em pleno funcionamento: sem bloqueios!
Em resumo, nas redes TRILL encontraremos as seguintes características:
- utilização plena de todos os recursos de links entre as camadas de SPIN e LEAF
- pode-se utilizar switches “mais simples” no que diz respeito ao nível de redundância de hardware – já que todos os switches participam no processo de composição do core distribuído, restam vários outros que podem assumir a função daquele que falhar.
- interoperabilidade com as redes hierárquicas legadas (que ainda estão rodando Spanning Tree).
O assunto é extenso e há muitos outros detalhes envolvidos. A idéia aqui é mostrar como está evoluindo o desenho de soluções de rede Ethernet e quais são as alternativas aos desenhos tradicionais. Há ainda muitos paradigmas a serem quebrados (principalmente quando falamos em aposentar os grandes switches chassis de rede, que passam uma sensação de segurança muito grande dada a sua alta redundância de hardware). Mas, definitivamente, é uma tendência para os próximos Data Centers que vem por aí.
