Introducao aos conceitos de programabilidade de infraestruturas de redes

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes

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

Este artigo apresentará fundamentos importantes acerca do gerenciamento de redes, em especial a disciplina de configurações, e pavimentará a sua jornada, caro leitor da Wiki do BPF, para as questões de programabilidade de infraestruturas de redes e com foco aos ambientes de ISP. Este é mais um daqueles artigos que publico na Wiki do BPF onde a principal intenção ou motivação é ensinar, educar, e capacitar e, portanto, o artigo não vai direto ao ponto: conto uma história primeiro, volto no tempo para mostrar algumas coisas e eventos importantes e, lá para o final, é que comento com mais propriedade sobre os aspectos de programabilidade pretendidos por este artigo. Esta abordagem mais didática poderá ser melhor apreciada por leitores mais "leigos".

Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo!

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes: comparando a rede ideal versus os modelos tradicionais

Pré-requisitos

A leitura deste artigo fará muito mais sentido caso você reúna determinados pré-requisitos em termos de conhecimentos técnicos. Recomendo que certifique-se de possuir os conhecimentos equivalentes aos temas discutidos nos seguintes artigos, já publicados na Wiki do Brasil Peering Forum (BPF).

• Fundamentos de Roteamento para Provedores
• Frameworks de Indústria para a Reestruturação e Profissionalização do ISP
• Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor

Precisamos evoluir: continuar configurando e operando ambientes de redes complexos da mesma forma em que temos feito por décadas, pra que?

Você já parou para pensar que, toda a vez que você recebe uma solicitação para a ativação de serviço, uma série de cuidados precisam ser observados? Você precisa gerir a demanda através de várias ações estritamente manuais, incluindo a projeção da mudança, produção do roteiro de configurações, classificação dos impactos, revisão de capacidades, reserva de recursos, a efetiva aplicação de blocos inteiros de configurações sobre um ou mais elementos de rede, além de fazer o arquivamento daquela mudança, acompanhamento, monitoramento e, eventualmente, o suporte. Você provavelmente deve ter uma noção que há muitos riscos e complicações durante todo este processo, mas que, de certa forma, estamos mais que habituados a isso. É uma questão cultural, algo que nos acompanha por muitos e muitos anos. Quanto a esta evolução proposta, eu passarei a fornecer algumas boas justificativas para que você possa compreender melhor a minha visão, e também o direcionamento de mercado, sobre esta redefinição de nossas práticas operacionais:

Como a programabilidade de redes poderá ajudar a superar os principais desafios dos modelos de operação tradicionais

Situação	Descrição
Atenuação da complexidade operacional	Embora não seja exatamente a realidade de todas as empresas, talvez nem da sua, neste caso, o fato é que há muitos ambientes computacionais verdadeiramente complexos, repletos de muitos componentes. "Abarrotados" de equipamentos tais como roteadores, switches, firewalls, balanceadores de carga, filtros de conteúdo, appliances de segurança, servidores, storage, além de bancos de dados, aplicações, desktops, unidades de vídeo-conferência, sistemas de comunicação multimídia diversos, controladores WiFi, pontos de acesso, etc.! Cada um destes exigindo configurações, muitas! E todos estes componentes e dispositivos necessitando se comunicar através de uma diversidade muito grande de tecnologias, incluindo protocolos, serviços de infraestrutura e de transporte, computação, storage, aplicação e afins. Na grande maioria das empresas as manobras de configuração são conduzidas por processos completamente manuais, mesmo que, em alguns ou muitos casos, de forma organizada e pautada, ou seja, seguindo processos, boas práticas, modelos funcionais, documentações, etc. No entanto, na medida em que estas redes crescem, seja em quantidades de desktops/usuários ou de servidores, ou, principalmente, a diversidade de soluções tecnológicas presentes, todo o ambiente começa a ficar realmente bem mais complicado para se manter. Toda esta complexidade operacional pode ser brutalmente atenuada com tecnologias de programabilidade de infraestruturas.
Redução massiva do tempo de provisionamento de serviços	Uma realidade para praticamente qualquer empresa, mas, certamente, um dos principais indicadores de performance do negócio dos provedores de acesso à Internet e também dos provedores de conteúdo: o tempo requerido para provisionar e ativar um serviço contratado por um cliente. Geralmente todo um fluxo de trabalho precisa ser cumprido para que a demanda possa ser devidamente compreendida, e uma cadeia de aprovação da mudança é estabelecida para que times específicos produzam os roteiros de configurações necessários, e isto tende a ser executado em horários específicos, ou seja, sempre levando um longo tempo entre a iniciação, ou solicitação da demanda, e a sua execução/conclusão. Infraestruturas ágeis, que contam com amplas capacidades de orquestração e automação, conseguem provisionar serviços muito mais rapidamente do que estes ambientes tradicionais e estáticos, podendo ser até mesmo instantaneamente, dependendo dos processos que estiverem estabelecidos pela organização.
Redução drástica dos esforços operacionais associados às tarefas de configuração e provisionamento	Não é simplesmente uma questão de "configurar alguma coisa na rede", mas sim de compreender o que precisa ser configurado, quais recursos ou funcionalidades, quais elementos, dispositivos e sistemas precisam ser modificados para a viabilidade da ativação daquele serviço, interpretar características de sintaxe e semântica, compatibilidades, integração; se há ou não um padrão ou modelo homologado para cumprir com estas tarefas de provisionamento, etc. Isto sem dúvida alguma exige mais que apenas esforço, tempo ou prazo: exige conhecimento; o domínio destas tecnologias, e a compreensão das relações e interdependências de cada caso, o que acentua ainda mais a necessidade por maior conhecimento e domínio das tecnologias utilizadas. E todo o trabalho executado nestas manobras desprende algum esforço, pouco ou muito, não me atreverei a mensurar por aqui, pois há casos e casos. Indiscutivelmente redes programáveis nos moldes sugeridos por este artigo reduzem em pelo menos 90% dos esforços operacionais que normalmente são exigidos ou desprendidos em ambientes de redes tradicionais.
Redução drástica dos riscos de negócios associados aos possíveis e frequentes downtimes	Como se não bastasse a complexidade e esforços operacionais, além do tempo/prazo, temos ainda que nos preocupar com possíveis impactos que são frequentemente decorrentes de erros provocados por falha humana durante as ações de configuração e provisionamento de serviços. É verdade que muitos destes riscos podem ser reduzidos com o auxílio de processos e práticas consistentes de gestão de mudanças (vide recomendações do COBIT/ITIL). Mas nada superará a confiabilidade de um provisionamento executado por meios de tecnologias e ferramentas de orquestração e automação, sendo isto um dos maiores atrativos da programabilidade de infraestruturas.
Maior agilidade e elasticidade para a disponibilidade e oferta de soluções mais complexas sobre a infraestrutura	O tempo que se gasta "remando contra a maré" e conduzindo extensas e monótonas configurações manuais pode muito bem ser empregado para "destravar" muitas oportunidades para a incorporação de soluções mais atraentes e de alto valor agregado para os seus clientes. A combinação de múltiplas ofertas de produtos e serviços para os clientes de um ISP frequentemente exige a integração de sofisticadas e complexas plataformas e soluções tecnológicas, o que tende a impulsionar ainda mais os casos citados anteriormente nesta tabela, ou seja, maior complexidade, maior esforço, maiores custos operacionais, maior prazo para go-to-market, maiores riscos de indisponibilidades, etc. Quando pensamos em infraestruturas altamente programáveis, conseguimos estender as capacidades de orquestração e automação para contemplar, além da rede, a parte de computação, incluindo servidores, storage e aplicações, e isto promove um salto tecnológico tremendo para os anseios de competitividade e atratividade da empresa.

Prepare-se para tornar-se um NetDevOps!

Eu explico. Há uma diferença muito grande entre o dinamismo presente nos ambientes computacionais envolvendo servidores virtuais, containers, aplicações, e a infraestrutura de redes. As redes que costumamos ver por aí geralmente possuem características operacionais muito mais estáticas do que esta área de servidores, desenvolvimento de software e aplicações, mas não em todos os casos, claro. Para fornecer um exemplo, por anos temos conseguido disponibilizar workloads inteiros em ambientes virtualizados em questão de minutos e com apenas alguns cliques, e, enquanto isso, as manobras necessárias sobre a infraestrutura da rede para acomodarmos estes workloads são geralmente feitas seguindo modelos estáticos de configuração, repletos de procedimentos manuais, caixa por caixa, CLI por CLI. Obviamente, há exceções à regra. Mas dá tranquilamente para generalizar desta forma.

Toda a vez que novas aplicações ou serviços são disponibilizadas para usuários internos e/ou externos, o que não é muito complicado de fazermos em função da versatilidade das ferramentas usadas hoje em dia, a rede precisa acompanhar o roteiro e "acomodar, compatibilizar e viabilizar" aquele serviço, ou seja, sofrer as configurações necessárias incluindo a VLAN, entroncamento da VLAN, roteamento IP, ACL, QoS e o que mais tiver que ser feito. Pois bem, novamente, a diferença é que na camada de computação as coisas são usualmente mais dinâmicas, enquanto a rede, na maioria das empresas, ainda precisa ser tratada de forma bem estática e manual.

Você provavelmente já ouviu falar de DevOps, mas, caso não saiba, o DevOps pode ser tratado como uma cultura de desenvolvimento de aplicações de TI, uma revolução na questão de processos de desenvolvimento de software, fazendo com que equipes de desenvolvimento (Dev) e equipes de operações (Ops) trabalhem juntas e em regime de estreita colaboração. Consequentemente, a adoção ágil por meios de implementação contínua e melhorias da infraestrutura de desenvolvimento promove uma oferta bem mais acelerada dos serviços de TI.

Nesta seara de DevOps é que notamos um monte de coisas relacionadas ao Agile, automação por pipelines de CI/CD (Continuous Integration / Continuous Delivery) e CI/CD/CD (Continuous Integration/Continuous Delivery/Continuous Deployment), coisas que provavelmente você já ouviu falar por aí. Pois, então, note que normalmente há um desvio muito expressivo entre estas práticas de agilidade dos times de desenvolvimento de software e as práticas adotadas pelos times de engenharia e operação de redes. Para exemplificar aqui, quaisquer alterações inadequadas que por ventura forem realizadas sobre as configurações de equipamentos de rede podem resultar em muitos problemas desnecessários, afetando negativamente aplicações e times de desenvolvimento, e tornando a situação mais complexa para estas equipes poderem lidar. E é a partir daí que os pipelines citados, Agile, DevOps, CI/CD e testes de unidade automatizados ajudam a superar esses desafios. O que até então era uma exclusividade dos times de desenvolvimento de software passou a ser portado para atender, também, os times responsáveis pela engenharia e operação de redes. E aí nasceu um novo paradigma chamado NetDevOps.

Em curtas palavras, o NetDevOps pode ser definido como uma interseção de Rede e DevOps, por meios de uma comunicação aberta e feita através da automação, e usando princípios de Infraestrutura como Código (IaC) ou "Infrastructure as Code".

Caso você ainda não faça a menor idéia do que eu esteja dissertando por aqui, quem sabe uma representação visual destes conceitos não vá esclarecer melhor?

Agile, DevOps (Fonte: Cisco Live)

