Network+ — Implementação de Rede: 75 questões

Step 1: Entender o que significa inter-VLAN routing — VLANs são domínios de broadcast separados; para permitir que hosts em VLANs diferentes comuniquem-se, é necessário um dispositivo de Camada 3 que faça encaminhamento (routing) entre as redes.

Step 2: Opções práticas — em ambientes empresariais você tem basicamente duas abordagens amplamente usadas: (a) usar um switch de camada 3 e criar SVIs (Switched Virtual Interfaces), uma SVI por VLAN que atua como gateway L3 para os hosts daquela VLAN, e habilitar o roteamento no switch (por exemplo 'ip routing'); (b) usar um roteador conectado via tronco 802.1Q ao switch e configurar subinterfaces no roteador (router-on-a-stick), cada subinterface com encapsulamento dot1q e um endereço IP para a respectiva VLAN.

Step 3: Implementação e validação — após criar SVIs ou subinterfaces, verifique tabelas de roteamento, ARP e conectividade entre hosts; aplique políticas ACL se for necessário controlar o tráfego entre VLANs. Trap: Uma armadilha comum é acreditar que apenas atribuir IPs em hosts permite comunicação entre VLANs — sem roteador ou SVI, as VLANs permanecem isoladas. Por que cada resposta errada falha: "Configurar NAT em cada SVI" — NAT traduz endereços entre redes, mas não é uma solução de roteamento entre VLANs e adiciona complexidade desnecessária; NAT não resolve o requisito de encaminhar pacotes entre redes internas e ainda pode quebrar serviços que requerem IPs originais. "Configurar apenas rotas estáticas nos hosts apontando para o mesmo gateway físico sem SVI" — isso pressupõe que exista um gateway L3 comum; se não houver uma interface L3 em cada VLAN (por exemplo, nenhum SVI e nenhum roteador com subinterfaces), as rotas estáticas nos hosts não funcionam, já que o tráfego de camada 2 não alcançará um roteador. As duas respostas corretas refletem as maneiras standard e compatíveis com equipamentos multilvL3 para fazer inter-VLAN routing numa rede corporativa.

Step 1: Como STP elege a root — O Spanning Tree Protocol elege a root bridge comparando bridge IDs que consistem em prioridade de bridge (bridge priority) e o MAC address. O menor valor de bridge ID vence. Ajustar a prioridade é a maneira direta e consistente de influenciar a eleição.

Step 2: Aplicando a mudança — Reduza a prioridade de bridge no switch que você deseja como raiz (por exemplo, configurar bridge priority para um valor menor) e então verifique a eleição com comandos de status STP (show spanning-tree). Isso fará com que o switch com menor prioridade seja eleito root e toda a topologia recalcule custos e portas designadas para otimizar caminhos a partir dessa raiz.

Step 3: Validação e impacto — Após definir a prioridade, monitore a convergência STP e verifique que os caminhos críticos ficaram com menor latência. Planeje janelas de manutenção se a mudança afetar portas que possam ser temporariamente bloqueadas até a reconvergência. Trap: Um equívoco comum é pensar que features como root guard ou ajuste de custos de porta forçarão a eleição do root — root guard impede que um switch se torne root, mas não força outro a ser root. Alterar custos pode influenciar as portas designadas, mas não substitui a regra principal de eleição baseada na bridge priority. Why each wrong answer fails: 1) Diminuir o custo do caminho em portas do switch desejado altera quais portas são designadas ou bloqueadas, mas não altera a eleição do root bridge porque a eleição é baseada primeiro no bridge ID; custos afetam seleção de caminhos relativos, não a escolha do root. 3) Habilitar root guard nas portas protege a topologia contra switches que tentam se tornar root inesperadamente, mas não garante que um switch específico seja a raiz; root guard é uma proteção reativa, não um meio de promoção de root. 4) Desabilitar STP em outros switches é perigoso e pode provocar loops de camada 2; além disso, a maioria dos switches modernos não permite simplesmente 'desabilitar STP' de forma segura e isso não é uma prática aceitável para eleger root. Portanto, reduzir a bridge priority no switch desejado é a técnica correta e segura para garantir que ele seja escolhido como root bridge.

