Para parceiros
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve diferentes cenários de configuração de mobilidade que cobrem topologias entre os Controladores de LAN Sem Fio (WLCs - Wireless LAN Controllers) do Catalyst 9800 e as WLCs do AireOS.
A Cisco recomenda que você tenha conhecimento destes tópicos:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Note:
1) Caso suas WLCs estejam em sub-redes diferentes, você precisa garantir que a porta UDP 16666 e 16667 estejam abertas entre elas.
2) Recomenda-se que as WLCs 9800 executem a mesma versão para que os clientes em roaming tenham uma experiência consistente em cenários de roaming de Camada 3 e ancoragem de convidados.
Este é um exemplo básico para configurar a mobilidade em dois controladores 9800. Isso é comumente usado para acesso de convidado (âncora), ou para permitir roaming de cliente entre controladores, para preservar a identidade do cliente.
Quando você configura a mobilidade no C9800, a primeira opção é o nome do grupo de mobilidade. O nome do grupo de mobilidade pré-preenchido é padrão, mas você pode personalizá-lo para um valor desejado. Lembre-se de que você deve configurar o mesmo nome de grupo de mobilidade entre os controladores, quando o roaming de camada 2 rápida como o Fast Transition (FT) ou o Cisco Centralized Key Management (CCKM) estiver em uso. Por padrão, o endereço MAC Ethernet base do chassi conforme visto em show version é refletido na GUI para o endereço MAC de mobilidade. Na CLI, por padrão, o MAC de mobilidade é 0000.0000.000, como visto em show run all | inc mobility mac-address No caso do 9800 emparelhado para SSO (Stateful Switchover) de alta disponibilidade (HA), se essa configuração for deixada no padrão e o mac do chassi for usado para formar um túnel de mobilidade, quando ocorrer failover, o chassi ativo e, portanto, o túnel de mobilidade será desativado. Portanto, é obrigatório que um MAC de mobilidade seja configurado para o par de HA do C9800.
Passo 1: Na GUI, navegue para Configuration > Wireless > Mobility > Global Configuration.
Através do CLI:
# config t # wireless mobility mac-address <AAAA.BBBB.CCCC>
# wireless mobility group name <mobility-group-name>
Para ambas as WLCs 9800, navegue para Configuração > Sem fio > Mobilidade > Configuração global e anote o seu Nome do Grupo de Mobilidade e o Endereço MAC de Mobilidade.
Através do CLI:
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652
Wireless Management IP Address: 172.16.51.88
Wireless Management IPv6 Address:
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: default
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility Multicast Ipv6 address: ::
Mobility MAC Address: 001e.e67e.75ff
Mobility Domain Identifier: 0x34ac
Navegue até Configuration > Wireless Mobility > Peer Configuration e preencha as informações do controlador de peer. Faça o mesmo para as WLCs 9800.
Através da GUI:
Através do CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <peer-ip-address> group <group-name> [ data-link-encryption ]
Note: Opcionalmente, você pode ativar a Criptografia de Enlace de Dados.
Esse cenário normalmente é feito para implantações de "brownfield" ou durante a migração do controlador, em que dividimos a rede em uma área de pontos de acesso controlados por um controlador AireOS e outra por 9800. É aconselhável que os APs sejam distribuídos entre controladores por áreas físicas ou de RF, de modo que os clientes façam roaming apenas entre controladores quando se moverem. Evite situações de saleiro e pimenta. Opcionalmente, essa topologia de mobilidade também pode ser usada para âncora de convidados, onde 9800 atua como estrangeira e um AireOS como controlador de âncora.
Como antes, se seus controladores 9800 estiverem em alta disponibilidade, certifique-se de ter configurado o endereço MAC de mobilidade.
Através da GUI:
Navegue até Configuration > Wireless > Mobility > Global Configuration e anote Mobility Group Name e Mobility MAC Address.
Através do CLI:
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652
Wireless Management IP Address: 172.16.51.88
Wireless Management IPv6 Address:
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: default
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility Multicast Ipv6 address: ::
Mobility MAC Address: 001e.e67e.75ff
Mobility Domain Identifier: 0x34ac
# show wireless management trustpoint
Trustpoint Name : Jay-9800_WLC_TP
Certificate Info : Available
Certificate Type : SSC
Certificate Hash : d7bde0898799dbfeffd4859108727d3372d3a63d
Private key Info : Available
FIPS suitability : Not Applicable
Através da GUI:
Navegue até CONTROLLER > Mobility Management > Mobility Groups > New.
Insira os valores e escolha Aplicar.
Note: O hash só é necessário se o 9800 usar um certificado autoassinado como o C9800-CL. Os dispositivos de hardware têm um certificado SUDI e não precisam de hash, por exemplo, um 9800-40, 9800-L, e assim por diante.
Através do CLI:
>config mobility group member add <9800 mac-address> <9800 WLC-IP> <group-name> encrypt enable
>config mobility group member hash <9800 WLC-IP> <9800 WLC-Hash>
>config mobility group member data-dtls <9800 mac-address> disable
Através da GUI:
Faça login na GUI do AireOS e navegue até CONTROLLER > Mobility Management > Mobility Groups e anote o endereço MAC, o endereço IP e o nome do grupo.
Através do CLI:
>show mobility summary Mobility Protocol Port........................... 16666 Default Mobility Domain.......................... TEST Multicast Mode .................................. Disabled Mobility Domain ID for 802.11r................... 0x6ef9 Mobility Keepalive Interval...................... 10 Mobility Keepalive Count......................... 3 Mobility Group Members Configured................ 2 Mobility Control Message DSCP Value.............. 48 Controllers configured in the Mobility Group MAC Address IP Address Group Name Multicast IP Status 08:96:ad:ac:3b:8f 10.88.173.72 TEST 0.0.0.0 Up
Através da GUI:
Navegue até Configuration > Wireless > Mobility > Peer Configuration > Add.
Insira as informações da WLC do AireOS.
Note: Na WLC 9800, a criptografia do plano de controle está sempre ativada, o que significa que você precisa ter a mobilidade segura habilitada no lado AireOS. Entretanto, a criptografia de enlace de dados é opcional. Se você ativá-lo no lado 9800, ative-o no AireOS com: config mobility group member data-dtls enable
Através do CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <ip-address> group <group-name>
Use esta seção para confirmar se a sua configuração funciona corretamente.
>show mobility summary Mobility Protocol Port........................... 16666 Default Mobility Domain.......................... TEST Multicast Mode .................................. Disabled Mobility Domain ID for 802.11r................... 0x6ef9 Mobility Keepalive Interval...................... 10 Mobility Keepalive Count......................... 3 Mobility Group Members Configured................ 2 Mobility Control Message DSCP Value.............. 48 Controllers configured in the Mobility Group MAC Address IP Address Group Name Multicast IP Status 00:1e:e6:7e:75:ff 172.16.51.88 default 0.0.0.0 Up 08:96:ad:ac:3b:8f 10.88.173.72 TEST 0.0.0.0 Up
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652 Wireless Management IP Address: 172.16.51.88 Mobility Control Message DSCP Value: 48 Mobility Keepalive Interval/Count: 10/3 Mobility Group Name: mb-kcg Mobility Multicast Ipv4 address: 0.0.0.0 Mobility Multicast Ipv6 address: :: Mobility MAC Address: 001e.e67e.75ff Controllers configured in the Mobility Domain: IP Public Ip Group Name Multicast IPv4 Multicast IPv6 Status PMTU ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 172.16.51.88 N/A default 0.0.0.0 :: N/A N/A 10.88.173.72 10.88.173.72 TEST 0.0.0.0 :: Up 1385
Esta seção disponibiliza informações para a solução de problemas de configuração. Para solucionar problemas da implementação do túnel de mobilidade, você pode usar estes comandos para depurar o processo:
Etapa 1. Ative as depurações de mobilidade.
debug mobility handoff enable debug mobility error enable debug mobility dtls error enable debug mobility dtls event enable debug mobility pmtu-discovery enable debug mobility config enable debug mobility directory enable
Etapa 2. Reproduza a configuração e verifique a saída
Exemplo de criação de um túnel de mobilidade bem-sucedida em uma WLC AirOS.
*capwapPingSocketTask: Feb 07 09:53:38.507: Client initiating connection on 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.507: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: Received DTLS packet from mobility peer 172.16.0.21 bytes: 48 *capwapPingSocketTask: Feb 07 09:53:38.508: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 48 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.508: Record : type=22, epoch=0, seq=0 *capwapPingSocketTask: Feb 07 09:53:38.508: Hndshk : type=3, len=23 seq=0, frag_off=0, frag_len=23 *capwapPingSocketTask: Feb 07 09:53:38.508: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 48 ! !<--output-omited--> ! *capwapPingSocketTask: Feb 07 09:53:38.511: dtls2_cert_verify_callback: Forcing Certificate validation as success *capwapPingSocketTask: Feb 07 09:53:38.511: Peer certificate verified. *capwapPingSocketTask: Feb 07 09:53:38.511: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.511: Nothing to send on link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.511: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 503 *capwapPingSocketTask: Feb 07 09:53:38.511: Received DTLS packet from mobility peer 172.16.0.21 bytes: 56 *capwapPingSocketTask: Feb 07 09:53:38.511: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 56 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.511: Record : type=22, epoch=0, seq=6 *capwapPingSocketTask: Feb 07 09:53:38.511: Hndshk : type=13, len=6 seq=3, frag_off=0, frag_len=6 *capwapPingSocketTask: Feb 07 09:53:38.523: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 56 *capwapPingSocketTask: Feb 07 09:53:38.527: Received DTLS packet from mobility peer 172.16.0.21 bytes: 91 *capwapPingSocketTask: Feb 07 09:53:38.527: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 91 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.527: Record : type=20, epoch=0, seq=8 *capwapPingSocketTask: Feb 07 09:53:38.527: Connection established for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.527: ciperspec 1 *capwapPingSocketTask: Feb 07 09:53:38.527: Nothing to send on link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.527: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 91 *mmMobility: Feb 07 09:53:38.527: DTLS Action Result message received *mmMobility: Feb 07 09:53:38.527: Key plumb succeeded *mmMobility: Feb 07 09:53:38.527: mm_dtls2_callback: Connection established with 172.16.0.21:16667 *mmMobility: Feb 07 09:53:38.527: mm_dtls2_db_status_up:895 Connections status up for entry 172.16.0.21:16667 *mmMobility: Feb 07 09:53:38.527: mm_dtls2_callback: DTLS Connection established with 172.16.0.21:16667, Sending update msg to mobility HB
Por padrão, os controladores 9800 registram continuamente as informações do processo, sem a necessidade de qualquer procedimento de depuração especial. Isso permite simplesmente conectar-se ao controlador e recuperar os registros associados a qualquer componente sem fio para fins de solução de problemas. Os registros podem durar dias, dependendo de quão ocupado está o controlador. Para simplificar a análise, você pode puxar os registros com um intervalo de tempo ou nos últimos X minutos, o tempo padrão é definido como 10 minutos e pode filtrar por endereços IP ou MAC.
Etapa 1. Verifique a hora atual do controlador para que você possa rastrear os registros no tempo até quando o problema ocorreu.
# show clock
Etapa 2. Colete os registros do controlador, caso haja alguma informação no nível do Cisco IOS que possa estar relacionada ao problema.
# show logging
Etapa 3. Colete os rastreamentos de nível de aviso sempre ativo para um endereço específico. Você pode usar o par de mobilidade IP ou MAC para filtrar.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Este comando gera registros durante os últimos 10 minutos, é possível ajustar desta vez com o comando show logging profile wireless last 1 hora filter mac AAAA.BBBB.CCCC para o arquivo bootflash:ra-AAAA.BBBB.CCCC.txt. Você pode exibir o conteúdo da sessão ou pode copiar o arquivo para um servidor TFTP externo.
# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt>
Se os registros sempre ativos não fornecerem informações suficientes para saber o que disparou qualquer problema durante a configuração dos túneis, você também poderá ativar depurações condicionais e capturar rastreamentos de rádio ativo (RA), o que lhe dará uma atividade de processo mais detalhada.
Etapa 1. Verifique se não há condições de depuração já habilitadas.
# show debugging IOSXE Conditional Debug Configs: Conditional Debug Global State: Stop IOSXE Packet Tracing Configs: Packet Infra debugs: Ip Address Port ------------------------------------------------------|----------
Se você vir alguma condição não relacionada ao endereço que deseja monitorar, desative-a.
Para remover um endereço específico:
# no debug platform condition feature wireless { mac <aaaa.bbbb.cccc> | ip <a.b.c.d> }
Para remover todas as condições (modo recomendado):
# clear platform condition all
Etapa 2. Adicione a condição de depuração para um endereço que você deseja monitorar.
# debug platform condition feature wireless ip <a.b.c.d>
Observação: se quiser monitorar mais de um par de mobilidade ao mesmo tempo, você pode fazer isso. Use o comando adebug platform condition feature wireless maccommand por endereço MAC.
Etapa 3. Faça com que a WLC 9800 inicie o monitoramento da atividade de endereço especificada.
# debug platform condition start
Note: A saída da atividade de mobilidade não é exibida, pois tudo é colocado em buffer internamente para ser coletado posteriormente.
Etapa 4. Reproduza o problema ou o comportamento que você deseja monitorar.
Etapa 5. Pare as depurações.
# debug platform condition stop
Etapa 6. Colete a saída da atividade de endereço.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Este comando gera registros durante os últimos 10 minutos, é possível ajustar desta vez com o comando show logging profile wireless last 1 hora filter mac AAAA.BBBB.CCCC para o arquivo bootflash:ra-AAAA.BBBB.CCCC.txt. Você pode copiar o arquivo FILENAME.txt para um servidor externo ou exibir a saída diretamente na tela.
Copie o arquivo para um servidor externo:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Exibir o conteúdo:
# more bootflash:ra-FILENAME.txt
Passo 7. Se você ainda não conseguir encontrar o motivo de uma falha, colete o nível interno de logs (você não precisa depurar o cliente novamente, você usa os logs que já estavam armazenados internamente, mas coleta uma maior variedade deles).
# show logging profile wireless internal filter ipv4 to-file bootflash:raInternal-AAAA.BBBB.CCCC.txt
Você pode copiar o arquivo FILENAME.txt para um servidor externo ou exibir a saída diretamente na tela.
Copie o arquivo para um servidor externo:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Exibir o conteúdo:
# more bootflash:ra-FILENAME.txt
Etapa 8. Remova as condições de depuração.
# clear platform condition all
Note: Certifique-se de sempre remover as condições de depuração após uma sessão de identificação e solução de problemas.
Exemplo de criação de um túnel de mobilidade bem-sucedida em uma WLC 9800.
2021/09/28 10:20:50.497612 {mobilityd_R0-0}{1}: [errmsg] [26516]: (info): %MM_NODE_LOG-6-MEMBER_ADDED: Adding Mobility member (IP: IP: 172.16.55.28: default)
2021/09/28 10:20:52.595483 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:20:52.595610 {mobilityd_R0-0}{1}: [mm-pmtu] [26516]: (debug): Peer IP: 172.16.55.28 PMTU size is 1385 and calculated additional header length is 148
2021/09/28 10:20:52.595628 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80578) to (ipv4: 172.16.55.28 )
2021/09/28 10:20:52.595686 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 1
2021/09/28 10:20:52.595694 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 1
2021/09/28 10:21:02.596500 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:21:02.596598 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 2
2021/09/28 10:21:02.598898 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 001e.e68c.5dff Received keepalive_data, sub type: 0 of XID (0) from (ipv4: 172.16.55.28 )
2021/09/28 10:21:12.597912 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:21:12.598009 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 Data link set state to UP (was DOWN)
2021/09/28 10:21:12.598361 {mobilityd_R0-0}{1}: [errmsg] [26516]: (note): %MM_NODE_LOG-5-KEEP_ALIVE: Mobility Data tunnel to peer IP: 172.16.55.28 changed state to UP
! !<--output-omited--> !
2021/09/28 10:21:22.604098 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.604099 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (info): DTLS client hello
2021/09/28 10:21:22.611477 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611555 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611608 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611679 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611933 {mobilityd_R0-0}{1}: [mm-dtls] [26516]: (note): Peer IP: 172.16.55.28 Port: 16666, Local IP: 172.16.51.88 Port: 16666 DTLS_SSC_HASH_VERIFY_CB: SSC hash validation success
2021/09/28 10:21:22.612163 {mobilityd_R0-0}{1}: [ewlc-dtls-sessmgr] [26516]: (info): Remote Host: 172.16.55.28[16666] Completed cert verification, status:CERT_VALIDATE_SUCCESS
! !<--output-omited--> !
2021/09/28 10:21:52.603200 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 Control link set state to UP (was DOWN)
2021/09/28 10:21:52.604109 {mobilityd_R0-0}{1}: [errmsg] [26516]: (note): %MM_NODE_LOG-5-KEEP_ALIVE: Mobility Control tunnel to peer IP: 172.16.55.28 changed state to UP
A maioria das vezes é muito útil para verificar pacotes trocados entre WLCs. É especialmente útil filtrar capturas com Access Control Lists (ACLs) para limitar o tráfego capturado. Este é um modelo de configuração para capturas incorporadas na CLI.
Etapa 1. Crie a ACL do filtro:
conf t
ip access-list extended <ACL_NAME>
10 permit ip host <WLC_IP_ADDR> host <PEER_WLC_IP_ADDR>
20 permit ip host <PEER_WLC_IP_ADDR>host <WLC_IP_ADDR>
end
Etapa 2. Defina os parâmetros de captura:
monitor capture <CAPTURE_NAME> access-list <ACL_NAME> buffer size 10 control-plane both interface <INTERFACE_NAME> both limit duration 300
Note: Selecione a interface de gerenciamento para o parâmetro INTERFACE_NAME
Etapa 3. Inicie a captura:
monitor capture <CAPTURE_NAME> start
Etapa 4. Parar a captura:
monitor capture <CAPTURE_NAME> stop
Etapa 5. Navegue até Troubleshooting > Packet Capture na GUI para coletar o arquivo de captura de pacote
Os próximos exemplos consistem em túneis formados entre 9800 WLCs.
A ativação de capturas de pacotes incorporados e sempre conectados fornece informações adicionais para a solução de problemas:
2021/09/28 09:54:22.490625 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80552) to (ipv4: 172.16.55.28 )
2021/09/28 09:54:22.490652 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 29
2021/09/28 09:54:22.490657 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 10
2021/09/28 09:54:32.491952 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 09:54:32.492127 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 30
As capturas de pacotes são úteis para confirmar o comportamento.
Observe que a depuração e a WLC mostram que não há resposta aos pings de controle ou dados. Um cenário comum é que a conectividade IP é permitida, mas as portas 16666 ou 16667 não têm permissão para se comunicar através da rede.
Nesse caso, confirmamos a conectividade de todas as portas entre WLCs, mas ainda assim percebemos que keepalives falharam.
A ativação de capturas de pacotes incorporados e sempre conectados fornece informações adicionais para a solução de problemas:
2021/09/28 11:34:22.927477 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 11:34:22.928025 {mobilityd_R0-0}{1}: [mm-pmtu] [26516]: (debug): Peer IP: 172.16.55.28 PMTU size is 1385 and calculated additional header length is 148
2021/09/28 11:34:22.928043 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80704) to (ipv4: 172.16.55.28 )
2021/09/28 11:34:22.928077 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 8
2021/09/28 11:34:22.928083 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 3
Os registros internos no peer 172.16.55.28 nos ajudam a confirmar a incompatibilidade de configuração
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [mm-keepalive] [27081]: (ERR): Peer IP: 172.16.51.88 Failed to validate endpoint: Invalid argument
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_NODE_LOG-3-PING_DROPPED: Drop data ping from IP: 172.16.51.88. Failed to validate endpoint
A incompatibilidade de configuração comum inclui: nome de grupo incorreto, incompatibilidade na Criptografia de Enlace de Dados e endereço MAC de Mobilidade incorreto.
Log de incompatibilidade de grupo:
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_INFRA_LOG-3-MSG_PROC_FAILED_GROUP_NAME_HASH: Pkt group name hash: 82FE070E6E9A37A543CEBED96DB0388F Peer group name hash: 3018E2A00F10176849AC824E0190AC86 Failed to validate endpoint. reason: Group name hash mismatch.
Log de incompatibilidade de endereço MAC:
2021/09/28 19:09:33.455 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_INFRA_LOG-3-MSG_PROC_FAILED_MAC_ADDR: Pkt MAC: 001e.e67e.75fa Peer MAC: 001e.e67e.75ff Failed to validate endpoint. reason: MAC address mismatch.
Esse tipo de problema está relacionado aos estabelecimentos de túnel DTLS entre WLCs. pode ser que o caminho de dados esteja ATIVADO, mas o caminho de controle permanece INativo.
A habilitação de capturas de pacotes incorporados e sempre conectados fornece informações adicionais para a solução de problemas:
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [mm-msg] [27081]: (ERR): Peer IP: 172.16.51.88 Port: 16666 DTLS_MSG: DTLS message process failed. Error: Invalid argument
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [errmsg] [27081]: (warn): %MM_NODE_LOG-4-DTLS_HANDSHAKE_FAIL: Mobility DTLS Ctrl handshake failed for 172.16.51.88 HB is down, need to re-initiate DTLS handshake
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [ewlc-capwapmsg-sess] [27081]: (ERR): Source IP:172.16.51.88[16666], DTLS message process failed. length:52
Use os comandos show wireless management trustpoint e show crypto pki trustpoints para verificar as informações do certificado.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
14-Sep-2021 |
Versão inicial |