Ao trazermos para os times de engenharia e operações de redes estas consagradas culturas e práticas utilizadas pelos times de desenvolvimento de software e, ao portarmos as nossas habituais tarefas de configuração de dispositivos - normalmente feitos, conforme já comentado, por CLI ou interface GUI/WebUI - para código, conseguimos viabilizar excepcionais capacidades de automação e orquestração, que são responsáveis por fornecer as almejadas agilidade, eficiência e confiabilidade para lidarmos com maestria com os serviços de TI em ambientes críticos. Consequentemente, conseguimos eliminar as barreiras entre os times de TI da organização (desenvolvimento de software, servidores, bancos de dados, redes), promover maior fluidez para a entrega de serviços de TI, e tudo isto exigindo muito menos prazo e esforço para a entrega destes serviços, e sem contar com a maior confiabilidade das operações, redução de riscos e impactos para os negócios, e tão cobiçada redução de custos.

Para preparar o seu prato de NetDevOps, misture numa panela o Agile, CI/CD, infraestrutura como código (IaC), ferramentas e soluções de automação e orquestração, mas não se esqueça de alguns ingredientes consagrados (boas práticas do COBIT/ITIL, lifecycle e outros frameworks funcionais necessários), tempere tudo com "Sazón", mexa bem, e estará pronto para servir. Você terá a oportunidade de experimentar um universo completamente novo de programabilidade de infraestruturas de redes e usufruirá de resultados indiscutivelmente melhores.

Por que não usar ambos o CLI com scripting e o protocolo SNMP para realizar as configurações da rede?

Antes que você me faça essa pergunta, permita-me antecipar os seguintes pontos:

• O scripting por CLI requer um bom esforço para comunicar particularidades de sintaxes e semânticas em ambientes heterogêneos, e a revisão e manutenção destes scripts é um trabalho igualmente estático e manual.
  • Não que scripts sejam ruins, não é isso! Mas a proposta do artigo aqui é tratamos da evolução de certos procedimentos operacionais, certo?
• O scripting por CLI peca muito por outra razão até mais importante ainda: a ausência de gerenciamento de transações.
  • Quando você for provisionar, quais scripts você precisa invocar, quais equipamentos estes scripts acionarão, como você tratará as diferentes sintaxes?
  • Apesar de você estar usando um script, ou vários, todo o trabalho tende a ser manual neste sentido, quando indicando quais equipamentos precisarão receber e quais configurações,
  • E se alguma coisa der errado, qualquer coisa, inclusive algo que pode parar a sua rede ou provocar distúrbios graves, como os seus scripts lidarão com isso?
  • Esta ausência de gerenciamento de transações dificulta muito contarmos com um controle decente de revisões de configuração, auditoria de quem fez, quando e onde, o que de fato foi modificado nestas configurações, e não possui facilidades de rollback, para simplificar aqui o meu ponto de vista.
• O scripting por CLI também carece de um gerenciamento estruturado de falhas que por ventura possam acontecer quando aplicando os comandos na CLI dos equipamentos, seja por questões de sintaxe, semântica, ou outros.
  • Isto é muito fácil de acontecer principalmente após a atualização de software dos equipamento, e o seu script muito provavelmente não saberá lidar com isto e não saberá desfazer a configuração parcial que foi implementada, o que poderá ser desastroso em alguns casos.
• O scripting por CLI apresenta um desafio relacionado as eventuais mudanças nas sintaxes do software de um determinado equipamento, o que poderá ser preocupante, agora imagine isto em um ambiente multivendor.
  • Você terá dificuldades em manter e certificar-se que seus scripts invoquem as sintaxes corretas para todos os equipamentos e em suas respectivas versões de software.
• O protocolo SNMP, se comparado ao CLI, com ou sem scripting, é ainda mais deficiente: embora o SNMP tenha sido projetado para realizar o gerenciamento com suporte à escrita (communities com permissão "Write"), ele só é eficiente mesmo para o gerenciamento de falhas e para o gerenciamento de desempenho. Para o gerenciamento de configurações, é um tanto desastroso.
• O protocolo SNMP não fornece capacidades legítimas de auto-descoberta capazes de localizar as MIBs corretas dos dispositivos gerenciados, e isto significa que você, o administrador da rede, é quem terá o trabalho manual de identificar quais MIBs são compatíveis e para quais finalidades, e fazendo isso para todo o tipo de equipamento da sua rede.
  • Se para o gerenciamento de falhas e de desempenho isto já dá um trabalho, você talvez não queira imaginar o quanto isto é custoso para o gerenciamento de configurações.
• As MIBs do protocolo SNMP frequentemente não possuem os OIDs que necessitamos para configurarmos um monte de coisas ou recursos nos equipamentos da rede.
• Esta complexidade toda e várias limitações são os principais motivos pelos quais os administradores de redes terem abandonado por completo o SNMP para fins de gerenciamento de configurações.
• O protocolo SNMP também não é diferente da CLI no que diz respeito à ausência de gerenciamento de transações. Logo, portanto, as mesmas situações discutidas no caso do CLI também são válidas para o SNMP.
• O protocolo SNMP é transportado pelo UDP, e isto significa que está suscetível a perda de mensagens na rede. Dependendo do caso, operações parciais podem ser implementadas, deixando um lastro de manobras incompletas durante um provisionamento de serviços, o que não seria nada bom para os nossos propósitos de consistência de configurações e disponibilidade da rede.

Sobre o meme a seguir: não vista a carapuça!

"Deuzulivre"!

Revisão dos principais conceitos e componentes de uma infraestrutura de redes Metro e IP

Para falarmos melhor sobre programabilidade, automação e orquestração, especialmente se você, leitor, estiver começando nesta área de redes, talvez seja prudente regredirmos um tanto e esmiuçarmos como as coisas acontecem de fato no modelo tradicional de operação de redes. Pensando assim, que tal fazermos uma boa revisão sobre os principais componentes e conceitos presentes em uma infraestrutura de redes? Ao término do artigo, talvez esta seção tenha sido bastante útil para você entender melhor as complicações no que diz respeito à manutenção das infraestruturas de redes, e como as tecnologias e ferramentas de programabilidade poderão drasticamente atenuar os esforços, prazos, complexidades e custos operacionais.

Dispositivos de rede

Em uma rede de ambiente ISP (aka "service provider") é comum encontrarmos os seguintes tipos de equipamentos ou elementos ativos, que são referências aos dispositivos de rede:

• Roteadores: devidamente categorizados por suas funções e missões, em especial em alinhamento com uma infraestrutura de redes hierárquica, modular e estruturada, ou seja roteadores de Acesso, Pré-Agregação, Agregação, Core, Borda de Serviços e Borda de Internet, e também os roteadores de clientes, sejam estes de propriedade do ISP (comodato) ou mantidos e gerenciados pelo próprio cliente. Aqui entram os conhecidos termos CE ou CPE (Customer Premises Equipment), PE (Provider Edge), P (Provider), e cada um destes, além de seu respectivo posicionamento na hierarquia topológica física e lógica da rede, desempenhando funções tais como LSR (Label Switch Router), LER (Label Edge Router), BNG (Broadband Network Gateway), dentre outros casos.
• Switches: praticamente a mesma coisa com relação aos roteadores no que diz respeito ao seus posicionamentos em uma rede, hierarquia e afins. Podendo ser elementos ativos desempenhando funções de encaminhamento de dados puramente de Camada 2 (L2), neste caso o processamento dos quadros (frames), ou multicamadas (L3), neste caso o processamento de pacotes, em ambientes Ethernet ou Ethernet + IP nativos, ou ainda em ambientes MPLS.
• GPON: sumarizando aqui os dispositivos desta infraestrutura, incluindo OLT (Optical Line Terminal), ONU (Optical Network Unit), ONT (Optical Network Terminal), e, por que não, toda a parte passiva (leia-se: não ativa) da infraestrutura, denominada Optical Distribution Network (ODN), e que abrange as fibras ópticas e passivos ópticos, como splitters, conectores, cordões, extensões, caixas de emenda e terminação.

Dispositivos de rede Metro Ethernet, IP, MPLS: roteadores e switches

Protocolos e serviços de infraestruturas de redes

Uma coisa são os dispositivos de redes mencionados anteriormente, outra coisa são as tecnologias (embarcadas nestes dispositivos) que viabilizam o funcionamento de uma rede, em especial no que diz respeito à comunicação e convergência necessária entre os elementos ativos para o transporte efetivo do tráfego da rede e dos serviços contratados por seus usuários. Nem de longe atreverei-me a listar tudo, pois isto seria completamente inviável! Elencarei apenas alguns exemplos, pois uma listagem completa mencionando todas as tecnologias produziria um artigo quilométrico!

O arranjo destas tecnologias, devidamente organizadas em suas respectivas categorias funcionais, é o que costumo chamar de "Salada de Tecnologias"!

