Nesse artigo de hoje vou fazer uma introdução a um assunto muito falado nos últimos tempos que é o SDN ou Software Defined Network, mais especificamente vamos falar sobre o SDN para o CCNA e ICND-2.

Mais especificamente o SDN para o CCNA R&S pode ser cobrado tando na prova CCNAX como no ICND-2.

No CCNAX ele faz parte do tópico “7.0 Infrastructure Management” do Bleuprint Oficial da Cisco.

Mais especificamente está dentro do item “7.7 Describe network programmability in enterprise network architecture” e traz os seguintes sub-itens:

• 7.7.a Function of a controller (funções de uma controladora)
• 7.7.b Separation of control plane and data plane (separação da rede em planos ou planes)
• 7.7.c Northbound and southbound APIs (interfaces Norte e Sul)

Na prova do ICND-2 o SDN entra no tópico “5.0 Infrastructure Maintenance“, mais especificamente no item “5.5 Describe network programmability in enterprise network architecture“.

Os sub-itens são os mesmos que vimos para o CCNAX, porém numerados de 5.5a até 5.5c, pois tanto em uma prova (CCNAX) ou duas provas (ICND-1/CCENT + ICND-2) o conteúdo do CCNA R&S é o mesmo!

Por questões de tempo e produtividade, o que vou propor aqui nesse artigo é uma introdução aos tópicos em um nível que ajude a você e os demais leitores do nosso blog a entender o que será alvo desse tópico, assim como aprendam o conceito do SDN ou Software Definied Network.

Deixa eu começar essa história de SDN com algo que assiti em um vídeo onde o apresentador comentava que essa evolução das redes tradicionais, onde tudo ficava na infraestrutura do cliente, separado em redes e servidores físicos muito amarrados, para servidores virtualizados em data centers e depois para o conceito de nuvem acabou criando uma “ansiedade”, pois no mundo virtualizado e em nuvem de um data Center tornou-se muito flexível, mas a rede não acompanhou esse ritmo e continua praticamente a mesma como nos primórdios.

Os swicthes tem sistemas operacionais proprietários, sem a possibilidade de instalação de aplicativos e com comandos de configuração que variam conforme o fabricante.

Por exemplo, se tenho um gargalo e preciso migar uma VM para outro ambiente menos sobrecarregado é só mover, claro que não é tão fácil assim, mas é muito mais fácil que mudar algo na infraestrutura de redes atual. Por exemplo, se algo no OSPF não funciona bem na sua rede o que fazer? Nada, você não pode alterar o funcionamento do OSPF, ou seja, como dizia o querido treinador Zagalo “você vai ter que engolir o OSPF”, ponto final.

Vamos a outro exemplo, você precisa aplicar políticas de segurança que foram requisitadas pela empresa em todos os dispositivos, ou seja, roteadores, switches, firewalls, APs e demais dispositivos de redes necessitam ser atualizados ou reconfigurados. Nessa empresa temos 1000 pontos com 5000 dispositivos de rede no total.

Você precisará nesse caso elaborar a configuração em um script em txt para aplicar via CLI, normalmente cada tipo de equipamento vai necessitar de uma configuração diferente, temos portas diferentes, com várias nomenclaturas, sem contar que se sua empresa tiver vários fabricantes teremos ainda comandos diferentes. Em resumo: caos total e muito trabalho braçal!

O SDN ou Software Defined Networking (rede definida por software ou rede programável) traz um conceito parecido com o que estudamos na virtualização e nuvem, que é flexibilizar e possibilitar que inovações sejam realizadas mais facilmente na rede.

O SDN traz uma visão diferente, sugerindo que os dispositivos sejam controlados de fora e possam até ter seu comportamento alterado frente a um tráfego conforme configurado em um aplicativo externo.

Ao invés de cada dispositivo ter seu “cérebro” na caixa eles são controlados por um dispositivo externo chamado “controladora” ou “controller”, o qual acaba sendo similar aos hypervisors, que abstraem o hardware e possibilitam que ele seja dividido em máquinas virtuais, o controller pode comunicar-se com aplicativos externos que possibilitarão controlar a rede conforme a necessidade das aplicações da rede e não pelas necessidades da rede por si só.

Se você é bom observador deve notar a rede atual é meio “egoísta”, pois as aplicações e aplicativos que fornecem serviços aos usuários muitas vezes precisam adequar-se ao que existe ou então os administradores de rede precisam fazer “gambiarras” para resolver os problemas de falta de flexibilidade da rede.

O SDN traz o foco para a aplicação, pois precisa haver um equilíbrio entre rede e aplicação para que o máximo proveito seja tirado dos serviços.

Um exemplo do que o SDN pode trazer de benefício é para implantações de rede, tradicionalmente o que levaria semanas de configuração (provisionamento ou “Provision”) pode ser feito em horas ou até minutos.

A ideia central do SDN é a separação do control plane (camada de controle) da camada de encaminhamento (data plane).

Data Plane, Control Plane e Management Plane

Tudo o que os dispositivos de rede fazem pode ser dividido em funções ou planos, chamado em inglês de plane.

Por exemplo, um switch L2 encaminha quadros com base em seu endereço MAC, porém para fazer isso sem causar loops ele roda um algoritmo chamado Spanning-Tree, que tem mais a ver com controle que encaminhamento propriamente dito.

