AP Filter: Automação na Configuração de Access Points

A evolução das redes wireless trouxe consigo uma crescente demanda por escalabilidade, flexibilidade e automação. Em ambientes corporativos com dezenas, centenas ou até milhares de Access Points (APs), a atribuição manual de configurações pode se tornar impraticável. É nesse cenário que o recurso AP Filter se destaca nas controladoras Cisco Catalyst 9800, permitindo uma configuração automatizada, inteligente e baseada em regras de correspondência usando expressões regulares (regex).


O que é o AP Filter?

O AP Filter é um mecanismo que permite atribuir automaticamente as três principais tags da arquitetura baseada em tags da Catalyst 9800:

  • Policy Tag
  • Site Tag
  • RF Tag

Essas tags controlam como o AP atua, quais políticas são aplicadas e como o rádio é configurado. Com o AP Filter, essas associações são feitas com base em regras de correspondência com nomes de AP, sem necessidade de intervenção manual por AP.finidos pelo administrador, sem necessidade de intervenção manual por AP.


Como funciona

O mecanismo avalia o nome do AP no momento em que ele se registra na controladora (Join) e verifica se existe alguma regra de AP Filter configurada. Caso exista, a controladora aplica a combinação de tags definida na regra.

Caso nenhuma regra seja satisfeita, o sistema aplica as tags definidas como default.


Condições de Correspondência (Match Conditions)

As regras usam expressões regulares (regex) aplicadas ao nome do AP (AP Name) como base de correspondência.

Você pode usar expressões como:

  • ^RJ-.* → corresponde a qualquer nome de AP que começa com “RJ-“
  • .*C9136.* → corresponde a nomes que contenham “C9136”
  • .*-HOSP-[0-9]{2}$ → corresponde a nomes terminando em “-HOSP-01”, “-HOSP-99”, etc.

Essas condições são altamente úteis para aplicar políticas por região, por modelo de AP, ou por qualquer outro critério lógico de agrupamento.gião, por modelo de AP, ou por qualquer outro critério lógico de agrupamento.


Estrutura de uma Regra

Cada regra de AP Filter possui:

  • Expressão regular (Regex)
  • Associação de Tags (Policy Tag, Site Tag e RF Tag)
  • Prioridade (ordem na lista de filtros, de cima para baixo)

A ordem de avaliação respeita a ordem das regras na lista: a primeira correspondência válida é aplicada.


Configuração via GUI

A interface gráfica da controladora Catalyst 9800 facilita a configuração dos AP Filters:

  1. Navegue até:
    • Configuration > Tags & Profiles > Tags > AP > Filter
  2. Clique em Add
  3. Defina a expressão regular para o nome do AP
  4. Associe as tags desejadas (Policy, Site, RF)
  5. Reorganize a prioridade das regras, se necessário
  6. Salve e aplique

Exemplo prático

Vamos imaginar o seguinte cenário: você tem APs em diferentes cidades do Brasil. Para automatizar o comportamento esperado, você cria filtros como:

Regex Match ConditionPolicy TagSite TagRF Tag
^SP-.*pt_spst_sprf_sp
^RJ-.*pt_rjst_rjrf_rj
.* (padrão genérico)pt_defaultst_defaultrf_default

Resultado: assim que o AP “SP-AP01” se registra, a controladora automaticamente associa as tags da primeira regra com correspondência.


Exemplos com Expressões Regulares (Regex)

A AP Filter suporta regex como método avançado de correspondência, permitindo maior controle em ambientes com regras complexas de nomeação. Veja alguns exemplos:

Regex Match ConditionPolicy TagSite TagRF Tag
^NE-[A-Z]{2}-\d+pt_nest_nerf_ne
.*C9130AX[E,I].*pt_modelst_modelrf_model
.*-HOSP-[0-9]{2}$pt_hospst_hosprf_hosp

Explicando alguns padrões:

  • ^NE-[A-Z]{2}-\d+ → corresponde a nomes como NE-BA-01, NE-PE-10
  • .*C9130AX[E,I].* → corresponde a qualquer AP modelo C9130AXE ou C9130AXI
  • .*-HOSP-[0-9]{2}$ → identifica APs localizados em hospitais com nomes como AP-SP-HOSP-01

Dica: Teste suas expressões em ambientes de homologação antes de aplicá-las em produção.


Benefícios do uso de AP Filter

  • Escalabilidade: elimina a necessidade de atribuição manual em ambientes grandes
  • Agilidade: APs entram na rede já com as configurações corretas
  • Padronização: garante consistência por localização, modelo ou outro critério
  • Automação: facilita integração com processos de PnP (Plug and Play)

Boas práticas

  • Use nomenclatura de APs consistente para facilitar o uso de regex
  • Priorize regras específicas antes das genéricas
  • Sempre configure uma regra genérica como fallback
  • Documente suas regras para manter clareza na operação

Conclusão

O AP Filter representa um avanço significativo na automação e escalabilidade da infraestrutura wireless com Cisco Catalyst 9800. Em vez de depender de configuração manual, a controladora toma decisões inteligentes com base em expressões regulares definidas pelo administrador. Isso resulta em uma gestão mais eficiente, menos propensa a erros e alinhada com as melhores práticas de redes corporativas modernas.

Com o uso inteligente do AP Filter, sua rede wireless está pronta para crescer de forma organizada, segura e automatizada.

Certificados no Cisco ISE: Entenda seu Papel e Importância

Quando falamos em segurança com o Cisco ISE (Identity Services Engine), estamos falando sobre confiança. E em um ambiente digital, a confiança é estabelecida por certificados digitais, que validam identidades e garantem comunicações criptografadas.