• Protocolos e serviços de camada 2 (L2): como menção ao modelo de referência OSI (RM-OSI) ou ao modelo de referência TCP/IP, são tecnologias primariamente envolvidas com a construção e manutenção de uma infraestrutura redundante (com foco na maior disponibilidade) isenta de bridging loops, e com capacidades de recuperação de falhas envolvendo enlaces de transmissão ou dos próprios elementos de rede. Exemplos de tecnologias assim: Spanning Tree Protocol (e suas variações, 802.1d (STP), 802.1w (RSTP), 802.1s (MSTP), 802.1aq (Shortest Path Bridging (SPB), e revisões incorporadas ao 802.1Q-2014, Resilient Ethernet Protocol (REP, proprietário), Ethernet Automatic Protection Switching (EAPS, proprietário), G.8032 (Ethernet Ring Protection (ERP) protocol), coexistência de Inter-Chassis Communication Protocol (ICCP) e STP, etc. E, claro, não poderia deixar de mencionar aqui o mais óbvio, que são tecnologias mais básicas e elementares tais como o próprio endereçamento físico (Media Access Control (MAC)) dos dispositivos, Virtual LAN (VLAN), entroncamento 802.1q e 802.1ad (Q-in-Q), operações flexíveis com tags de VLAN (Flexible VLAN Tags, Ethernet Flow Point (EFP)), circuitos Ethernet Virtuais (Ethernet Virtual Circuit (EVC)), etc. E isto focando apenas no óbvio, pois há uma gama muito grande de tecnologias e serviços que implementam funções ou que atuam na camada 2. E, para concluir, L2VPN (VPLS, VPWS, EVPN) também são exemplos de tecnologias para o transporte de tráfego/serviços L2 em uma rede MPLS (VPLS/VPWS/EVPN) ou VxLAN (EVPN). Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), Layer 2 Protocol Tunneling (L2PT), Point-to-Point Tunneling Protocol (PPTP) são outros exemplos clássicos e que empregam conceitos de túneis.
• Protocolos e serviços de camada 3 (L3): também em alinhamento ao RM-OSI, são tecnologias que tem como propósito a construção e manutenção de uma rede IP "roteada", convergida e isenta de routing loops. Enquadram-se aqui o endereçamento IPv4 e IPv6, protocolos de roteamento dinâmicos (ex: OSPF, IS-IS, EIGRP, BGP, RIPv2 para IPv4, e RIPng, OSPFv3, IS-IS for IPv6, EIGRP for IPv6, BGP para o IPv6), além de rotas conectadas, rotas estáticas, serviços de roteamento por políticas (PBR, ABF ou nome similar usado pelo seu fabricante de equipamento). Enquadram-se também, à título de serviços L3, mas com algumas destas tecnologias implementando funções também em outras camadas, os seguintes: Network Address Translation (NAT), Carrier Grade NAT (CGN), Broadband Network Gateway (BNG, como concentrador PPPoE e/ou IPoE).
• Protocolos e serviços orientados à confiabilidade, resiliência e disponibilidade: compreenda estes como serviços periféricos e pensados para melhorarmos a confiabilidade geral da infraestrutura, seja em cenários L2 ou L3, ou ainda ambos. Exemplos de tecnologias que enquadram-se aqui temos o Unidirectional Link Detection (UDLD), Bidirectional Forwarding Detection (BFD), In-Service Software Upgrade (ISSU), Online Insertion and Removal (OIR), Stateful Switchover (SSO), Nonstop Forwarding (NSF) ou Graceful Restart (GR), Non Stop Routing (NSR), MPLS Traffic Engineering Fast Reroute (FRR), Topology Independent LFA (TI-LFA) e RLFA, Segment Routing TI-LFA (SRTILFA), Link Aggregation Control Protocol (LACP), enfim, são exemplos clássicos. Outros exemplos aqui incluem os protocolos de resiliência de primeiro salto ou de default gateway, conhecidos por FHRP (First Hop Redundancy Protocol), tais como o HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol) e GLBP (Gateway Load Balancing Protocol). Isto para não mencionar os mecanismos periféricos presentes em outros protocolos já apresentados, como, por exemplo, o OSPF LSA e SPF Throttling, BGP Prefix Independent Convergence (PIC), etc.
• Protocolos e serviços de suporte à infraestrutura: enquadram-se aqui protocolos e serviços incluindo o PPPoE (Point-to-Point Protocol over Ethernet), IPoE (Internet Protocol over Ethernet), DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name System), AAA (Authentication, Authorization, Accounting), RADIUS (Remote Authentication Dial In User Service), TACACS+ (Terminal Access Controller Access-Control System), Diameter, NTP (Network Time Protocol), PTP (Precision Time Protocol), SyncE (Synchronous Ethernet), e tantos outros. As tecnologias com foco no Quality of Service (QoS) também podem ser descritas aqui.
• Protocolos e serviços de gerenciamento: figuram aqui, dentre tantos, o Simple Network Management Protocol (SNMP), Remote Network MONitoring (RMON) MIB, Netflow, Internet Protocol Flow Information Export (IPFIX), Telnet, Secure Shell (SSH), SSH File Transfer Protocol (SFTP), Operations, Administration and Maintenance (OAM) incluindo Ethernet OAM Link Fault Management (EOAM LFM), 802.1ag Connectivity Fault Management (CFM), Ethernet Local Management Interface (E-LMI), Ethernet Performance Management, MPLS OAM; Network Configuration e modelos Yang (NETCONF/Yang), interface RESTful para a modelagem Yang com RESTCONF, Technical Report 069 (TR-69) e substitutos, dentre tantos outros protocolos, serviços e procedimentos.
• Protocolos e serviços de segurança da infraestrutura: há tantos casos para citar aqui, tentarei ser bem prático. Port Security, 802.1X IBNS, MACsec, Network Admission Control (NAC), Private VLAN, Dynamic ARP Inspection (DAI), DHCP Snooping, IP Source Guard (IPSG), Root Guard, BPDU Guard, BPDU Filtering, mecanismos de autenticação dos protocolos de roteamento, mecanismos de autenticação de protocolos MPLS (LDP e RSVP-TE), filtros e políticas de roteamento, BGP Flowspec, Remotely Triggered Black Hole (RTBH), stateful packet filtering, BGP Resource Public Key Infrastructure (RPKI), Control Plane Policing (CoPP/dCoPP), Broadcast, Unicast and Multicast (BUM) Storm Control, limitação de prefixos mantidos em tabelas de roteamento, Unicast Reverse Path Forwarding (uRPF), e muitos outros. E isto com relação às tecnologias apenas, sem considerar os appliances (dispositivos) de segurança que embarcam estas tecnologias e serviços, tais como firewalls, UTMs, etc.

Que "salada" de tecnologias! É tanta coisa que temos que nos preocupar em fazer funcionar corretamente e conforme as boas práticas!

Sistemas e serviços de suporte à infraestrutura

A lista de situações aqui é mais simples, mas não menos complexa:

• Sistemas de Suporte ao Negócio (BSS)
• Sistemas de Suporte à Operação (OSS)
• Serviços de Diretório (ex: LDAP, Active Directory)
• Infraestrutura Public Key Infrastructure (PKI)
• Sistemas específicos de serviços de segurança (RADIUS, TACACS+, AAA, NAC e afins)
• Sistema de IP Address Management (IPAM)
• Sistemas específicos para fins de gerenciamento de elementos e de infraestrutura (EMS e NMS), com baixa ou parcial aderência aos padrões OSS.
• Etc.

Exemplo de integrações de sistemas OSS e BSS, demonstrando a solução IBM Catalog Driven Order Management Solution. Note o "SID", um dos frameworks do TM Forum Frameworx!

OBS: no segmento de ISPs regionais de pequeno e médio portes é onde compreendemos, também, uma diferença bastante acentuada entre os padrões de sistemas empregados por estes quando comparados aos sistemas de gestão operacional e de negócios dos operadores de redes "grandes". Nos ISPs regionais, é muito mais comum o uso de sistemas para missões bem específicas e que operam de forma completamente independente e com nenhuma ou mínima troca ou compartilhamento de dados entre si, mesmo que funcionais para a realidade desta empresas. No entanto, a ausência das devidas e desejadas integrações entre estes sistemas (vide Frameworx (eTOM BPF, SID, TAM, TNA)) tende a dificultar a adoção de capacidades de orquestração mais completas para o provisionamento de serviços fim a fim.

Áreas sistêmicas das arquiteturas de roteadores e switches

Tantos destes protocolos e serviços de rede precisam ser selecionados e configurados por você, um por um, e conforme diretivas do seu projeto técnico (ex: configurações homologadas, boas práticas, validação de sintaxe e semântica, etc.) para que possam convergir e fornecer o transporte e a efetiva viabilidade dos serviços e produtos contratados pelos clientes. Para fazer toda a coisa acontecer, há um determinado arranjo de dependências entre as tecnologias necessárias onde, em muitos casos, para que uma determinada tecnologia que você configurou possa funcionar, são necessários o suporte e o funcionamento de outras tecnologias e serviços, as quais, por sua vez, precisarão ser também pensadas, projetadas, e configuradas por... você! Para exemplificar aqui, para que o BGP de seu AS possa operar é necessário o roteamento recursivo para o transporte das sessões IBGP e a devida resolução do atributo NEXT_HOP das rotas mantidas pelo BGP, e isto significa que você precisará adotar um protocolo de roteamento interior (IGP), provavelmente o OSPF aqui, o qual, por sua vez, depende de endereçamento IP, definição das tecnologias de enlace (VLANs, entroncamentos, etc.) e das tecnologias de transmissão (L1). Ou seja, uma coisa depende da outra.

Em particular, roteadores e switches em uma rede mantém áreas sistêmicas e funcionais para os propósitos de conectividade e de serviços:

• Plano de Controle: área sistêmica responsável por hospedar protocolos que forneçam entendimento e convergência para fins de encaminhamento de tráfego L2 (ex: STP, REP, EAPS...) e L3 (ex: OSPF, IS-IS, BGP, etc.), e até mesmo "L2.5" (ex: MPLS). Não somente os protocolos são mantidos nesta área, mas também as suas respectivas estruturas de dados, tais como o Link-State Database (LSDB) do OSPF, o Label Information Base (LIB) do MPLS LDP, a BGP Table do BGP, e a própria tabela de roteamento IP (Routing Information Base ou RIB) do roteador, protocolos adicionais tipo o PCEP, etc.
• Plano de Dados: área sistêmica responsável por hospedar as estruturas de dados especificamente orientadas ao processamento e efetivo encaminhamento de pacotes, tais como a Forwarding Information Base (FIB) ou Forwarding Table, Label Forwarding Information Table (LFIB), Adjacency Table (ADJ) ou similar, isto no caso dos roteadores, e Content Addressable Memory (CAM) ou MAC Table, no caso dos switches, além de outras estruturas de dados que possam servir para funções adicionais da cadeia de processamento de pacotes, geralmente organizadas em TCAMs (Ternary Content Addressable Memory), para o acionamento de manipulações de cabeçalhos, QoS, ACL, etc.
• Plano de Gerenciamento: responsável por hospedar e manter os serviços de gerenciamento do dispositivo, tais como Telnet, SSH, SNMP, NETCONF, HTTP server, Syslog, NTP, etc.
• Plano de Serviços: responsável por manter processos relacionados ao RADIUS, TACACS+, PPPoE, IPoE, IPsec, NAT, QoS, Stateful Firewall, AVC, etc.

É importante salientar que o modelo de computação em rede tradicional é completamente distribuído, ou seja, que estas áreas sistêmicas supracitadas são independentes e localmente significantes para cada dispositivo. Isto significa que o estado de informação de cada processo de software referente a um destes protocolos e serviços é mantido por cada equipamento, independentemente, podendo haver, em algumas situações, alguma integração entre equipamentos distintos para um determinado componente.

Projeto técnico compatível com o plano de negócios

Você deve ter notado a quantidade brutal de componentes e recursos tecnológicos listados até agora! No que tange aos tipos de equipamentos que você precisa utilizar, como deverão ser feitas as conexões físicas e lógicas, quais protocolos e serviços deverão ser projetados e empregados (configurados, ativados...), e tudo mais, enfim, isto dependerá muito de como o seu projeto técnico for construído, e este projeto precisa "casar" com o seu plano de negócios. A dissertação disto está fora do escopo deste artigo e por razões bem óbvias, pois seria um baita off-topic. Isto será tema para futuros artigos aqui na Wiki do BPF. Todavia, caso tenha curiosidade de saber um pouco mais sobre o tema, talvez estes dois vídeos possam ser úteis neste sentido, pois, neles, tento apresentar de forma bem objetiva estes conceitos:

• [BPF] Conceitos e análises de investimentos tecnológicos para o ISP
• [BPF] Caracterização das funcionalidades e recursos para projetos de redes no ISP