Step 1: Compreender o comportamento do AP — quando um AP oferece múltiplos SSIDs, ele tipicamente marca frames de cada SSID com a VLAN apropriada (802.1Q tags) e envia tudo pelo uplink. A porta do switch ligada ao AP deve aceitar e transportar múltiplas VLANs; se estiver como access, somente uma VLAN será entregue, fazendo com que SSIDs sejam colocados incorretamente e clientes não obtenham o isolamento desejado.

Step 2: Configurar o trunk e a VLAN nativa — altere a porta do switch para modo trunk e permita as VLANs 20 e 30 no trunk. Isso assegura que frames tagueados de 'corporate' e 'guest' cheguem ao switch e sejam encaminhados corretamente. Além disso, definir a VLAN nativa do trunk para uma VLAN não utilizada (ou uma VLAN de gerenciamento isolada) previne que frames não tagueados (por exemplo, tráfego de gerenciamento do AP ou situações de compatibilidade) caiam na VLAN 1 padrão, evitando exposição indesejada de usuários às VLANs de produção.

Step 3: Validar com testes e logs — depois de configurar, teste associações em ambos os SSIDs e confirme que os clientes recebem endereços IP da sub-rede correta (VLAN 20 ou 30). Utilize show commands para verificar estado do trunk, VLANs permitidas e counters de trunking. Ajuste políticas de segurança (port security, DHCP snooping) conforme necessário. Trap: Um erro comum é pensar que basta habilitar portfast ou transformar a porta em access numa das VLANs; portfast acelera convergência STP para portas de usuário e não resolve necessidade de múltiplas VLANs. Outra armadilha é tentar usar múltiplos cabos físicos do AP para separar VLANs — a maioria dos APs modernos usa um único uplink com tags 802.1Q para múltiplos SSIDs. Why each wrong answer fails: - Configurar a porta do switch como trunk e permitir as VLANs 20 e 30 (Correta): Essencial para transportar múltiplos SSIDs mapeados a VLANs distintas; permite que o AP envie frames tagueados para cada SSID. - Mudar a porta do switch para access VLAN 20 e criar um segundo cabo para VLAN 30 (Errada): Raramente prático — a maioria dos APs possui um único uplink e não suporta efetivamente dividir VLANs por cabos físicos; além disso, requisitar dois cabos é ineficiente e aumenta complexidade de cabeamento. - Definir a VLAN nativa do trunk para uma VLAN não utilizada e manter VLANs 20 e 30 tagueadas (Correta): Ao escolher uma VLAN nativa não utilizada, você evita que tráfego não tagueado caia em VLANs de usuários (reduzindo risco e confusão), mantendo VLANs 20/30 como tagueadas para os SSIDs. - Habilitar spanning-tree portfast na porta do AP para acelerar a associação wireless (Errada): Portfast reduz o tempo de ativação do STP para portas que não participam do STP ativo, e pode acelerar o tempo de link, mas não resolve o problema de transporte de múltiplas VLANs; não substitui a necessidade de configurar a porta como trunk e permitir as VLANs apropriadas.

Step 1: Converter prefixos em capacidade de hosts. Calcule quantos bits de host cada prefixo fornece: /24 = 8 bits de host → 2^8 = 256 endereços (254 utilizáveis); /25 = 7 bits → 128 endereços (126 utilizáveis); /26 = 6 bits → 64 endereços (62 utilizáveis); /23 = 9 bits → 512 endereços (510 utilizáveis).

Step 2: Comparar com a necessidade de 200 hosts. O menor bloco que satisfaça >=200 hosts é o /24 (254 utilizáveis), pois /25 e /26 não alcançam 200.

Step 3: Selecionar o prefixo que atende e minimiza desperdício. Entre /23 (510 hosts utilizáveis) e /24 (254), o /24 é menor e portanto mais eficiente sem comprometer o requisito. Trap: Um erro comum é escolher o maior bloco por segurança (/23) para “dar folga”, mas isso pode levar a desperdício de endereços e complicar roteamento e políticas. Em redes corporativas, planejar o espaço de endereçamento com prefixos apropriados ajuda a evitar esgotamento e manter agregação. Por que cada resposta errada falha: - /25: fornece apenas 126 hosts utilizáveis, insuficiente para 200. - /26: fornece apenas 62 hosts utilizáveis, claramente insuficiente. - /23: fornece 510 hosts utilizáveis, o que atende o requisito, mas não é o menor prefixo que cumpre a necessidade; usar /23 quando /24 basta pode desperdiçar espaço de endereçamento e reduzir a granularidade de segmentação. Recomenda-se selecionar o menor prefixo que suporte a carga prevista, e considerar crescimento futuro ao documentar o plano de endereçamento.

