SDN on Cisco Redes

BLOG – NFD20 – VMware – SDWAN

Mon, 11 Mar 2019 00:00:00 +0000

Olá Pessoal,

Enfim, mais um ” resumão ” sobre nossa visita ao NFD20 ( Tech Field Day ), e desta vez vou abordar sobre a sessão que tivemos nas dependência da VMware ( Palo Alto City ), com o propósito de apresentar sobre sua solução de SDWAN atrelado ao produto Velocloud.

Acredito que todos devem saber, porém vale relembrar que a VMware adquiriu a Velocloud em Dezembro de 2017, com o intuito de agregar a seu portfolio as soluções de SDWAN, bem como já existia um interesse nessa aquisição devido a Velocloud ter trabalhado muito mais proximo da VMware e as integrações dos produtos de uma certa forma já estavam um pouco amarradas.

Inicialmente, Tom Gillis ( SVP & GM, NSBU ) apresentou sobre a visão de integração entre as área de ” Networking ” e ” Segurança “, colocando seus detalhes sobre as oportunidades que VMware visualiza dentro desse segmento, bem como sobre as demandas em Cloud, trazendo cada vez mais dentro de infraestruturas em código, assim como os exemplos de hoje termos diversas VMs e microserviços espalhados por toda a estrutura ( on-premisses, Cloud ), desta forma conseguir oferecer essa camada de conectividade e proteção ao seu ambiente. As oportunidades são justamente em trazer toda essas facilidades através de software ( NSX – serie de posts em nosso BLOG ) + Web GUI + Rest API. Se desejar saber mais sobre essa sessão recomendo assistir ao video abaixo, onde ele também explora sobre os nossos conceitos relacionados as menções de hardware e virtualização.

Após esse anúncio, iniciou-se a parte que eu mais gostaria de visualizar que seriam sobre as atualizações dos produtos relacionados a SDWAN, bem como a demo. Toda a estrutura se formos pensar sobre a solução de SDWAN, ela está totalmente correlacionada ao NSX, que por sua vez, terá as funcionalidades de trazer seu ” Plano de Controle ” + ” Gerência ” + ” Análises ” + ” Visibilidade “. Desta forma, teremos os pontos chave para que possamos construir essa solução associada ao conhecimento que Velocloud agrega ao produto. Abaixo segue as menções sobre as demandas que deve-se oferecer como: um meio de transporte totalmente transparente, oferecer segurança unificada, uma interface ( GUI ) de fácil usabilidade, e o carro chefe de qualquer produto SDWAN ( Dynamic Path ).

Depois desse overview, Tony Banuelos ( Product Line Manager, NSBU, VMware ), iniciou falando sobre os modelos dos SD-WAN Edge que podemos obter, baseando-se na necessidade de cada ponto remoto ( edge ), sempre correlacionando com a largura de banda. Desta forma, podemos observar nesse momento à evolução desses ” White-Box ” e a relação de alguns modelos que aceitam trabalhar com ” VNF – Virtual Network Function “, bem como os modelos que temos para adquirir através somente de um arquivo ( .ova ) para deploy deles em suas estruturas ( KVM, ESXi ). Todos eles podem ser adquiridos através de seu CAPEX e também você paga o ” subscription “. Segue abaixo os modelos:

Alguns questionamentos foram abordados no sentido de trabalhar com esses enlaces LTE, Broadband, MPLS em Active – Active, porém até o presente momento a plataforma consegue oferecer apenas o Active – Backup, bem como a questão de suporte a IPv6, onde ainda não temos essa capacidade para trabalhar nativamente com IPv6. Muitas menções foram colocadas sobre as homologações das ISPs para oferta do LTE, e os citados estão totalmente atrelados as operadoras dos USA ( ATT, Verizon, T-Mobile ), devido a isso eu acabei perguntando diretamente ( off-line da sessão ) sobre as questões em relação a região que nos aqui brasileiros trabalhamos, e segundo a resposta do Tony eles estão trabalhando para aumentar isso agora para outras regiões, mas que até o momento não é possivel utilizarmos esses recursos no Brasil. Segue o vídeo abaixo para sua analise:

Após esses detalhes, Fan Gu ( Product Line Manager ) apresentou sobre ” Visibilidade ” e as menções sobre as integrações dentro da plataforma para que possamos trabalhar com ” VNF “, bem como os parceiros em ” IaaS ” ( AWS, Azure ) para oferecer granularidade e acesso as suas aplicações diretamente nessa infra-estrutura. Desta forma, também já temos disponivéis dentro desses parceiros via MarketPlace para executar instalação desses virtual appliances. Segue abaixo o vídeo detalhando todos esses parâmetros:

Finalmente, chegou a hora relacionado a demo, onde foi exposto um exemplo de implementação utilizando os recursos disponivéis da Azure. Nesta demonstração foi criado dois tunneis através de seu Virtual Edge via Orchestrator Velocloud, após essa criação podemos observar os tunneis sendo criados automaticamente no Virtual HUB instalado dentro da infraestrutura Azure e com isso trazendo sua comunicação ” Branch Office ” para suas duas VNETs. Segue abaixo a demo:

Para finalizar foi entregue um livro para todos os representantes, conforme abaixo. Até o momento eu não finalizei a leitura dele, assim que eu finalizar volto aqui para comentar sobre o mesmo.

Sinceramente eu espera um pouco mais sobre a demo, explorando um pouco mais afundo seus detalhes sobre scripts, segurança, analise mais profunda de alguma aplicação, etc. Um ponto importante que chamou minha atenção e gostaria de ressaltar que nessas apresentações, por diversas vezes a menção CCIE foi falada, principalmente sobre as características da real necessidade desse engenheiro, entretanto essas discussões nos podemos trazer em outro post para correlacionar mais esses ítens.

Espero que vocês tenham gostado e se ficou alguma dúvida ou sugestão coloque aqui em nossos comentários. 🙂

Abs,
Rodrigo

Disclaimer: Gelstalt IT, the organizers of Networking Field Day, provides travel and expenses for me to attend Networking Field Day. I do not receive cash compensation as a delegate. Also, I do not receive compensation for writing about or promoting Networking Field Day.

Cisco – 4 Free ebooks- Você sabia?

Wed, 17 Oct 2018 00:00:00 +0000

Olá Comunidade,

Como todos vem observando a Cisco já mudou bastante algumas culturas, na qual você já pode pensar/refletir sobre elas. Baseado nisso venho aqui para trazer mais uma facilidade que a Cisco vem trabalhando para conseguir atender uma demanda maior de pessoas, bem como divulgar cada vez mais seus produtos e caminhando para área de Automação, Intuitiva, Programável.

Todo esse progresso está muito relacionado com a cultura agora da empresa de ” Developer ” e com isso atingindo cada vez mais as comunidades e pessoas que buscam essas informações e de alguma forma divulgam elas.

Hoje venho para compartilhar 4 Livros disponibilizados gratuitamente. Ainda não consegui ler todos, pois temos muito conteúdo, porém já estou na metade do livro de IOS XE. Segue abaixo os livros:

Todo esse projeto foi possivel através de uma parceria que iniciou-se em 2014 e que está produzindo os livros com muito menos burocracia e agilidade de editoração e tempo de impressão. A parceira é a BookSprints.

Espero que apreciem a leitura e seja de alguma forma um incentivador para iniciar sua trajetoria nesse segmento.

Abs,
Rodrigo

VMware – História do NSX – Parte 1

Thu, 14 Jun 2018 00:00:00 +0000

Olá Pessoal,

Gostaria de iniciar uma serie para explicar um pouco sobre esse produto da VMware que é chamado de NSX. A ideia dessa serie é tentar detalhar um pouco sobre as características dele e alguns caminhos que você pode utilizar para visualizar sua console, configurar e também fazer o deploy.