É importante salientar que há muita redundância entre as tecnologias citadas previamente, particularmente no que concerne às aplicabilidades, cenários e casos de uso. Por exemplo, você não irá realmente rodar o protocolo de roteamento EIGRP no backbone do seu provedor, pois será óbvia e natural a escolha pelo protocolo de roteamento OSPF (as razões quanto a isto podem ser estudadas no artigo Boas Práticas para a Implantação do OSPF em Ambientes de ISP), embora ambos sejam protocolos de roteamento, e muito bons por sinal. Assim como, caso a sua rede de Acesso seja L2, será muito provável que você vá optar por tecnologias de resiliência Ethernet mais sofisticadas, preferindo o G.8032 ou EAPS, ao invés do protocolo Spanning Tree, mesmo que ambos sejam protocolos de resiliência destinados ao mesmo propósito (vide artigo Proteção e Resiliência em Redes L2 de Provedores para saber o por que). Assim como você optará pelo IPoE ou PPPoE, ou ainda rodando os dois serviços simultaneamente por um tempo em caráter de transição tecnológica, mas, no final das contas, é provável que você vá manter apenas o IPoE, embora ambos PPPoE e IPoE tenham como proposta a mesma missão (apenas a cumprem de formas distintas). Quanto aos protocolos FHRP, é bem provável que você vá optar pelo VRRP (até mesmo pela provável natureza multivendor da sua rede), e não pelo HSRP, por se tratar de uma tecnologia proprietária. A maioria absoluta das instalações de rede de Internet residencial emprega o protocolo/serviço RADIUS como um dos componentes de integração requeridos, mas a tendência é que, com o passar do tempo, vejamos cada vez mais instalações operando com o protocolo Diameter. Enfim, acho que você conseguiu me entender aqui.