Step 1: Entender como DHCP Snooping funciona — DHCP Snooping protege contra servidores DHCP não autorizados ao construir uma tabela de ligações de clientes e ao permitir apenas respostas DHCP vindas de portas marcadas como 'trusted' (confiáveis), tipicamente a porta que leva ao servidor DHCP ou ao roteador que faz relay.

Step 2: Sintomas e causas comuns — se usuários deixaram de obter endereços depois de habilitar DHCP Snooping, as causas mais frequentes são: a porta uplink para o servidor não foi configurada como trusted (portas não 'trusted' terão respostas DHCP (DHCPOFFER/DHCPACK) filtradas), ou o servidor está em outra VLAN/segmento sem que exista um DHCP relay configurado (ip helper-address no roteador), então os REQUESTs nunca alcançam o servidor.

Step 3: Como verificar e resolver — execute show ip dhcp snooping para verificar status, show ip dhcp snooping binding para ver se TTLs/entradas aparecem; verifique quais interfaces estão como trusted (ex: ip dhcp snooping trust em interfaces uplink); se servidor DHCP está em outra VLAN, configure ip helper-address no SVI/roteador ou posicione o servidor em uma rede alcançável; se necessário marque a interface do roteador/switch conectada ao servidor como trusted. Trap: Uma armadilha é pressupor que DHCP Snooping apenas registra e não impede tráfego — na verdade, quando configurado, ele descarta mensagens DHCP de servidores em portas 'untrusted', portanto é comum “quebrar” o serviço se o uplink ao DHCP não for explicitamente marcado como trusted. Por que cada alternativa falha ou é correta: - "A porta do switch conectada ao servidor DHCP não foi marcada como 'trusted' para DHCP snooping, então ofertas do servidor estão sendo descartadas": CORRETO — esta é a causa mais típica quando o DHCP funcionava antes e parou ao ativar DHCP Snooping. - "O DHCP Snooping limita o número de pedidos e os usuários ultrapassaram a taxa por porta configurada": INCORRETO como causa primária neste cenário, pois o DHCP snooping não aplica tipicamente rate-limit por default para bloquear pedidos legítimos; existem mecanismos de rate-limiting em switches, mas o sintoma geral após ativar DHCP Snooping costuma ser ofertas inadmissíveis devido a portas não-trusted, não uma taxa de pedidos excedida. - "O DHCP snooping exige que o banco de dados seync entre switches via protocolo proprietário e o banco não foi sincronizado": INCORRETO — embora existam recursos que possibilitam persistência de bindings e sincronização (por exemplo, DHCP snooping database), o problema descrito (todos os usuários de VLAN 30 sem IP) é mais tipicamente por falta de trusted uplink ou falta de relay; a falta de sync não costuma causar a total ausência de leases em apenas uma VLAN imediatamente após habilitação. - "O servidor DHCP está em outra VLAN e não há um relay (ip helper) configurado no roteador para encaminhar os requests": CORRETO — se o servidor estiver em outro segmento sem relay, os broadcasts DHCP não saem da VLAN de origem e nenhum lease será obtido. Resolução prática: marcar uplink/roteador como trusted, garantir existência de ip helper-address quando o servidor DHCP está em outra VLAN, e revisar a tabela de bindings para confirmar recebimento de ofertas.

Step 1: Objetivo e contexto — Em um ambiente corporativo, portas de switch que atendem usuários finais devem ser tratadas como pontos de controle: devem pertencer a uma VLAN específica (access) e ter mecanismos que impeçam dispositivos não autorizados de se conectar. Port-security é uma funcionalidade que limita o número de endereços MAC aprendidos e pode bloquear ou restringir a porta quando ocorre uma violação.

Step 2: Implementação prática — Configure a porta em modo access na VLAN apropriada, habilite port-security, defina o número máximo de endereços MAC permitidos (muitas vezes 1 para estações de trabalho) e escolha a ação de violação adequada (por exemplo, shutdown para maior segurança ou restrict para registrar e descartar). Opcionalmente, atribua MACs estáticos para portas críticas. Essas ações reduzem a superfície de ataque, evitam uso de hubs ou pontos de acesso não autorizados e ajudam a controlar movimentos laterais de dispositivos desconhecidos.