Além disso,  switch pode ser gerenciado via SNMP, por exemplo. Cada função citada pode ser classificada entre controle, encaminhamento e gerenciamento.

Essa é a base para entender e descrever como podemos criar redes programáveis, ou seja, separando as funções que existem nos dispositivos em três “planes”: data plane, control plane e management plane.

Atualmente nos dispositivos tradicionais tudo está na caixa, por exemplo, um switch tem esses três planes e tudo é realizado dentro dele. O SDN propõe a separação dessas funções, por isso é tão importante entendermos esses conceitos.

Controladoras SDN e Arquitetura Centralizada

Atualmente os dispositivos de rede tem uma arquitetura de controle (control plane) e gerenciamento (management plane) descentralizada, isso porque cada dispositivo ou caixa tem seu próprio controle e gerenciamento, simples assim.

Por exemplo, quando você precisa ativar um protocolo de roteamento como OSPF o que é preciso fazer?

Entrar em cada dispositivo e configurar o OSPF no control plane de cada um deles manualmente, seja através da CLI (com ou sem script) ou uma interface Web como o CCP, mas mesmo assim aplicar essa implementação (deploy) é uma tarefa feita dispositivo a dispositivo manualmente.

E após configurado cada dispositivo roda sua própria instância de OSPF localmente, portanto alterações mais uma vez precisam ser realizadas em cada dispositivo isoladamente.

Com o conceito de control plane os protocolos como STP, OSPF, EIGRP e demais da camada de controle poderiam ser centralizados e separados do hardware dos dispositivos, por exemplo, o control plane poderia estar rodando em um servidor ou dispositivo remoto de maneira centralizada ao invés de distribuído como é realizado na arquitetura convencional.

Sem discutir vantagens e desvantagens de arquiteturas centralizadas em relação a distrubuídas, a centralização do control plane permitiria, por exemplo, que alterações em vários dispositivos fossem mais simples, pois as informações de controle estariam centralizadas em um único ponto, facilitando a distribuição dessas novas regras para todos os dispositivos.

As redes programáveis e o SDN normalmente utilizam-se desse conceito de arquitetura de rede contralizada (centralized architecture), com a separação e centralização do control plane em uma controladora ou “controller”.

Essa controladora (controller ou SDN controller) tem, portanto, a função de centralizar o controle dos dispositivos de rede, sendo que o nível de controle pode variar conforme a implementação e/ou fabricante, indo de um controle completo de todas as funções do control plane, controle parcial ou até somente estar ciente do trabalho dos control planes distribuídos em dispositivos tradicionais.

Por exemplo, você poderia ter uma rede com uma controladora SDN centralizada e seus switches do data Center controladas por essa controladora, portanto os switches não teriam a inteligência neles.

Eles não decidiriam como aprender MACs ou encaminhar quadros, quem faria essas tarefas seria a controladora que apenas repassaria uma tabela de encaminhamento para os switches, os quais continuam tendo o data plane distribuído em cada dispositivo.

Note que a comunicação entre o controller SDN e os switches é realizada através de uma interface chamada Southbound Internet ou SBI, a qual utiliza protocolos específicos para comunicação, mas vamos estudar mais sobre esses detalhes no próximo tópico.

Interfaces SDN Southbound e Northbound

Quando falamos em interfaces na realidade não são interfaces físicas, mas sim interfaces de software ou APIs (Application Programming Interface) que os controllers utilizam para fazer a comunicação com os dispositivos de rede e demais dispositivos da arquitetura SDN.

O SDN define quatro tipos de interfaces: Northbound, Southbound, Westbound e Eastbound (norte, sul, leste e oeste), sendo que para o exame apenas as duas primeiras são importantes, pois as duas últimas tratam da comunicação entre controllers e não estão ainda bem definidas.

A arquitetura SDN normalmente é dividida em três camadas: Infraestrutura (infrastructure), Controller (camada de controle onde estão as controladoras) e Aplicação (application onde estão os aplicativos).

Como você pode notar na figura anterior a interface southbound ou SBI faz a comunicação entre o controller e os dispositivos da infraestrutura de redes como switches e roteadores.

A SBI é uma interface entre dois programas de computador (um contido no controller e outro no dispositivo de rede) que permite a comunicação entre eles, sendo que seu objetivo final é permitir que as tabelas de encaminhamento possam ser controladas nos dispositivos.

Essa comunicação pode ser realizada através de protocolos ou APIs.

Os APIs que são utilizados para que uma aplicação ou programa troque dados com outra aplicação ou programa, ou seja, um API é uma interface de aplicação (programa ou aplicativo) que permite que ele troque informações com outras aplicações.

A diferença para o protocolo é que para ele existe uma documentação, normalmente um padrão aberto ou proprietário, por exemplo, uma RFC que normatiza o protocolo, enquanto para a API temos funções, variáveis e estruturas de programação.

Com isso chegamos ao fim de mais um super artigo em nosso Blog, onde você pode aprender os princípios de funcionamento, topologias e terminologias do SDN.

Espero que você tenha gostado e indique nosso artigo para o máximo de amigos e colgas da área de Redes e Infra de TI, assim vamos disseminar cada vez mais conhecimentos e crescer nossa comunidade!

Muito obrigado e até um próximo post!