Para tudo isto que escrevi acima, o que escolher, o que adotar, "o que comer, o que vestir", enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do ciclo de vida do projeto (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.

Qual é a relação entre a "seção de revisão de componentes tecnológicos" deste artigo e os objetivos propostos pelo mesmo?

Talvez você esteja se perguntando: "Tá, Leonardo, mas.... o que tem isso a ver?".

Em primeiro momento, informo que nem todos os leitores de nossa Wiki são profissionais altamente experientes quanto você, nobre leitor! Há indivíduos que nos visitam aqui que já reportaram dificuldades em absorver conhecimentos mais avançados ou complexos, ou que estejam em processo de aperfeiçoamento de carreira. Para este perfil de nosso público, tenho certeza que as informações apresentadas na seção anterior são tidas como muito úteis e, portanto, achei prudente lembra-los da magnitude em termos de quantidade e diversidade de componentes, recursos, conceitos, procedimentos e especificações tipicamente encontrados nas redes de service providers, e tudo isso pode ser tratado como componentes que são ou que devam ser configurados em uma rede, seja pelo modelo tradicional (CLI, WebUI) ou por meios da automação por ferramentas de programabilidade.

A pergunta que faço agora: como você projeta, implementa (as tecnologias, protocolos, serviços, etc.), opera (a manutenção geral), suporta (diagnóstico, troubleshooting), e provisiona clientes e seus respectivos produtos contratados?

Sabemos que na grande maioria dos casos a coisa não funciona por pura e simples "mágica", e quase tudo depende de ações e intervenções humanas. Aposto que hoje, no seu ambiente, mais de 95% de tudo o que a sua rede precisa fazer é fruto de alguma configuração realizada inteiramente pelas mãos de um operador da sua rede, um profissional de operações (NOC), provisionamento ou da engenharia! O camarada foi lá e configurou elemento por elemento, "na mão", pela linha de comando (CLI) ou por alguma interface gráfica tipo Device Manager (gerenciador de dispositivo, específico para aquele e cada equipamento), e todo o ambiente é mantido assim, desta forma.

Cada vez que você tiver que adicionar um novo elemento/equipamento na sua rede, como você faz? Cada vez que você precisa suportar novos prefixos IP, como você lida com as modificações nas suas políticas de roteamento? Cada vez que você precisa ativar um cliente corporativo para um produto do seu ISP, como você faz para provisionar este serviço? Ativar uma L2VPN ponto a ponto ou multiponto, ou uma extensão entre data centers (Data Center Interconnect), ou uma L3VPN (simple, complex, managed services, e Internet), ou um serviço SD-WAN gerenciado e em combinação com proteção de DNS e outros "mimos"? E com relação ao assinante residencial, como você faz? Tenho quase certeza que hoje, no seu caso, a maior parte destes processos, pra não citar "todos", é manual ou, no melhor caso, requer uma ação humana realizada sobre algum tipo de ferramenta que atenua estes esforços, mas que, mesmo assim, precisa ser realizada sobre diversos equipamentos da infraestrutura.

Para efeitos comparativos aqui: nos melhores casos e envolvendo grandes empresas do setor de tecnologia, quando você contrata uma plataforma como serviço (PaaS) ou uma infraestrutura como serviço (IaaS) de uma destas consagradas empresas globais, você realmente acredita que alguém recebe um email (referente a sua solicitação) e o encaminha internamente para as áreas técnicas para que estes mobilizem qualquer atividade de ativação manualmente, tais como a instalação de equipamentos, instalação e atualização de software, configuração de dispositivos e serviços? Claro que não! Nestes perfis de organizações, tudo isso é orquestrado e automatizado a partir do momento em que você passa o seu cartão de crédito durante o procedimento de subscrição ou de contratação do serviço!

E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.

A relação entre este artigo e os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP

Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades de você conhecer mais sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.

Talvez você queira aprofundar-se um pouco mais sobre esta área com a leitura do artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP, caso não tenha feito isso ainda.

Há muitos anos o ITU-T introduziu o termo Telecommunications Management Network (TMN) para a descrição de uma rede dedicada com interfaces orientadas ao gerenciamento de redes de telecomunicações, e buscando definir os pontos de interconexão entre as duas redes, além de especificar as diversas funcionalidades de gerenciamento. A proposta deste framework foi ilustrar as áreas funcionais distintas e como estas deveriam interoperar. E isto foi originalmente especificado pelo ITU-T M.3400 e X.700, em especial a classificação das funcionalidades de gerenciamento, mas sem a descrição detalhada dos componentes destas funções, algo que foi tratado mais apropriadamente por outros padrões periféricos mais específicos e que nasceram mais ou menos no mesmo período.

Por sua vez, o FCAPS é um modelo de gerenciamento de redes produzido pela ISO, e não pelo ITU-T, descrito inicialmente como Working Drafts (N1719) da norma ISO 10040, e com o intuito de definir cinco padrões de protocolos distintos, sendo cada um para uma área funcional específica. Posteriormente, dadas as similaridades entre muitas funções pretendidas por estes protocolos, os cinco foram consolidados em um só (Common Management Information Protocol ou CMIP). No entanto, a coisa não parou por aí, e muitas evoluções ocorreram, até que o próprio ITU-T, nos anos 90, passasse a integrar o FCAPS como parte de seu framework TMN. Esta integração entre TMN e FCAPS está mostrada na ilustração logo abaixo.

Posteriormente, o FCAPS evoluiu para o que chamamos de FAB (Fulfillment, Assurance, Billing), conforme definido pelo framework Business Process Framework (BPF), que foi bem esclarecido no mapa eTOM apresentado no artigo "Frameworks de Indústria para a Reestruturação e Profissionalização do ISP", publicado em nossa Wiki. Ou seja, resumindo aqui, tanto a ISO quanto o ITU-T tinham propostas e modelos bastante interessantes para compreendermos as questões associadas ao gerenciamento de infraestruturas, e houve este esforço ou intenção de ambas as partes para que o melhor dos dois mundos pudessem se encontrar, promover uma certa unificação e direcionamento para os melhores resultados para a indústria. No que concerne ao FCAPS em si, para todos os efeitos mais práticos, as classificações das funções de gerenciamento para cada uma das áreas de negócios e funcionais de um ISP foram inicialmente especificadas pelo FCAPS da ISO, posteriormente integradas pelo TMN da ITU-T, e aprimoradas e portadas para o eTOM BPF. Atualmente, o framework BPF é um dos frameworks do Frameworx, criado e mantido pelo TM Forum.

Visualização da integração entre TMN e FCAPS, e a ênfase no conceito de Configuration, que será o foco do artigo a partir deste ponto

A relação entre eTOM BPF ou FAB ou FCAPS, enfim, e este artigo, é buscar capacitá-los com informações fundamentais sobre o Gerenciamento de Configurações de uma rede de ISP.

Por que o FCAPS é útil, inclusive para o nosso artigo aqui? Assim como temos o hábito de usarmos frequentemente o modelo de referência OSI (RM-OSI), ou seja, aquelas 7 camadas (Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação) para ensinarmos os fundamentos de redes para profissionais da área ou indivíduos que estejam começando nela, usamos também o FCAPS para este mesmo propósito, que é o de ensinar e capacitar, só que, neste caso, sobre os conceitos e fundamentos de gerenciamento de infraestruturas!

O FCAPS, mesmo que o "original" esteja um pouco defasado (pois hoje está incorporado, mais amplo e melhor especificado no eTOM BPF), é uma excelente ferramenta de aprendizado! Por este motivo decidi escrever um pouco a respeito dele nesta seção do artigo. Quer ensinar redes para alguém? O modelo de referência OSI é ótimo para isso! Quer ensinar fundamentos de gerenciamento de redes para alguém? O FCAPS é certamente um dos recursos mais interessantes e úteis para concebermos estes ensinamentos!

Para concluir, a sequência deste artigo estará centrada no Gerenciamento de Configurações (o "C" do modelo FCAPS). Além do artigo, você talvez tenha interesse em consultar a recomendação ITU-T G.7710/Y.1701 (08/2019) - Common Equipment Management Function Requirements para ampliar seus horizontes.

Como o gerenciamento de configurações é realizado pela maioria dos ISPs regionais de pequeno e médio portes

É de amplo conhecimento que, em parâmetros tecnológicos, os provedores de acesso à Internet de pequeno e médio portes evoluíram muito de uns anos para cá. Em termos de sofisticação de equipamentos e tecnologias, estes ISPs tem "encostado" nos grandes operadores de rede, geralmente ficando as principais diferenças entre ambos os perfis nas questões associadas ao porte dos equipamentos utilizados (capacidade, densidade, quantidade, volume), tamanhos das áreas de concessão, tamanho da base de assinantes, sendo estas diferenças até bastante expressivas, mas não no tipo ou na qualidade da tecnologias empregadas. E, nas questões administrativas, claro, a quantidade de colaboradores, os orçamentos, áreas internas do negócio, e diversos outros casos que não convém elencar no momento.

Mas há uma diferença muito significativa, importantíssima, e que tem a ver com o que este artigo propõe-se a discutir: o gerenciamento da infraestrutura como um todo, incluindo frameworks, processos, procedimentos, metodologias, sistemas, integrações entre sistemas e infraestruturas, o tanto de programabilidade, automação e orquestração, os respectivos padrões de ferramentas empregadas... e isto são algumas das principais comparações operacionais e procedurais que faço quando analisando um operador de redes de grande porte e um ISP regional de pequeno ou médio porte, quanto a estes quesitos.

No que diz respeito ao gerenciamento de configurações, mais especificamente quando um ISP regional de menor porte precisa ativar ou provisionar um novo serviço, geralmente são necessários os seguintes procedimentos (estou generalizando aqui):

1. Se a manobra tiver que incluir a instalação física de um novo equipamento em um site/Pop do ISP, conduzir e documentar um Projeto Provisório de Instalação (PPI) ou Projeto Definitivo de Instalação (PDI), juntamente com os demais procedimentos homologados pela Engenharia da empresa, tais como Plano de Instalação e Ativação, etc.
   1. Sejamos realistas: a instalação física de um equipamento não pode ser automatizada! (exceto, talvez, por robôs, o que não será o caso tão cedo)
2. Configuração de equipamento para a sua efetiva integração com a rede, o que, por sua vez, normalmente, ou quase sempre, exige a condução de outros procedimentos aprovados pela Engenharia da empresa, em particular a atualização do software para a versão homologada e a condução de um extenso roteiro/script contendo os parâmetros de configuração, apoiados por artefatos tais como um Plano de Instalação e Configuração Lógica.
   1. Aqui temos a primeira oportunidade de automação e orquestração, via métodos de provisionamento tais como o de zero toque ou "Zero Touch Provisioning" ou tecnologia similar, os quais propõem-se a simplesmente exigir do profissional lá no site/Pop apenas as manobras de energização e cabeamento/conectorização das portas do equipamento, que a rede automaticamente se encarregará de todo o resto e fornecerá a configuração definitiva do equipamento.
3. Em seguida, o provisionamento do serviço do cliente! É aqui que você terá que "visitar" a CLI (linha de comando) ou WebUI de vários equipamentos para realização das configurações necessárias para a viabilidade fim-a-fim do serviço contratado pelo assinante, e geralmente apoiado por um formato pré-estabelecido para aquele tipo de produto/configuração. Ou seja, definir as VLANs, entroncamentos de VLAN, os mecanismos de controle de admissão à rede, recursos de segurança, endereços IP, roteamento, QoS, policies, etc., e fazendo isto para as tecnologias requeridas, caso a caso, sobre todo e qualquer dispositivo exigido para a viabilidade quanto à "ativação" (fim a fim) daquele produto que aquele assinante contratou.
   1. Talvez uma das áreas operacionais mais frágeis da organização seja exatamente esta baixa aderência quanto às boas práticas regidas pelo "C" do FCAPS, ou seja, da disciplina de gerenciamento de configurações! Muito frequentemente, para não dizer "quase sempre", é um processo estritamente manual e associado a custos mais elevados, maiores esforços e complexidades operacionais, maiores riscos de incidentes e downtime (decorrentes de falha humana durante o processo de configuração de elementos de rede), dentre muitas situações eventual e obviamente indesejadas.
   2. E é aqui que enxergo mais uma excelente oportunidade para os ISPs regionais poderem se modernizar!
4. O serviço que foi ativado (produto + assinante) é testado e validado, e posicionado para produção em caráter definitivo. A partir deste ponto, a Operação da rede (ex: NOC) deverá ficar responsável por assegurar que as métricas do SLA contratado sejam respeitadas, tais como capacidade, consumo de banda dentro do perfil, latência, jitter, perda de pacotes, disponibilidade/uptime, etc.
   1. Outra seara repleta de procedimentos manuais e ferramentas dissimilares que não "conversam" entre si, não compartilham dados, e fica bem mais difícil encontrar uma utilidade real para os sistemas de gerenciamento de elementos (EMS) e de rede (NMS) da organização, como partes integrantes ou isoladamente dos sistemas de suporte a operação (OSS).
   2. Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!

O roteiro tradicional de implantação e provisionamento de serviços de um ISP

Introdução aos conceitos da disciplina de configurações

Realmente pretendo pular a parte referente aos conceitos de IT Service Management (ITSM), e um tanto do que a versão 3 do ITIL (Information Technology Infrastructure Library) aborda neste sentido. Voltaremos aqui ao que importa, e o FCAPS é mais apropriado para dissertarmos a respeito disto.

Na questão de "Configurações", o FCAPS é centrado em um bocado de coisas, mas dá para sumarizar suas principais funções e objetivos da seguinte forma:

1. Inicialização do Serviço
2. Provisionamento do Serviço
3. Auto-descoberta (de elementos e suas capacidades e propriedades, topologias, etc.)
4. Backup e restauração (obviamente incluindo muitas capacidades e facilidades aqui, tais como diff-check, dry-run, etc.)
5. Desligamento de recursos (quando não são mais necessários, ou por mudança de perfil de assinante (ex: bloqueado, cancelado))
6. Gestão de mudanças (os processos e ferramentas para a "GMUD").
7. Pré-provisionamento
8. Gerenciamento de inventário (não somente a parte do hardware inteiro, mais também os módulos, acessórios, software, licenças, etc.)
9. Cópia de configurações
10. Configuração remota
11. Atualização automática de software (incluindo funcionalidades que maximizem a disponibilidade dos dispositivos, compliance de software, etc.)
12. Iniciação, rastreamento e execução de job

Ou seja, tudo para viabilizar os controles necessários para implementar a configuração inicial dos elementos da rede e seus respectivos componentes, sincronismo e monitoramento dos parâmetros de configuração empregados; distribuição de tarefas de configuração com o auxílio de templates, configuração de propriedades avançadas sobre os elementos da rede (proteção e resiliência, VLANs, entroncamentos, endereçamento IP, roteamento, QoS, etc.), manutenção e auditoria de configurações, e tantos outros.

A arquitetura Equipment Management Function (EMF) proposta pelo ITU-T com relação ao FCAPS fornece as recomendações sobre como os sistemas de gerenciamento de elementos (EMS) gerenciam as funções de elementos de redes (NEF), ao interagir com funções atômicas da camada de transporte e sincronização (AF), e fazendo isto através da troca de informações de gerenciamento (MI) sobre os pontos de gerenciamento (MP); esse "tequiniquês" é abordado no ITU-T G.806, ITU-T X.701 e ITU-T X.720, enfim, suprimamos isso aqui. Talvez eu deva ao menos fornecer uma noção visual destes conceitos:

Ilustração de conceitos FCAPS tais como NEF, EMF, MAF, MCF, MI e MP (Fonte: ITU-T)

Em termos mais práticos, isto significa que você precisa considerar para a sua infraestrutura as devidas funções de gerenciamento para cada uma áreas recomendadas pelo FCAPS (ou eTOM BPF, neste caso), observando como os sistemas de negócios da empresa estão mapeados para os sistemas mais técnicos e operacionais, e como estes sistemas mais técnicos-operacionais interagem com a infraestrutura para aditivar as tecnologias, as quais, por sua vez, darão apoio direto aos resultados tanto técnicos quando os de negócios. Aquela tão desejada aderência...

Você basicamente possui dois caminhos possíveis, dependendo do perfil do seu ambiente em termos de "vendor" (fabricante de escolha dos seus equipamentos):

• Rede homogênea: se a sua rede contiver dispositivos e soluções de apenas um fabricante, você muito provavelmente poderá utilizar as ferramentas/sistemas ou soluções daquele fabricante para as necessidades de gerenciamento de configurações. Aliás, não somente configurações, mas também a parte de desempenho, falhas/incidente, segurança, etc. Ou seja, as plataformas de gerenciamento desenvolvidas pelo fabricante para aquela classe de produtos que você tem na sua rede. Desnecessário comentar que são soluções proprietárias, certo? Não que isto seja algo ruim, mas é bom deixar isto bem claro.
• Rede heterogênea: se a sua rede contiver um mix de soluções e de vários fabricantes, você terá bem mais dificuldades. Na maioria dos casos, você terá que rodar múltiplos sistemas de gerenciamento para acomodar cada uma das áreas funcionais previstas pelo FCAPS através deste cenário multivendor. É muito improvável que a plataforma de gerenciamento de um determinado fabricante vá suportar bem os equipamentos de outros fabricantes, principalmente quando o assunto for gerenciamento de configurações. E, caso haja esse suporte, ele quase sempre ou fatalmente será limitado, ou possuirá algumas chatas restrições.

Em muitos casos, nos vemos forçados a usar uma solução para gerenciar os elementos da marca "A", outra solução de gerenciamento para os elementos da marca "B", mais uma solução para gerenciar os elementos da marca "C", e uma ou mais soluções open source (ou não) para monitorar componentes em comum das marcas "A", "B" e "C", como ocorre frequentemente para a parte de gerenciamento de desempenho e gerenciamento de falhas/incidentes, onde soluções tais como PRTG, Zabbix, Libre NMS, Observium, Nagios, Cacti, etc., são bastante populares. Eu particularmente vejo muita fragilidade e inconvenientes aqui, pois raramente estes sistemas integram bem com sistemas de outros fabricantes, exceto, talvez, e dependendo do caso, via extensas e complexas integrações por Common Object Request Broker Architecture (CORBA), do Object Management Group (OMG), algo que já vi acontecer um bocado em ambientes de telecom. Um porre! Não é a toa que o TM Forum tem buscado impulsionar bastante o Frameworx como forma de padronização, interoperabilidade e integração entre os sistemas BSS e OSS.

Que tal darmos uma praticidade para estes argumentos?

• O Winbox da Mikrotik não vai gerenciar configurações de um equipamento Cisco, Juniper ou Huawei (pelo menos não que eu saiba! KKKKKKK).
• O Cisco Prime LAN Management Solution não vai gerenciar configurações de elementos de rede de classe corporativa não-Cisco.
• O Cisco Application Policy Infrastructure Controller (APIC) possui alguma integração com soluções específicas (Check Point, Palo Alto Networks, Fortinet Inc, Radware – DefensePro, A10 Networks, Avi Networks, Citrix Systems, F5 Networks, Radware – Alteon VA e VX), mas não para todos os recursos e funções que talvez você necessite para o seu projeto.
• O Cisco Adaptive Security Device Manager (ASDM) só serve para gerenciar dispositivos de segurança ASA da Cisco.
• O Cisco Network Services Orchestrator (NSO) não é orientado para funções de gerenciamento de falhas ou desempenho, e sim para o gerenciamento de configurações, e talvez seja uma das poucas soluções comerciais que conseguem orquestrar o provisionamento de serviços fim a fim sobre qualquer equipamento e de qualquer vendor (a não ser que o seu equipamento não seja realmente lá grandes coisas...), e compete com vantagens contra o Ansible Tower.
• O Junos Space Network Management Platform da Juniper consegue integrar alguns dispositivos de terceiros como elementos gerenciados, mas, "guess what?", há restrições de funcionalidades.
• O HPE Intelligent Management Center Enterprise da HP permite adicionar alguns elementos externos/de terceiros, tais como o switch Cisco Nexus, e integrações com Aruba Airwave (faz sentido, pois houve a aquisição aqui), ClearPass e HPE OneView. O que exatamente é suportado ou quais são as restrições aqui, eu desconheço no momento.
• O Zabbix pode ser ótimo para necessidades de gerenciamento de falhas/incidentes e de performance/desempenho, até mesmo porque é amplamente customizável. Agora experimente conduzir a disciplina de gerenciamento de configurações com esta ferramenta, e você verá que é simplesmente inviável e contra-indicado.
• O Libre NMS é outro exemplo clássico, idêntico ao caso do Zabbix, assim como as outras ferramentas bem conhecidas do mercado citadas anteriormente.
• O ManageEngine ou o PRTG são outros ótimos exemplos para as questões de gerenciamento de falhas e de desempenho, mas não são funcionais para o gerenciamento de configurações.

Como você pode notar, muito frequentemente os sistemas que nós utilizamos não atendem bem a todas as nossas necessidades, e nos vemos forçados a contar com 3 ou 4 soluções de gerenciamento para manter a infraestrutura funcionando. Sistemas, estes, que funcionam de forma completamente independente, como "ilhas" mesmo, isolados, e com mínima ou zero troca de dados entre si. Para falhas e desempenho, isto é até "aceitável", embora, ainda assim, indesejável. Mas, para o gerenciamento de configurações, isto é inaceitável! Meus "2 cents" aqui.

A ilustração a seguir fornece exemplos de soluções mapeadas para as áreas do FCAPS, para que você tenha essa noção de que alguns fabricantes procuram especificar as funções de suas soluções de gerenciamento para ficarem mais "alinhadas" com as recomendações do FCAPS. Os exemplos não são completos e tampouco estão atualizados 100%, mas acho que você compreenderá a essência.

(Fonte: snmpcenter.com)

E é por esta razão que a indústria está convergindo cada vez mais para os princípios de programabilidade, pois os modelos de gerenciamento tradicionais não mais correspondem às nossas expectativas, e pelas tantas razões e situações comentadas até este momento!

Agora, há uma terceira opção aqui, que seria considerar soluções comerciais (destes mesmos fabricantes ou de terceiros) em combinação com outras iniciativas que entendam melhor as nossas necessidades e que sejam capazes de promover melhor aderência. Muitos destes sistemas "fechados" podem não atender integralmente as nossas necessidades, principalmente quando estes possuem baixas capacidades e recursos de integração com outros sistemas. E é nessa hora onde ferramentas e soluções de programabilidade poderão ser bem mais efetivas para os nossos propósitos. É nessa hora que pensamos em Ansible / Ansible Tower, Chef, Puppet, Salt, Cisco NSO e outras ferramentas de programabilidade, integradas a controladores SDN ou não.

Agora que você já está "anestesiado" e a par de todas as situações e pré-requisitos, vamos à programabilidade de infraestruturas

Tentarei ser muito objetivo ao explicar logo a seguir algumas verdades, assim como aproveitar a oportunidade para esclarecer algumas "inverdades", sobre este universo envolvendo programabilidade, orquestração, automação, provisionamento, SDN, NFV, etc. Vamos lá?

• O provisionamento é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes.
  • Este provisionamento de um serviço (ex: um L2VPN "LAN-to-LAN" ou "DCI", uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais, assim como empresas do setor corporativo) ou de forma bem mais "programável"; orquestrada e automatizada.
  • Geralmente referimos o conceito à ativação de um serviço fim-a-fim e que vá envolver diversas tecnologias (L2, L3, e outros) e em vários dispositivos de rede, homogêneos (mesmo padrão de sintaxe e semântica) ou heterogêneos (diferentes vendors, ou CLIs, sintaxes, etc.).
  • O provisionamento pode ser também uma coisa bem mais específica e pontual (um pequeno bloco de configuração a ser programado em um único dispositivo, por exemplo).
• A orquestração é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, frequentemente tocando em componentes multivendor, para a ativação de um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.
  • As tecnologias que fomentam a orquestração precisam ou devem operar sobre um regime de abstração entre as funções lógicas pretendidas e os componentes da infraestrutura de rede física. A solução preferencialmente deve suportar, além da abstração, o modelo de operações por transações. Quais equipamentos precisarão ser configurados? Ou quais equipamentos precisam receber quais configurações para a ativação deste serviço? E isto independente do vendor ou da sintaxe da CLI, sendo este o principal propósito desta abstração requerida. E, caso haja algum problema com a ativação, as devidas facilidades de rollback automático.
  • A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).