Step 3: Verificação e monitoramento — Depois de aplicar, monitore logs e status da porta (show port-security, show interfaces status). Teste removendo e conectando dispositivos para ver se as políticas são aplicadas. Trap: Uma armadilha comum é acreditar que funcionalidades como CDP/LLDP aumentam a segurança por si só — na verdade ajudam para inventário e detecção, mas não impedem acesso. Why each wrong answer fails: 1) Configurar a porta como trunk expõe múltiplas VLANs para o dispositivo conectado e aumenta risco: um usuário mal-intencionado poderia negociar VLANs adicionais e ter acesso indevido; trunks são adequados entre switches, não para portas de usuários finais. 3) Habilitar CDP/LLDP apenas fornece informações de vizinhança e pode até expor detalhes do equipamento; não impede um dispositivo não autorizado de obter conectividade. 4) Aumentar MTU não tem relação com controle de acesso ou prevenção de conexões não autorizadas; é uma configuração de camada de enlace para desempenho em casos específicos, não uma medida de segurança de porta. Portanto, a combinação de access mode e port-security é a resposta apropriada para limitar conectividade não autorizada em portas de usuário.

Step 1: Determinar os requisitos físicos e de distância. O cenário pede 10 Gbps a 85 metros dentro de uma sala de cabeamento; para links 10G, os limites e a imunidade a ruído/crosstalk determinam a escolha do meio.

Step 2: Mapear capacidades dos meios. Cat5e foi projetado para Gigabit em condições normais e não garante 10G a distâncias comerciais; Cat6 pode fornecer 10G mas somente em curtas distâncias (tipicamente até ~55 m sob condições ideais); Cat6a foi especificado para 10G até 100 m e melhora proteção contra alien crosstalk; a fibra multimodo (com transceptores 10G SFP+ e conectores LC) suporta 10G sem os mesmos limites de comprimento de cobre (dependendo do tipo OM2/OM3/OM4, por exemplo) e é comum em ambientes de distribuição e backbone.

Step 3: Selecionar soluções e implementar. Para 85 m, Cat6a cobre o requisito de 100 m para 10GBASE-T e é uma boa escolha quando se quer manter conectores RJ-45 e cabos de cobre. Alternativamente, fibra multimodo com conexões LC e transceptores 10G SFP+ é apropriada e frequentemente escolhida para reduzir interferência eletromagnética e diminuir peso do cabo em dutos. Ao instalar, verificar ventilação térmica dos patch panels, certificar com equipamento de teste para garantir desempenho, e escolher transceptores compatíveis com os módulos de switch. Trap: Uma armadilha comum é assumir que porque Cat6 funciona em distâncias curtas para 10G, ele também é adequado para qualquer link de sala de cabeamento. A especificação prática limita 10G sobre Cat6 a ~55 m em muitas implementações; portanto, para 85 m não é confiável. Why each wrong answer fails: - Cabo Cat5e com conectores RJ-45: Falha porque Cat5e não foi projetado para 10G em distâncias corporativas; mesmo quando alguns fabricantes relatam compatibilidade em laboratório, não é recomendado para ambientes empresariais e não atende o requisito de 85 m. - Cabo Cat6 com conectores RJ-45: Cat6 pode suportar 10G em curtas distâncias (até ~55 m) sob condições ótimas, mas a distância especificada é 85 m, acima do limite prático para 10G em Cat6, portanto não é uma escolha confiável para o cenário. - Cabo Cat6a com conectores RJ-45: Correto — Cat6a foi projetado para suportar 10GBASE-T até 100 m com melhor proteção contra alien crosstalk; mantém RJ-45 e é uma solução prática para infra-estrutura cobre. - Fibra multimodo com conectores LC: Correto — multimodo com transceptores 10G (SFP+) e conectores LC suporta 10G em distâncias típicas de campus/backbone e é frequentemente usado em links de backbone entre painéis, evitando limitações de cobre. Recomenda-se verificar o tipo de MMF (OM3/OM4) e transceptores para garantir distância e suporte de 10G.