Acredito que nem todos saibam mas esse produto inicialmente foi desenvolvido pela NICIRA chamado de NVP ( Network Virtualization Plataform ), onde era uma empresa focada em um software definido para redes ( SDN ) e virtualização, a qual foi fundada em 2007 por Martin Casado, Nick McKeown and Scott Shenker. Baseado em seu desenvolvimento e interesse de mercado a empresa foi adquirida pela VMware em Agosto de 2012 agregando esse produto em seu portofolio trazendo no conceito de SDDC ( Software Defined Data Center ). Praticamente após 1 ano de aquisição desse produto a VMware lançou no mercado trazendo o nome de NSX, onde de fato trouxe para esse player uma demanda denominada aqui como ” Networking ” ou literalmente para a fatia de mercado intitulada como rede virtualizada.

Nos sabemos que VMware anteriormente tinha muito forte sua estrutura voltada especificamente para virtualização e atendendo muito bem a demanda dentro de ambientes de DC ( Data Center ), no qual agregava-se outros conceitos voltados para redes em seus parceiros, onde obviamente Cisco sempre foi uma grande aliada nesse setor, oferecendo soluções agregadas/compartilhadas a todo esse portfolio. Nesse momento vemos muitos confrontos de ” market share ” entre essas empresas devido a diferentes fatores que não irei detalhar nesse momento, mas que cada um pode fazer sua analogia e reflexão pessoal ( rsrs ).

Muito bem, voltando para o detalhamento dessa solução, eu gostaria de colocar alguns ítens, para que para os futuros posts possa ser melhor aproveitado falando-se em terminologia e acrônimos. Se você não viu meu post sobre essa sopa de letrinhas, vale a pena verificar ” Acrônimos do mercado atual “, e claro, devido esses termos vou detalhar voltado para nosso tema:

SDS – Software Defined Storage ( VMware VSAN, EMC ViPR )
SDC – Software Defined Compute ( VMware vSphere, Hyper-V )
SDN – Software Defined Network ( NSX, Contrail, ACI [ A Cisco não gosta de caracterizar como SDN devido ao DNAc ] )
SDDC – Software Defined Data Center ( Flexível, Provisionamento DC automatizado )

Com isso podemos agora mencionar sobre as versões que temos disponivéis para o mercado, onde tivemos algumas alterações para atendimento não somente de produtos VMware, mas devido agora este mundo onde precisa-se de multiplataformas, tendo a fisolofia que não pode atender apenas seu ” parquinho ” de equipamentos proprietários. Com isso posso trazer:

NSX-V – Somente atendido ao ambiente VMware ( vSphere )
NSX-mh – Multi-hypervisor utilizando multiplas images ( OpenStack, KVM, Kubernetes, ESXi, Hyper-V )

Você pode estar se perguntando, mh? Sim, anteriormente foi assim denominado e agora ele é chamado de NSX-T ( Transformers ). Pois bem, e o que muda entre essas versões?

Com o NSX-V, as organizações podem mobilizar a conectividade de rede entre máquinas virtuais e permitir que essas cargas de trabalho sejam conectadas de maneiras que, de outra forma, não poderiam ser entregues de forma eficiente pelo hardware de rede física. Na maioria das vezes, se você deseja executar uma infraestrutura de rede definida por software no âmbito do VMware vSphere, o NSX-V é a plataforma que você provavelmente usará.

Em contra-partida o NSX-T foi projetado para lidar com estruturas e arquiteturas de aplicativos emergentes, que possuem terminais heterogêneos e pilhas de tecnologia. Um dos principais casos de uso do NSX-T é com contêineres. Na virtualização de hoje, estamos vendo mais e mais aplicativos sendo executados em ambientes fora das máquinas virtuais.

O VMware NSX-T é integrado com o VMware Photon Platform, que é o sistema operacional centrado em nuvem que a VMware desenvolveu desde o início com os gostos do atual servidor vCenter em execução no topo dessa plataforma. O NSX-T também contém o plugin de interface de rede de contêiner ( CNI ) do NSX-T que permitirá aos desenvolvedores configurar a conectividade de rede para aplicativos de contêiner que ajudam a fornecer Infraestrutura como um Serviço.

Tivemos recentemente também atualização do NSX-T Datacenter que está co-relacionado ao NSX-Cloud, trazendo o conceito sobre MultiCloud com as integrações em AWS e Azure. Eu irei detalhar um pouco sobre essa demanda, mas deixarei para o final, pois gostaria de trazer alguns conceitos antes para que possamos chegar nessa estrutura. Se quiser conferir sobre o assunto, você já pode verificar através do anuncio do NSX-T Data Center.