• A automação é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam "zero" ou o mínimo possível de ações humanas.
  • Desejavelmente, a automação deve estar contida na orquestração, pois, por exemplo, do contrário, não fará muito sentido "juntar as peças de sistemas dissimilares" (alçada da orquestração) se você tiver que executar os blocos do contrato manualmente depois, na CLI, GUI/WebUI ou por scripts, em vários equipamentos.
  • A orquestração e automação devem andar lado a lado.
    • Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples frontend, os parâmetros são preenchidos/fornecidos para que, no backend, a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).
    • Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.
• A programabilidade tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações automatizadas de serviços.
  • Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para a programabilidade do provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, "zero" ou menor esforço de implementação, e menores riscos para a rede e para o negócio.
• Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.
  • Scripts customizados por você podem não ter qualquer relação com ações de orquestração, além de serem isentos de capacidades de abstração, ou seja, scripts montados para aplicar configurações com sintaxes específicas e com acionamento caso a caso.
• Programabilidade e Software-Defined Networking (SDN), apesar de andarem lado a lado constantemente, são coisas completamente distintas.
• Orquestração e Software-Defined Networking (SDN) são coisas distintas. Nem toda orquestração ocorre em um ambiente SDN (ex: com controladoras e soluções específicas de SDN), mas quase sempre o inverso é verdadeiro.
• Software-Defined Networking (SDN) e Network Functions Virtualization (NFV) são coisas completamente distintas.
• As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de tecnologias, recursos e ferramentas específicas, e isto valendo para cada equipamento.
  • Não adiantará muito controladoras SDN em um projeto com suporte ao OpenFlow na sua rede se os seus elementos de rede (equipamentos) forem incompatíveis com este protocolo. Ou, ao invés do OpenFlow, não adiantará muito (ou pelo menos ficará bem mais complicado) fazer a orquestração de serviços na rede se os seus equipamentos não suportarem o protocolo NETCONF.
• Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.

A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.

Exemplos de componentes fomentadores da programabilidade de infraestruturas

Identificando as principais soluções, ferramentas e componentes orientados aos princípios de programabilidade

Caso você tenha ficado impressionado com a "salada de tecnologias" ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais, além de citar algumas ferramentas e os principais componentes usados por estas, tais como protocolos, procedimentos e formatos de dados, onde for viável comentar neste nível. Aliás, a intenção a seguir não é realmente esmiuçar como são de fato implementadas ou inseridas nas infraestruturas. Outro aspecto importante a ser comentado é que os exemplos a seguir não funcionam "sozinhos", no sentido que, em uma rede, você precisará combinar diversas destas soluções, linguagens, modelos, ferramentas e procedimentos; e que nem tudo o que está citado a seguir depende de controladoras SDN para acontecer. Há casos e casos, e cenários para tudo.

A ilustração a seguir mostra algumas áreas relacionadas aos princípios de programabilidade:

Algumas áreas do conceito de programabilidade de infraestruturas

Descrição das principais soluções, ferramentas, modelos, procedimentos e componentes de programabilidade