Step 1: Avaliar requisitos de velocidade e distância — o enlace exige 10 Gbps sobre cobre a 90 metros em um ambiente empresarial com possível interferência eletromagnética (EMI). O padrão 10GBase-T tem limites físicos que variam conforme a categoria do cabo e o nível de ruído.

Step 2: Comparar capacidades dos cabos — Cat5e foi desenvolvido para 1 Gbps e não garante 10G em distâncias empresariais; Cat6 pode suportar 10G, porém, na prática, seu alcance para 10GBase-T cai para aproximadamente 35–55 metros dependendo do crosstalk e da EMI; Cat6a foi projetado para 10GBase-T até 100 metros e variantes blindadas (F/UTP ou S/FTP) reduzem a suscetibilidade a EMI; multimodo OM1 não é solução para 10GBase-T porque é fibra (mídia distinta) e exigiria transceptores de fibra, não 10GBase-T sobre cobre.

Step 3: Selecionar e justificar a solução — escolher Cat6a F/UTP atende a 10 Gbps até 100 m e, com blindagem, protege melhor contra EMI em ambientes empresariais, reduzindo erros e retrabalhos. Trap: Uma armadilha comum é acreditar que Cat6 sempre suporta 10G a 100 m; embora Cat6 possa funcionar a 10G em curtas distâncias, em instalações com ruído ou quando se usa conectores/terminações não ideais, sua capacidade de 10G a 90–100 m não é garantida. Por que cada resposta incorreta falha: - Cabo de par trançado Cat5e UTP: Cat5e suporta até gigabit com margem razoável, mas não é garantido para 10GBase-T a 90 metros; usar Cat5e leva a links instáveis ou incapacidade de atingir 10 Gbps. - Cabo de par trançado Cat6 UTP: Cat6 pode suportar 10GBase-T, mas tipicamente apenas até ~55 m em cenários com ruído; a distância de 90 m excede a capacidade prática de Cat6 para 10G em ambientes empresariais. - Cabo de fibra multimodo OM1: Fibra multimodo requer equipamentos e transceptores para fibra (10GBase-SR, por exemplo); OM1 é uma fibra antiga com limitações para 10 Gbps (alcance muito curto) e não resolve a necessidade de 10GBase-T sobre cobre; além disso, passar de cobre para fibra exigiria mudanças de porta e transceivers. Adicional: Ao especificar cabos em ambientes empresariais, considerar também requisitos futuros e PoE, bem como práticas de instalação (padrões TIA/EIA), testes pós-instalação com certificador de cabos e uso de blindagem adequada para reduzir problemas relacionados a EMI e NEXT.

Step 1: Determinar quantos endereços úteis cada máscara fornece — /26 dá 62 hosts úteis (64-2), /27 dá 30 hosts úteis, /28 dá 14 hosts úteis, /25 dá 126 hosts úteis. Comparar com as demandas: A precisa de até 60 hosts (necessário pelo menos 60), B até 25 (pelo menos 25), C até 12 (pelo menos 12).

Step 2: Avaliar cada opção quanto à capacidade e eficiência — opção 1: A com 192.168.50.0/26 -> 62 hosts (ok para 60), B com 192.168.50.64/27 -> 30 hosts (ok para 25), C com 192.168.50.96/28 -> 14 hosts (ok para 12). Todas as sub-redes cabem dentro do /24 e atendem as necessidades com uso eficiente. Opção 2: A com /25 -> 126 hosts (mais do que suficiente, porém utilizável se houver previsão de crescimento), B com 192.168.50.128/26 -> 62 hosts (suficiente para 25), C com 192.168.50.192/27 -> 30 hosts (suficiente para 12). Do ponto de vista estrito de capacidade, também atende, embora gere espaço mais 'gordo' (especialmente o /25).

Step 3: Escolher sub-redes balanceando capacidade e desperdício — em ambientes empresariais preferimos minimizar desperdício, mas também reservar espaço para crescimento; a opção 1 é mais eficiente, a opção 2 é viável se se antecipa crescimento. Trap: Um equívoco comum é confundir o número total de endereços com hosts utilizáveis — cada sub-rede perde 2 endereços reservados (network e broadcast). Por que cada resposta errada falha: Opção 3 (três /26) falha porque cada /26 tem 62 hosts; atribuir /26 para B e C é excessivo e desperdiça espaço — embora funcione, não é eficiente e o número de sub-redes planejadas pode extrapolar os limites do /24 dependendo da alocação; nesta questão quer-se eficiência. Opção 4 falha porque aloca /27 para A (30 hosts) que é insuficiente para Departamento A que precisa de até 60 hosts; portanto não atende o requisito mínimo. Observação final: Tanto a opção 1 quanto a 2 são tecnicamente válidas, mas a primeira é a alocação mais justa considerando requisitos mínimos; a segunda é aceitável se houver necessidade de margem de crescimento reservada.

