Controlador de LAN sem fio da CISCO e questão de design da AP


9

Existem algumas perguntas sobre a solução de design.

  1. O túnel CAPWAP é criado entre o controlador e os pontos de acesso. As extremidades do túnel são a interface "ap-management" do controlador e a interface de gerenciamento do ponto de acesso. Descobri que ter o AP e o Controller em diferentes domínios L2 é uma prática recomendada, mas em teoria isso parece ser uma solução melhor. Qual é correto?

  2. Uma das redes sem fio será o convidado WI-FI. Uma secretária criará atributos de acesso. É necessário criar uma interface adicional (na rede corporativa) no controlador e fornecer credenciais ao "Lobby Admin" para implementar esse esquema?


2
Parecem perguntas de lição de casa. Não estamos aqui para responder perguntas de trabalhos de casa, portanto, se este é um exemplo do mundo real, forneça mais detalhes do que você está tentando realizar.
YLearn

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:


4
  1. Colocar os APs e o controlador no mesmo domínio L2 é a solução mais simples, pois você não precisa fazer mais nada para que eles se encontrem. Se você colocar os pontos de acesso em uma sub-rede diferente, precisará configurar a opção 43 da DHCP na sub-rede de pontos de acesso ou inserir uma entrada DNS para cisco-capwap-controller.DOMAIN-APs-GET-FROM.DHC. Anteriormente, era o Cisco-lwapp-controller.

  2. Você precisará conceder ao secretário acesso de administrador ou de lobby ao WLC para que eles possam criar os logins. Ele não precisa de uma interface adicional para wifi de convidado, mas você pode usá-lo e conectá-lo à DMZ para melhor isolamento.

Edit: Corrigido o número da opção DHCP como @generalnetworkerror apontou minha memória defeituosa.


A opção 43 é para o DHCP especificar os WLCs para os APs realizarem uma junção quando em domínios L2 diferentes.
generalnetworkerror

3
  1. Os pontos de acesso e o controlador que estão na mesma sub-rede são bastante improváveis. Você provavelmente teria um controlador centralizado em algum lugar da sua organização e os APs seriam conectados às portas em diferentes armários IDF que abrangem várias sub-redes. Quando os APs inicializam, eles pegam o nome de domínio atribuído via DHCP e tentam resolver CISCO-CAPWAP-CONTROLLER.domainname.com ou CISCO-LWAP-CONTROLLER.domainname.com e encapsulam seus túneis CAPWAP ou LWAP lá. Ter a mesma VLAN L2 estendida em torno de seus múltiplos switches e troncos é perigoso para um ponto de acesso STP. Então, eu diria que ter APs e controladores no mesmo domínio L2 é uma prática ruim.
  2. A menos que você queira conceder à sua secretária acesso ao controlador - observe o uso do servidor Cisco Guest Access. http://www.cisco.com/en/US/products/ps10160/index.html

Isso permite que a secretária gere nomes de usuário e senhas para os hóspedes, além de enviá-las por e-mail (elas podem ler em seus smartphones e fazer login) e especificar o período de tempo em que a conta permanecerá conectada. Dessa forma, ninguém conhece o PSK ou o login genérico usando autenticação na web. Também é uma prática recomendada criptografar a rede wifi aberta / de convidado com uma senha simples para fornecer segurança ao usuário.


0
  1. Você poderia tentar manter os APs e a interface de gerenciamento do controlador no mesmo domínio L2, mas isso não causaria nada além de uma dor de cabeça. A arquitetura foi projetada para permitir APs plug-and-play em toda a sua rede, mesmo através dos limites L3. Os APs descobrirão os controladores através de várias maneiras diferentes. Usamos a descoberta de DNS. (Adicione um registro A para "CISCO-CAPWAP-CONTROLLER.yourdomain.com". Acredito que há outro registro A a adicionar, mas ele me escapa no momento)
  2. Não sei se entendo 100% dessa parte da pergunta. Parece que uma secretária definirá o PSK para os convidados. Nesse caso, eu recomendaria com certeza que você tenha uma interface diferente que não permita o acesso ao espaço de endereço da RFC 1918. Use um servidor DNS externo. Tudo o que resta é conceder à secretária acesso ao WLC para alterar o PSK do SSID.

O outro registro é provavelmente o CISCO-LWAPP-CONTROLLER. Foi usado para versões mais antigas (anteriores à 5.2), mas agora o que CISCO-CAPWAP-CONTROLLERvocê mencionou na sua resposta é suficiente.
pajaja

0

É possível ter WLC e APs na mesma sub-rede, mas improvável, pois é difícil gerenciar, especialmente em ambientes grandes ou quando você implanta novos pontos de acesso com freqüência. Da minha experiência: Em pequenos locais onde você tem de 10 a 20 APs e WLC no local, é mais fácil colocá-los na mesma VLAN. Em instalações maiores, nas quais você tem um (ou mais WLCs redundantes) centralizados e muitos APs (geograficamente) dispersos, fáceis de configurar e 'limpos', é usar o DNS para o processo de descoberta. Quando você tem redes mais complexas, devido a requisitos específicos ou talvez a um design ruim, você pode usar a opção 43 do DHCP (ou configuração estática).

Usar o registro DNS é uma solução simples para descobrir o controlador, especialmente se você possui apenas um em seu domínio ou não se importa com qual WLC o AP se juntará. Eu gosto de usar opções específicas do fornecedor DHCP para o processo de descoberta, pois é mais fácil do que configurar manualmente olwapp ap controller ip addressmas dá mais controle, especialmente quando você não pode usar domínios diferentes por algum motivo e deseja poder enviar IPs WLC diferentes para os APs. Você pode criar uma política baseada em escopo que tenha a opção 43 do DHCP com endereço IP do controlador para os VCIs (identificadores de classe de fornecedor) de seus pontos de acesso. O VCI é enviado na opção 60 pelo cliente DHCP durante a transmissão de descoberta DHCP inicial e é usado para identificar a classe específica de dispositivos (daí o nome). Para VCIs correspondentes, o DHCP enviará a opção 43 com 102 ou 241 opções que você configurará para manter os endereços IP de seus controladores (e outros clientes não os verão).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.