CISCO Wireless Lan Controller e domanda di progettazione dell'AP

Ci sono un paio di domande sulla soluzione di design.

1. Il tunnel CAPWAP viene creato tra il controller e i punti di accesso. Le estremità del tunnel sono l'interfaccia "ap-management" del controller e l'interfaccia di gestione dell'access point. Ho scoperto che avere AP e Controller in diversi domini L2 è la migliore pratica, ma in teoria sembra una soluzione migliore. Che è corretto?

2. Una delle reti wireless sarà l'ospite WI-FI. Un segretario creerà gli attributi di accesso. È necessario creare un'interfaccia aggiuntiva (nella rete aziendale) sul controller e fornire le credenziali a "Lobby Admin" per implementare tale schema?

1. Mettere gli AP e il controller nello stesso dominio L2 è la soluzione più semplice in quanto non è necessario fare altro per trovarsi l'un l'altro. Se si inseriscono gli AP su una sottorete diversa, è necessario configurare l'opzione DHCP 43 sulla sottorete degli AP o inserire una voce DNS per cisco-capwap-controller.DOMAIN-APs-GET-FROM.DHC. In precedenza questo era cisco-lwapp-controller.

2. Dovrai consentire al segretario o amministratore o lobby di accedere alla WLC in modo che possano creare gli accessi. Non ha bisogno di un'interfaccia aggiuntiva per il wifi ospite ma puoi usarne una e collegarla alla DMZ per un migliore isolamento.

Modifica: corretto il numero dell'opzione DHCP quando @generalnetworkerror ha indicato la mia memoria difettosa.

1. È improbabile che gli AP e il controller si trovino sulla stessa sottorete. Probabilmente avresti un controller centralizzato da qualche parte nella tua organizzazione e gli AP verrebbero collegati alle porte in diversi armadi IDF che si estendono su più sottoreti. All'avvio degli AP, prendono il nome di dominio assegnato tramite DHCP e provano a risolvere CISCO-CAPWAP-CONTROLLER.domainname.com o CISCO-LWAP-CONTROLLER.domainname.com e eseguono il tunneling dei loro tunnel CAPWAP o LWAP. Avere la stessa VLAN L2 distribuita su più switch e trunk è pericoloso da un punto di vista STP. Quindi direi che avere AP e controller nello stesso dominio L2 è una cattiva pratica.
2. A meno che tu non voglia dare alla tua segretaria l'accesso al controller, guarda usando il server Cisco Guest Access. http://www.cisco.com/en/US/products/ps10160/index.html

Ciò consente al segretario di generare nomi utente e password per gli ospiti, nonché di inviare loro via e-mail le informazioni (possono leggerle sul proprio smartphone e accedere) e specificare il periodo di tempo durante il quale l'account rimarrà connesso. In questo modo nessuno conosce il PSK o il login generico usando l'autenticazione web. È inoltre consigliabile crittografare la rete wifi aperta / ospite con una semplice password per garantire la sicurezza dell'utente.

1. Potresti tentare di mantenere gli AP e l'interfaccia di gestione del controller nello stesso dominio L2 ma non ti farebbe guadagnare altro che mal di testa. L'architettura è progettata per consentire agli AP plug-and-play in tutta la rete anche oltre i confini L3. Gli AP scopriranno i controller attraverso una manciata di modi diversi. Usiamo il rilevamento DNS. (Aggiungi un record A per "CISCO-CAPWAP-CONTROLLER.yourdomain.com". Credo che ci sia un altro record A da aggiungere, ma al momento mi sfugge)
2. Non sono sicuro di aver capito al 100% questa parte della domanda. Sembra che un segretario imposterà il PSK per gli ospiti. In questo caso, consiglierei sicuramente di avere un'interfaccia diversa che non consente l'accesso allo spazio degli indirizzi RFC 1918. Utilizzare un server DNS esterno. Quindi non resta che fornire alla segreteria l'accesso al WLC per modificare il PSK del SSID.

È possibile avere WLC e AP nella stessa sottorete, ma è improbabile poiché è difficile da gestire soprattutto in ambienti di grandi dimensioni o quando si distribuiscono frequentemente nuovi punti di accesso. Dalla mia esperienza: in piccole località in cui sono presenti 10-20 AP e WLC in loco, è più facile inserirli nella stessa VLAN. Nelle installazioni più grandi in cui si dispone di uno (o più ridondanti) WLC centralizzato e molti AP che sono (geograficamente) soluzioni sparse, facili da configurare e "pulite" è utilizzare il DNS per il processo di rilevamento. Quando si hanno reti più complesse, a causa di requisiti specifici o forse di cattiva progettazione, è possibile utilizzare l'opzione DHCP 43 (o la configurazione statica).

L'uso del record DNS è una soluzione semplice per scoprire il controller soprattutto se ne hai solo uno nel tuo dominio o non ti interessa a quale WLC aderirà l'AP. Mi piace utilizzare le opzioni specifiche del fornitore DHCP per il processo di individuazione poiché è più semplice quindi configurare manualmentelwapp ap controller ip addressma offre un maggiore controllo soprattutto quando non è possibile utilizzare domini diversi per qualche motivo e si desidera poter inviare IP WLC diversi agli AP. È possibile creare criteri basati sull'ambito con l'opzione DHCP 43 con indirizzo IP del controller per i VCI (identificatori di classe del fornitore) dei punti di accesso. VCI viene inviato nell'opzione 60 dal client DHCP durante la trasmissione di rilevamento DHCP iniziale e viene utilizzato per identificare la classe specifica di dispositivi (da cui il nome). Per i VCI abbinati, DHCP invierà l'opzione 43 con 102 o 241 opzioni che configurerai per contenere gli indirizzi IP dei tuoi controller (e altri client non li vedranno).