Step 1: Revisar a configuração de port-security e os modos de violação. Port-security geralmente tem parâmetros: maximum (número máximo de endereços MAC permitidos), e violation mode (shutdown, restrict, protect). Em mode=shutdown, a ação ao detectar uma violação é colocar a porta em estado error-disabled instantaneamente.

Step 2: Quando um terceiro MAC aparece e o máximo permitido é 2, o switch verifica o modo de violação. No modo shutdown, o comportamento é explícito: gerar um log/alarme, incrementar contador de violações e desativar a porta, interrompendo todo o tráfego. A porta fica em erro e não encaminha pacotes até que um administrador a reabilite manualmente ou até que um timer de recuperação automática (se configurado) reinicie a porta.

Step 3: Entender efeitos operacionais e segurança. Esse comportamento evita que um dispositivo não autorizado acesse a rede através de um porto potencialmente inseguro; porém, também pode interromper usuários legítimos se dispositivos forem trocados sem notificação. Trap: Muitos pensam que 'descartar' ou 'ignorar' o novo MAC é padrão — isso é verdade somente no modo protect ou restrict, não no modo shutdown. Also confundir protect e restrict é comum: protect descarta frames dos MACs adicionais silenciosamente; restrict descarta e gera contador/alertas; shutdown desabilita a porta. Why each wrong answer fails: O switch ignorará o novo endereço MAC e permitirá apenas os dois primeiros, sem afetar a porta — incorreto para o modo shutdown; esse comportamento corresponde ao modo protect, não a shutdown. O switch descartará o tráfego do terceiro dispositivo mas continuará registrando violações sem desabilitar a porta — isso descreve o modo restrict (descarta e registra), mas a pergunta especifica que o modo é shutdown, portanto não se aplica. O switch mudará automaticamente o modo para permitir todos os MACs no porto — isso não ocorre; switches não alteram modos de segurança automaticamente para permitir mais dispositivos porque isso quebraria a política de segurança e não é comportamento padrão de port-security. Assim, a resposta correta é que a porta será colocada em estado error-disabled/shutdown, interrompendo o tráfego até intervenção ou recuperação configurada.

Step 1: Identificar a sintaxe padrão de configuração de rota em muitos roteadores de nível empresarial/educacional: a sintaxe clássica amplamente utilizada é 'ip route [network] [mask] [next-hop-address]'. Essa forma declara explicitamente a rede de destino, a máscara de rede e o próximo salto (next-hop) que o roteador deve usar para encaminhar pacotes para essa rede.

Step 2: Comparar as opções fornecidas com a sintaxe conhecida. A opção 'ip route 172.16.10.0 255.255.255.0 10.1.1.2' corresponde exatamente ao formato esperado. Outras linhas podem representar formas alternativas usadas por diferentes sistemas operacionais, mas a opção 1 é a sintaxe tradicional mais reconhecível e correta para esse contexto.

Step 3: Verificar interoperabilidade e plausibilidade. Uma rota estática precisa de rede, máscara e next-hop ou interface de saída. A opção correta fornece esses elementos; as demais podem ser sintaxes alternativas de outros sistemas ou formas incorretas. Trap: Assumir que qualquer linha que pareça semântica semelhante é válida. Sistemas operacionais de roteadores e firewalls têm variações de sintaxe; portanto copiar um comando sem verificar o contexto de IOS/CLI correto pode levar a erros operacionais. Why each wrong answer fails: route add 172.16.10.0/24 gateway 10.1.1.2 — essa é uma forma genérica que lembra sintaxe de sistemas operacionais host (por exemplo, alguns shells), mas não é a sintaxe clássica do CLI de roteadores que a questão solicita; além disso usa o termo 'gateway' em vez de next-hop formatado e o prefixo em /24, que embora legível, não corresponde ao estilo de configuração tradicional citado. router static 172.16.10.0 mask 255.255.255.0 next-hop 10.1.1.2 — essa opção é verossímil mas não é uma sintaxe real padronizada em roteadores comuns; mistura campos de forma mais descritiva e por isso é inválida como comando direto. set route 172.16.10.0 255.255.255.0 via 10.1.1.2 — essa forma pode existir em alguns sistemas de gerenciamento ou em sistemas baseados em políticas, mas não é a sintaxe clássica e direta mais utilizada em roteadores de configuração CLI tradicional. Dado o contexto didático e a sintaxe esperada, 'ip route 172.16.10.0 255.255.255.0 10.1.1.2' é a escolha correta.