Em nosso próximo post vou falar sobre o ítens que compõem o provisionamento do NSX ( Manager, Controllers, Edge, dLR, DFW, etc ).

Abs,
Rodrigo

Nova Carreira de Certificação Cisco – Programmability

Mon, 10 Apr 2017 00:00:00 +0000

Olá Pessoal,

Recentemente a Cisco lançou mais uma cadeia de certificações para essas novas tendências que estão surgindo, baseando na estrutura do Cisco DNA.

Essas certificações estão dentro da cadeia de ” Specialist “, para qual temos 3 níveis de certificações voltados para Design e Implementação, Desenvolvimento ( ODL, onePK, APIC ) e Desenvolvedores especificos para aplicaçãoes ( SAP, Oracle ). Nas certificações de Design e Desenvolvimento os pré-requisitos seriam a nível de CC*P. Para maiores informações verifique as certificações de Programability.

Para os candidatos que são novos nessa area, eles indicam um treinamento que irá abordar alguns temas como Python, NX-APi, DevNet, etc. Entretanto, esse treinamento está sendo oferecido por U$499,00 ( 😯 ), na qual eu sinceramente acho pesado este valor.

Para maiores informações acesse o site que está oferecendo o curso de PRNE e deixem seus comentários em relação as essa nova abordagem.

Atenciosamente,
Rodrigo

Cisco – SandBox

Fri, 17 Mar 2017 00:00:00 +0000

Olá Pessoal,

Conforme havia comentado anteriormente em nosso post sobre DevNet, hoje gostaria de trazer para vocês mais alguns ítens que estão totalmente relacionados a esses novos desenvolvimentos, bem como laboratórios free para que você possa praticar alguns conceitos.

A plataforma Sandbox está disponivel para que você possa usar para desenvolvimento, testar APIs, aprender como configurar um produto, treinamento, hackathons, etc. Dentro desse perfil existe dois módulos que são chamados de ” Always-On ” e ” Reservation “, onde cada um teria sua particularidade:

Always on = Acesso instantâneo sem necessidade de qualquer reserva, acesso completo para as APIs, porém como o acesso é compartilhado com todos os usuários, alguns níveis de privilégios são bloqueados.
Reservation = Necessidade de reservar ambiente, acesso administrativo, ambiente privado, porém existe as policitas que necessita de uma conexão via VPN e as configurações executadas depois de finalizar sua reserva não serão gravadas.

Com isso, você pode testar seu código ou até mesmo visualizar de que forma as novas plataformas estão trabalhando, praticando em alguns casos exemplos de configuração. Neste modelo já existem laboratórios para diversas torres de tecnologia, como abaixo:

Agora as ferramentas já temos disponíveis, apenas precisamos entender esses novos conceitos para praticar e vivenciar um pouco dessa nova experiencia. 🙂

Abs,
Rodrigo

Cisco DNA – Enterprise NFV

Fri, 10 Mar 2017 00:00:00 +0000

Olá Pessoal,

Conforme mencionado anteriormente, gostaria de trazer mais alguns itens co-relacionados a estrutura Cisco DNA, com uma maior visibilidade dentro do ambientes de nossos clientes ( Branch Sites ) com as novas estruturas de NFV ( Network Function Virtualization ).

Devido anuncio desse novo hardware e as tendências de mercado trago hoje mais algumas nomenclaturas e recursos que podemos oferecer utilizando equipamentos Cisco. Para isso mostro abaixo os componentes que estão integrando-se para um solução NFV.

Dentro dessa estrutura podemos visualizar algumas camadas:

Orquestração: Sendo executada pelo APIC-EM bem como o ESA, que são ferramentas de configuração de equipamento, gerenciamento de todas as caixas em seu ambiente de produção
Serviços de Rede: Nesse tópico o grande ponto seriam ” conectadores ” com outros fabricantes através de APIs ou até mesmo de ” VMs ” que poderiam ser instaladas ofertando um serviço de Firewall, Otimização de WAN, etc.
NFVIS: Seria a camada de abstração para que suas plataformas de VNF possam trabalhar, baseando em um Kernel para seu equipamento. Podemos fazer uma analogia por exemplo com um ESXI, Hyper-V, KVM. Neste item recomendo uma leitura relacionado ao NFVIS.
Plataforma ( Hardware ): Neste item seria abordagem que podemos fazer baseando-se em um UCS, ENCS e até de um roteador 4K.

Baseando-se nesses itens gostaria dar uma visibilidade dos possíveis hardwares que podemos pensar quando falamos em NFV.

Agora como você visualiza um item conhecido ” roteador “, gostaria de trazer ideias para que você possa pensar no momento quando é mencionado ” O roteador que está no meu cliente hoje não terá mais funções? “. O que posso responder para você seria ” tudo depende “. 🙂

Porque? Porque, avaliações precisam ser feitas com a intenção de entender o fator de crescimentos e as necessidades exigidas para seu crescimento. Hoje na plataforma 4K, temos hardware ( UCS ) que pode ser inserido, para que baseando-se nos limites desse hardware muitos serviços de NFV podem ser ofertados, bem como, instalações de Sistemas operacionais nesses equipamentos. Esse hardware pode potencializar seu equipamento oferecendo muitos serviços de virtualização.

Baseando-se nessas informações o que visualiza dessas novas soluções? Podem trazer benefícios para nosso dia a dia?

Abs,

Rodrigo

Cisco DNA – Digital Network Architecture

Thu, 23 Feb 2017 00:00:00 +0000

Olá Pessoal,

Gostaria de trazer uma novidade sobre anúncio de um novo produto que a Cisco esta trazendo para essa categoria de SD-WAN, SDN, Digital Network.

Os produtos, que incluem um dispositivo em um site remoto onde temos NFV ( Virtualização de Funções de Rede ) trazendo melhorias para o software segmentação de redes, estão sob o plano de arquitetura de Rede Digital da Cisco. DNA oferece software integrado de rede – virtualização, automação, análise, gerenciamento de serviços em nuvem e segurança em uma única plataforma.

No lado do hardware, a Cisco lançou o Enterprise Network Compute System (ENCS) Série 5400, um servidor 1RU Intel Xeon que inclui 8 portas GE onde suporta LTE, T1, DSL, bem como Dual-Phy Gigabit Ethernet WAN e 64Gb de memória.

O 5400 é uma plataforma para sites remotos criados para ajudar os clientes a acelerar suas implantações Enterprise NFV estendendo roteamento, segurança, otimização de WAN e outros serviços de rede para seus ambientes de filiais.

Para você entender um pouco melhor arquitetura segue a foto de um slide relacionado apresentação do produto.

Em nossos próximos post vou explicar um pouco melhor sobre esse termo que a Cisco está trazendo como DNA. Para que vocês possam entender um pouco melhor segue o link sobre Cisco DNA.

Abs,
Rodrigo

O que é API e Rest API?

Mon, 13 Feb 2017 00:00:00 +0000

Olá Pessoal,

Devido as novas demandas que estão surgindo, principalmente a relação de integração de software com nossa infraestrutura ( routers, switches, firewalls ) esses termos mencionados em nosso título acabam sendo evidenciados.

Acredito que todos quando observam esses termos imaginam que isso seja algo relacionado a quem trabalha com programação, integração de sistemas, desenvolvedores de sistemas, etc.

Pois bem, isso não é mais a realidade que vivenciamos em nossa área de redes e infraestrutura. Porquê? 💡

Como todos nos sabemos nossa área esta passando por várias transformações, bem como as empresas estão adicionando em seus produtos muitas funcionalidades que podem ser visualizadas / consultadas por outros fabricantes, com o intuito de oferecer serviços e integrações entre as plataformas. Com isso podemos definir dois ítens:

API ( Application Programming Interface ) : Isso está relacionado a ferramenta ou biblioteca que pode ajudar aos desenvolvedores acessarem informações dentro de seu código ( fabricante ) para fazer a tratativa das informações necessária para o desenvolvimento de sua ferramenta. Essas APIs podem estar contidas nos sistemas operacionais, sistema de banco de dados, hardware de computadores, etc. No caso de uma API podemos mencionar que pensando no protocolo HTTP você poderia fazer um ” GET ” no código para obter as informações.

Como exemplo de uma API poderíamos citar dois exemplos:

Quando acessamos um site onde vamos pesquisar seu endereço e nele temos o mapa do ” Google MAPS ” populados automaticamente na página daquele cliente, e da mesma forma podemos navegar nessa janela olhando pelas ruas próximas ao mapa, ou seja, o site está acessando uma API publica do Google para mostrar aquela informação.
Poderíamos citar sobre o Facebook que disponibiliza uma API para que por exemplo outros software possam fazer uma publicação automatica baseado na sua autorização de utilização da API ( Keys ).

Rest API ( Representational state transfer API ) : Como informado acima API oferece caminhos para que você possa acessar as informações, e quando a menção se torna uma REST API seria quando eu defino funções a qual os desenvolvedores podem executar solicitações e receber respostas por exemplo através do protocolo HTTP ( GET e POST )

Com isso diversas plataforma agora estão vindo com API públicas para que você possa consultar e de alguma forma possa interagir com as ferramentas / hardware que esse fabricante disponibiliza. Você poderia estar pensando o que vou fazer com essas funcionalidades?

Em nosso segundo post vou mencionar sobre o que fazer com essas funcionalidades e como a Cisco está trabalhando com essas novas demandas.

Abs,
Rodrigo

Sessão ao Vivo – Projeções para SDN

Wed, 14 Dec 2016 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com vocês uma sessão ao vivo que vou fazer pelo Youtube ( 15/12/2016 – 15hs ). Nessa seção vou trazer o assunto SDN e explorar um pouco o conceito e as projeções que temos para o mercado.

Nos tópicos abordados também vou trazer algumas ideias de como a Cisco esta trazendo essas soluções para o mercado.

Reserve na sua agenda e dê um subscribe em nosso canal.

Abs,
Rodrigo

Congresso Online 5° Edição – Dezembro 2016

Mon, 28 Nov 2016 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com vocês agenda que irei trazer para nossa palestra no Congresso On-Line de TI.

Segue abaixo:

Segue o sumario do que irei apresentar para vocês:

Evolução da Era
Redes Tradicionais
Dia a dia do Engenheiro de Redes
SDN
Instituições OpenSource
Estrutura como Serviço
Evolução Tecnológica

Lembrando-se que para assistir a palestra vocês precisam se cadastrar no site www.congressodeti.com.br

Abs,
Rodrigo

Cisco ACI, o que é?

Mon, 14 Nov 2016 00:00:00 +0000

Olá Pessoal,

Conforme mencionando em nosso post anterior, gostaria de trazer para nosso debate um pouco sobre Cisco ACI ( Application Centric Infrastructure )

Todo esse artefato tem sido gerado pelas evoluções de nossa tecnologia, principalmente muito relacionado área de Datacenter, que esta relacionado ao movimento de trazermos todos os nossos serviços para dentro das ” clouds “.

Com isso a Cisco tem a sua filosofia desenvolvimento para essas novas ferramentas que trazem o beneficio para utilização do SDN.

Devido a isso, Cisco ACI é uma solução fortemente acoplada à política que integra software e hardware. O hardware para Cisco ACI baseia-se na família de switches Cisco Nexus 9000. O software e os pontos de integração para o ACI incluem alguns componentes, embora não haja uma dependência explícita de qualquer switch virtual específico, neste momento, as políticas só podem ser executadas aos switches virtuais se o Virtual Application Switch (AVS) da Cisco for usado, embora tenha havido conversas sobre como estender isso para Open vSwitch no futuro próximo. Porém, vocês poderiam perguntar o que é AVS?

O AVS é um switch de rede virtual ( hypervisor ) e que foi projetado especificamente para a arquitetura ACI. Com base no bem sucedido switch Cisco Nexus 1000V, o AVS oferece suporte a recursos para o modelo de política de aplicativos ACI, recursos de comutação completa e recursos de telemetria mais avançados. O AVS também oferece:

Ponto único de gerenciamento e controle para cargas de trabalho físicas e virtuais.
Mobilidade de carga de trabalho contínua.
Suporte para todos os principais “ hypervisors ” com um modelo operacional consistente em implementações para operações simplificadas em data centers heterogêneos.

Com isso, podemos trazer mais um componente para nossa estrutura o termo APIC ( Application Policy Infrastructure Controller ). O APIC é o ponto único de automação e gerenciamento em ambientes físicos e virtuais, permitindo que os operadores construam redes totalmente automatizadas e multi-tenant com escalabilidade. A principal função do Cisco APIC é oferecer autoridade política e métodos de resolução para o Cisco ACI, bem como para os dispositivos conectados ao Cisco ACI. Segue abaixo para visualização:

Esse tema é bastante extenso e irei trazer mais conceitos em nossos próximos post. Aguardem!!!

Abs,
Rodrigo

Fonte: http://www.cisco.com/c/pt_br/solutions/data-center-virtualization/application-centric-infrastructure/index.html

OpFlex – Protocolo Cisco

Thu, 10 Nov 2016 00:00:00 +0000

Olá Pessoal,

Conforme comentado anteriormente gostaria de trazer a filosofia Cisco para a versão do OpenFlow, chamado pela Cisco de OpFlex. Vale lembrar que esse protocolo ele não será de uso exclusivo da Cisco, ou seja, qualquer vendor poderia trabalhar normalmente com esse protocolo.

Por que?

A Cisco esta propondo uma padronização para o IETF, em um trabalho conjunto com os parceiros IBM, Plexxi, Midokura para submeter OpFlex ao OpendayLight ( orgão para padronização SDN ). Essa versão foi encaminhada para “ pre-aceitação ” na versão ” Helium ” do OpenDaylight. Você pode conferir na pagina do OpendayLight e também conseguimos observar isso no site do IETF como uma versão draft.

Devido a isso, o protocolo OpFlex da Cisco pretende manter a inteligência de controle na infra-estrutura de rede em vez de centralizá-la em um controlador separado, que é a essência do modelo desacoplamento do plano de controle / plano de dados do OpenFlow. O OpFlex procura manter o hardware de infra-estrutura de rede como o elemento de controle fundamental da rede programável em vez de ser apenas um equipamento de encaminhamento da controladora SDN baseada em software.

Essas declarações sobre OpFlex e OpenFlow acabam se baseado em dois modos:

Imperativo = Controladora SDN é sua gerência/gestão e plano de controle, enquanto equipamentos de rede são seu plano de dados.
Declarativo = Controladora SDN é seu plano gerência/gestão, enquanto equipamentos de rede são ambos plano de controle e dados.

No conceito do OpFlex, teriamos o modelo declarativo sendo implementado, que seria o inverso do OpenFlow que estaria se adotando para o modelo imperativo. O projeto OpenDaylight (ODL) está em andamento para definir um modelo de política uniforme, e a Cisco também está trabalhando em um agente OpFlex de código aberto para Open vSwitch (OVS). O objetivo é oferecer três componentes principais para a comunidade:

Implementação de uma política de código aberto
Uma implementação OpFlex do lado da controladora em ODL
Um agente OpFlex do lado do switch para Open vSwitch

Logo abaixo você pode ter um pouco mais detalhamento:

Relacionado a todas essas menções o OpFlex, acaba-se moldando muito perfeitamente para o novo modelo de hierarquia que a Cisco esta trazendo para o mercado, que estaria aplicado para o ACI ( Application Centric Infrastructure ), que seria onde as politicas seriam implementadas para os determinados equipamentos gerenciados. Pensando em familia de equipamentos Cisco, os modelo que suportariam:

Cisco Application Centric Infrastructure, Nexus 9000 Series
Cisco Nexus 1000V
Cisco ASR 9000 Series
Cisco Nexus 7000 Series
Cisco ASA
Cisco SourceFire

No proximo post irei detalhar sobre ACI. Aguardo comentários, críticas e sugestões.

Abs,
Rodrigo

Fonte: http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731304.html