Neste artigo, vamos explorar por que os certificados são essenciais no Cisco ISE, quais tipos existem, como configurá-los corretamente e como evitar os erros mais comuns.

Por que o Cisco ISE depende de certificados?

O Cisco ISE é uma plataforma central de controle de acesso à rede, onde múltiplos elementos se comunicam: endpoints, switches, controladoras wireless, servidores, navegadores, AD, MDM, etc.

Para que todas essas comunicações ocorram com segurança e confiança, é necessário:

  • Provar a identidade das partes envolvidas (ex: o servidor ISE precisa provar que é legítimo)
  • Garantir que a comunicação seja confidencial (criptografia de dados)
  • Assegurar a integridade das mensagens (nada foi alterado no caminho)

Essas três propriedades são garantidas por certificados digitais baseados em criptografia de chave pública (PKI).


Principais tipos de certificados no Cisco ISE

1. Certificado do Servidor ISE (EAP/HTTPS)

Esse é o certificado mais crítico do ISE. Ele é apresentado:

  • Durante a autenticação 802.1X com EAP-TLS, PEAP ou EAP-FAST
  • Na interface de administração web (https://ise.company.com)
  • Em portais como Guest, BYOD e Self-Service

Impactos práticos:

  • Se o certificado estiver expirado, o processo de autenticação falha
  • Se o nome no certificado não corresponder ao FQDN do servidor, o navegador exibirá erros
  • Se o certificado for autoassinado e não confiável, os endpoints rejeitarão a conexão (a não ser que confiem na raiz manualmente)

Dica prática: Use um certificado de CA interna para EAP, e um certificado de CA pública para portais.

A figura abaixo descreve o processo de criptografia quando há comunicação com o portal de Admin.

Já a figura abaixo, apresenta o processo de criptografia para cada possível processo EAP.

  • PEAP
  • EAP-TLS
  • EAP-TTLS
  • EAP-FAST
  • TEAP

Com métodos EAP tunelados, como PEAP e FAST, o protocolo TLS (Transport Layer Security) é usado para proteger a troca de credenciais. Assim como ao acessar um site HTTPS, o cliente estabelece a conexão com o servidor, que apresenta seu certificado ao cliente. Se o cliente confiar no certificado, o túnel TLS é formado. As credenciais do cliente não são enviadas ao servidor até que esse túnel seja estabelecido, garantindo assim uma troca segura. Em uma implantação de Acesso Seguro, o cliente é um solicitante e o servidor é um nó do ISE Policy Services.


2. Certificados para Portais Web (Guest, BYOD)

Os portais web hospedados pelo ISE (como guest.company.com) exigem certificados válidos e confiáveis para HTTPS.

Recomendado:

  • Usar certificados wildcard públicos (*.company.com)
  • Configurar um nome DNS válido e resolvível para o portal
  • Garantir que o navegador do usuário confie na CA emissora

Evite o uso de certificados autoassinados para portais, pois geram alertas nos navegadores e criam desconfiança no usuário final.


3. Certificados internos para comunicação entre nós ISE

O Cisco ISE pode ser composto por vários nós com funções distintas:

  • Admin Node
  • Policy Service Node (PSN)
  • Monitoring Node
  • pxGrid Node

A comunicação entre esses nós é autenticada via certificados. Esses certificados também são usados em:

  • Sincronização de dados
  • Replicação de logs
  • pxGrid (publish/subscribe)

Boas práticas:

  • Use certificados válidos com FQDN correto
  • Use uma CA corporativa e renove antes da expiração
  • Certifique-se de que a cadeia de certificados está completa (raiz + intermediária)

4. Quais valores de certificado devem ser usados em uma implantação do ISE?

Aqui vamos abordar os três modelos recomendados para uso de certificados em um ambiente ISE distribuído.

Modelo 1: Um certificado por nó (multiuso)

  • Descrição: Cada nó do ISE (PAN, PSN, MnT) usa um único certificado para múltiplos serviços — administração, EAP, portal e pxGrid.
  • Requisitos do certificado:
    • CN (Common Name): deve ser o FQDN do nó (ex: psn1.company.com).
    • SAN (Subject Alternative Name): incluindo:
      • FQDN do próprio nó
      • FQDN dos portais (guest, sponsor, mydevices) servidos por esse nó
    • Deve incluir extensões EKU (Extended Key Usage) para:
      • Server Authentication (todos os nodes)
      • Client Authentication (fundamental para uso em pxGrid)
  • Vantagens: simplifica o gerenciamento, pois utiliza apenas um certificado multiuso por nó.

Modelo 2: Certificados separados por serviço, por nó

  • Descrição: Cada serviço (Admin, EAP, Portal, pxGrid) em um nó tem seu próprio certificado.
  • Requisitos do certificado:
    • Admin: CN = FQDN do nó.
    • EAP: CN pode ser o nome do nó ou um nome genérico, como eap.company.com.
    • Portal (Sponsor / MyDevices / Guest): CN = nome específico do portal (sponsor.company.com).
    • pxGrid: deve ter EKUs para Server e Client Authentication.
  • Vantagens: oferece maior isolamento entre serviços, útil para cenários que exigem segregação de funções ou políticas distintas.

Modelo 3: Certificado Único em Todos os PSNs

  • Este método utiliza o mesmo par de chaves pública e privada em todos os nós ISE. Geralmente, é usado em ambientes com muitos dispositivos do tipo BYOD. O principal motivo para seguir este modelo é garantir que o mesmo certificado seja usado em todas as PSNs; assim, os dispositivos BYOD já confiarão em qualquer servidor EAP no qual precisem se autenticar.
  • Para realizar este método, gere uma solicitação de assinatura de certificado (CSR) em um único nó ISE. Após vincular o certificado assinado à chave privada, exporte o par de chaves resultante e importe-o em todos os outros nós. Configure o certificado único para:
    1. O CN do Certificado conterá um único FQDN, como ise.company.com
    2. O Subject Alternate Name do Certificado conterá:
      • O Subject CN, como ise.company.com
      • FQDN real de cada nó ISE como entradas SAN
      • Nome amigável para o Sponsor Portal
      • Nome amigável para o Mydevices Portal

Comparativo entre os modelos

ModeloSimplicidadeEscalabilidadeComplexidade de gestão
Certificado multiuso por nóAltaBoaMédia
Certificados por serviçoBaixaAltaAlta
Certificado Único em Todos os PSNsMuito altaAltaBaixa

Autoridades Certificadoras: CA Pública x CA Interna

O certificado do ISE deve ser confiável pelo cliente — isso exige que a CA que o emitiu esteja no repositório de confiança do sistema cliente (Windows, macOS, Android, etc.).

Comparativo:

CritérioCA PúblicaCA Interna
Reconhecida por padrão✅ Sim❌ Não (precisa importar a raiz)
Ideal para portais web✅ Sim⚠️ Pode gerar alerta no navegador
Ideal para EAP-TLS✅ Sim (mas caro)✅ Sim (usado via GPO ou MDM)
Custo$ (certificados pagos)Grátis, mas requer gerenciamento

O que é um certificado wildcard?

Um certificado wildcard é um tipo de certificado digital SSL/TLS que utiliza um caractere curinga (*) no campo Common Name (CN) ou no Subject Alternative Name (SAN). Ele é utilizado para proteger múltiplos subdomínios dentro de um mesmo domínio principal.

🔹 Exemplo prático:

  • CN: *.empresa.com
  • Este certificado é válido para:
    • guest.empresa.com
    • sponsor.empresa.com
    • mydevices.empresa.com
    • ise1.empresa.com
    • vpn.empresa.com

Mas não é válido para:

  • sub.guest.empresa.com (nível adicional de subdomínio)
  • empresa.net (domínio diferente)

Uso de certificados wildcard no Cisco ISE

No Cisco ISE, os certificados wildcard são comumente usados para proteger portais web, como:

  • Guest Portal
  • BYOD Portal
  • Self-Service/MyDevices Portal
  • Portais de Sponsor

Isso porque esses portais geralmente operam em subdomínios como guest.empresa.com, sponsor.empresa.com, etc.

Vantagens:

  • Simplifica o gerenciamento: apenas um certificado cobre todos os portais
  • Reduz custos: ao invés de emitir múltiplos certificados por subdomínio
  • Flexibilidade: ao adicionar novos portais ou PSNs, o mesmo certificado pode ser reaproveitado

Limitações e recomendações:

  • EAP-TLS e certificados wildcard:
    Alguns clientes (como Windows e certos supplicants) podem não aceitar certificados wildcard durante a negociação EAP, especialmente em ambientes mais restritivos ou quando o nome do servidor precisa ser validado contra o CN exato.
  • Uso em pxGrid:
    pxGrid exige que o certificado tenha o nome exato do host (FQDN) no CN ou no SAN. Certificados wildcard não são recomendados para pxGrid.
  • Associação correta no ISE:
    O certificado deve ser associado ao serviço de portal web, não ao EAP ou pxGrid.

Resumo — Quando usar certificado wildcard no ISE?

Caso de usoWildcard é recomendado?
Portais Web (Guest, BYOD)✅ Sim
Interface de Admin (HTTPS)⚠️ Sim, mas com atenção
EAP (PEAP, EAP-TLS)⚠️ Depende do supplicant
pxGrid❌ Não recomendado

Gerenciamento de Certificados no ISE

Onde gerenciar:

Administration > System > Certificates

Você pode:

  • Gerar CSR para envio à CA
  • Importar certificados assinados (usando o CSR anterior)
  • Importar cadeias completas (Root + Intermediate)
  • Associar certificados a serviços específicos, como EAP Authentication, Admin Portal, pxGrid, etc.
  • Monitorar a expiração automática com alertas de renovação

Boas práticas:

  • Tenha um plano de renovação periódica (scriptado ou manual)
  • Use nomes FQDN corretos nos certificados
  • Certifique-se de que o campo SAN contenha o nome DNS correto
  • Evite reusar o mesmo certificado para múltiplos serviços (a não ser que seja wildcard)

Conclusão

O Cisco ISE é uma solução poderosa e flexível de controle de acesso à rede — mas sua segurança e funcionalidade dependem fortemente de uma infraestrutura de certificados digitais bem planejada.

Ao longo deste artigo, vimos que os certificados não são apenas um requisito técnico, mas um pilar fundamental para garantir identidade, confiança e comunicação segura entre o ISE, os dispositivos de rede, os usuários e os sistemas externos.

Seja na autenticação EAP-TLS, no acesso aos portais Guest/BYOD, na integração via pxGrid, ou na administração web — tudo passa pela confiança em certificados válidos, corretamente emitidos, distribuídos e associados.

A escolha entre um certificado por nó, por serviço ou compartilhado deve ser guiada pelo equilíbrio entre simplicidade operacional, escalabilidade e segurança. O uso de certificados wildcard pode facilitar o gerenciamento de portais web, mas deve ser feito com cuidado em cenários que envolvam autenticação EAP ou integração com pxGrid.

Caso queira entender mais a fundo sobre os certificados no ISE, recomendo a leitura do seguinte material:

https://community.cisco.com/t5/security-knowledge-base/how-to-implement-digital-certificates-in-ise/ta-p/3630897

Como Utilizar Dicionários no Cisco ISE para Políticas Eficazes

Ao trabalhar com políticas no Cisco ISE, é comum utilizar atributos como grupos de usuários, SSID, tipos de dispositivos ou status de postura. Mas o que poucos administradores compreendem a fundo é de onde vêm esses atributos e como o ISE os organiza.

A resposta está nos dicionários do Cisco ISE — componentes essenciais que estruturam toda a lógica de decisão da plataforma. Neste artigo, você vai entender o que são esses dicionários, como utilizá-los e por que dominá-los torna a administração do ISE muito mais eficiente e segura.


O que são dicionários no Cisco ISE?

No Cisco ISE, um dicionário é uma coleção de atributos relacionados a uma fonte específica de dados, como o RADIUS, Active Directory, posture ou profiling. Esses dicionários são usados para criar condições em regras de autenticação, autorização, perfil de dispositivos e outras funcionalidades da plataforma.

Você pode pensar em um dicionário como uma “tabela de atributos” que o ISE consulta para entender o contexto da conexão ou a identidade do usuário/dispositivo.


Tipos de Dicionários no Cisco ISE

1. System Dictionary

Contém atributos internos do próprio ISE, como ISE Device, EndPointPolicy, AuthenticationStatus, entre outros. São amplamente usados para condições administrativas e controle interno.

2. RADIUS Dictionary

Lista atributos padrão definidos pelo protocolo RADIUS, como:

  • Radius:Calling-Station-ID
  • Radius:NAS-Port-Type
  • Radius:Framed-IP-Address

Esses atributos são usados frequentemente em políticas que analisam dados de portas, switches, SSIDs, entre outros.

3. Active Directory / LDAP Dictionaries

Quando o ISE se integra com um diretório externo (como o AD), ele importa um conjunto de atributos, como:

  • AD:MemberOf (grupo de segurança)
  • AD:sAMAccountName
  • AD:Department
  • LDAP:Title, LDAP:Manager

Esses atributos permitem decisões baseadas em identidade corporativa.

4. Posture and AnyConnect Dictionaries

Utilizados quando o ISE trabalha com avaliação de postura (NAC), especialmente com o agente Cisco AnyConnect. Exemplos:

  • Posture:Status
  • Cisco-AV-Pair: posture-token
  • ClientVersion, OS, AVCompliance

5. Profiling Dictionary

Contém atributos coletados automaticamente pelo mecanismo de profiling do ISE, como:

  • DeviceType
  • DeviceFamily
  • Manufacturer
  • OperatingSystem

Usados para identificar e classificar dispositivos conectados (impressoras, IP phones, câmeras, etc.).

6. Custom Dictionaries (Personalizados)

O administrador pode criar dicionários personalizados para suportar atributos específicos de aplicações ou extensões externas via pxGrid, scripts, APIs ou integração com firewalls.


Como os dicionários são usados nas políticas?

Os atributos presentes nos dicionários são utilizados ao criar condições dentro das Authentication ou Authorization Policies. Veja alguns exemplos práticos:

Exemplo de condição (IF)Fonte do atributo
Radius:Calling-Station-ID = "Corp-WiFi"RADIUS Dictionary
AD:MemberOf = "TI"Active Directory Dictionary
Posture:Status = CompliantPosture Dictionary
Endpoint:DeviceType = "Smartphone"Profiling Dictionary
LDAP:Department = "Financeiro"LDAP Dictionary

Essas condições permitem ações como: atribuir VLANs, aplicar SGTs, redirecionar para portais, bloquear acesso ou enviar CoA (Change of Authorization).


Onde visualizar e gerenciar dicionários no ISE?

Você pode acessar os dicionários e seus atributos em:

Menu:
Policy > Policy Elements > Dictionaries

Nessa tela é possível:

  • Explorar todos os dicionários disponíveis
  • Ver os atributos disponíveis (nome, tipo, permissões)
  • Adicionar dicionários personalizados
  • Mapear novos atributos de um AD/LDAP

Importante: Nem todos os atributos são editáveis. A maioria dos dicionários padrão é de leitura apenas, mas os personalizados permitem configuração total.


Exemplos práticos

1. Usando um dicionário AD em uma regra

Objetivo: aplicar uma VLAN específica para usuários cujo campo Department no AD seja igual a “Segurança”.

Passo a passo:

  1. Verifique se o atributo Department foi mapeado na integração com o AD.
  2. Vá em Policy > Policy Sets > Authorization Policy
  3. Crie uma condição: IF AD:Department EQUALS "Segurança" THEN Apply VLAN 60 + SGT “Security”

Simples e altamente eficaz. Você está aplicando segmentação baseada em um campo organizacional real, sem depender de múltiplos grupos de AD.

2. Adicionando um Dicionário RADIUS de um Fabricante Externo no Cisco ISE

Em muitos cenários de integração — como com firewalls Palo Alto, Fortinet, F5, Aruba, etc. — é comum que esses dispositivos utilizem atributos RADIUS proprietários ou Vendor-Specific Attributes (VSAs) para enviar dados adicionais em pacotes RADIUS.

Por padrão, o Cisco ISE reconhece os atributos mais comuns do protocolo. No entanto, se você quiser consumir atributos personalizados de outro fabricante, precisará importar ou criar um dicionário RADIUS específico para esse vendor.

Exemplo de uso:

Você deseja criar uma regra no ISE baseada em um atributo específico enviado por um firewall Palo Alto, como PaloAlto-User-Group.

Passo a passo: como adicionar um dicionário RADIUS personalizado

  1. Acesse o menu de dicionários:
    No ISE 3.1 ou superior, vá em:
    Policy > Policy Elements > Dictionaries > RADIUS > RADIUS Vendors
  2. Clique em “Add” (Adicionar)
  3. Preencha os campos principais:
    • Vendor Name: nome do fabricante (ex: PaloAlto)
    • Vendor ID: o ID atribuído pelo IANA (ex: 25461 para Palo Alto)
    • Vendor Type: selecione RADIUS
    • Clique em Submit
  4. Adicione os atributos específicos do vendor:
    Após criar o dicionário, clique sobre ele e vá em “Attributes” > “Add”. Exemplo de atributo:
    • Name: PaloAlto-User-Group
    • Attribute ID: conforme a documentação do fabricante (ex: 1)
    • Data Type: String, Integer, Boolean, etc.
    • Length: se necessário
    • Direction: geralmente “Input” (se o ISE vai ler esse valor)
    Clique em Submit para salvar o atributo.
  5. Usar o novo atributo em políticas:
    Agora que o atributo faz parte de um dicionário válido, você pode utilizá-lo em condições dentro de Authorization Policies, exatamente como faria com um atributo RADIUS nativo.

Onde obter os detalhes dos atributos?

Consulte a documentação oficial do fabricante (Palo Alto, Fortinet, etc.) para obter:

  • O Vendor ID (IANA)
  • A lista de atributos disponíveis
  • Os Vendor-Specific Attribute IDs e seus tipos

Exemplo:
O Vendor ID da Palo Alto Networks é 25461. Um dos atributos mais usados é o PaloAlto-User-Group, que pode ser utilizado para segmentação baseada em grupos de usuários na rede.

Benefícios dessa integração

Facilita a integração com soluções de segurança de terceiros em ambientes heterogêneos

Permite que o ISE reconheça e atue com base em atributos personalizados enviados por firewalls, proxies ou NACs externos

Expande a capacidade de decisões contextuais com dados além do AD ou RADIUS padrão

Conclusão

Os dicionários no Cisco ISE são mais do que uma lista de atributos — eles são a base para políticas inteligentes, dinâmicas e contextuais.
Ao dominar seu uso, você:

  • Cria regras mais precisas e alinhadas ao negócio
  • Reduz erros ao aplicar permissões
  • Ganha flexibilidade para integrações com AD, firewalls, posture e profiling
  • Torna sua rede mais segura e automatizada

Designing Enterprise Campus LAN – Parte 1

Uma série em que abordaremos os conceitos para elaborar um design eficiente e confiável para redes LAN.

Nessa série de artigos divididos em três partes, falaremos sobre design de uma rede Enterprise Campus LAN, a importância de criar um design eficiente e confiável para operação da rede local. Abordaremos os conceitos de uma rede tradicional em layer 2 e a diferença para o design routed access puramente em layer 3.

Introdução

Switches de camada 2 (ou switches L2) são frequentemente utilizados como meio de prover conectividade entre os clientes e a rede local. Toda segmentação do ambiente a nível de camada 2 (local area networks ou simplesmente LAN) são efetuadas nestes equipamentos.

Switches de camada 3 (switches L3) são basicamente roteadores com o “fast forwarding” feito via hardware. O encaminhamento de pacotes envolve a pesquisa de melhor rota, o decremento da contagem do TTL (time to live), o recalculo do checksum e o encaminhamento do quadro com o apropriado cabeçalho MAC para a correta porta de saída.

De forma implícita, acabamos assumindo que switches layer 3 também operam como switches Layer 2, mas isso nem sempre é verdade.

Vamos entender como combinar os switches Layer 2 e Layer 3 em um modelo de Enterprise Campus LAN.

Campus LAN – Endo-to-end VLANs ou Local VLANs

Dois dos principais modelos de design em Campus LAN são end-to-end VLANs e Local VLANs. Vamos entender como cada um desses dois modelos funcionam.

  • End-to-End VLANs: Modelo em que todas as VLANs são distribuídas e disponíveis em todos os switches do Campus. Neste modelo, faz-se necessário o uso de ferramentas como o STP (spanning-tree) para prevenção de loops. Nesse modelo, os usuários tem acesso a suas respectivas VLANs independentemente de sua localização física no Campus. O termo end-to-end VLANs faz referência ao fato de uma única VLAN estar presente em múltiplos switches através da rede do Campus.
  • Local VLANs: Neste modelo, os usuários são agrupados em VLANs dependendo de sua localização física, se um usuário move de um local para outro no campus, a VLAN que o mesmo irá utilizar será diferente. Neste caso, switches Layer 2 são utilizados para prover acesso ao usuário, já na camada de distribuição, o roteamento entre VLANs é efetuado para que o usuário consiga acessar os recursos necessários na rede.

End-to-end VLANs e Local VLANs são dois tipos de design, durante a fase de planejamento você pode optar por utilizar um mix de ambos.

End-to-End VLANsLocal VLANs
Pros:
– Todas as VLANs estão disponíveis em todos os switches do Campus;
– Mesmas políticas (QoS, segurança) são aplicadas aos usuários, independente de sua localização geográfica dentro do Campus.
Pros:
– Modelo de design mais escalável;
– Troubleshooting pode ser simplificado;
– Caminhos redundantes podem ser facilmente criados.
Contras:
– Todos os switches precisam estar configurados com todas as VLANs;
– Mensagens de broadcast trafegam por todos os switches;
– Troubleshoot pode ser um desafio neste ambiente.
Contras:
– São necessários mais equipamentos com características de roteamento (switches L3).

No modelo de end-to-end VLANs, você deve levar em consideração que todos os switches trafegam dados de todas as VLANs, mesmo que não haja um usuário conectado a uma determinada VLAN em algum switch do Campus. Por este motivo, efetuar troubleshooting neste tipo de ambiente pode ser um problema, pois, o tráfego de uma simples VLAN atravessa múltiplos switches no Campus.

Já no modelo de design de Local VLANs, as VLANs que são utilizadas para a camada de acesso não devem ser estendidas além do switch de distribuição. Este modelo de design pode mitigar muitos problemas, além de prover vários benefícios como:

  • Determinar o caminho do tráfego: Este modelo provê de forma mais previsível o tráfego entre o switch L2 e o switch L3. Em uma eventual falha, a simplicidade do modelo permite facilita com que o problema seja isolado e rapidamente identificado.
  • Caminhos redundantes: Com a implementação do STP (aqui considere as diferentes versões do STP como, RSTP, PVST, MST) é possível utilizar todos os links de interconexão entre o switch L2 e o switch L3 e utilizar caminhos redundantes.
  • Menor ponto de falhas: Se a VLAN é local a um determinado bloco da rede e o número de usuários atrelados a essa VLAN é pequeno, uma eventual falha no layer 2 dessa VLAN acabará por impactar um número baixo de usuários.
  • Design Escalável: Permite um design muito mais escalável, a incorporação de novos switches ou adição de novas VLANs no ambiente de forma muito mais simples.

O modelo tradicional de Layer 2

Em um design hierárquico tradicional, o bloco de distribuição usa uma combinação protocolos e serviços de camadas 2, 3 e 4 para prover convergência, escalabilidade, segurança e gerenciamento. Neste modelo, os switches de acesso são configurados como switches L2 e encaminham o tráfego através de uplinks com os switches de distribuição através de portas configuradas como trunks. Já os switches de distribuição são configurados para suportar o encaminhamento em L2 para os switches de acesso e também encaminhamentos em L3 para a camada superior, que é o core da rede.

Neste modelo tradicional de Layer 2, a demarcação entre as camadas de L2/L3 fica a cargo dos switches de distribuição. Eles atuam o default gateways para as redes (VLANs) que são criadas no ambiente e com o encaminhamento em L3 para a camada superior. Duas características deste modelo de design:

  • 1º: É que não é possível alcançar de forma verdadeira o balanceamento de carga entre os links, já que o STP irá bloquear caminhos redundantes. Balanceamento de carga é efetuado através de manipulação do STP e FHRP (First Hop Redundancy Protocol), enviando o tráfego de diferentes VLANs em diferentes links, porém, manipulação manual do STP e FHRP não é uma forma verdadeira de efetuar balanceamento de carga.
  • 2º: O tempo de convergência da rede pode ser alto. Implementações do STP como RSTP tornam o tempo de convergência da rede mais rápido, mas isso só é possível alcançar com um bom nível de design de roteamento hierárquico e ajustando-se os tempos de convergência do FHRP.

Modelo de layer L2 atualizado

Neste modelo, as VLANs ainda são terminadas nos switches de distribuição (os switches continuam atuando como default gateways). A diferença é que não há mais links bloqueados através do STP. O uso de features como StackWise virtual, presente em switches da séries Catalyst 9500 por exemplo, permite que que dois switches operem logicamente como um único equipamento.

Aqui, o STP passa a atuar apenas para prevenção de conexões erradas de cabeamento, o etherchannel criado entre os switches de acesso e a camada de distribuição passa a oferecer o balanceamento de tráfego entre os links e o uso de FHRP não é mais necessário. Tudo isso resulta em um tempo de convergência muito melhor se comparado ao modelo tradicional de design em L2.

Descrevendo o modelo de acesso em Layer 3

Uma alternativa para o modo tradicional de design com bloco de switches de distribuição é fazer com que os switches de acesso atuem em modo L3 (routed access). A camada de acesso para a distribuição tradicionalmente composta por switches operando em L2 é substituída por switches que operam em modo L3. Isso significa que a demarcação entre as camadas de L2/L3 é movida da distribuição para a camada de acesso. Neste cenário não há necessidade de uso de FHRP.

Nesse modelo, o switch de acesso atua como o default gateway e cada switch participa do domínio de roteamento. O roteamento, se configurado corretamente, oferece ótimos resultados de balanceamento de carga e tempos de convergência.

No design de layer 3, o default gateway e o root bridge para as VLANs é simplesmente movido da camada de distribuição para o switch de acesso. O endereçamento IP de todos os end points permanece o mesmo, assim como o default gateway. VLANs e as configurações de portas dos switches de acesso configurações de interface de roteamento, access-lists, ip helper e qualquer outra configuração para cada VLAN permanece a mesma, Entretanto, as interfaces SVI agora são definidas nos switches de acesso ao invés de serem configuradas nos switches de distribuição.

Designs comuns de interconexão entre acesso e distribuição

Vamos explorar alguns modelos de design de interconexão entre a camada de acesso e a camada de distribuição e vamos entender como cada uma funciona.

  • Design Layer 2 Loop: Utiliza switches em layer 2 na camada de acesso até a conexão com os switches de distribuição. Este modelo necessita do uso do STP para evitar loops na rede o que acaba por inutilizar um dos uplinks do acesso até a distribuição. Em uma situação de falha do uplink, o tempo de convergência irá depender de como o STP e o FHRP estarão configurados.
  • Design Layer 2 Loop Free: Utiliza switches em layer 2 no acesso e layer 3 na interconexão entre os switches de distribuição. Não oferece um cenário de loop de camada 2 entre os switches de acesso e distribuição. Neste modelo, o tempo de convergência em caso de falha de um dos links depende dos tempo de convergência do FHRP.
  • Design StackWise virtual: Neste modelo, com o uso do StackWise e etherchannel, o STP reconhece o caminho do switch de acesso ao distribuição como um único link lógico. O STP é somente utilizados nas portas de acesso em que os dispositivos de usuários serão conectados, a fim de evitar que um usuário crie algum loop na rede. Se um dos uplinks falhar, o encaminhamento do tráfego se dará sem maiores problemas e sem a necessidade de reconvergência da rede.
  • Design Layer 3 routed access: Utiliza roteamento na camada de acesso e distribuição (inclusive na interconexão entre os switches de distribuição). Não há necessidade de utilização de STP, com exceção do uso nas portas de acesso aonde os equipamentos dos clientes serão conectados. O tempo de reconvergência depende exclusivamente do tempo de convergência do protocolo de roteamento utilizado.

Comparação dos tempos de convergência entre rede layer 2 e layer 3

Esse talvez seja o aprimoramento mais significante quando comparamos os tempos de convergência entre uma rede com a camada de acesso operando em L2 e uma rede operando no modo routed access, com o acesso em L3. Em uma rede layer 2 tradicional, o tempo de convergência do STP pode variar entre 800-900 msec, comparado com o modelo routed access, esse tempo é reduzido para menos de 200msec.

Aqui vale destacar que cada ambiente terá suas particularidades, estes valores são apenas referências de comparação entre um modelo de design L2 e outro em L3 Os tempos de convergência não necessariamente serão esses.

Fonte: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/routed-ex.html#wp999019

Modelo de acesso em L2 ou L3, qual a melhor escolha?

Qual design é melhor levando-se em consideração tudo o que foi apresentado até então?

O resultado final de qual design escolher é uma decisão de projeto baseado em vários fatores, não é possível dizer qual modelo é melhor sem conhecer os requisitos do ambiente e as necessidades do cliente, qual o budget disponível e etc. Operar em uma rede no modelo routed access trás vantagens em relação ao tempo de convergência, porém a mesma trás desvantagens com relação ao nível de conhecimento técnico necessário para mantê-la.

Já uma rede tradicional operando em L2 em um primeiro momento pode ser mais fácil de gerenciar, mas a mesma apresenta um tempo de convergência maior, para se ter um tempo de convergência próximo aos da rede routed access são necessários vários ajustes no STP e nos tempos do FHRP.

Com isso encerro essa primeira parte dessa série de artigos sobre design Enterprise Campus LAN. Na segunda parte falaremos especificamente sobre o design em Layer 2 e na parte 3 falaremos sobre o design em Layer 3.

Bons estudos e até a próxima.

Troubleshooting em ambientes de redes, métodos para resolução de problemas

Neste artigo falaremos sobre alguns métodos de troubleshooting em ambientes de rede.

Se você não sabe para onde ir, qualquer caminho serve.

Lewis Carroll

O que a frase eternizada por Lewis Carroll tem em comum quando falamos de troubleshooting? Simples, se você não consegue entender a possível causa do problema, então, qualquer método para tentar soluciona-lo serve. Mas então, como elaborar um plano de ação que efetivamente funcione? É o que vamos discutir neste artigo.

Introdução

Antes de iniciarmos é importante frisar que não há um caminho certo ou errado para fazer troubleshooting, mas existe uma maneira mais eficiente e efetiva de condução que poderá lhe auxiliar durante o processo.

Durante nossa caminhada profissional vamos sempre aprendendo e desenvolvendo novas habilidades. Troubleshooting é uma delas, ao longo do tempo e com vivência em diversas situações, você irá lapidando essa importante habilidade, quanto mais situações desafiadoras você for encontrando, mais você elevará essa habilidade e como consequência sua confiança.

Forma estruturada de troubleshooting

Os problemas podem acontecer de diferentes formas, erros de configuração, atualizações de softwares, falha do hardware e etc. Independentemente do motivo da falha, podemos abordar o problema o dividindo em três simples passos.

  • Problema reportado: O processo tem o início quando alguém reporta o problema, informando que algo em seu ambiente não esta funcionando como esperado.
  • Diagnóstico: Essa é uma das fases mais importante, pois é aqui que você irá coletar as informações necessárias para tentar encontrar a causa do problema. Nessa etapa, podemos dividi-la em alguns passos adicionais:
    1. Coleta de Informações: Aqui são coletadas informações adicionais sobre o problema. Em muitas situações temos o usuário que simplesmente diz que algo não esta funcionando e não sabe repassar as informações de maneira mais precisa. Neste caso, conversar com outros usuários que estejam passando pelo mesmo problema pode ajudar a compreender um pouco mais do problema.
    2. Examinar as informações coletadas: De posse das informações coletadas é possível examinar o que esta ocorrendo no ambiente.
    3. Eliminar possíveis causas do problema: Baseado no conhecimento do ambiente e juntamente com as informações coletadas anteriormente é possível eliminar possíveis causas do problema. Aqui de fato começamos a “fazer um filtro” de onde esta a causa raiz do problema.
    4. Hipótese: Após eliminadas possíveis causas do problema, começamos a nos direcionar para o que consideramos ser o real motivo da falha.
    5. Verificar hipótese: Essa fase consiste em verificar as hipóteses levantadas no passo anterior a fim de validar se elas estão corretas ou não. Em caso negativo, voltamos à fase das hipóteses novamente.

A vantagem de se trabalhar de uma forma estruturada é que você não fica “testando as possibilidades” até encontrar o erro de forma aleatória, isso acabará por deixa-lo confuso e irá fazer com que você perca o foco no que realmente é o problema.

Lembre-se, na resolução de problemas você precisa ser eficiente, ser rápido é algo que virá com o tempo e experiência.

O diagrama abaixo apresenta de forma visual os passos descritos anteriormente, esse diagrama mostra a forma estruturada de troubleshooting que descrevemos até aqui.

Essa metodologia estruturada é ótima para quem ainda não possuí tanta experiência em troubleshooting, sendo um ponto de apoio a quem esta começando, ajudando a manter uma linha de raciocínio lógica durante todo o processo de análise e resolução do problema.

Com o passar do tempo, você se torna mais familiar com os cenários com os quais passa a trabalhar, adquire experiência e passa a observar que alguns problemas apresentam semelhanças na forma como originam e são solucionados, desta forma, aplicar a metodologia estruturada de troubleshooting passa a ser algo que pode lhe consumir bastante tempo, assim sendo, você pode adiantar algumas dessas etapas saindo a fase de diagnóstico e indo para a fase de hipóteses, como apresentado no diagrama abaixo.

Obs: Procure sempre documentar tudo o que ocorreu durante a análise e resolução dos problemas, informações relatadas pelos usuários, falhas que ocorreram no ambiente e principalmente, documente o que foi feito para sanar o problema, ao longo do tempo você terá criado uma base de conhecimento que servirá de apoio análises futuras.

Métodos populares de troubleshooting

Uma das fases mais importantes do método estruturado é a fase de eliminar as possíveis causas do problema e para isso existem algumas formas de abordagem que podem ser utilizadas, vamos conhece-las:

  • Método Top-down
  • Método botton-up
  • Método dividir para conquistar
  • Seguir o caminho do tráfego
  • Comparar configurações
  • Troca de componentes

Vamos ver como utilizar cada uma dessas abordagens.

Tenha em mente que não existe o melhor método a se aplicar, dependendo da situação que você esteja analisando, você poderá utilizar um ou vários métodos.

Neste ponto espero que você esteja bem familiarizado com o modelo OSI de 7 camadas, pois é a partir dele que iremos descrever alguns métodos.

Método Top-down

O método top-down começa a partir do topo da camada do modelo OSI, ou seja, partimos da camada 7 (camada de aplicação) e vamos descendo.

Esse método checa se a aplicação na qual você esta efetuando o troubleshooting esta funcionando, assumindo que, se a aplicação esta funcionando, todas as demais camadas abaixo dela também estão. Se você efetua um teste de ping (ICMP) entre uma máquina e o local aonde sua aplicação esta armazenada, você esta testando as camadas 1,2 e 3. Uma desvantagem deste método é que para efetuar os testes na camada de aplicação, você precisa efetivamente acessar a aplicação específica que esta passando por problemas para testar a camada 7.

Método Botton-up

O oposto do método top-down. Neste método iniciamos nossa análise a partir da camada 1 do modelo OSI e vamos subindo. Aqui testamos o cabeamento, conectores, se a porta ethernet no switch ou no computador esta funcionando, se temos algum problema de spanning-tree, se as vlans estão corretamente configuradas e aplicadas nas portas, features como port-security e etc. Vamos seguindo e subindo o modelo até chegarmos a camada de rede (layer 3) e testamos a conectividade IP, access-list, protocolos de roteamento e assim por diante.

Método dividir para conquistar

Se você não esta certo por onde começar sua análise, esse pode ser um bom ponto de partida.

Como o próprio nome sugere, aqui dividimos o ponto de partida de nossa análise, começamos da camada 3 e com um simples teste de conectividade IP podemos rapidamente identificar o método que iremos utilizar para análise. Se você efetua um teste de ping (ICMP) e o resultado falha, então você tem uma sinalização que algo entre as camadas de 1 a 3 não esta funcionando corretamente e o método botton-up pode ser aplicado a partir deste momento.

Seguir o caminho do tráfego

Um método muito útil, aqui você de fato irá seguir o caminho do tráfego da origem até o destino final. Se um usuário informa que não consegue acessar um determinado servidor ou uma aplicação, primeiro você passa a analisar a conectividade entre o computador do cliente com o switch de rede, se tudo estiver ok, você segue para o próximo passo que é testar a conectividade do switch com o roteador ou o firewall do ambiente e assim por diante até encontrar aonde o tráfego esta parando.

Comparar configurações

Imagine que você possua um ambiente com vários switches de rede espalhados pela empresa. Você observa que apenas um desses switches não esta operando corretamente como os demais, como esses switches compartilham de muitas configurações em comum, você decide comparar as configurações aplicadas em ambos os equipamentos a fim de identificar a possível causa do problema (a falta de alguma configuração, como uma VLAN, ACL e etc).

Aqui fica a observação que se você não sabe exatamente o que esta procurando, você pode acabar adicionando novos problemas ao ambiente por simplesmente copiar uma configuração de um equipamento em outro.

Troca de componentes

Esse método é quando você suspeita que há algo errado com o hardware em si e resolve efetuar uma troca dos componentes físicos e efetuar novos testes, como por exemplo, a troca de um cabo de rede ou até mesmo um switch, se após efetuar a troca você observar que o problema não mais existe, você pode concluir que o problema estava no componente em si.

Conclusões

Muito pode ser dito sobre troubleshooting. Conversar com outras pessoas e entender como cada um traça um plano de ação sempre que esta efetuando um troubleshooting pode lhe ajudar e criar suas próprias estratégias. Aqui procurei demonstrar a teoria por trás desse conceito. Agora cabe a você utiliza-lo da melhor forma possível em seu dia a dia.

Lembre-se, a experiência virá com o tempo então seja paciente pois a caminhada é longa. Procure ganhar experiência praticando em laboratórios replicando sempre que possível alguns cenários desafiadores. Entender a teoria de como as coisas funcionam é essencial, com isso em mente, procure estudar e entender como cada tecnologia funciona, como por exemplo, como o OSPF o EIGRP, o STP e tudo mais que esteja operando no ambiente deveria funcionar?

Ao final do dia de nada adianta a teoria sem a aplicação da prática, então procure praticar sempre que possível.

Com isso encerro mais esse artigo, até a próxima e bons estudos.