Olá Network Folks !!
Meu nome é Pedro e sou analista SR de redes com foco em Data Centers e Service Providers. Há 2 anos criei o site www.howtonetwork.com.br e posto diversos artigos técnicos sobre diversos temas de routing/switching voltados para esses dois ambientes para ajudar a comunidade técnica que encontra dificuldade de alguns temas especificos em PT/BR e uso referencias de DBZ (Dragon Ball Z) para dar alivio cômico nesses assuntos técnicos rs.
Seguindo com o tema de Cisco ACI, nesse artigo irei explicar um pouco de como é o setup inicial de um fabric ACI do 0 juntamente com algumas configurações para podermos nos familiarizar com essa solução SDN.
Pega o seu café bem forte e vem comigo!
Cisco ACI setup (DAY 0)
Conforme explicado no ultimo artigo(aqui eu dei uma contextualizada sobre programabilidade de rede e de forma introdutória, o que é SDN e a solução ACI), ACI é uma solução SDN direcionada a Data Centers que demandam agilidade operacional e redes programáveis independente de onde o ambiente do cliente esteja(seja em ambiente on-premisses, Cloud only ou multi-cloud).
O ACI trabalha sobre o modelo de Aplication Networks profile. Esse modelo possui toda uma hierarquia na qual tudo visa trabalhar em cima da aplicação da nossa infraestrutura, e não mais em parâmetros como IP e porta. Não se esqueçam, agora estamos no nosso "instinto superior" rs.
Vamos começar o nosso setup? Os steps são:
Realizar toda a ligação física dos equipamentos respeitando a arquitetura CLOS (Spine - Leaf) conforme imagem abaixo.
2. Feita a conexão física, precisamos acessar o nosso APIC e realizar o SETUP preenchendo alguns campos (essa é a única vez que você vai acessar CLI.Após isso, somente via GUI!) que a APIC vai te perguntando. Nesse vídeo ,a Cisco mostra como é simples o preenchimento juntamente com uma imagem do processo de setup da APIC. Como já existe esse procedimento, vou me atentar em explicar somente o que cada campo significa.
Fabric name: Nome do nosso domínio Fabric
Fabric ID: Definir o ID do nosso Fabric
Number of active controllers: Numero de controladoras ativas (podemos ter só 1 ativa e 2 em standby, mas nao muda o fato que precisamos ter 3 APIC's no ambiente)
Standby controller: Numero de controladoras em standby
POD ID: Define o numero do nosso POD (site)
Controller name: Define o nome da nossa controladora
IP address pool for tunnel endpoint addresses: Endereçamento "backbone"da nossa infra.Esse enderecamento sera o nosso underlay (se voce nao sabe o que é underlay e overlay, sugiro que leia esse artigo que escrevi no Cisco Fórum) para que o nosso Overlay (VxLAN) opere. Importante frisar que esse endereçamento seja EXCLUSIVO na sua rede e que seja um range de um /16 até um /23 (A cisco recomenda o uso do /16, tanto que por default o endereçamento vem como 10.0.0.0/16).
VLAN ID for infrastructure network: Vlan que será exclusiva para uso do ACI (a Cisco recomenda o uso da vlan 3967)
IP address pool for bridge domain multicast address (GIPo): Range para ser utilizado no fabric ACI para trafego multicast (a cisco recomenda o uso do range 225.0.0.0/15)
IPv4/IPv6 addresses for the out-of-band management: Endereçamento OOB do APIC
IPv4/IPv6 addresses of the default gateway: Default gateway para a rede de OOB.
Management interface speed/duplex mode: Speed da porta .
Strong password check: Se voce quer utilizar um check de senha (Y ou N).
Password: "A sua senha" (esse passo voce só precisaria definir na primeira APIC. Após provisionar a primeira, a senha que vc definiu nela será a mesma nas demais APIC's do seu ambiente)
E "voilà", subimos nossa APIC e já possuímos acesso a ela conforme abaixo
Feito isso, agora precisamos cadastrar os switches na nossa APIC e subir nosso fabric ACI. Ao acessarmos "Fabric Membership"nos vemos que possuímos um LEAF pendente de cadastro (esse LEAF é o LEAF que está diretamente conectado a essa APIC que estamos acessando.Esse discovery é feito via LLDP). Clique em "Register"e preencha os campos conforme abaixo
Após cadastrar o primeiro LEAF, o LLDP ira descobrir os demais switches do fabric e o processo se repete. Note que eu só precisei informar o nome, o ID e que tipo de node ele é.O IP e toda configuração de underlay/overlay foi configurada AUTOMATICAMENTE!
Vamos ver nossos "meninos?" Para ver o desenho topológico do nosso fabric ACI, nos vamos em Fabric>POD1>Topology
Agora sim! Nosso fabric esta UP com apenas alguns clicks e tudo o que fizemos foi preencher alguns campos e toda a mágica aconteceu.
Construção lógica do ACI.
Agora que nosso fabric ACI esta UP, é hora de entendermos como ele funciona. Acho que a forma mais fácil de explicar, é ir demonstrando como é a parte lógica do ACI campo a campo utilizando o método de 5 steps conforme o print abaixo. Para deixar mais didático, vamos tratar isso como um projeto. Precisamos subir um ambiente de PROD no nosso fabric ACI, e iremos utilizar os 5 steps para realizar esse processo. Vamos começar!
OBS: Não irei abordar o item 5 nesse artigo.
Bom, vamos lá!
1. Create Tenant and VRF (Bridge Domain)
Tenants são grupos lógicos que contem todas as nossas policies (entenda tenant como uma partição do seu ambiente.Você consegue "dividir" o seu ambiente em PROD,DEV e QA por exemplo. São 3 "instancias distintas").
OBS: Por default, o ACI ja possui a Infra Tenant,Management Tenant e a Common Tenant. A Infra Tenant é usada pelo IS-IS Discovery,MP-BGP e é responsável pelo nosso trafego VXLAN e pela auto-configuração e discovery dos nossos devices(o que vimos anteriormente acontecer) e utiliza a VRF Overlay-1 . A Management Tenant é usada para nosso trafego OOB (Out-of-band) e utiliza a VRF OOB/Management e a Common Tenant é a tenant que criamos toda a configuração do nosso ambiente (VRF's,EPG's, Contracts e etc).
Abaixo as tenants default do ACI
No nosso caso, vamos criar uma Tenant chamada PROD e dentro desse Tenant,vamos criar as VRF`s que o ambiente de PROD irá utilizar. Eu recomendo que crie uma Tenant nova ao subir um novo ambiente e/ou clientes e não utilize a Common Tenant.
Podemos ver a tenant "PROD"na lista de tenants do nosso ACI.
Após criarmos nossa tentant e a VRF-PROD, devemos criar um bridge domain e adicionar as subredes. O bridge domain é um domínio L2 exclusivo que contém uma ou mais subredes.Cada bridge domain deve estar vinculado a uma VRF (ou context). Vamos criar então dois Bridge domains, cada um com uma subrede diferente.Para criar, vamos em Tenants>PROD>Networking e clicamos no icone de "Bridge Domain"e arrastamos para dentro da VRF PROD. Feito isso, preenchemos os campos conforme as imagens a seguir
Ao configurarmos o "Gateway address 192.168.10.1" automaticamente estaremos criando o Anycast Gateway em todo o nosso fabric. Agora, independente da onde a maquina esteja conectada, desde que que ela esteja atrelada a um EPG (irei explicar na sequencia o que é) que contenha a VRF PROD, o seu gateway é distribuído para todos os LEAF's do nosso fabric, fazendo que o LEAF que estiver mais próximo da maquina, seja o seu Gateway! Mais um ganho incrível para o nosso DC com essa solução.
Bridge domain PROD_BD e DEV_BD criado com as subnets desses domínios sendo mostradas no canto esquerdo (no nosso caso, redes 192.168.10.0 e 192.168.20.0/24)
2. Application Profiles
São a principal construção que define uma política dentro do ACI.Ele é uma representação gráfica da configuração de rede. Veja o application profile como um "folder"daquela determinada aplicação.
OBS: Dentro do fabric ACI, não configuramos VLAN's, e sim EPG's para segmentar o trafego. As vlans só são "criadas"para auto designar a criação de port-groups nos Hypervisors (ja vou chegar la).
Vamos criar o nosso application profile. Para isso, vá em Tenants>PROD>Application Profiles> + Create Application Profile
Topology do nosso Application Profile - SAP
Criado o nosso Application Profile, é hora de criarmos o nosso EPG e atrela-lo ao nosso application profile SAP.
3. Create and use EPG's
Conforme explicado nesse doc, "EPGs (Endpoint groups) são uma coleção de terminais semelhantes que representam uma camada de aplicativo ou conjunto de serviços.Eles fornecem um agrupamento lógico de objetos que requerem políticas semelhantes.Por exemplo, um EPG pode ser o grupo de componentes que constituem a camada da web de um aplicativo.Os terminais são definidos usando a placa de interface de rede (NIC), NIC virtual (vNIC), endereço IP ou nome do Sistema de Nomes de Domínio (DNS), com extensibilidade para oferecer suporte a métodos futuros de identificação de componentes de aplicativos.EPGs são coleções de um ou mais terminais que fornecem função semelhante" .
Ou seja, ao criarmos um EPG, nos atrelamos ele a um BD (Bridge Domain) e definimos políticas para todo um perfil (profile) que esteja vinculado a esse EPG. Abaixo a criação de um dos EPG's
No nosso caso, criamos dois EPG;s (10-PROD e 20-DEV) e integramos ele com o nosso Hypervisor (no caso, nosso VMWARE). Mas você deve estar se perguntando, porque isso?
Lembra da definição do que é EPG que falamos acima? No momento que eu crio essa integração entre o meu Hypervisor (VMware no caso) e o EPG, o ACI faz uma chamada API no vCENTER e cria os Port-groups dos EPG's que acabei de definir de forma automatizada.
OBS: Bare-metals e Switches legados precisam de mapeamento VLAN-TO-EPG estaticamente.
EX: VLAN 10= EPG WEB
Agora, precisamos garantir a comunicação entre os ambientes e para isso, precisaremos de contratos!
4. Create contracts
Os EPG's possuem duas regras principais:
Hosts que pertencem ao mesmo EPG's podem se comunicar por default (é similar a maquinas que estão no mesmo domínio broadcast).
Hosts que pertencem a EPG's diferentes só conseguem se comunicar com o uso de contratos (Zero-trust).
Abaixo um exemplo para ilustrar como dois hosts mesmo estando na mesma rede (mesmo bridge-domain) , estão em EPG's diferentes e com isso a sua comunicação não ira funcionar.
No nosso cenário, vamos criar um contrato permitindo comunicação ICMP partindo da origem PROD-EPG (no mundo ACI, quem origina a conexão se chama consumer) para o DEV-EPG (no mundo ACI, quem recebe a conexão se chama receiver ou provider).
Para criar o contract, basta na própria "Topology"do APP SAP nos selecionarmos o ícone C (contract) e fazer um link entre os EPG's conforme a imagem abaixo.
Contrato (que é o equivalente a uma ACL) criado e agora os hosts que pertencem a esse EPG conseguem comunicação entre si!Veja que no modo tradicional, teríamos que criar essa ACL nos switches no qual as maquinas estão conectadas, e atrelar essa ACL nessa interface.Porem, e se fizermos um VMotion dessa maquina? E se o host físico mudar de local? Teria que transpor toda a minha regra (ou regras!) para a nova porta, criar a ACL em outro SW...conseguem ver o trabalho e a chance de falha humana?
No ACI, independente da onde essa maquina for, essa regra irá continuar funcionado para ele pois ela e atrelada ao EPG, que por sua vez é atraleada ao VMM Domain do nosso ambiente, da nossa Application profile e por ai segue... uma coisa se correlacionando com a outra(Isso se chama Application-Centric Approach!)
OBS: Por limitações do LAB que eu utilizei, eu nao vou conseguir evidenciar a comunicacao entre as maquinas.
5. L3 Out EPG
E por ultimo, e não menos importante, criamos o L3 Out EPG se nós precisarmos de comunicação L3 com algum prefixo externo do nosso fabric ( roteador MPLS da operadora que realiza a comunicação matriz e filial por exemplo). Nesse caso, nos precisaremos especificar qual LEAF (o LEAF que recebe conexões externas é chamado de BORDER LEAF) e qual porta iremos habilitar o roteamento externo.
Não vou entrar nos detalhes da configuração do L3OUT pois irei entrar em maiores detalhes no artigo que irei escrever sobre migração de rede "legada"para dentro do fabric ACI. Abaixo uma topologia para entender a arquitetura do que acabei de explicar.
Espero que tenha ficado claro e não se preocupe de não entender na primeira leitura pois é realmente uma solução muito disruptiva. O ACI muda o jogo quando pensamos nas redes tradicionais, e o nível de abstração(tudo feito por baixo dos panos de forma automática e só acessamos a GUI) e microssegmentação(a hierarquia de Tenants,contracts,EPG's e App profile)nos fornece é incrível e super necessário nos data centers atuais.
3 Comentários