Ferramenta	Descrição
Soluções Comerciais
VMware vSphere	O vSphere é provavelmente a solução de virtualização de servidores mais utilizada do mercado. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens. Esta solução é amplamente utilizada no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração. Possui excepcionais capacidades de integração com regimes de orquestração e provisionamento completos de servidores virtuais.
VMware vRealize	VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a construção de nuvens heterogêneas híbridas, e apresenta excepcionais capacidades de integração.
Cisco APIC-EM	O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN. A sua proposta é a de fornecer uma plataforma elástica para a automação, simplificação e abstração da rede, acomodando aplicações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.
Cisco DNA Center	O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco. Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.
Cisco Application Centric Infrastructure (ACI)	O Cisco Application Policy Infrastructure Controller (Cisco APIC) é o principal componente arquitetural da solução Cisco ACI. Ele é o ponto unificado de automação e gerenciamento para a estrutura, a aplicação de políticas e o monitoramento de integridade da solução. O controlador otimiza o desempenho e a gestão, além de operar uma estrutura multiusuário escalonável da Cisco ACI. A solução como um todo embarca outros componentes tais como a própria controladora (Cisco APIC), Cisco Cloud ACI, Cisco Virtual ACI, swiches Cisco Nexus 9000 Series, Cisco ACI Multisite Orchestrator, Cisco ACI App Center, além de ótimas integrações com outras soluções tais como AppDynamics, DNA Center e ISE. O foco do ACI está para os ambientes de data center.
Cisco Crosswork Network Automation	O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursos para o gerenciamento proativo fim a fim das redes. Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.
Cisco Network Services Orchestrator	O Cisco NSO é uma solução muito robusta de orquestração com abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de orquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound, suportando ambientes completamente heterogêneos (multivendor). O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.
Cisco Open SDN Controller	O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogêneas para a entrega de serviços.
Microsoft System Center	O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.
BMC Software	A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global. A BMC possui sofisticadas soluções para o grenciamento multi-cloud, automação e DevOps, segurança e conformidade, otimização de TI, inteligência artificial e machine learning, e gerenciamento de serviços. Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.
Juniper Contrail	A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010. O Contrail pode ser utilizado por service providers / ISPs para agilizar o provisionamento de serviços, e também atende a muitos casos e necessidades de empresas do segmento corporativo. A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.
Huawei Agile SDN Controller	O controlador Agile para campus é a última geração de controladores da Huawei para redes LAN e WAN. É utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de políticas e SD-WAN.
Soluções de Código Aberto, Ferramentas, Sistemas, Linguagens, Protocolos, Procedimentos e Formatos de Dados
Ansible	O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações. O Ansible não usa agentes e nenhuma infraestrutura de segurança personalizada adicional, apenas uma linguagem muito simples (YAML, na forma de Ansible Playbooks) que permite descrever seus trabalhos de automação de uma maneira que se aproxima bastante do inglês comum. É uma ferramenta bastante popular!
Chef	Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever "receitas" na configuração do sistema. O Chef transforma a infraestrutura em código, onde você pode automatizar a criação, implantação e gerenciamento da sua infraestrutura, e de forma bastante versátil, testável e repetível. O servidor Chef armazena suas receitas e outros dados de configuração. O cliente Chef fica instalado em cada servidor, máquina virtual, container ou dispositivo de rede que você gerencia, chamados de "nodes". O cliente consulta periodicamente a política e o estado mais recente da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.
Puppet	O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave. Em curtas palavras, é composto de uma linguagem declarativa para expressar a configuração do sistema, um cliente e servidor para distribuí-lo, e uma biblioteca para realizar a tarefa de configuração pretendida.
SaltStack	O SaltStack ou "Salt" é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de software em servidores físicos, virtuais e cloud. O SaltStack automatiza tarefas repetidas de implementação administrativa e de código do sistema, eliminando processos manuais de maneira a reduzir os erros que ocorrem quando as organizações de TI configuram e disponibilizam seus sistemas. O Salt é bastante usado por times de DevOps porque extrai o código do desenvolvedor e as informações de configuração de um repositório de código central, como o GitHub ou o Subversion, e envia esse conteúdo remotamente para os servidores. Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.
CFEngine	CFEngine é um sistema de gerenciamento de configuração de código aberto, e a sua principal função é fornecer facilidades de configuração e manutenção automatizadas de sistemas de computadores em larga escala, incluindo o gerenciamento unificado de servidores, desktops, dispositivos industriais e de consumidor, dispositivos de rede incorporados, smartphones móveis e tablets.
GitLab	O GitLab é uma ótima ferramenta de ciclo de vida de DevOps que fornece um gerenciador de repositório Git, recursos de wiki, rastreamento de problemas e pipeline de CI/CD. Há um artigo em nossa Wiki demonstrando o gerenciamento de configurações de rede com ele.
OpenConfig	OpenConfig é um workgroup e também modelo de comunicação de rede que busca padronizar interfaces de gerenciamento de rede e APIs entre os principais fornecedores/vendors. O OpenConfig segue bem a proposta do que estamos discutindo neste artigo, que é a filosofia do afastamento natural dos administradores das ações de configuração por linha de comando (CLI), onde, cada vez mais, estes profissionais buscam promover configurações baseadas em códigos/programas e indo em direção às redes definidas por software (SDN).
OpenStack	O OpenStack é um sistema operacional que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo "SDN" sem que o nome OpenStack seja lembrado, sendo, indiscutivelmente, a solução mais popular para este propósito.
OpenDaylight	O OpenDaylight (ODL) é uma plataforma aberta e modular para a customização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes, onde o Cisco OSC é um exemplo claro disto.
OpenContrail (Tungsten Fabric)	O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, containers ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.
Kubernetes	Kubernetes é um formidável sistema de orquestração de containers open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em containers. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um "must have" em ambientes onde containers são fundamentais para os projetos de infraestrutura.
Docker, Jails, LXC, LXD, etc.	FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a elasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.
Recursos proprietários de equipamentos	Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.), tipo o IOS, JUNOS e outros, possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação. Citarei alguns exemplos aqui: Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), PoAP, Scheduler, TCLsh, dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação de tarefa ou procedimento. Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações. OBS: antes que você me questione ou reclame por eu ter citado apenas tecnologias "Cisco" aqui, relaxe: consulte a documentação de SEU fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento! E sem chororô!
OpenFlow	O OpenFlow não é uma "solução" em si, mas sim uma combinação de especificações e protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento, QoS e outros. O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN). Dentre outras coisas, o OpenFlow permite a administração remota de tabelas de encaminhamento de pacotes de roteadores, adicionando, modificando e removendo regras e ações de correspondência ou de incidência de pacotes. Dessa forma, as decisões de roteamento podem ser tomadas periodicamente ou por ad hoc pelo controlador, e traduzidas em regras e ações com uma lifecycle configurável, que são, então, aplicadas automaticamente nas tabelas dos equipamentos. Apesar de bastante promissor e muito interessante no ponto de vista de pesquisas e estudos, o OpenFlow nunca "deslanchou" como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!
Python	Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender. O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de códigos. É certamente um dos "queridinhos" dos times de DevOps para as necessidades de automação de infraestruturas de redes.
Ruby	Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script. Seu criador (Yukihiro “Matz” Matsumoto) juntou o "melhor dos mundos" de suas linguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.
Application Programming Interface (API)	Um conjunto de requisitos que governa como um aplicativo pode ser usado por outro. Uma API expõe funções internas ao mundo externo, ou seja, permite que outros aplicativos externos utilizem a funcionalidade dentro do aplicativo. O API não é um conceito novo, já que a maioria dos aplicativos modernos tem algum tipo de API. Frequentemente usa autenticação, enquanto a comunicação geralmente usa scripts Java, Python, XML ou HTTP simples, para exemplificar alguns casos. As APIs são extremamente fundamentais para ambientes de programabilidade, pois fornecem a devida modularidade, onde os aplicativos podem ser construídos em módulos que podem se comunicar com outros módulos por meio de uma API. Além disto, a abstração, pois permite expor parte das bibliotecas de um programa e ferramentas externas, na condição de orquestradores, os quais podem ser automatizados em um aplicativo ou infraestrutura de forma mais consistente e sem a necessidade de entender as implementações dos dispositivos da infraestrutura. E, por fim, a automação, pois as APIs são muito importantes para as tecnologias em nuvem, assim como projetos de infraestruturas de redes bem dinâmicas e elásticas, já que permitem que os recursos e o provisionamento sejam orquestrados por meios destas.
REST / RESTCONF	REST significa "Representational State Transfer", um estilo de arquitetura para projetar aplicativos em rede que usa HTTP/S para fazer chamadas entre entidades. O REST opera em representações de recursos, cada qual identificado por uma URL, sendo crucial para projetos de infraestrutura prevendo ampla automação de praticamente todas as suas funções. Por exemplo, APIs northbound em SDN são geralmente ou preferencialmente SDN RESTful APIs usadas para a comunicação entre a controladora SDN e os tantos serviços e aplicativos em execução na rede. Essas APIs podem ser usadas para facilitar a orquestração e automação eficientes da rede para o alinhamento com as necessidades de diferentes aplicações, e fazendo isto via esta capacidade de programabilidade da rede SDN. O RESTCONF é um draft do IETF que procura descrever como mapear uma especificação Yang para uma interface RESTful. Os dados de resposta podem ser em formato JSON ou XML, cujas as estruturas, nestes casos, seguem de acordo com o JSON-YANG e XML-YANG, respectivamente.
NETCONF	O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no RFC 6241. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração "na mão". Basicamente dependíamos de algumas (ou várias!) gambiarras envolvendo scripts para o lançamento de configurações nos elementos de rede. Em alguns casos, para os mais afortunados, equipados com algumas soluções e componentes proprietários, tais como interfaces Linux embarcadas nos equipamento (tipo guestshell), CLI scraping, dentre outros casos, conseguíamos resultados interessantes. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, "automatizados", é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, que será apresentado logo a seguir. O NETCONF é o que de fato promoveu excepcional capacidade de configuração de elementos de rede para os padrões atuais, em especial a instalação, configuração e manipulação de configurações em uma rede, e é considerado por muitos (inclusive por mim) como a melhor abordagem "interface para o sul" disponível atualmente.
Yang	O YANG é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.
XML	O XML significa "Extensible Markup Language", e é uma linguagem de marcação muito parecida com HTML, projetada para transportar dados, enquanto o HTML concentra-se mais com a aparência destes dados. O XML requer que você defina suas próprias tags, além de ser projetado para ser auto-descritivo. Note que a natureza de transporte dados do XML o torna um dos formatos mais populares para a troca de dados numa infraestrutura prevendo a programabilidade. O protocolo NETCONF citado anteriormente utiliza este formato de dados.
JSON	JSON significa "JavaScript Object Notation", que é um formato de dados que usa texto facilmente legível ou interpretável por nós, humanos, para transmitir objetos de dados que consistem em pares de atributo-valor. O JSON é relativamente bem fácil para que máquinas consigam analisar e gerar seu formato, e é construído com base em duas estruturas: pares de nome / valor, e lista ordenada de valores. Assim como o XML, o JSON é bastante popular por ser um formato de dados de fácil leitura e parsing, e é o formato de representação de dados mais usado em REST APIs.
Northbound APIs	Northbound APIs ("APIs para o norte") são o elo entre os aplicações de TI, tais como os sistemas OSS e BSS, e o controlador SDN. Estas aplicações podem informar à rede sobre o que necessitam, incluindo parâmetros tais como dados, armazenamento, largura de banda, planos de produto, políticas de admissão, etc., fazendo com que a rede então possa fornecer estes recursos ou comunicar o que possui. Essas APIs northbound suportam uma ampla variedade de aplicativos, sendo geralmente os componentes mais moldáveis existentes em um ambiente SDN, pois existem muitas interfaces possíveis em diferentes locais das pilhas para controlar diferentes tipos de serviços por meio de uma controladora SDN. Ambientes SDN muito bem sucedidos (leia-se: funcionais de verdade, pra valer!) são aqueles que fazem as melhores integrações entre os sistemas da empresa e os controladores, por meios destas interfaces para o norte. Exemplos de serviços de rede que podem ser otimizados via interfaces norte incluem roteadores, switches, concentradores de assinantes de Internet banda larga, firewalls, balanceadores de carga, serviços de segurança definidos por software ou aplicativos de orquestração de recursos da nuvem, etc. As APIs Northbound também são usadas para integrar a controladora SDN com pilhas de automação, tais como Puppet, Chef, SaltStack, Ansible e CFEngine, além de plataformas de orquestração, como OpenStack, vCloudDirector da VMware ou CloudStack, de código aberto do Apache, e Cisco NSO. Nestes casos, o objetivo é abstrair o funcionamento interno da rede, para que os desenvolvedores de aplicações possam conectar-se à rede visando fazer alterações para acomodar as necessidades da aplicação. O maior e melhor exemplo de interface norte aqui seria por Representational State Transfer (REST) API, o qual é baseado em URIs (Uniform Resource Identifier, ou seja, URLs de tipo específico), transportados por protocolo HTTP/S e utilizando rotineiramente o formato de dados em JSON. Há muitas vantagens ao considerar este tipo de interface norte. Outros casos menos conhecidos incluem SMASH, IPMI, WSMAN, e SOAP, mas a lista não para por aí.
Southbound APIs	Equanto uma API Northbound (ou interface para o norte) é uma interface que permite que um componente específico de uma rede se comunique com um componente de nível superior, a API Southbound (ou interface para o sul), por sua vez, permite que um componente de rede específico se comunique com um componente de nível inferior. Apenas para constar: ambas as APIs northbound e southbound frequentemente existem em qualquer tipo de infraestrutura de rede ou ambiente computacionai, e não necessariamente, ou não apenas, em ambientes SDN, embora a popularização da SDNs tenha aumentado essa ligação destas APIs para si. Um exemplo clássico de API Southbound envolve as especificações para o funcionamento do protocolo OpenFlow, já apresentado previamente. Mas, conforme citado anteriormente, o OpenFlow de fato nunca deslanchou como achávamos que fosse acontecer, então citarei aqui um exemplo melhor: NETCONF! Nada melhor que citar o NETCONF/Yang para ilustrar o conceito de APIs Southbound! Outro exemplo um tanto conhecido disto é o Cisco OnePK. Exemplo mais "pobres" (ou menos sofisticados e flexíveis que o NETCONF, por exemplo) de interfaces para o sul seria invocação por procedimentos SSH e SNMP, mas, sabemos, há limitações em usar o SNMP para transportar dados de configuração, por exemplo, e por isto que sou fã incondicional do NETCONF.
Software-Defined Networking (SDN)	Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.
Network Functions Virtualization (NFV)	Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware "commodity". Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado.

Ufa, hein!

Que tal ilustrarmos alguns destes (principais) componentes?

Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade

De todas as coisas citadas na "mega-tabela anterior", focaremos a seguir somente nos componentes que possuem relação direta com infraestrutura de redes, ou seja, dispensando situações envolvendo servidores, máquinas virtuais, containers e aplicações.

A integração entre dispositivos de redes, gerenciamento de configurações e pilhas de orquestração

Já que o artigo tem como principal proposta falarmos de programabilidade e com foco no gerenciamento de configurações, talvez seja prudente comentar aqui as principais diferenças entre algumas das conhecidas soluções para esta necessidade. Lembra que eu comentei anteriormente que, em muitos casos, as plataformas de gerenciamento não atendem integralmente às nossas necessidades, especialmente no que diz respeito ao gerenciamento de configurações? Pois bem, é nessa hora que vale a pena considerar ótimas soluções para administrarmos isto. As mais conhecidas são o Chef, Puppet, Ansible e Salt. A tabela a seguir fornece um comparativo superficial entre eles.

Comparativos entre as soluções de gerenciamento de configurações mais populares

	Chef	Puppet	Ansible	Salt
Template	Cookbook/Recipe	Manifest	Playbook	States/Pillars
Linguagem	Extensão do Ruby	Linguagem customizada semelhante ao JSON com opção Ruby	YAML	YAML
Licença	Apache	Apache	GPL	Apache
Agente	Requerido	Requerido	Não requerido	Não requerido, porém recomendado ("Minions")
Confira os comparativos entre as diversas soluções deste tipo aqui:
https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software

Os principais benefícios destas soluções são:

