Olá Pessoal,

   Acredito que muitos vem escutando esse termo mencionado em nosso título, e acredito que para muitos isso ainda é uma “ caixinha preta “.

   Definitivamente esse termo vai alterar muito o dia a dia de nosso trabalho. Como o próprio nome diz, ” Redes definidas por software “, ou seja, falando resumidamente o software vai programar toda a nossa rede. Sim e não.

   Na verdade, aquele nosso famoso conceito sobre a estrutura de nosso querido hardware, onde existe plano de controle e o plano de dados, o SDN trabalharia diretamente nessa camada do plano de controle, que hoje cada hardware executa individualmente sua ações/decisões. Segue abaixo:

   Para trazer um pouco mais definição sobre esse termos, poderíamos resumir dessa forma:

• Plano de Controle: São relacionados aos dados locais a serem utilizados para criar as tabelas de roteamento, controle dos protocolos, calculos dos algoritmos, etc, para que o plano de dados possa encaminhar as informações entre as portas de entrada e saída. Pense na questão da RIB ( Routing Information Base ) e na FIB ( Fowarding Information Base ).
• Plano de Dados: O datagrama correto é processado no plano de dados realizando as buscas na FIB ( que já foram anteriormente programadas pelo plano de controle ). As ações que poderíamos definir aqui seriam: Encaminhar ( ou replicar na questão de multicast ), descartar, remarcar, enfileirar.

   Segue abaixo um detalhamento sobre as funcionalidades que cada camada vai executar.

   Lembrando-se que todo pacote que é processado pela control plane é tendencioso é ser mais lento, porque precisamos executar uma solicitação ao processador para ele efetuar as tarefas e posteriormente devolver isso a camanda de data plane. Vale ressaltar que hoje a maioria dos novos equipamentos já trabalham com processadores dedicados em sua camada de controle.

   Com isso a ideia do SDN foi fazer com que toda a essência do controle fosse feita separadamente da camada de dados, com isso o fator “ pensante ” de toda minha infra estrutura estaria nessa camada, ficando a cargo de equipamentos mais ” baratos ” para efetuar a comutação dos pacotes. Devido a estes fatores todas as empresas começaram a enxergar isso como uma metodologia promissora, para que de uma forma dinâmica eu posso efetuar minhas tarefas sem ter muito a influência em relação ao qual vendor eu vou trabalhar no futuro.

   Porém, isso nada adiantava se não existir um protocolo em qual todos os fabricantes possam se conversar e a comunicação entre essas camadas fosse de comum acordo. Relacionado esse ponto foi iniciado a menção sobre o protocolo OpenFlow de natureza opensource, onde todas as empresas poderiam desenvolver baseado nesse protocolo. Para entender um pouco melhor recomendo dar uma visitada nesse link que é do proprio orgão que está trabalhando nesses quesitos.

   Nas menções sobre Cisco temos diversos equipamentos que foram definidos para utilização do OpenFlow, como:

• ISR, ASR, Nexus, linhas do Catalyst
• Cisco ONE ( Open Network Environment ) –  definido para controladora de software
• Cisco ONEPK – um pacote proprietario de APIs criado pela Cisco

   Como em toda metodologia a Cisco traz algumas menções sobre melhoria dos protocolo, devido a isso você pode observar que ela traz essa evolução que ela chama de OpFlex.

   Nos posts seguintes vou trazer um pouco mais detalhamento sobre OpFlex e menções sobre ACI da Cisco. Aguardem!!!

Abs,
Rodrigo

Fonte: http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-59/161-sdn.html