Step 1: Como SSIDs e VLANs interagem — em redes corporativas, APs normalmente mapeiam SSIDs para VLANs e enviam esse tráfego ao switch por um trunk 802.1Q; o switch deve permitir as VLANs necessárias no trunk e o AP deve taggear corretamente os frames. Se houver atribuição dinâmica de VLAN via RADIUS (quando o servidor de autenticação retorna qual VLAN usar), o AP aplica essa VLAN ao usuário após autenticação.

Step 2: Diagnóstico dos sintomas — clientes recebendo IP da VLAN errada ou sem IP geralmente indicam que os frames não estão sendo transportados na VLAN esperada: isso pode ocorrer se a VLAN não está nas allowed VLANs do trunk, se o AP não está configurado como trunk, ou se o mecanismo de dynamic VLAN falhou e deixou o cliente na VLAN default.

Step 3: Verificações e correções — verifique show interfaces trunk / show interface switchport para confirmar se a VLAN do SSID está permitida; confirme no AP se o SSID está mapeado para a VLAN correta; se usar RADIUS para dynamic VLAN, verifique logs do servidor RADIUS e do AP para ver se o atributo de VLAN (VLAN assignment) foi retornado; ajuste allowed VLANs com switchport trunk allowed vlan add <vlan>. Trap: A armadilha é supor que um mismatch da VLAN nativa sempre causa esse problema — native VLAN mismatch afeta tráfego não taggeado e pode resultar em tráfego indo para VLAN errada, mas em ambiente de AP que taggea SSID normalmente o tráfego é taggeado, então a causa mais comum é allowed VLANs ou falha no mecanismo que determina a VLAN do usuário. Por que cada alternativa falha ou é correta: - "A lista de VLANs permitidas no trunk do switch não inclui a VLAN associada ao SSID problemático": CORRETO — se a VLAN do SSID não estiver na lista allowed do trunk, frames dessa VLAN serão filtrados e o cliente não obterá IP da VLAN correta (ou poderá cair na VLAN nativa). - "Mismatch da VLAN nativa entre o switch e o AP pode fazer com que tráfego taggeado seja interpretado como pertencente à VLAN errada": INCORRETO como causa primária neste caso quando o AP taggea frames; native VLAN mismatch afeta tráfego sem tag (untagged) — pode causar sintomas estranhos, mas se o AP está corretamente taggeando SSIDs, o mismatch da nativa não explica porque o SSID específico recebe a VLAN errada. - "O AP está configurado para taggear frames, mas o switch espera que o AP opere em modo access (sem trunk)": INCORRETO tipicamente — esse cenário resultaria em incompatibilidade óbvia (o AP enviando tags para uma porta access geralmente causa perda de conectividade, mas em implementações comuns APs são conectados via trunk; além disso, isso não explica por que alguns SSIDs funcionam e outro não a menos que haja configurações inconsistentes). - "A atribuição dinâmica de VLAN via RADIUS (dynamic VLAN assignment) falhou ou não está retornando a instrução de VLAN correta para a sessão": CORRETO — quando a autenticação 802.1X ou similar depende do RADIUS para definir a VLAN do usuário, uma falha no retorno do atributo VLAN deixa o cliente na VLAN default ou sem VLAN apropriada, resultando em IP errado ou falta de conectividade. Recomendações: verifique allowed VLANs no trunk, confirme configuração de SSID no AP, revise logs e atributos RADIUS para dynamic VLAN, e teste com um cliente que forcene manualmente a VLAN para isolar se o problema está no AP/switch ou no servidor RADIUS.