Redes de data center dividem-se em duas funções distintas: LAN Ethernet, que transporta aplicações, usuários e tráfego IP, e SAN Fibre Channel, que transporta blocos de armazenamento com requisitos rigorosos de perda, latência e ordenação. Este guia percorre a arquitetura spine-leaf, as abordagens Cisco ACI e Juniper EVPN-VXLAN para a LAN, o Fibre Channel com Cisco MDS e Brocade para a SAN, e como dimensionar, proteger e operar ambos.
Sobre este material: as capacidades citadas variam por modelo, versão de software, licença, óptica, distância e configuração. Valide sempre as matrizes de compatibilidade e os documentos vigentes do fabricante antes da aquisição ou mudança.
LAN e SAN: funções diferentes
A LAN do data center usa Ethernet 10/25/50/100/200/400/800G conforme a plataforma, com VLAN/VRF para segmentação, VXLAN para escalar o overlay e BGP/OSPF/IS-IS no underlay — carregando tráfego leste-oeste, norte-sul, gerenciamento, backup, storage IP e clusters.
A SAN Fibre Channel é dedicada, com WWPN, zoning, name server, FSPF, ISL e VSAN/Virtual Fabric, operando caminhos A/B independentes e multipathing no host; FC-NVMe pode coexistir com FCP quando suportado ponta a ponta.
RoCEv2, iSCSI e NVMe/TCP usam Ethernet para convergir dados de storage e rede, mas pedem desenho próprio de QoS, congestionamento, buffers, PFC/ECN quando aplicável e isolamento operacional — convergência exige cautela, não é um atalho automático.
Spine, leaf, ToR e border leaf
O fabric Clos reduz saltos, distribui capacidade e permite expansão horizontal previsível. O spine é a camada de alta capacidade: cada spine conecta-se a todos os leafs e não recebe servidores diretamente no desenho padrão.
Leaf é a função na arquitetura; ToR descreve a posição física no rack — um leaf pode ser ToR, middle-of-row ou end-of-row. O border leaf faz a transição para WAN, Internet, firewalls, redes legadas, MPLS/EVPN ou outro site, e deve ser dimensionado para o tráfego norte-sul e rotas externas. O service leaf conecta serviços como ADC, firewall, IDS/IPS, DNS e appliances — evite service insertion complexo sem observabilidade e testes de simetria.
Topologia LAN básica: dois spines e três leafs
O padrão que elimina gargalos começa simples: cada leaf conectado a todos os spines, sem conexão direta entre leafs.
Tráfego leste-oeste (servidor para servidor) cruza leaf-spine-leaf; com ECMP, múltiplos caminhos ativos distribuem os fluxos. Tráfego norte-sul sai por um border leaf para firewall, WAN, Internet, balanceador ou rede legada. A perda de um enlace ou spine reduz capacidade, mas não deve interromper a conectividade — regra prática: cada leaf deve ter pelo menos dois uplinks, um para cada spine, com capacidade calculada no pior caso N-1 e cabeamento, ópticas e MTU padronizados em todo o fabric.
Topologia LAN complexa: fabric corporativo redundante
Da borda aos workloads, um fabric corporativo redundante elimina pontos únicos de falha em cada camada.
Nesse desenho, o underlay L3 usa adjacências ponto a ponto, ECMP, BFD e endereçamento /31 ou unnumbered. O overlay VXLAN usa control plane BGP EVPN ou, no ACI, políticas distribuídas pelo APIC. A camada de serviços — border leaf, service leaf, firewall, load balancer e gateways externos — deve ser redundante em cada um desses pontos.
Underlay, overlay e VXLAN
Separar a conectividade física da conectividade lógica facilita escala e automação. O underlay L3 usa links roteados leaf-spine com ECMP para múltiplos caminhos, BGP, OSPF ou IS-IS conforme a arquitetura, BFD para detecção rápida quando suportado, e MTU consistente, endereçamento determinístico e sumarização quando possível.
No overlay VXLAN, VTEPs encapsulam quadros/rotas em VXLAN; VNIs representam segmentos L2 ou VRFs L3, ampliando o espaço além das VLANs. O BGP EVPN distribui informações MAC/IP e prefixos, reduz flooding e habilita multihoming, anycast gateway e mobilidade controlada. Tráfego BUM (broadcast, unknown unicast e multicast) exige política de replicação — monitore o volume e evite domínios L2 maiores que o necessário.
Cisco ACI: arquitetura e objetos
O ACI transforma requisitos de conectividade em políticas aplicadas no fabric Nexus 9000 e orquestradas por controladores APIC. O APIC é um cluster de controladores responsável por inventário, políticas, APIs, health score e integração; spines e leafs Nexus 9000 fazem o encaminhamento distribuído no fabric VXLAN; o Nexus Dashboard adiciona serviços operacionais, visibilidade e orquestração conforme licenciamento.
No modelo de política, um tenant contém VRFs, bridge domains e application profiles; EPGs agrupam endpoints, e contracts definem as relações permitidas entre EPGs. VMM domains, bare metal, L3Out, L2Out, service graphs e conectividade multisite devem ser tratados como blocos de desenho, não apenas objetos de GUI. O ACI não elimina fundamentos de rede: endereçamento, routing, MTU, multicast, QoS, capacidade e domínios de falha continuam essenciais.
ACI: fluxo de política em linguagem simples
A política parte da intenção da aplicação e termina em regras distribuídas nos leafs. Um exemplo típico: tenant ENQ-PROD, VRF VRF-ERP, bridge domains BD-APP e BD-DB; EPG-APP contém os servidores de aplicação, EPG-DB contém os bancos de dados, e um contract ERP-SQL permite somente TCP/1433 de APP para DB.
Endpoints são aprendidos e associados ao EPG; o gateway anycast pode existir nos leafs, e o contrato é aplicado de modo distribuído. O L3Out conecta a VRF a roteadores ou firewalls externos via BGP/OSPF/rotas estáticas, com route control e políticas de importação/exportação. Governança exige nomenclatura, templates, revisão por pares, versionamento e testes — evite objetos órfãos, contratos any-any e dependência de configuração manual.
Cisco ACI: alta disponibilidade e escala
A disponibilidade deve considerar controladores, forwarding, serviços externos e operações. Planeje a quantidade e a distribuição do cluster APIC conforme a escala suportada e o desenho do fabricante — um APIC fora do quorum não deve interromper o forwarding já programado, mas limita mudanças.
Servidores e appliances podem usar vPC para redundância L2; valide LACP, orphan ports, hashing, consistência e o comportamento do equipamento conectado. Multi-Pod estende um único fabric com IPN; Multi-Site coordena fabrics independentes — a escolha muda blast radius, latência, operação e recuperação. Para atualizações, leia release notes, matriz de compatibilidade e caminhos de upgrade, e faça pre-checks, backup de configuração, validação de faults e plano de rollback.
Juniper: fabric EVPN-VXLAN
Na abordagem Juniper, o QFX opera o fabric IP e o BGP EVPN fornece o control plane do overlay; o Apstra pode adicionar intenção, validação e automação. Switches QFX fixos ou modulares atuam como leaf, spine, border e super-spine conforme a escala; o Junos OS traz routing policy, EVPN, VXLAN, telemetry e automação; o Apstra oferece design intent-based, blueprints, assurance e operação multivendor conforme suporte.
Os modelos EVPN incluem VLAN-based, VLAN-aware bundle ou VLAN bundle — a escolha afeta escala, isolamento e operação; Type 2 anuncia MAC/IP, Type 5 anuncia prefixos IP. O EVPN multihoming usa Ethernet Segments e DF election, reduzindo a dependência de MLAG em desenhos suportados. IRB e anycast gateway aproximam o roteamento dos workloads, reduzem hairpin e suportam mobilidade dentro dos limites do desenho.
Juniper: desenho e operação
Um fabric baseado em padrões oferece flexibilidade, mas exige políticas BGP e automação disciplinadas. eBGP underlay é comum pela simplicidade de política e isolamento; iBGP com route reflectors também é possível — o overlay EVPN precisa de address families e políticas consistentes.
Routing Type 5 permite anunciar prefixos IP independentemente de MAC, útil para serviços L3, border leaf e DCI. Para interconexão entre data centers, evite estender L2 sem necessidade — compare EVPN DCI, inter-VRF routing, firewalls e replicação da aplicação, já que latência e domínio de falha importam mais que conveniência. O Assurance do Apstra valida cabos, adjacências, ASN, loopbacks, VNIs, VLANs, IRBs, policies e endpoints contra o blueprint antes e depois de cada mudança.
Cisco ACI x Juniper EVPN-VXLAN
São duas abordagens maduras, com operações diferentes. O ACI é um policy-based fabric com APIC sobre hardware Nexus 9000, onde o APIC mantém a intenção e as políticas, a segmentação usa tenant/VRF/BD/EPG/contract, o gateway é anycast/distributed no leaf, a operação é centrada em GUI/API sobre objetos ACI, e o multisite passa pelo Nexus Dashboard Orchestrator — a escolha favorece quem quer ecossistema ACI e governança integrada.
O Juniper EVPN-VXLAN é um fabric standards-based com BGP EVPN sobre QFX em Junos OS/Apstra, onde o BGP distribui MAC/IP e rotas EVPN, a segmentação usa VRF/VLAN/VNI e políticas de firewall, o gateway é IRB anycast no leaf, a operação é centrada em CLI/API/automação sobre EVPN, e o multisite passa por EVPN DCI, Apstra e desenho específico — a escolha favorece aderência a padrões e flexibilidade. Não existe vencedor universal: a decisão deve ponderar equipe, automação, suporte, interoperabilidade, custo total, roadmap e requisitos de segurança.
Dimensionamento da LAN
Dimensionar significa transformar perfis de tráfego em portas, uplinks, buffers, ópticas, energia e margem de crescimento. Oversubscription é a relação entre a capacidade de portas de servidores e os uplinks do leaf — por exemplo, 48 portas de 25G somam 1,2 Tb/s, contra 6 uplinks de 100G somando 600 Gb/s, uma oversubscription nominal de 2:1.
No cenário N-1, verifique se, com a perda de um spine ou uplink, a capacidade restante atende ao pico aceitável — não use somente a média diária. Perfis de tráfego diferem: virtualização gera muitos fluxos e mobilidade, com foco leste-oeste; storage IP/RoCE traz microbursts, perda, latência e congestionamento; IA/HPC produz elephant flows, all-reduce, rail optimization e job completion time como métricas centrais. Para ópticas e distância, valide velocidade, breakout, FEC, tipo de fibra, potência óptica, alcance, temperatura e compatibilidade do fabricante.
Topologia SAN básica: dual fabric A/B
Duas redes independentes até cada controladora é o desenho de referência da SAN corporativa.
O isolamento é real: fabric A e B não têm ISL entre si, então falhas e mudanças permanecem contidas em uma fabric. O multipathing (MPIO) escolhe caminhos e reage à perda de HBA, link, switch, porta ou controladora. Para zoning, prefira single-initiator/single-target ou single-initiator/multi-target, conforme o padrão do array.
Fibre Channel: conceitos essenciais
FC é uma rede orientada a perda mínima e entrega confiável, com mecanismos próprios de login, nomes, roteamento e controle de fluxo. Em identidade, o WWNN identifica o nó, o WWPN identifica a porta, e o FCID é atribuído após o login no fabric — documente os três no troubleshooting.
Nos logins, FLOGI registra a porta no fabric, PLOGI cria a sessão entre portas, e PRLI negocia o protocolo superior, como FCP ou FC-NVMe. No roteamento e controle, o FSPF calcula caminhos, e buffer-to-buffer credits limitam quantos frames podem ser enviados sem confirmação de buffer disponível. ISLs unem switches do mesmo fabric; trunking agrega enlaces compatíveis — distância e RTT podem exigir credits adicionais.
Cisco MDS: VSAN, zoning e operação
O Cisco MDS 9000 usa NX-OS e oferece segmentação por VSAN, zoning, port-channels FC e telemetria, conforme modelo e licença. A VSAN cria fabrics lógicos independentes sobre a infraestrutura física compartilhada — cada VSAN possui serviços e FSPF próprios, e deve ser usada conscientemente para isolamento.
No zoning, o modo pode ser basic ou enhanced conforme a governança; aliases/device aliases reduzem erros, e zonesets precisam ser ativados na VSAN correta — Smart Zoning pode reduzir entradas de hardware em cenários compatíveis. O port-channel FC agrega ISLs compatíveis, melhorando utilização e resiliência; verifique velocidade, trunking, VSANs permitidas e consistência. Para OAM, Cisco SAN Analytics/telemetry, syslog, SNMP, Call Home e dashboards ajudam a encontrar congestionamento, slow drain e erros físicos.
Brocade: Fabric OS e boas práticas
Brocade oferece switches e diretores Fibre Channel com Fabric OS, zoning, trunking, virtual fabrics e Fabric Vision, conforme plataforma e licença. Virtual Fabrics usa logical switches para separar ambientes e serviços — defina FIDs, base switch e inter-fabric routing somente quando o caso exigir.
No zoning, use aliases consistentes, zone configurations versionadas e peer zoning quando apropriado; mudanças devem ser pequenas, revisadas e reversíveis. O ISL Trunking agrega links compatíveis em trunks para balanceamento em nível de frame — confirme licença, distância, ópticas e requisitos de port group. O Fabric Vision reúne métricas, MAPS, Flow Vision e diagnósticos para detectar degradação, congestionamento e dispositivos slow drain, conforme suporte/licença.
Topologia SAN complexa: core-edge com diretores
Escalar a SAN exige domínios de falha bem definidos e ISLs calculados, não apenas mais portas.
As regras de desenho centrais: separe fabric A e B em switches, alimentação, patch panels, rotas físicas e domínios administrativos; dimensione ISLs pelo pico simultâneo, distância, compressão, créditos de buffer e cenário N-1; evite fabrics excessivamente grandes, limitando o blast radius com virtual fabrics/VSANs quando necessário; e monitore CRC, enc_out, loss of sync, congestion, slow drain, credit zero e latência de E/S continuamente.
Zoning e masking: defesa em profundidade
Zoning controla comunicação no fabric; LUN masking controla apresentação no array — ambos são necessários. O modelo recomendado é uma zona por initiator com um ou poucos targets, o que reduz interferência, facilita auditoria e limita o impacto de mudanças.
Aliases devem carregar ambiente, host, HBA/porta, fabric e função — por exemplo, PRD-DB01-HBAA e AFF01-CTA-P01. O processo de mudança segue: coletar WWPNs de fonte confiável, validar login no fabric antes de criar a zona, alterar somente uma fabric por vez quando possível, e ativar, testar MPIO, observar erros e registrar evidências. Evite zonas all-access, mistura de initiators sem justificativa, targets de arrays diferentes na mesma zona, e remoção simultânea em A/B.
Congestionamento e slow drain
Um dispositivo lento pode reter credits e espalhar congestão pelo fabric, elevando latência e afetando workloads não relacionados. Os sinais incluem credit zero prolongado, timeouts, queueing e latência de E/S; CRC, invalid transmission word, loss of sync/signal e enc_out; e backpressure persistente, frames descartados ou caminhos MPIO instáveis.
No diagnóstico, correlacione host, HBA, driver/firmware, SFP, fibra, porta, ISL, controladora e array — um contador isolado raramente conta toda a história. A correção passa por substituir componentes físicos comprovadamente defeituosos, corrigir firmware/driver, redistribuir carga, e só aumentar ISL/credits quando a causa e o dimensionamento justificarem. A prevenção depende de baselines por porta, alertas por tendência, testes de failover, margens de capacidade e processo rigoroso de compatibilidade.
Automação e infraestrutura como código
Automação deve aumentar consistência e evidência, não acelerar erros. Em APIs e ferramentas, o Cisco ACI oferece REST API, Cobra SDK, Ansible e Terraform providers conforme suporte; a Juniper oferece NETCONF/YANG, PyEZ, gNMI, Ansible, Terraform e Apstra; e Cisco MDS/Brocade oferecem APIs, Ansible, scripts e plataformas de gestão conforme versão.
Um pipeline seguro inclui lint e validação de schema, laboratório, diff, aprovação, janela, execução serial por domínio de falha, health checks e rollback. A fonte da verdade — NetBox/DCIM/CMDB ou repositório versionado — deve guardar IPAM, ASN, portas, ópticas, VLAN/VNI, VRF, zones, WWPN e dependências. Segredos nunca devem ser armazenados em código: use vault, RBAC mínimo, rotação, logs de auditoria e contas individuais.
Segurança da infraestrutura de rede
O plano de gerenciamento é um ativo crítico e deve ser separado, autenticado, monitorado e recuperável. No management plane, use rede OOB independente, AAA central com fallback controlado, TACACS+/RADIUS e MFA onde suportado; SSH, HTTPS e SNMPv3, desativando serviços e cifras legadas; NTP autenticado quando disponível; e RBAC por função com logs imutáveis enviados a SIEM.
No control plane, aplique CoPP/policers, autenticação de adjacências, filtros de peers, TTL security quando aplicável e proteção contra route leaks. No data plane, use microsegmentação, contracts/policies mínimos, VRFs, firewalls e validação de tráfego permitido — criptografia MACsec/IPsec/FC-SP depende do risco e suporte. Para resiliência, mantenha backups exportados, golden configuration, peças sobressalentes, contatos de suporte e exercícios de recuperação.
Observabilidade e SLOs
Disponibilidade não é "ping responde": é preciso monitorar experiência da aplicação, capacidade e saúde por domínio. Na LAN, acompanhe utilização e headroom por link/fila, drops, ECN/PFC quando usados, latência e jitter; neighbors de BGP/EVPN/OSPF/IS-IS, MAC moves, endpoint churn e inconsistências; e ópticas — Rx/Tx power, temperatura, FEC e erros.
Na SAN, acompanhe IOPS, throughput e latência por host/target/LUN; credits, congestionamento, CRC, link resets e slow drain; e o estado de zoneset/config, logins e paths MPIO. Defina SLOs mensuráveis — disponibilidade, tempo de convergência, perda, latência, headroom, prazo de correção e sucesso de mudanças — e garanta que mudanças, alertas, fluxos, inventário e tickets compartilhem timestamp, ativo e serviço afetado para permitir correlação real.
Plano de implantação em oito etapas
Implante por ondas pequenas e verificáveis, mantendo sempre um caminho de retorno testado. Nas etapas 1–2 (descoberta e HLD), levante requisitos, aplicações, tráfego, latência, segurança, crescimento, RTO/RPO, sites e integrações, produzindo um HLD com decisões e alternativas.
Nas etapas 3–4 (LLD e staging), defina port maps, IPAM, ASN, VLAN/VNI, VRF, políticas, zoning, ópticas, cabos, energia, configuração, testes e MOP, montando e atualizando equipamentos fora da produção. Nas etapas 5–6 (piloto e migração), comece por um serviço não crítico, valide falhas e observabilidade, e migre em lotes com critérios de go/no-go e checkpoints. Nas etapas 7–8 (estabilização e handover), acompanhe baselines, corrija desvios, atualize documentação, treine as operações, registre o as-built e aceite formalmente o ambiente.
Checklist de aceitação LAN
Use esta lista como ponto de partida, adaptando-a aos padrões e riscos do ambiente. No físico: racks, RU, airflow, A/B power, aterramento, cabos e etiquetas conferidos; ópticas compatíveis, com níveis Tx/Rx e FEC dentro do esperado. No underlay/overlay: todos os links e neighbors up, ECMP instalado, MTU e BFD testados; VNIs/VLANs/VRFs/gateways/EPGs/contracts validados, sem flooding ou MAC moves anormais.
Na resiliência: falha de link, leaf, spine, fonte e peer testada sob carga representativa; border/firewall/LB com simetria e convergência comprovadas. Na operação: backup, OOB, AAA, NTP, DNS, syslog, SNMP/telemetria e alertas funcionais; dashboards, runbooks, as-built, inventário e suporte entregues.
Checklist de aceitação SAN
Cada caminho deve ser testado isoladamente e em combinações de falha plausíveis. No fabric: A/B fisicamente independentes, domain IDs/FIDs/VSANs corretos, ISLs e trunks saudáveis, sem CRC, loss of sync, credit starvation ou congestionamento persistente. Em hosts e arrays: WWPNs, HBA firmware/driver e array interoperability confirmados; zoning e masking revisados, com todos os paths MPIO ativos/otimizados conforme política.
Nos testes: remoção controlada de uma fabric sem interrupção da aplicação; failover de controladora, porta, HBA e ISL conforme matriz de testes; desempenho e latência dentro do baseline em carga normal e pico. Na governança: backups, aliases, zonesets/configs, port maps e as-built versionados; runbook de slow drain, falha física e mudança de zoning aprovado.
Conclusão
Redes de data center bem projetadas separam responsabilidades com clareza: a LAN carrega aplicações e usuários sobre um fabric spine-leaf redundante, com Cisco ACI ou Juniper EVPN-VXLAN como abordagens maduras e distintas; a SAN carrega blocos de armazenamento sobre Fibre Channel com Cisco MDS ou Brocade, isolada em dual fabric A/B. Convergência com Ethernet — RoCEv2, iSCSI, NVMe/TCP — é possível, mas exige desenho próprio de QoS e isolamento, não é um atalho.
O valor real aparece quando dimensionamento, redundância, automação, segurança e observabilidade são tratados como um único sistema, testados sob falha real antes de entrar em produção — não como escolhas isoladas feitas em momentos diferentes do projeto.