• Automação do provisionamento
• Consistência nas configurações dos elementos de rede
• Controle de versões das configurações, onde a infraestrutura pode ser representada como código
• Código aberto
• Redução dos riscos de indisponibilidade da rede provocados por falha humana
• Redução drástica do tempo de provisionamento de serviços

Comparativos superficiais entre Puppet e Ansible (Fonte: Cisco)

De todas as soluções mostradas na tabela acima, o Ansible possui algumas vantagens a seu favor, incluindo o fato de não requerer agentes nos dispositivos, de ser escrito em Python (uma linguagem de fácil interpretação), de ser simples e fácil de começar a usar, suporte a rede, servidores e aplicações, por possuir uma taxonomia descomplicada, e por ser código aberto. Quanto a taxonomia do Ansible:

• Role: um conjunto de Playbooks
• Playbook: um padrão de configurações repetitivas
• Play: um conjunto de tarefas
• Task: uma única ação que é referenciada em um módulo
• Module: scripts standalone reusáveis

Visão geral dos principais componentes do Ansible, em um exemplo envolvendo Cisco IOS/IOS XE

Como o artigo é introdutório, não detalharei mais sobre o Ansible, e nem sobre outras ferramentas e soluções. Isto será feito naturalmente em futuros artigos aqui no BPF.

Todavia. já recebemos uma colaboração recente neste sentido: Orquestrando sua rede com Ansible e Gitlab, publicado pelo Renato Oliveira.

Para finalizar, dependendo das suas necessidades em termos de projetos, facilidades e objetivos a serem conquistados, no que diz respeito ao Ansible, talvez você queira optar pelo Ansible Tower.

O que é e o que não é o Software-Defined Networking (SDN)

Conforme antecipado em outras ocasiões neste artigo, por incrível que possa parecer, não há uma dependência direta entre automação e SDN, neste exato sentido, pois, por exemplo, é possível instrumentar uma rede com bons padrões de automação usando ferramentas e recursos embarcados nos dispositivos da rede, e até mesmo com o auxílio de várias ferramentas, e sem que isto vá exigir controladoras SDN como um OpenStack, por exemplo. Por outro lado, em termos de eficiência de automação com muito foco na orquestração, o SDN possui uma relação direta com toda essa cadeia de programabilidade. Curioso, não? Para automatizar e até mesmo contar com padrões razoáveis de programabilidade na sua rede, o SDN não está necessariamente "presente", mas, ao considerarmos o SDN, este promoverá um padrão de orquestração e automação incomparáveis, e isto é um fato!

A propósito, você compreende o mínimo de SDN? Para os mais leigos, isto será bastante apropriado:

• O SDN não pode ser representado como se fosse um simples "botão", onde clica-se e temos um ambiente pronto, rodando! Não é bem por aí... e está longe de ser algo deste tipo.
• O SDN tem como uma de suas principais propostas a atenuação drástica dos esforços e complexidades operacionais associados com a orquestração, provisionamento e manutenção de infraestruturas de redes.
• O SDN é um esforço da indústria para a caracterização de redes mais automatizadas, ágeis, elásticas, e empregando menos esforços e custos operacionais, assim como a diminuição de riscos para os negócios das empresas.
• O SDN não obrigará que você torne-se um programador do dia para a noite, mas saber o essencial de lógica de programação e algumas linguagens de programação será muito útil para você poder destravar potenciais incríveis de seu ambiente!
• O SDN não substituirá a necessidade da sua empresa em continuar contando com engenheiros e operadores de NOC, muito pelo contrário! Todavia, a tendência é que consolidem-se no setor os profissionais mais especializados e diferenciados. Os negócios precisam evoluir (sempre para melhor), e por que você não pode fazer o mesmo com a sua carreira?
  • Que tal levar a minha sugestão de NetDevOps mais a sério? A hora é essa!
• O SDN originalmente busca promover uma abordagem de arquitetura que realiza uma separação bem legítima entre os planos de controle e de dados (control plane e data plane), levando o estado de informações, juntamente com a inteligência para tomadas de decisões, para um conceito logicamente centralizado. Ou seja, a centralização do estado de informações em uma zona estratégica da infraestrutura, enquanto os dispositivos de redes ficam mais dedicados e especializados em executar o processamento de pacotes e afins.
• O SDN promove excepcional abstração entre a infraestrutura de rede (a qual possui seus serviços mais íntimos, tipo o IGP da infraestrutura, o MPLS, o QoS do backbone, etc.) e as aplicações e demais serviços da rede. E pode oferecer uma separação bastante interessante entre redes underlay e overlay.
• O SDN pode ser representado como um conceito de interfaces programáticas que permitem que sistemas externos influenciem no provisionamento de serviços, controle e operações da rede.
• O SDN fornece novas formas de interação com os equipamentos e serviços da rede via controladoras e APIs (Application Programming Interface). Neste caso, por interfaces northbound e southbound.
• O SDN permite formidáveis capacidades de provisionamento, orquestração, automação e normalização de equipamentos e serviços.
• O SDN pode destravar diversas barreiras do seu negócio ao permitir que agentes externos - devidamente integrados à rede - consigam influenciar nas características de seu projeto e na sua operação, promovendo melhor alinhamento entre as tecnologias empregadas e os resultados almejados pelos modelos de negócios.
• Os cenários de redes SDN podem ser:
  • Uma rede onde os dispositivos retém os seus próprios planos de controle, mas que uma controladora SDN também mantém o estado de informação de protocolos e serviços, podendo influenciar e provisionar serviços sobre a rede. Isto seria o exemplo de uma abordagem híbrida.
  • Uma rede onde todo o plano de controle é centralizado na(s) controladora(s) SDN, enquanto os equipamentos ficam dedicados para as funções de processamento de pacotes. O que seria o caso de uma abordagem SDN "pura".
  • Uma rede (tipificada como Underlay) onde outras redes completamente distintas e abstraídas são provisionadas sobre ela, o que seria o caso típico das soluções para redes Overlay.

A ilustração a seguir mostra um excelente comparativo entre redes tradicionais e SDN, "for dummies" (para os leigos).

Comparativos entre redes tradicionais e SDN, para os leigos

Já a próxima ilustração mostra de forma um tanto simplificada como um ambiente SDN pode ser representado em termos de seus principais componentes:

Exemplificando um ambiente SDN

Exatamente qual ou quais controladoras você consideraria para o seu projeto (OpenStack, OpenDaylight, Contrail/Tungsten Fabric, Cisco OSC, ou algo mais específico (Cisco ACI, Huawei Agile, etc.)), assim como quais interfaces Northbound você deveria considerar (meus "2 cents": eu recomendaria sempre que possível por REST API) e quais interfaces Southbound (recomendo sempre que viável o NETCONF/Yang), isto dependerá muito do seu projeto técnico, arquiteturas necessárias, integrações a serem realizadas, customizações, desenvolvimentos adicionais, etc., o que está completamente fora do escopo de um artigo introdutório.

Para ser bem franco e honesto aqui, é bem factível que num primeiro momento você sequer necessite de um ambiente SDN puro, e talvez uma solução de orquestração devidamente integrada e implementada vá resolver a maior parte dos seus problemas e desafios, se não todos, mas isso, novamente, dependerá do seu projeto e do que se espera para a sua organização. A sua empresa realmente se beneficiaria muito se adotasse, por exemplo, o OpenStack juntamente com o OpenFlow? Você ou o seu time tem expertise para saber lidar com este padrão de arquitetura e essas soluções?

Quem sabe uma solução de orquestração de configurações bem integrada à sua rede e sistemas não consiga fazer exatamente aquilo que você esteja buscando para a sua infraestrutura, sem exigir a complexidade de adoção de um OpenStack e OpenFlow? Por exemplo, eu particularmente considero o Cisco NSO excepcional, pois pode ou não ser integrado com controladoras SDN, standalone, ou integrado diretamente para os sistemas OSS e BSS da sua empresa via interfaces Northbound, além de oferecer suporte absoluto multivendor, desde que seus equipamentos suportem NETCONF, o que seria bem razoável para plataformas de primeira linha, e sem que isto fosse necessitar da complexidade das controladoras SDN e do OpenFlow. Inclusive, caso você já possua o Ansible em seu ambiente, é possível integrar um módulo do Cisco NSO no Ansible via uma interface REST para JSON-RPC para que o NSO faça o parsing dos dados YAML dos Playbooks do Ansible em CDB do NSO, e conduza, na sequência, toda a orquestração pelas interfaces Southbound (ex: NETCONF/Yang) com os dispositivos da rede, mantendo todo os seus diferenciais e modelos de transações; commit dry-run, rollback upon failure, commit, rollback, relatórios de compliance de configurações, e tantos outros benefícios.

A solução Cisco NSO (Fonte: Cisco)

A solução Cisco NSO integrada à ambientes mais complexos envolvendo Virtualização, Rede e Computação (Fonte: Cisco)

Alternativamente ao Cisco NSO, você poderá partir para o Ansible Tower, se preferir, ou para o GitLab, ou as outras sugestões comentadas anteriormente, cada qual com suas vantagens, benefícios, prós e contras. Mas, no final das contas, você inevitavelmente terá que especificar todas as funcionalidades e processos desejados para as suas necessidades de orquestração e automação para poder, depois, selecionar melhor a arquitetura e soluções ideais para o seu projeto, e isto é um fato!

E, para concluir, a ilustração a seguir mostra os possíveis cenários de SDN.

Cenários típicos de redes SDN

Conclusão do artigo

O que era para ser um artigo, tornou-se quase um livro! Isto que dá escrever "pelos cotovelos" e sem um roteiro combinado! Sim... muito do que eu publico as vezes aqui na Wiki do BPF são "estalos", inspirações, que me fazem quase que imediatamente a vir até aqui e sair digitando a torto e a direito, pois, do contrário, a inspiração "esfria". Aí, durante o processo, um assunto vai puxando o outro e eu não sou muito fã de deixar as coisas incompletas ou mal esclarecidas, o que justifica meus artigos um tanto extensos. Apesar dessa dinâmica um tanto improvisada que tenho as vezes, é a minha "cachaça"! Estou perdoado?

Espero que as informações apresentadas aqui tenham sido úteis para ajudá-lo a se interessar pelo tema e a embarcar no universo NetDevOps!

Propositalmente deixei de fora vários exemplos e detalhamentos acerca de algumas coisas muito importantes envolvendo o NETCONF/Yang, RESTCONF, XML e JSON, etc., e até mesmo das soluções citadas, tipo o Ansible, Puppet, Cisco NSO, e outras, pois isto tornaria o artigo realmente muito gigantesco. Mas, fique tranquilo, produzir artigos sobre estes temas, fornecendo demonstrações e tudo mais, está definitivamente no radar do Comitê de Programa do Brasil Peering Forum (BPF)!

Obrigado por acompanhar o nosso trabalho, e contamos com você para promover e divulgar cada vez mais os conteúdos de nossa Wiki. Compartilhe sem dó nem piedade! Desejamos continuar contribuindo para o desenvolvimento dos provedores de acesso à Internet e, por tabela, tanto quanto, de qualquer empresa e de qualquer segmento que esteja buscando em nossa Wiki os conhecimentos necessários para a transformação de suas infraestruturas.

Um abraço!

Autor: Leonardo Furtado